Eric Noulard wrote: > 2007/9/14, Jan Kiszka <[EMAIL PROTECTED]>: >> Eric Noulard wrote: >>> 2007/9/13, Bachman Kharazmi <[EMAIL PROTECTED]>: >>>> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
