[Lazarus] SdpoSerial Tx and Rx buffers?

[Thomas Gatliff]

Sorry in advance for piping in so late in the discussion...

Windows and Linux serial implementations are very different in design from a
buffering standpoint.   In simple terms, the windows serial was a
afterthought whereby serialtty in linux is as simple as reading and writing.
  No controls can be expected to be near flawless to seamlessly work between
these platforms.

To keep it short... As long as you are not doing visual work (qt,gtk,etc),
cross compiling with fpc is very well built.  I have a Ubuntu 10.10 virtual
machine (vmware) I use for (i386/arm9) linux cross compiling that you can
use if you want it.  Its out of the box functionality.  Just send an email
to tgatliff at gatliff.com if you want a copy of it.   I am currently having
issues getting the qt sdk (4.6.3) interfacing, and would smile greatly for
anyone who would want to join efforts to solve the problems.  Otherwise, I
will just keep working away at it...

On Tue, Feb 15, 2011 at 4:45 AM, Bo Berglund <bo.berglund at gmail.com> wrote:

> On Tue, 15 Feb 2011 00:49:56 +0000, Paulo Costa <paco at fe.up.pt> wrote:
>
> >On 14/02/2011 19:32, Bo Berglund wrote:
> >
> >First one thing, your message subject is too broad:
> Sorry about that, I just meant to ask about the way the Tx and Rx
> buffers are handled since I did not find any property for them to be
> set...
>
> >Are we talking about the RX or thr TX buffer?
> Both really.
>
> >Then, are we talking about the component, the library or the OS buffers?
> >And then are we talking about Windows 32, 64 bits or Linux?
> >It is hard to answer for all cases...
> I have turned to FPC/Lazarus because I need the software to be
> portable between Windows, Linux and embedded Linux on ARM. I had the
> impression that I did not have to bother with the distinctions you are
> making (write once compile everywhere...).
>
> >Synaser is blocking both for writing and reading.
> >The SdpoSerial component creates a thread to listen and generates an
> >event when bytes are received. So reading can be non-blocking.
> >The write methods are direct calls to the Synaser ones and they are
> >blocking.
>
> Does that mean that until all of the bytes have left the serial port
> the Write does not return to my program? This is exactly why I asked
> about the buffers...
>
> >> So I need to know in the case of SdpoSerial that it is possible
> >> without data loss to write a string of 1 Mbytes size.
> >
> >In a blocking way (the function will only return when most of the bytes
> >are already sent), all bytes will be transmitted.
>
> What does "most" mean? And do you mean when they have actually left
> the UART on to the RS232 wires?
>
> >> I also need to know how I can examine the progress of the transfer so
> >> I can control a progress bar or similar on screen while the transfer
> >> is running.
> >
> >For that, you must break your transmission in small block and use the
> >completion of each transfer to signal the progress.
>
> Are you really sure that the Write in SdpoSerial is blocking? So there
> are no internal transmit buffers that receive the data and then the
> call returns and the work is done by a transmit thread????
>
> >> While the transfer runs my program sits and waits for an ACK coming
> >> back from the other end after it has checked the checksum. That is a
> >> loop with Application.Processmessages, Sleep and a timeout...
> >
> >I don't know if that is an option but I would break such big
> >transmission in smaller packets each one with its own checksum...
>
> I can do that for the general memory transfer function because it is
> defined such that the sender defines what address range is to be sent.
> But it will add handshaking overhead to the transfer.
>
> The instrument protocol for this is as follows:
> Memory transfer:
> Tx: <command byte><destination address><number of bytes>
> Rx: ACK (if the instrument can receive the data, NAK otherwise
> Tx: <length of data><binary data><checksum>
> Rx: ACK if all bytes received and checksum is OK, NAK otherwise
> (Of course if not all bytes according to the length are send the
> instrument waits forever for the remaining data so there will be no
> NAK in this case).
>
> But file transfers are different, they can only be transferred
> complete.
> And I cannot change the protocol...
>
>
> --
> Bo Berglund
> Developer in Sweden
>
>
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110215/e49ae19d/attachment-0003.html>