RTEMS driver development questions

[Sebastian Huber]

Hello David,

On 07/02/2013 06:31 PM, David Paterson wrote:
[...]
> Firstly, for a PCI driver, is the best approach to use the driver manager
> layer, or to write it as a basic driver?  It looks like the driver manager
> would be a simpler way to go, as it provides more facilities, but it's not
> clear if it's a standard RTEMS feature, or only available on LEON-based
> systems.  (I'm actually working on a LEON-based board at the moment, but we
> would like the drivers to be useable on other platforms in the future.)

this driver manager is maintained outside the RTEMS main sources.

> Secondly, I'm a bit unsure about handling of multiple devices (and
> hot-pluggable devices).  It looks like the driver manager would call my init1 &
> init2 functions for each device it found with matching vendor & device ID's,
> but how does this get handled in the basic (non-driver-manager) approach?  Is
> it up to my initialisation function to scan for my devices?  For hot-pluggable,
> e.g. USB, devices, the situation looks even more confusing...
[...]

Unfortunately the standard RTEMS system has no dynamic driver management 
framework.  It only provides very simple static device drivers.

See also:

http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__ClassicIO.html

You can also use the generic IMFS nodes for simple device drivers:

http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__IMFSGenericNodes.html

The USB library and the new network stack for RTEMS uses the FreeBSD device 
driver model.  I would use this API also for RTEMS in addition to the simple 
static device drivers.

http://www.freebsd.org/doc/en/books/arch-handbook/devicedrivers.html

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.