[Xenomai-help] too fast write to serialport?

[Xenomai-help] too fast write to serialport?

[Bachman Kharazmi]

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.

Is this some kind of limit how quickly I can write stuff on the rtser0?
How do I handle this?

/Bachman

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

[Eric Noulard]

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++;
}

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)

FIRST of ALL you should check the return value of your function call

rt_dev_write should return either the number of written bytes
http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__userapi.html#ge966625748b547779bb8c5385e7fb2aa

or a negative error code:
http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__rtserial.html


> Is this some kind of limit how quickly I can write stuff on the rtser0?

Yes there must be.
Serial device are not as fast as any recent CPU.
Beginning with the fact that you did configure the serial link at 115200 bauds
it would'nt wise to try to feed at an "average" speed that exceed this number.


> How do I handle this?

Check the return value of your rt_dev_write calls :)


-- 
Erk

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

[Bachman Kharazmi]

while(counter<100){
	sem.take()
size = rt_dev_write(fd, myString, strlen(myString));
        sem.give()
        if(size<0){
	printf(MAIN_PREFIX "3 : error %s (write), %s\n", WRITE_FILE, strerror(-size));
	return size;
	}	
	printf("%d\n",counter);
usleep(100000);  //sleep a few millis
counter++;
}
There should be solutions to with a flag or similar which can tell
when rt_dev_write() actually is finished. Until then wait()/sleep()
would probabily be the best solution.

Are there suitable solutions where no polling is made and make me wait
until the data have been written out to rtser0?
/Bachman
On 13/09/2007, Eric Noulard <eric.noulard@domain.hid> 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++;
> }
>
> 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)
>
> FIRST of ALL you should check the return value of your function call
>
> rt_dev_write should return either the number of written bytes
> http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__userapi.html#ge966625748b547779bb8c5385e7fb2aa
>
> or a negative error code:
> http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__rtserial.html
>
>
> > Is this some kind of limit how quickly I can write stuff on the rtser0?
>
> Yes there must be.
> Serial device are not as fast as any recent CPU.
> Beginning with the fact that you did configure the serial link at 115200 bauds
> it would'nt wise to try to feed at an "average" speed that exceed this number.
>
>
> > How do I handle this?
>
> Check the return value of your rt_dev_write calls :)
>
>
> --
> Erk
>

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

[Eric Noulard]

2007/9/13, Bachman Kharazmi <bahkha@domain.hid>:
> while(counter<100){
>         sem.take()
> size = rt_dev_write(fd, myString, strlen(myString));
>         sem.give()
>         if(size<0){
>         printf(MAIN_PREFIX "3 : error %s (write), %s\n", WRITE_FILE, strerror(-size));
>         return size;
>         }
>         printf("%d\n",counter);
> usleep(100000);  //sleep a few millis
> counter++;
> }
> There should be solutions to with a flag or similar which can tell
> when rt_dev_write() actually is finished. Until then wait()/sleep()
> would probabily be the best solution.
>
> Are there suitable solutions where no polling is made and make me wait
> until the data have been written out to rtser0?

You want a blocking semantic.
It seems that the rt_serial config structure contains
some send timeout value.

http://www.xenomai.org/documentation/branches/v2.3.x/html/api/structrtser__config.html

which "may" be used for that purpose.

I am no xenomai rt serial expert I cannot answer precisely
about the usage of those parameters
and/or how to configure rtserial in blocking mode.

The fact is usually in realtime task you don't want to block...
So fixing an appropriate timeout for sending is usually
the user jobs since this is the only one which knows his
RT constraint.

-- 
Erk

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

[Jan Kiszka]

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

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. That's a shortcoming of the current
driver (+ the serial profile spec) I trapped in myself - as the
developer of this code. :(

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

> 
> FIRST of ALL you should check the return value of your function call
> 
> rt_dev_write should return either the number of written bytes
> http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__userapi.html#ge966625748b547779bb8c5385e7fb2aa
> 
> or a negative error code:
> http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__rtserial.html
> 
> 
>> Is this some kind of limit how quickly I can write stuff on the rtser0?
> 
> Yes there must be.
> Serial device are not as fast as any recent CPU.
> Beginning with the fact that you did configure the serial link at 115200 bauds
> it would'nt wise to try to feed at an "average" speed that exceed this number.
> 
> 
>> How do I handle this?
> 
> Check the return value of your rt_dev_write calls :)
> 

Won't help here as I explained above. Still, my beer-ware was lacking
return code checks, and that is never recommendable for real code.

Jan


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

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

[Eric Noulard]

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'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?

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

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.

-- 
Erk

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

[Jan Kiszka]

[-- 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 --]

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

[Anders Blomdell]

Jan Kiszka wrote:
>> 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.
One way would be to implement ioctl for setting TxBufffer size, then 
with proper coding, TxBufSize = 0 would (analogous to 0 size FIFO) imply 
rendezvous semantics.

Just my 5 cents

Regards

Anders Blomdell

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

[Eric Noulard]

2007/9/14, Jan Kiszka <jan.kiszka@domain.hid>:
> >
> > 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.

May be you may mimic the POSIX termios API (cf man termios(3))
which would be "write to fd" then "tcdrain" it.
This is just the same behavior you described with a known API.

May be such API (tcdrain) only deserve to be in userland
or the serial device profile may be updated to include
feature inspired from termios.
May be another RTSER_RTIOC_DRAIN
which may be the same
as RTSER_RTIOC_WAIT_EVENT on TXDONE.

Talking about this I don't really know who (driver, kernel, libc)
is doing what (write,ioctl, ...) when I use the termios API
on a "classical" linux serial device.

However I thought termios might be inspiring for RTDM serial device profile.
-- 
Erk