[Lazarus] SdpoSerial Tx and Rx buffers?

[Paulo Costa]

On 14/02/2011 19:32, Bo Berglund wrote:

First one thing, your message subject is too broad:
Are we talking about the RX or thr TX buffer?
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...

> But in the serial comm projects I am used to components that are
> non-blocking, which means that a send method returns immediately even
> before all data have been sent. Then the data are handled by a thread
> maintained by the component internals (or Windows perhaps).
> The net effect is that the main application is not blocked and
> non-responsive while the transfer takes place.

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.

> In my case I am using SdpoSerial because it is included with
> FPC/Lazarus. I am sending a data block that potentially can be 1
> Mbytes in size over a channel operating at 38400 baud or slower.
> Theoretically this means a transfer time of 273 seconds (4.5 min) or
> more. My application must meanwhile give some feedback to the user
> that the transfer is happening and also how it is proceeding.
>
> 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.

> 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.

> 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...

Paulo Costa