erc32 bsp, context switch / task variables

[Nicolas Horro]

Hi,

I'm working on a driver which accesses a device implemented in a FPGA that
is used as a state machine. That is, there are configuration registers that
determine how operations are executed.

For example,

a register named ADDRESS_MODE determines if address range 0x2000 to 0x2010
will correspond to a register set belonging to UART 1 or SDRAM.

ADDRESS_MODE = 0x00 ==>  UART1 Register set
ADDRESS_MODE = 0x80 ==>  SDRAM Register set

(in the real device this is a bit more complex, this is just an example to
illustrate the nature of the problem)

I have a driver in a .lib with directives that perform different operations
using this device, such as

device_init();
...
uarts_send()
uarts_receive()
...
sdram_write_block(),
sdram_read_block(),
...
etc.

each directive has to:

1. save ADDRESS_MODE value and other "state registers" values.
2. configure ADDRESS_MODE and other registers to target the desired register
set and operation mode.
3. access registers to perform operation.
4. restore original ADDRESS_MODE value and other "state registers" values.
5. return

The problem with this solution is that it is not multitasking-safe.

A similar problem occurs when handling errors using (for example) trap 0x9.
A global structure is used to read device status registers, but there is no
way of knowing from which task they were generated so each task can track
its own errors.

Im stucked at this dilemma:

- I believe the ideal solution would be to provide a context_switch() hook
that preserves the critical registers for each device, but this would
require altering the BSP, wouldn't it ? Is there a way to provide a custom
context_switch() routine with preallocated space in confdefs.h for a number
of tasks known at compilation time ?

- In case this is not possible, could RTEMS Task variables be used instead ?

Any help would be appreciated : )

Thanks,

Nicolás Eduardo Horro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090212/b04290be/attachment.html>