In the heartbeat example, there is the following comment:
/* Note: The I-pipe patch for blackfin ensures that
gpio_set_value
* (among other services) can safely be called from RT
context. */
So this states that the gpio_set_value can be called from an RT context.
What about an I2C driver, or an SPI driver? There are linux kernel drivers
to support these devices. Does it make sense to continue to use these
drivers in the linux kernel, and somehow have an RT context that can tap
into this data? Does an RT context take precedence over the linux kernel
I2C and SPI drivers? The Xenomai is its own kernel and somehow interacts
and works together with the linux kernel. Do I have to re-structure a linux
kernel I2C driver completely into a Xenomai I2C driver?
In the past I have written a linux kernel driver on top of the I2C driver to
collect I2C data into a buffer. I also wrote a Xenomai driver that makes
calls into this top level linux kernel I2C driver to get the data. And
there is a Xenomai user application, running an RT context, that gets the
data from the Xenomai driver.
Is there a particular strategy I should be using for the I2C and SPI
interfaces?
Wayne
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
