On 02/17/2011 05:46 PM, Bo Berglund wrote:
At least in the embedded world UART:s have *both* a transmit and
receive FIFO.
Same with PCs. And AFAIK, the OS-driver adds a huge Fifo buffer in both
directions to allow for the quite latency userland software to work as
good as possible without
On Fri, 18 Feb 2011 09:11:14 +0100, Michael Schnell
mschn...@lumino.de wrote:
On 02/17/2011 05:46 PM, Bo Berglund wrote:
At least in the embedded world UART:s have *both* a transmit and
receive FIFO.
Same with PCs. And AFAIK, the OS-driver adds a huge Fifo buffer in both
directions to allow
Michael Schnell schrieb:
On 02/18/2011 03:14 AM, Hans-Peter Diettrich wrote:
Quite a bit. Applications don't have to care about such hardware details,
Yep and this is why user land software can't (and should not) detect the
point in time the data it issued towards the serial port actually
On 02/18/2011 12:37 PM, Hans-Peter Diettrich wrote:
It's perfectly sufficient when the software is informed that the next
data packet can be supplied for transmission.
IMHO the decent way for user land software is to use a timeout that is
_a_lot_ greater than the time the hardware needs to
On 02/18/2011 02:43 PM, Bo Berglund wrote:
I have to somehow adapt to this fact and add a buffer layer myself in
a thread that feeds data to the WriteData method.
That is why I suggested that the best way to go is porting the
appropriate parts of AsyncPro, that perfectly does this.
Some time
Hello Lazarus-List,
Friday, February 18, 2011, 12:37:53 PM, you wrote:
Both have FIFOs, in fact the FIFO was implemented for the transmitter
(sender) to achive a speed higher than 38400 bps and before the chip
goes out a receive FIFO was added also.
HPD Correction: the FIFO was implemented
Hello Lazarus-List,
Friday, February 18, 2011, 4:16:31 PM, you wrote:
MS BTW be warned: The necessary Event-mechanism (e.g
MS Apllication.QueuAsyncCall) does not work correctly with the current svn
MS Lazarus version and gtk2 (maybe it does work with the Windows and/or
MS the qt Widget Type)
On 02/18/2011 04:56 PM, José Mejuto wrote:
You can use Syncronize, the syncronized procedure raises the event in
your code.
Unfortunately, with these Widget sets, TThread.Synchronize does not
work, either :( (see FPC bug tracker)
Application.QueueAsyncCall is more suitable, as it
1) allows
On Fri, 18 Feb 2011 16:05:50 +0100, Michael Schnell
mschn...@lumino.de wrote:
On 02/18/2011 02:43 PM, Bo Berglund wrote:
I have to somehow adapt to this fact and add a buffer layer myself in
a thread that feeds data to the WriteData method.
That is why I suggested that the best way to go is
Hello Lazarus-List,
Thursday, February 17, 2011, 12:25:26 AM, you 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.
HPD I'm not sure, but IMO a FIFO for outgoing data is used at best in a
HPD
On Wed, 16 Feb 2011 10:53:32 +0100, Michael Schnell
mschn...@lumino.de wrote:
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
On 02/17/2011 12:58 PM, Bo Berglund wrote:
I might even let the thread create the SdpoSerial object so it is only
touched by the thread itself...
If you create an object in a thread that does not mean that it's code
will run in that thread.
But I don't know what would happen because the
On Wed, 16 Feb 2011 12:07:28 +0100, José Mejuto joshy...@gmail.com
wrote:
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
Hello Hans-Peter,
Thursday, February 17, 2011, 12:28:08 PM, you wrote:
the 16550A is interrupt driven and FIFO 16 bytes.
HPD And the FIFO resides in the receiver, the transmitter doesn't have a
HPD FIFO. At least it was so, 20 years ago...
Both have FIFOs, in fact the FIFO was implemented for
Hello Lazarus-List,
Thursday, February 17, 2011, 5:46:08 PM, you 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.
BB At least in the embedded world UART:s have *both* a transmit and
BB receive FIFO. You
José Mejuto schrieb:
Thanks for your FIFO research :-)
Right, I do not correctly write the idea. I was trying to say that the
FIFO in acts like a buffer that you can forget about it (until no
receive event/interrupt) is received, while in the send FIFO the OS
waits for a full
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
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,
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
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
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
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
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
On Wed, 16 Feb 2011 10:50:14 +0100, Michael Schnell
mschn...@lumino.de wrote:
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
José Mejuto schrieb:
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
On Tue, 15 Feb 2011 00:49:56 +, Paulo Costa p...@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
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
On Tue, 15 Feb 2011 00:49:56 +, Paulo Costa p...@fe.up.pt 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
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
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 bo.bergl...@gmail.com wrote:
From: Bo Berglund bo.bergl...@gmail.com
Subject: Re: [Lazarus] SdpoSerial Tx and Rx buffers?
To: lazarus
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
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
On Mon, 14 Feb 2011 11:29:06 +0100, Michael Schnell
mschn...@lumino.de 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.
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
On Mon, 14 Feb 2011 13:00:36 -0500, waldo kitty
wkitt...@windstream.net 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
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
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
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
38 matches
Mail list logo
