I have been looking at multiple options for building RTOS projects using the beagleboard as a base. The biggest one is a Fuel Injection ECU project for my KZ1000 motorcycle. People have done FI computers with MUCH less power than the OMAP 3530... so it really makes me wonder what can be accomplished with such a brute.
The OMAP 3530 processor has 12 32-bit general purpose timers (yeah.. 12!!!) This would be great for so many real-time applications. Most MCU's don't have such a plethora of timers. And all of the timers can do capture, compare, one-shot and PWM operations.
So the question for me was: How can I get and ROTS running, and still have support for all of the hardware goodies onboard? Well. It seems for now that's impossible.
I looked at QNX, FreeRTOS, etc. QNX and FreeRTOS are possibilities. QNX supplies some hardware support, FreeRTOS is roll-your-own everything (works great on the Luminary Micro ARM controllers). I'm not really into QNX licensing.
At first I was shrinking away from using Angstrom Linux. Linux is NOT an RTOS. But it has such rich support for the beagleboard it's very tempting.
This brings me to another question: With hand-rolled kernel module providing GP Timer controll/IRQ handling, can I approach the RTOS timing requirements that I need? I need to be able to sync to a crankshaft gear sensor, and need to perform fuel/timing calculations, AND supply accurately timed firing of injectors and ignition coils. Definately enough timers to do this...
Some ideas: use the onboard DSP to offload fuel/timing calculations from the ARM core. Use the onboard graphics processor to provide a "dashboard" on a LCD screen to eliminate the need for any other instrumentation. Allow datalogging to the onboard MMC port.
This leaves me with a couple make-or-break proof of concept tasks:
-Does the beagle boards expansion break-out have enough of these timers exposed for what I need?
-Make a GP Timer kernel module that can sync a crank sensor
-Test the syncing of the crank sensor (probably compare input/sync'ed signals on oscilloscope?)
-Test out the DSP chip... so far I haven't touched this thing... Doesn't seem to be a lot of intro-level docs for how to: communicate, compile, etc. for this thing. Should be quite a challenge
I attempted some basic testing with the beagleboard to determine its viability for a fuel injection computer... Unfortunately it led me to scrap the idea.
The main problem was GPIO and Linux kernel latency. Unlike most simple microcontrollers, which have a relatively direct linkage between GPIO's and the CPU's interrupt controller, the OMAP 3530 is a more complex, and more layered. This adds a significant amount of jitter to the latency between GPIO edge detection, and IRQ handling in the A8 core. Furthermore, the Linux kernel adds even more jitter.
I determined this by running an experiment:
The result: almost 1msec jitter... no kidding! I was amazed, since an old PIC could get around 1uS or better. I'm not sure how much jitter was added by any of the individual stages of IRQ processing, Linux kernel or output GPIO processing, but this was still a deal breaker.