Re: [uCsimm] RTLinux and the uCsimm

From: Tom Walsh (tom@openhardware.net)
Date: Tue Oct 10 2000 - 00:12:55 EDT


"D. Peter Siddons" wrote:
>
> Can anyone point me to simple instructions for making the RT
> patches to uClinux using the .diff files provided on the
> March 2000 CD? It seems to me the patches are generated from
> a different uclinux version (2.0.38.0 vs 2.0.38.1) and so
> the patches fail, or I just don't know what I'm doing.
> Which is quite likely :) Any pointers would be appreciated.
> Pete Siddons
> This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/

I applied the patches against the modified 2.0.381pre1 sources without
problems, it appears that the patches were made against uClinux as
opposed to a stock kernel. I have been told that there are problems
with the RT-Linux patches that need to be cleared up. I was warned that
the kernel could suddenly do a Hard Crash (freeze) at times and I did
have this happen to me while with a customer, fortunately, the customer
did not notice and I quietly reset the board. Since then, I have not
done anything with the RT-Linux modified sources and have returned to
attaching the RT problem from the standpoint of adding this
functionality into the stock uClinux source. The freezing problem seems
to come from a collision of the RT-Linux patch "forgetting" to
reprogramm the timer so it will fire again later. The RT patches
assumed that it would be multiplexing the timer with the jiffies
interrupts and be calculating when to allow the jiffies to have the
interrupt response, or the RT ISR would service the interrupt (I have
not verified this as being the case, but I respect the source of this
information).

This does have its own issues, for example, the most powerful realtime
resource (the Timer) is used to maintain the jiffies clock. As this is
a level 6 interrupt source, there is little chance of losing "ticks" of
the clock and timekeeping is stable. It would be possible to tack on
some additional code to the Timer interrupt to do some fixed realtime
stuff, but it would have to be at a fixed rate of 1 ms. Not too bad,
but you have to keep your ISR time down to < 1ms so you don't lose a
"tick".

Another solution that I have looked at is to used the SAM (sampling rate
timer) as a RealTime element, this does work but you are restricted as
to the rates you can get, with the max period to be at 512hz. I have an
application that does this, ..., it does have an odd problem that I need
to track down that seems to be related to the interrupt services,
occasionally I get an odd reading from my hardware. I am not sure why
this is, I have to still determine if the erroneous reading is due to an
actual hardware reading, or if it is a problem with register values
being indeterminate under some conditions (perhaps a higher level
interrupt is disturbing the register contents).

Another solution would be to use the level 7 interupt to drive the
jiffies clock, thus freeing up the 16 bit timer + SAM timer for
application use. To do this, some external hardware is needed. I am
toying with the idea of taking the 32kHz clock of the processor, running
it thru a 6 stage divider to produce a 1024 Hz interrupt, and changing
the jiffies rate from 100 to a 1024 divisor (the #define HZ value). You
have to be careful on implementing this as the *EMUIRQ is a level
triggered interrupt and you would need to reset the last stage of the
divider to "ack" the interrupt source. Using a 74HCT393 would work with
some combinational logic, or a PLD...

Any other ideas or comments?

TomW

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



This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:38 EST