Re: [Xenomai-help] too fast write to serialport?

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]

Eric Noulard wrote:
> 2007/9/14, Jan Kiszka <jan.kiszka@domain.hid>:
>> Eric Noulard wrote:
>>> 2007/9/13, Bachman Kharazmi <bahkha@domain.hid>:
>>>> Hi!
>>>> I try to print to serialport using rtdm according to: http://pastebin.ca/695418
>>>>
>>>> But if I don't have sleep(1) only "hello   " or similar is written to
>>>> the serialport.
>>>> But if I've sleep(1) "helloworld" is written every second as expected.
>>> I'm no xenomai expert but I think
>>> you shouldn't write to serial device in such a tight loop:
>>>
>>> while(counter <100){
>>>         rt_dev_write(fd, myString, strlen(myString));
>>>        printf("%d\n",counter);
>>>       // sleep(1);  WITHOUT THIS SLEEP helloworld is sent on serial once.
>>>      counter++;
>>> }
>> The _will_ work, but the problem is that pending bytes are dropped on
>> rt_dev_close + the shortcoming that there is no way to synchronise on
>> the buffer being flushed reliably.
> 
> I am not sure to fully understand that.
> Do you mean that the serial driver (you wrote) has currently no
> way to know if written bytes have been sent on the wire by the UART ?

That is true. The asynchronous transmitting of data was intentionally
installed, but I didn't consider to establish some interface to request
and/or synchronise on the output completion. Will think about this when
time permits.

> 
>> That's a shortcoming of the current
>> driver (+ the serial profile spec) I trapped in myself - as the
>> developer of this code. :(
> 
> Meaning it _could_ be done but it is not in current implementation?

Yeah, likely. One option I currently have in mind is to establish
something like RTSER_EVENT_TXDONE that is raised when he TX interrupt
fired and the software buffer is empty.

> 
>>> because you will certainly fills the send buffer without giving a chance
>>> to the drive to send more data than the one that fits in the buffer
>>> (this heavily depends wether if the device is opened in blocking
>>>  or non-blocking mode)
>> Nope, the problem here has nothing to do with the timeout or the
>> blocking mode. That write will block (given a timeout > 0 or infinite)
>> when the software buffer (4k) is full. That's not specific in the serial
>> profile, and that's bad.
> 
> Ok I see blocking / timeout feature is a "software" feature of the driver.
> 
> For some kind of "realtime" serial communication ones
> may need something like "synchronous" write, meaning
> driver write call should block or timeout if underlying HW is not
> able to send the provided data.

Yes, I agree, I just don't want to change the semantic of rtserial's
write service. Besides likely breaking existing apps, I don't see the
need for the change in the _common_ case. Most scenarios I saw so far
either used the real-time UART port just for reading (+ some
initialisation maybe) or they synchronised on the transmission by
waiting on a reply from the devices. The case that you just write was
yet not required, but it is a valid one. For that case, a patter of
"write to port" + "wait on TXDONE event" would be appropriate IMO.

> 
> I hope you'll excuse me to give such approximate  [wrong] answers.
> I was trying to help, may be I should check the source code
> before trying to answer.
> 
> Sorry about that.
> 

No need to excuse. This misunderstanding is surely not your fault, and
this whole thread nicely uncovered some weaknesses that need to be fixed.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]