I am kind of confuded how a piece of realtime code would look like using Ingo Molnars CONFIG_PREEMPT_RT patch.
What would I need to make a process realtime. How would I be able to generate a somewhat exact timing, e.g. for a control circuit. From the perspective of a normal Linux system programming guy /dev/rtc comes to mind.
For the realtime stuff, would it be enough to just use a negative nice-level and a SCHED_FIFO policy?
Is there any kind of realtime programming Howto which I have not found searching the web? Or is this just an exmple of another piece of fine but undocumented work which is quite common in the Open-Source world?
Sven
--
This APT has Super Cow Powers.
(apt-get --help on debian woody)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
RTAI is not what I am talking about. Its Ingo Molnars patches for the Standard Kernel aka Realtime preemtion.
Sven
-- "Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch." (Anselm Lingnau in de.comp.os.unix.discussion) /me ist giggls@ircnet,
If not, the information is probably relevant to your question.
- The guys involved in that discussion should be able to answer you (Ingo himself?).
- Maybe it's a question that can be posted on the kernel mailing list itself (not sure about that, I haven't used it before, but I would guess that not many embedded developpers have done what you are trying to do).
- I guess you also already know this article:
formatting link
but just in case...
Was just trying to help a little, since you haven't received any relevant answer after nearly two days.
I did not know it, but unfortunately it does not talk about CONFIG_PREEMPT_RT anyway.
Sven
--
"The American news-media is no longer a news source; it is a
cheerleading squad." (unknown source)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
Several approaches are "identical" from a users perspective. Simpel rule: Highest priority process runs The point of the different approaches is to ensure that this is correct.
Lets try an example, read from serial port (buffer in driver): A process runs (A) - like idle process, web server, ...
- Interrupt arrives
- Handled by irq-handler in driver, driver collects characters until some limit is reached / special character is read.
- Irq handler now wakes up the process (B) waiting for this interrupt. But here comes the problem. What was the process A doing.
1) Running in user space (the actual application code) No problem, when leaving from the interrupt it will be noticed that the current process should let another process run. A context switch will occur when leaving.
2) Running in system space (walking through all page descriptors trying to find a page to swap out). This is worse since the process might be accessing shared structures - rules must be followed. a) Wait for process to leave kernel space. b) When doing stuff that can take time in the kernel - check if another higher priority stuff wants to run. c) Use multiprocessor spinlocks, do not allow process switches while in a critical section. d) Reduce critical sections by minimising spinlocks, do this by d1) Replacing them with semaphores d2) Add checks inside the spinlocks e) Don't bother with the kernel at all, let the RT processes be handled by their own micro OS that sees Linux as one of its processes. Usually trying to use the same API (Posix) but you will not be able to use all services of Linux.
But an ordinary file could be the source, consider tail -f /var/log/something with a requirement that it should output "something" within two secons.
nice-level is only used in SCHED_OTHER (and that is never Real Time)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.