Help: ISR completed and Working, but one doubt...

[Joel Sherrill <joel@OARcorp.com>]

Alex wrote:
> Hi all,
> 
> First thank to all of you who helped me with getting my printer port driver working. It is working!!
> 
> According to rtems documentation and according to rtems mailling list messages, 
> When one is writting device drivers he/she needs to pay attention to the following "rules", right?
> 
> 1. Do not block inside an ISR.
> 2. keep ISR source code as small as possible, putting the "heavy" computation in the application.
> 3. Do not call other functions than the ones referred in the Rtems Interrupt Manager.

If you mean the "set that is safe from ISRs", then yes.  That list is 
probably not 100% inclusive.  The general rule is that if a call does 
not block and is not creating or deleting including malloc, and object 
creation, etc. it is most likely safe.

For example, I doubt that that list includes the POSIX mutex, semaphore, 
or message queue managers and the services which send/unlock should be 
just as safe to be called from an ISR>

> For now, my printer device driver just counts interrupt occurencies. 
> I have testing it and I think it is working fine, but I am afreid of 
> forgetting some important rule concerning ISR's, that my tests are not covering...
> 
> My question is:
> 
> Do you know any other important rules to take in account when working with IRS's?
> 
>    .Do we need to worry about turn on and turn of interrupts? We don't, right?

Often not if you completely deal with the interrupt in the ISR.   Since 
this is a simple short ISR, I would tend to leave interrupts off and not 
worry about nesting for simplicity.

>    .Do we need to take care of the context switching? We dont, right?

If you stick to the RTEMS ISR model, the "wrapper" that gets you to your 
C handler takes care of that magic.

> Some Extra Info:
> 
> Env: RTEMS 4.6.2, i686
> 
> I only implemented the xxx_initialize function of the device driver table, 
> because I want to read and write directly to/from printer ports.

But if you implement the read/write, you can then do the read() and 
write() system calls like on POSIX.

> In xxx_initialize function I installed the irq handler using the BSP_install_irq_handler() function.
> 
> In the interrupt handler struct I only implemented the xxx_On(), where I initialize the printer 
> ports in order to receive interrupts.
> 
> In the interrupt handler I inc. the counter of interrupts and then I signal the 8259 saying that
> the interrupt was processed...
> 
> In the application source code, I do driver registering "on the fly" using the rtems_io_register_driver() 
> function.

 From the description, this sounds perfectly fine.  Except that by 
providing read/write you can open(2) the device and read(2) and write(2) 
it.  You will also be able to use libc routines like fprintf, etc.

> Thanks once again,
> 
> Alex
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ______________________________________________________________________
> O IOL aumentou a caixa de correio para 100 MB!
> Saiba mais - http://www.iol.pt/correio/rodape.php?dst=0501181
> 


-- 
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