Results 1 to 1 of 1
Hi all, I'm hoping someone can provide some clarity on this issue for me. I'm running Linux on a PC104 board. The application requires bit banging of i/o pins to ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 07-19-2006 #1
- Join Date
- Jul 2006
task scheduling, process timings / delays
I'm hoping someone can provide some clarity on this issue for me.
I'm running Linux on a PC104 board. The application requires bit banging of i/o pins to simulate a comm interface.
So I set an i/o pin high - read another i/o pin - wait 1ms - set a different pin high - read an analog channel - wait 1ms - do this/that - wait 5ms ... you get the picture.
All that needs to be done in one sequence - ie. no spurious LENGTHY context switches to other processes (CRT interface for example). My understanding is that by default, the kernel handles task switching / delays / timers on the order of 10ms. That sort of absence from the running program will invalidate the results.
There would be alot of idle time during operation - that is it would be fine to
1- turn pin on
2- read another pin (no more than ~500us later)
3- idle time (program suspended perhaps - don't really care)
4- turn another pin (no more than ~2ms after step 2)
The program just couldn't handle random 10ms absences from execution.
If this is pretty much the only process running / loading the CPU (sure in the background their will be vga / keyboard controllers, etc) - might it be safe to assume that it will not be interrupted for lengthy periods (ie. 2ms++) ?
Do I need to go with a real time kernel such as RTLinux ?
But then it seems I would have the joy of rewriting all the device drivers of the manufacturer specific parts for RTLinux - right ?
Or can I mess with SCHED_FIFO, give the process a high priority, and have it interrupt driven off of the real-time clock to guarantee (somewhat) some form of deterministic runtime ?
Or am I totally missing the boat here, overlooking the obvious --?
Any input would be much appreciated..