writing rtems drivers

[Joel Sherrill]

"Aaron J. Grier" wrote:
> 
> I've successfully ported RTEMS to an in-house 68331-based test
> instrument.  My gratitude goes out to Joel and and all the others who
> have made RTEMS such a nice portable RTOS.
> 
> Now it's driver writing time.  ;)
> 
> The first thing I've decided to tackle is the instrument's internal
> (matrix-scanned) keyboard.  I currently have polled-mode drivers
> working, but the hardware supports interrupts, and I'd like to have the
> option of using an event-driven framework.
> 
> What are my options for generating events from drivers?  Is it wise to
> use the rtems_message_queue_* operations from within a device driver or
> ISR?

The rule of thumb is use "unblock" operations in an ISR with the 
"blocking" mate in a service task. For example:

  ISR -> event_send, task -> event_receive
  ISR -> msg_send, task-> msg_receive
  ISR -> sem_release, task -> sem_obtain
  ISR -> mutex_unlock, task ->mutex_lock

NEVER NEVER block in an ISR.  :)

Sending messages is higher overhead than other mechanisms but
carries information.  So it may be the best thing in some 
situations.

Remember that whatever you do implies that the application
must configure the resources.

> --
>   Aaron J. Grier   |   Frye Electronics, Tigard, OR   |   aaron at frye.com

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985