We have two product lines that have been made for several years with custom hardware and proprietary RTOS. We decided to migrate these to COTS hardware and Linux. Conventional wisdom, right? The other line migrated first. There was pain, but not unbearable. We used RTLinux because we needed something that could sample the A/D card at predictable intervals and it was what was available at the time. I recently embarked on the conversion of my line and ran into a big problem. My A/D card controls the timing, so I shouldn't need and RTOS. I have a serial stream of 20 byte packets at 60 hz, but Linux should handle that, right? Well, if I had Mot serial chips that did hardware handshake, it would be OK, but COTS hardware has 16550s which require and interrupt to drop the handshake line(s). If Linux it too busy to service an interrupt for a full receive fifo, how is it going to handle the handshake? It can't. So I was dropping bytes every so often. Linux didn't have to mask the interrupt for long, just a fifo full at 38400. So it wsa RTOS time. I picked Xenomai this time primarily because of the patent issues, but it has a serial driver also. I am not sorry. Yeah, there was some pain with the pipes, but it is working slick now. The serial task is only using 0.1% of a relatively slow CPU. I like the status in/proc. I like the level of support here. Most of all, I like the quality of Xenomai. Fantastic job all who are involved in Xenomai, and a heartfelt thanks. |
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
