Hello Cédric Sorry, but I had to give up my ambitions due to time pressure. I ended up using the standard UART drivers in the Debian environment. If you are in the same application situation as me, you may consider using standard Linux drivers:
I am implementing a sensor platform where the sensors each issues hardware interrupts that marks the time of measurement. Sensors are: GPS (1Hz), Barometer (1Hz), Gyro-/Accelero-/Magneto-meter (4Hz-8KHz), Inertial platform (200Hz), SwarmRadio (10Hz?). UART: GPS + SwarmRadio I2C: Barometer + Gyro-/Accelero-/Magneto-meter IMU: SPI After each GPIO interrupt the data is collected by UART, I2C and SPI. The most important rea-time task is to relate the hardware interrupts (i.e. the collected data) to a common timer. I managed to do that by writing kernel RTDMs for the interrupting GPIO-lines. The sensor tasks issues blocking reads towards the RTDMs that sends the timer-value from the interrupts. The tasks then uses the standard Linux drivers for collecting data. So far, the only driver causing marginal situations is the SPI driver in combination with an Inertial Measuring Unit (IMU). This sensor operates on 200Hz, hence I have to collect its data within 5ms. The IMU uses 16-bit transfers, but require the chip-select to go in-active for at least 2us between each transfer. This cannot be handled by the standard SPI driver an forces me to generate separate 16-bit transfer calls to the driver. Each call gives a 20-30us kernel/user-space punishment and a very jittering total transfer-time. Bottom line (for me) is that I have to cope with the standard Linux drivers for the time being. I am now running tests on all interfaces and the only sensors that misses interrupts is the SPI-bus. I am not sure how degrading these standard drivers is for my real-time requirement, but I hope to reveal this by some long-term testing. At the moment I am part of the "under-wood" and must rely on the patient support from the "tall trees" (Gilles and Robert). If time allows later on, I will look into the possibilities of doing some work on the drivers. First driver to get my attention will be the SPI driver... Bon chance! Best regards Terje From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Cédric Sent: 4. desember 2014 16:52 To: beagleboard@googlegroups.com Subject: Re: [beagleboard] xeno_16550A driver install on Debian 3.8.13-bone67 Dear Terje, Did you find how to use the 8250 driver with * .dts? Pour utiliser le pilote 8250, vous aurez aussi besoin de modifier le fichier * .dts. Le mercredi 12 novembre 2014 18:32:11 UTC+1, Terje Froysa a écrit : Thanks Robert, for taking your time to enlight a newbie. The fog is slowly lifting.... Regards Terje On Wednesday, November 12, 2014 6:01:52 PM UTC+1, RobertCNelson wrote: On Wed, Nov 12, 2014 at 10:50 AM, Terje Froysa <terje....@sintef.no<mailto:terje....@sintef.no>> wrote: > Robert, > just for my curiosity and pease of mind: > > If the 8250 have been "no mainline" for several years and there are no > dtbo's to enable it. > Why is the ttySx still there and the 8250 by default enabled in the -bone67 > ? The history goes like this.. Back in the "board" era, omap used the 8250 driver, then "new" non-generic features where added enabling omap features, thus making the "omap-serial" driver. Then came device tree's.. First the omap-serial driver got it's dts bindings and all omap devices used them. In the background, 8250 got some more generic enhancements and generic dts bindings... Fast forward the 8250 now has even shinny-er better features then the lagging omap-serial driver.. Thus it was decided to move back, in a release or two.. That ^ may be childlish, but it's the condensed version of pages and pages of discussions on linux-omap.... Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/l2sKZCHEXbU/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com<mailto:beagleboard+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
