Nucleus RTOS I/O Driver Advice

I am new to Nucleus RTOS and I am trying to sketch out the architecture
for a set of drivers that I will write for a BSP.  I would greatly
appreciate any tips or I/O driver examples that might help me along
with the design.

I want to use the standard Nucleus I/O driver requests to implement
(among others) a two layered I/O driver to access an RTC connected on
an I2C bus.

I would like to have a separate I/O driver for the RTC and the I2C
devices.

The I2C bus driver can be accessed by multiple drivers/tasks and the
assign request is used to arbitrate access to the driver. If two tasks
want to use the driver at the same time one will suspend until the
other is done with the I2C driver.

When executing a request such as "get time" the RTC driver assigns
the I2C driver and then reads data from the RTC device.  If another
task is busy accessing another I2C device at the time then the assign
request will suspend the task making the call into the RTC driver until
the I2C driver is free.

The RTC device has an interrupt line, used for example to indicate when
the alarm is active.  The interrupt is connected to an RTC HISR
function.  The HISR function checks and clears the state of the
interrupts in the RTC device and launches the appropriate callback
function.

The problem I see before me is that the RTC HISR function is not
allowed to suspend on the assign request to the I2C driver.

One option is to have the HISR simply indicate that an event has
occurred and define a request by which the calling task can probe the
state of the RTC device.

I end up with the same problem if I want to start a timer that polls
the state the of the RTC device, the timer callback is not allowed to
suspend either.

Should I create a task inside the I/O driver that waits for the HISR to
tell it when to read data from the RTC device (a third layer of ISR)?

Is there something fundamentally wrong with my design? Am I trying to
build too much intelligence into a driver?  The driver documentation
from Nucleus is not very informative. A good starting point would be an
example of a fully functional layered Nucleus I/O driver(s) that handle
interrupts and asynchronous notifications using callback functions.
Thanks in advance for any help.

"Michel" <nube@comnet.ca> wrote in
news:1106216898.292983.131720@z14g2000cwz.googlegroups.com: 

> I am new to Nucleus RTOS and I am trying to sketch out the architecture
> for a set of drivers that I will write for a BSP.  I would greatly
> appreciate any tips or I/O driver examples that might help me along
> with the design.
> 
> I want to use the standard Nucleus I/O driver requests to implement
> (among others) a two layered I/O driver to access an RTC connected on
> an I2C bus.

They're model might be a bit "heavy" for I2C and RTC access. Did they
advise you to use their driver model? 

> The problem I see before me is that the RTC HISR function is not
> allowed to suspend on the assign request to the I2C driver.
> 
> One option is to have the HISR simply indicate that an event has
> occurred and define a request by which the calling task can probe the
> state of the RTC device.

Exactly.
 
> I end up with the same problem if I want to start a timer that polls
> the state the of the RTC device, the timer callback is not allowed to
> suspend either.
> 
> Should I create a task inside the I/O driver that waits for the HISR to
> tell it when to read data from the RTC device (a third layer of ISR)?

How about a function call the falls asleep if the HISR hasn't
NU_Set_Events() on your event of interest yet? Since you'll be calling it
from a task, why create another task? 
 
> Is there something fundamentally wrong with my design? Am I trying to
> build too much intelligence into a driver?  The driver documentation
> from Nucleus is not very informative. A good starting point would be an
> example of a fully functional layered Nucleus I/O driver(s) that handle
> interrupts and asynchronous notifications using callback functions.
> Thanks in advance for any help.

I think you may be trying to make the driver too complex. You could
probably write a simply I/O driver with NU_Sleep() polling on the device
and forgo much of the complexity. I don't know if you can live without
interrupts on receive though. The I/O driver model for Nucleus PLUS is
there for those who require one, it is not required to be use (I've never
used it) and you can still play quite nicely with the RTOS even if you
don't use their I/O driver model. 

-- 
- Mark ->
--