Goran Bervar wrote:
> 1) IMO it is always a bad idea to lock the serious RTOS (excluding DOS of
> course <g>) for such a long time. Can somebody explain what would happen
> under RTL if done so?
When you disable interrupts, you obviously disconnect yourself from the outside
world and lose your "hard" real-time capabilities. Assume you have a very
high-priority interrupt-driven asynchronous task, it will not be able to
pre-empt a lower priority task if you disable interrupts. This is a very brute
force method of doing things. Look into using mutexs. Specifically,
priority-inheritence or priority-ceiling mutexes.
> 2) Handling IRQ, I have to make all IO operations before re-enabling
> interrupts. I assume after that computation should be made in the highest
> priority task in RT kernel space. Is anything wrong with such a design? Some
> better ideas? Link to a similar example? And BTW, how to detect an overdue?
In the case that the task runs at a given rate and it is synchronous to some
event, you simply use a timer. I am going to assume you know this and want to
know how you do this for asynchronous tasks.
Even the best scheduling algorithms are based on heuristics. There are four
main flavors of scheduling theory. Detecting an overdue is not something easily
done from software. You have to start hacking at the scheduling algorithm of
the OS. One of the best methods I've come across, when needing to meet "hard"
real-time requirements, is to schedule a task only if your real-time
requirements can be met; otherwise an exception is thrown. Obviously, you will
need to profile your tasks so that you know their timing requirements. If you
only have "soft" real-time requirements, then you don't care that it is
overdue. Again, some sort of time stamping can be used.
> 3) Can I use scheduling instead of IRQ to start the sample?
Scheduling is the method in which you ensure, in a multitasking environment,
that high-priority tasks will be run before low-priority tasks. In a
pre-emptive multitasking environment, high-priority tasks should be able to
pre-empt low-priority tasks. Disabling interrupts only ensures that the current
task will not be disturbed by interrupts.
> How "accurate"
> is it?
Proper scheduling and assignment of priorities is the only way to be truly
"accurate".
>
> 4) Communication between threads is something I can not decide how to.
> Taking in account that there is quite some non-critical information from RT
> thread (mostly read-only) that user thread must read often (where the data
> *may* be partly incorrect now and than), what is in your opinion "the best"
> way to do it? Shared memory, FIFOs, messaging...?
It seems you want some form of messaging, whether it be through shared memory, a
queue, or some form of thread broadcasting. It seems, for your case, that
shared memory that is managed with a semaphore should be simple and effective.
>
> 5) I have some problem understanding RT Linux mutexes. Do they include
> priority switch to avoid priority dead locks?
I didn't see this when I answered 1). In short, look into the two types of
mutexes I gave you in answer to 1). They both have their advantages and
disadvantages.
Good luck in your endeavors,
Tony Macabuhay
Senior Embedded Systems Design Engineer
-- [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/
