Control.com - Nerds in Control

Hi,

I need that some procedures be executed in an
exact time and in a periodic manner. That is,
for example a buffer must be copied for each 200
microseconds elapsed. The execution time of the
procedure shall not be delayed even for a 10
microseconds. I mean that the task must be
performed exactly in the clock tick. So What I
need is a very exact timing mechanism in Linux.

I tried some approaches to meet the above requirement.
I modified the real time clock device driver
(/usr/src/linux/drivers/char/rtc.c) by adding some
code to rtc_interrupt() routine. This code intends to inform a user process to perform the desired task via sending a signal to it. But the user process does not immediately receive the signal because the signal is queued and would be delivered until the next time that the process is scheduled and take the CPU. This delay to receive signal is my problem.

To solve it, I save the "current" pointer in rtc_open() routine in a variable called MAC, and then in rtc_interrupt() routine, I change the value of "MAC->state" field to TASK_RUNNING and then call schedule() to wake up my desired task. But when I run my process, computer hangs up and must be restarted manually. Should I use RTLinux instead of Linux ???...

I look forward to hear from you soon.
Thanks for your valuable hints and assistance,


Best regards,

Nader Ghasemi

Sep 17,2001

_______________________________________________
Linu xPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/ linuxplc

As a general rule, PC operating systems are not geared for real tight real time systems. When I have to do it, I let an interface board with a
microcontroller collect the data, and then signal the PC the data is ready to be downloaded and processed.

Another approach I have used is to use the DMA hardware on the PC. It can be set to dump data into a 64K byte block of memory (<640K limit). And it can interrupt when the data is done transferring. This happens in the "dead" time on the bus. I have done this with the DOS operating system, but have not done it with Linux. When the interrupt hits, I change the pointers to let it dump into another 64K block, or I let it refill the current block, because I am processing the data as it comes in.

Kip


____________________________________________ ___
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/ linuxplc

Yes!

What you are attempting is a very ugly hack. Real-Time OSs exist for exactly this kind of requirement.

You have other problems too, if you decide to stick with general purpose Linux. Linux disables interrupts for short periods of time when it needs to execute atomic code. You must guarantee that this will never take longer than 10 microseconds! This is a long time for modern PCs, so you might just be able to pull it off, but it all depends on how _sure_ you want to be that your procedure is not delayed. If you need 100%
certainty, you are better off using a RT OS.

Remember too that the RTClock interrupt might also be delayed by higher priority interrupts! Please note that I don't have the interrupt table
of the PC handy at the moment, so I can't verify the priority of the RTC interrupt. This constraint is due to PC hardware, so you won't be
avoiding it if you move over to RTLinux.



If you can live with the above constraints, why don't you write the part of the code that needs exact timing directly in the device driver? Mind you, it must then be able to execute very fast, you probably don't want to delay the handling of other interrupts (network card, ...) for too long.

These are just the first thoughts that crossed my mind. If anybody knows any better, please do correct me!



Cheers,

Mario.


--
------------------------------------------------------------------ ----------
Mario J. R. de Sousa
msousa@fe.up.pt
----------------------------------------------- -----------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/ linuxplc

I have had very good luck with FSM labs RTLinux. It is open source and provides the timing that you are describing. I have had processes execute
within 2us of the desired period (on a PIII 500MHz), which is quite nice. If you want better than that, the auxillary hardware approach described earlier would be best. Without knowing the application it is difficult to say what the best approach is.

~Ken

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/ linuxplc

On Mon, 17 Sep 2001, Ken Emmons, Jr. wrote:
> I have had very good luck with FSM labs RTLinux. It is open source and
> provides the timing that you are describing.

There's also RTAI out there which is a True Free Software Project (TM) and is released under the LGPL. However, everyone working with a realtime
Linux variant should be aware of the fact that FSM-Labs has this unfamous patent for the RT Linux mechanism. You should find out yourself what that means for your project...

Robert
--
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel |
| Linux Solutions for Science and Industry |
| Braunschweiger Stra=DFe 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 Fax: +49-5121-28619-4 |
+--------------------------------------------------------+


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/ linuxplc

Good news! FSM and FSF have come to terms on a fully GPL compatible license.
Also if you watch the kernel lists there is a patch for a fully preemptable kernel which should make soft realtime better.

http://kt.zork.net/kernel-traffic/kt20010917_133.html#1
http://www.linuxdevices.com/news/NS6732857828.html

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/ linuxplc

This is _not_ good news. They are only fixing some minor problems, but the main problem still exists (and doesn't have anything to do with what the FSF was trying to change now):

FSM-Labs' interpretation of the (kernel+realtimeextention) license is that every application written with RTL (and maybe also with RTAI) uses the patented process and therefore you have to pay if you want to do closed source applications ontop of that.

Not that I'm very hungry for writing closed source stuff, but you know that in automation business you sometimes can't avoid it (at least for parts of the code).

Imagine what happened if no proprietary applications would be allowed on Linux without paying Linus... nobody would use it today. Or if everybody who uses the PuffinPLC had to publish all his PLC programs (which means e.g. his way of performing a special chemical process)...

Robert
--
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel |
| Linux Solutions for Science and Industry |
| Braunschweiger Straße 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 Fax: +49-5121-28619-4 |
+--------------------------------------------------------+


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/ linuxplc

just go here! http://www.ittc.ku.edu/kurt/documents-noframes.html