[Lazarus] SdpoSerial Tx and Rx buffers?

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[Lazarus] SdpoSerial Tx and Rx buffers?

Bo Berglund
In serial components I have used with Delphi before there was always a
property to set the buffer sizes (both Tx and Rx). But I cannot find a
way to do this with SdpoSerial.
Is it not needed (does SdpoSerial manage the buffers by itself) or
have I overlooked some property? I have not installed SdpoSerial in
Lazarus as a component since it is non-visual. I create it in code
instead.

I am wondering about this because I am now reaching the point in my
project where I have to send large data arrays (up to 1 Mbytes) and I
am not sure if I have to check the transmit buffer before I submit the
data to the SdpoSerial.

What will happen if I have not set any buffer size (so they are at
default values, whatever that is) and then use the method
  FComm.WriteData(cmd);
with cmd being a string containing 1 Mbytes of data?
(FComm is of course a TSdpoSerial instance)


Bo Berglund


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Michael Schnell
On 02/13/2011 11:15 PM, Bo Berglund wrote:
> In serial components I have used with Delphi before there was always a
> property to set the buffer sizes (both Tx and Rx). But I cannot find a
> way to do this with SdpoSerial.
Does SdpoSerial use buffers at all ? With AsyncPro, Buffers necessary to
convert the blocking System interface into the event driven AsyncPro
user API by doing the blocking system calls in threads. With the
receiver, the collected data needs to be buffered until the main thread
is available to handle it, With the sender, the data generated by the
main thread needs to be buffered until the system API unblocks the
interface it blocked to prevent overrun of the system buffers.

Without using threads the user just sees a blocking interface and no
buffers are necessary.

-Michael

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Michael Schnell
On 02/14/2011 11:29 AM, Michael Schnell wrote:
>
> Without using threads the user just sees a blocking interface and no
> buffers are necessary.
>
Don't do this in the main thread, otherwise the complete application hangs.

-Michael

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Bo Berglund
In reply to this post by Michael Schnell
On Mon, 14 Feb 2011 11:29:06 +0100, Michael Schnell
<[hidden email]> wrote:

>On 02/13/2011 11:15 PM, Bo Berglund wrote:
>> In serial components I have used with Delphi before there was always a
>> property to set the buffer sizes (both Tx and Rx). But I cannot find a
>> way to do this with SdpoSerial.
>Does SdpoSerial use buffers at all ? With AsyncPro, Buffers necessary to
>convert the blocking System interface into the event driven AsyncPro
>user API by doing the blocking system calls in threads. With the
>receiver, the collected data needs to be buffered until the main thread
>is available to handle it, With the sender, the data generated by the
>main thread needs to be buffered until the system API unblocks the
>interface it blocked to prevent overrun of the system buffers.
>
>Without using threads the user just sees a blocking interface and no
>buffers are necessary.

AFAICT SdpoSerial is a wrapper for the Synaser blocking serial
component to make it more "user friendly" by providing receive events
when data arrive.
And my question is really about the existence of buffers and in that
case how to adjust them?

I don't want to mess with the component files myself, they are way too
intricate, I just want to use the serial comm functions.
But I need to know if there will be loss of data if I use a write
command with a very big string argument and the communications buffers
are not big enough to store this string. What will happen?
- Loss of data?
- Reverting to blocking operations (ouch!)?

Of course I can test it by actually sending a large chunk of data, but
then I might use test data that are just a tad too short to reveal a
buffer problem. Better to know how it will react.

And another important thing should I not need to set a buffer size:
How can I know when the data I submitted to SdpoSerial has actually
left the serial port on to the wire? A TxBuffer.DataCount property or
similar would come in handy here if it existed....


Bo Berglund


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

wkitty42
On 2/14/2011 11:32, Bo Berglund wrote:
> AFAICT SdpoSerial is a wrapper for the Synaser blocking serial
> component to make it more "user friendly" by providing receive events
> when data arrive.
> And my question is really about the existence of buffers and in that
> case how to adjust them?

