inetbot web crawler
Main  |  Get access to the repository  |  API  |  The robot  |  Publications  |  Usenet Groups  |  Plainweb  | 
 inetbot - Groups (beta)

Current group: comp.realtime

Nucleus RTOS I/O Driver Advice

Nucleus RTOS I/O Driver Advice  
Michel
From:Michel
Subject:Nucleus RTOS I/O Driver Advice
Date:20 Jan 2005 02:21:31 -0800
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.
   

Copyright © 2006 inetbot   -   All rights reserved