Re: [PATCH] local_irq_disable removal

Esben Nielsen
2005-06-13T12:19:54Z

On Mon, 13 Jun 2005, Paulo Marques wrote:

> Gene Heskett wrote:
> > [...]
> > Lets add the operation of 4 or more stepper motors in real time for
> > smaller milling machines. There, the constraints are more related to
> > maintaining a steady flow of step/direction data at high enough
> > speeds to make a stepper, with 8 microsteps per step, and 240 steps
> > per revolution, run smoothly at speeds up to say 20 kilohertz, or 50
> > microseconds per step, maintaining that 50 microseconds plus or minus
> > not more than 5 microseconds else the motors will start sounding
> > ragged and stuttering.
>
> This is the kind of problem that is screaming "give me dedicated
> hardware!". Why would one spend $500+ on a PC to do the work of a $2
> microcontroller (and possibly throw in an FPGA to the mix)?. Not to
> mention that the microcontroller/FPGA would maintain 50us +/- 0us
> instead of the 50 +/- 5 you've mentioned.
>
Linux does not always run on a $500+ PC. People also use Linux on
_embedded_ devices costing only a small fraction of a $500+ PC. But I do
agree it is kind of silly to use the OS for this example.

Assuming you do not put any "highlevel" calculations in a IRQ handler,
the only usefull place to have fast IRQ handlers, as far as I can see,
without having fast preemption is with cheap hardware without a lot of
buffering.

I can come up with CAN controllers, which only have very little
bufferspace (because they are cheap as they are sold in large volumes).
Worst case you will have to empty it every 100-200 us or so to avoid
having an overrun and loosing packages. The interpretation of the packets
should ofcourse be deferred to a task. The tolerated latency of that task
ofcourse depend on what you want to use the data for....

Esben