i don't know if this makes any difference but i'm trudging thru the synapse
library attempting to work with its mime coding stuff... in my travels thru the
documentation i note that synapse is synchronous instead of asynchronous (see:
http://www.ararat.cz/synapse/doku.php/about )... the third and fourth paragraphs
are important...

since the synapse library has synaser as one of its sub(?)libraries, i assume
that we're talking about the same library...

the reason i mention the above is because i'm not sure how it might affect what
you are attempting to do and if buffers are really needed... it has been a while
since i did any comm coding which, at that time, was done directly to the com
port or via a FOSSIL driver (which greatly alleviated and abstracted much)...

i hope this helps in some small way...

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Bo Berglund
On Mon, 14 Feb 2011 13:00:36 -0500, waldo kitty
<[hidden email]> wrote:

>On 2/14/2011 11:32, Bo Berglund wrote:
>> AFAICT SdpoSerial is a wrapper for the Synaser blocking serial
>> component to make it more "user friendly" by providing receive events
>> when data arrive.
>> And my question is really about the existence of buffers and in that
>> case how to adjust them?
>
>i don't know if this makes any difference but i'm trudging thru the synapse
>library attempting to work with its mime coding stuff... in my travels thru the
>documentation i note that synapse is synchronous instead of asynchronous (see:
>http://www.ararat.cz/synapse/doku.php/about )... the third and fourth paragraphs
>are important...
>
>since the synapse library has synaser as one of its sub(?)libraries, i assume
>that we're talking about the same library...
>
>the reason i mention the above is because i'm not sure how it might affect what
>you are attempting to do and if buffers are really needed... it has been a while
>since i did any comm coding which, at that time, was done directly to the com
>port or via a FOSSIL driver (which greatly alleviated and abstracted much)...
>
>i hope this helps in some small way...

Gosh, I did not know this....

For TCP/IP work I always use Indy, which is now also available and
maintained for freepascal.

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.

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

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

In a blocking design this wait loop would of course not have been
needed becaus ethe Write would not return until all data have been
written to the output.


Bo Berglund


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

José Mejuto
Hello Lazarus-List,

Monday, February 14, 2011, 8:32:37 PM, you wrote:

BB> While the transfer runs my program sits and waits for an ACK coming
BB> back from the other end after it has checked the checksum. That is a
BB> loop with Application.Processmessages, Sleep and a timeout...
BB> In a blocking design this wait loop would of course not have been
BB> needed becaus ethe Write would not return until all data have been
BB> written to the output.

So you can send in small chuncks (64 bytes) and give feedback every
250ms.

Or use a "send" thread.

--
Best regards,
 José


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Paulo Costa
In reply to this post by Bo Berglund
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

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Bo Berglund
On Tue, 15 Feb 2011 00:49:56 +0000, Paulo Costa <[hidden email]> 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
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [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 [hidden email] 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 <[hidden email]> wrote:
On Tue, 15 Feb 2011 00:49:56 +0000, Paulo Costa <[hidden email]> 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
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Bo Berglund
In reply to this post by Paulo Costa
On Tue, 15 Feb 2011 00:49:56 +0000, Paulo Costa <[hidden email]> wrote:

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

I just checked by setting up a transfer of 100.000 bytes at 38400
baud. With a breakpoint at the FComm.WriteData method I could time
this function using the step-over command. It returned in 30 s when
the packet was 100006 bytes long, an effective baudrate of 33300 baud.
So it really looks like the WriteData *is* blocking...

>For that, you must break your transmission in small block and use the
>completion of each transfer to signal the progress.

Sadly this seems to be the case...

I would have to send in chunks of 1500 bytes or so to get 2 progress
ticks per second. The application will probably be stone dead and
nonresponsive too, which is one of the things I really like to
*always* avoid.

What one would need to do to fix this is to put the SdpoSerial into a
thread and let the thread send data out from a buffer that can be
loaded by the main application. But then we have the problem of
transferring the Tx data into the thread environment in a threadsafe
way...

My project just grew. :-(


Bo Berglund


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Hans-Peter Diettrich
Bo Berglund schrieb:

> So it really looks like the WriteData *is* blocking...
>
>> For that, you must break your transmission in small block and use the
>> completion of each transfer to signal the progress.
>
> Sadly this seems to be the case...

Even if it were non-blocking, a block is required when you try to
overflow the output buffer.

DoDi


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

dennis martin
In reply to this post by Bo Berglund
may i suggest looking at elecomm for an ideal it's a old pascal serial library but would fit your needs

--- On Tue, 2/15/11, Bo Berglund <[hidden email]> wrote:

> From: Bo Berglund <[hidden email]>
> Subject: Re: [Lazarus] SdpoSerial Tx and Rx buffers?
> To: [hidden email]
> Date: Tuesday, February 15, 2011, 2:53 PM
> On Tue, 15 Feb 2011 00:49:56 +0000,
> Paulo Costa <[hidden email]>
> wrote:
>
> >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.
>
> I just checked by setting up a transfer of 100.000 bytes at
> 38400
> baud. With a breakpoint at the FComm.WriteData method I
> could time
> this function using the step-over command. It returned in
> 30 s when
> the packet was 100006 bytes long, an effective baudrate of
> 33300 baud.
> So it really looks like the WriteData *is* blocking...
>
> >For that, you must break your transmission in small
> block and use the
> >completion of each transfer to signal the progress.
>
> Sadly this seems to be the case...
>
> I would have to send in chunks of 1500 bytes or so to get 2
> progress
> ticks per second. The application will probably be stone
> dead and
> nonresponsive too, which is one of the things I really like
> to
> *always* avoid.
>
> What one would need to do to fix this is to put the
> SdpoSerial into a
> thread and let the thread send data out from a buffer that
> can be
> loaded by the main application. But then we have the
> problem of
> transferring the Tx data into the thread environment in a
> threadsafe
> way...
>
> My project just grew. :-(
>
>
> Bo Berglund
>
>
> --
> _______________________________________________
> Lazarus mailing list
> [hidden email]
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>


     

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Michael Schnell
In reply to this post by Bo Berglund
On 02/14/2011 08:32 PM, Bo Berglund wrote:
> That is a
> loop with Application.Processmessages, Sleep and a timeout...
Thus completely ignoring the event driven Object Pascal programming
paradigm.

Yak.

-Michael

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Michael Schnell
In reply to this post by Bo Berglund
On 02/14/2011 08:32 PM, Bo Berglund wrote:
>
> In a blocking design this wait loop would of course not have been
> needed becaus ethe Write would not return until all data have been
> written to the output.
But here the program's GUI stops working, as the software hangs in the
blocking read or write,

So IMHO, the only decent way to handle a serial interface is doing
blocking communications calls in threads and fire events in the main
thread (e.g. by Application.QueuAsyncCall (avoiding the "Windowish"
PostMessage() stuff ) ) .

And here, of course, you do need buffers to transfer data between the
main thread and the threads

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Michael Schnell
In reply to this post by Paulo Costa
On 02/15/2011 01:49 AM, Paulo Costa wrote:
>
> 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.
>
So I feel that SdpoSerial needs a buffer to hold the data read from the
interface until the main thread is inclined to bother. The size of this
buffer should somehow be configurable.

-Michael

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Michael Schnell
In reply to this post by Bo Berglund
On 02/15/2011 10:45 AM, Bo Berglund wrote:
> 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...
Regarding sending, there still is a FiFo (usually some 4..64  Bytes ) in
the serial hardware (hundreds or thousands of bytes) and a software Fifo
in the OS driver. So the software can't tell when something has left the
serial port. For such deeply embedded issues  the specifics of the
driver and hardware needs to be considered

-Michael

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

José Mejuto
Hello Lazarus-List,

Wednesday, February 16, 2011, 10:59:02 AM, you wrote:

MS> On 02/15/2011 10:45 AM, Bo Berglund wrote:
>> 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...
MS> Regarding sending, there still is a FiFo (usually some 4..64  Bytes ) in
MS> the serial hardware (hundreds or thousands of bytes) and a software Fifo
MS> in the OS driver. So the software can't tell when something has left the
MS> serial port. For such deeply embedded issues  the specifics of the
MS> driver and hardware needs to be considered

AFAIK the FIFO is in the receive, in sent the FIFOs are filled but
function does not return until the hardware sends the last byte.

--
Best regards,
 José


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

Michael Schnell
On 02/16/2011 12:07 PM, José Mejuto wrote:
> AFAIK the FIFO is in the receive, in sent the FIFOs are filled but
> function does not return until the hardware sends the last byte.
If this is true somewhere, it is not portable.

-Michael

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] SdpoSerial Tx and Rx buffers?

José Mejuto
Hello Lazarus-List,

Wednesday, February 16, 2011, 1:26:38 PM, you wrote:

MS> On 02/16/2011 12:07 PM, José Mejuto wrote:
>> AFAIK the FIFO is in the receive, in sent the FIFOs are filled but
>> function does not return until the hardware sends the last byte.
MS> If this is true somewhere, it is not portable.

Glups! What ?

MSDN about RS232: Nonoverlapped I/O is familiar to most developers
because this is the traditional form of I/O, where an operation is
requested and is assumed to be complete when the function returns.

In non-overlapped mode, block mode, or whichever you like to call it,
the program sends, in example, 100 bytes to rs-232, the operative
system sends 16 of them to the UART, when FIFO bytes has been sent the
UART generates an interrupt to tell to the OS to refill the FIFO
buffer. This procedure is repeated several times, when no more data is
pending in the OS buffers to be sent, the OS waits for the interrupt
or timeout interrupt, and when the transmission buffer is empty
(interrupt received) the OS exits the send function. FIFO in
transmission alleviate the overhead in interrupts 16:1.

The problem is in the timeout case as you will not know at which byte
the transmission timedout as the FIFO can only be asked about empty or
not.

Non blocking is pretty the same at the OS level, except that the send
function returns inmediatly and you have some helper functions to
inquiry the current transmission status/state/progress.

--
Best regards,
 José


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
123