----- Original Message -----
From: "David Olofson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: 23. maj 2001 1:59
Subject: Re: [rtl] Semi-beginner's (app design) questions
David,
Tkank you for very informative answers but of course a have some additional
questions.
> > 1) IMO it is always a bad idea to lock the serious RTOS
>
> If you have only one RT thread, there's no problem.
Oh! Good news.
> BTW, the only problem with "locking" the CPU for extended periods of time
> (pretty much regardless of platform), is that you may cause some drivers
for
> timing sensitive hardware to freak out as a result of missing IRQs.
Thanks for a warning, I am well aware of this. As I wrote in my original
post I have a 1ms sample period and approximately 0,5 ms CPU "lock". It
works perfectly 9600 baud IRQ driven (sic!) serial communication and GUI on
100 MHz Pentium. If necessary I can switch to higher speed processor so I'll
probably stick with this design. It is most simple to implement. The best
thing is that I block all other interrupts for a period of sample so my RT
thread will do its job for sure inpredictable time.The worst thing is the
same as other threads will be delayed. But IMHO I can live with that if RT
Linux can.
> > 2) Handling IRQ, I have to make all IO operations before re-enabling
> > interrupts.
>
> No hardware buffering/latching + timing? Always lots of fun! *heh*
Sure! Quite some but nothing critical. NOP is a nice Intel asm instruction
isn't it? ( I am one of "minimalistic" programers - IMHO it is better to
throw CPUI time away than mine).
> It would be simpler and safer
<snip>
> Also, you'll wreck the user space real
> time performance of a Linux/lowlatency kernel that way. (Your CPU hogging
> will add to the latencies of the Linux scheduler.)
It just _has_ to be done before the next IRQ or application is broken - so
it doesn't really matter when and where within a period time frame it does.
If the influence to Linux kernel and user space is lack of performance
reacts only like runing on a slower CPU) it's more than adeqate to me.
> > And BTW, how to detect an overdue?
>
> If you just want to know how you're doing in respect to the deadline, you
> could query the performance counter (preferably using the RTL API) to see
how
> close you ore to the next expected interrupt.
Thanks but I was hoping to see the simple example how to <s>.
> If you've just missed it, well... tough luck! ;-)
My hardware has ENABLE output watched by hardware trigger - and in such
cases. Very loud but safe shutdown
so I don't like to hear it often :-)
> As to more general CPU overload protection:
Thanks for that info. I already do have hardware watchdog and
high-to-low-thread watchdog implemented.
> > 3) Can I use scheduling instead of IRQ to start the sample? How
"accurate"
> > is it?
>
> Yes, and it's quite accurate, at least in terms of what you'd use IRQs and
> software dependent timing for.
I am looking for somthing like +-3% on a 1 ms sample.
> > 4) Communication between threads is something I can not decide how to.
<snip>
> For higher bandwidths, it might be a good idea to use shared memory(...)
(FIFOs
> can be used for passing references to buffers in the shared memory area,
for
> example. Very simple way of dealing with complex allocation and timing
> patterns.)
That sounds promising. Any links or references to more info?
Finally about mutexes - I am still waiting someone to answer how it is done
in RT Linux though I absolutely agree it is nearly a war going on in the
RTOS community if they are of any good.
Thanks again, David
Goran Bervar
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
