[Lazarus] SdpoSerial Tx and Rx buffers?

[Bo Berglund]

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