[uClinux-dev] Re: question about Interrupt handler

Tom Walsh tom at cyberiansoftware.com
Fri Nov 23 08:54:37 EST 2001


Vladimir Vorobyov wrote:
> 
> Hi,
> 
> Continuing Interrupt handlers topic I want to ask some questions:
> 
> 1) I know that I can't transfer data to/from user space from interrupt
> handler and the best way to do it is to wake_up another part of driver
> (for example read function) and let it to perform transferring data from
> FIFO-buffer
> to user space. But 'woken_up' process can strart executing only after next
> timer tick (is it correct ?), in other words after <=10msec. For my task I
> have to

Essentially, yes, sleeping processes, scheduled processes, and delays
are generally controlled by the action (increments) of the jiffies
clock.  Jiffies clock is the "heartbeat" of the system.


> read large amount of data from FIFO buffer rather fast and 10msec delay
> will dramatically decrease transfer speed. Could you give me an advise how
> to solve this problem ?

??  I am not sure why you think that a sleeping process would affect the
operation of your driver.  If you have a large amount of data in the
driver that would need to be read via user app, and are concerned with
data loss.  I would consider how important that loss of data would be.. 
If you are reading a camera, then that would maybe mean the loss of one
frame, annoying but not fatal, however if you are monitoring a security
device then the loss of data could mean that someone enters the secured
area undetected.  Or, loss of a frame of data from an ADC monitoring a
chemical process could be serious...

It all depends on how important the data is.

You cannot get around the sleeping task, it is only a problem if you
make it so.  Inherently, a multitasking O/S like linux is going to have
to put processes to sleep so that the other processes can run.  What you
can do is to set the nice value high enough in priority that this task
gets to run more often..

The ultimate solution may be to offload that time critical task to a
smaller micro, like the 89C2051 processor, let it crunch the data and
hand your uClinux system the cooked results to, perhaps, deliver via
ethernet/TCP.

> 
> 2) On the other hand, I work on the rocessor without MMU (MCF5272) and
> transferring data to/from user space from interrupt handler works properly,
> but
> is it correct to do it (write to user space directly)?
> 

It is only as correct as you are going to make it.  IMO, the only right
way to do things is the way that makes it work.  As we gain in
experience, we learn more elegant ways to do things.  You are on cutting
edge stuff here:  unix + realtime.. I would say that if it works, use
it.


As someone else pointed out that it was possible for the app to crash
and leave the interrupt handler still pumping data into the user space. 
But, it would make sense to me that any unsupervised system would have
some kind of a watchdog running.  A Dallas MAX590 is a nice independant
watchdog (I don't like internal watchdogs, I have seen processors crash
their micro code sequencers and die before).  Your strategy may be to
have the interrupt task "push" a value up, then the user app look to see
if the data has been "pushed", then it would push it back down and
toggle the watchdog bit port pin to keep the watchdog at bay..  This
way, if the user space crashed, the whole system would get reset by the
lack of activity on that pin.

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/



More information about the uClinux-dev mailing list