Long time programmer but new to embedded electronics.
I got an Arduino board with ATMega328, did the blinky blinky thing(cool!).
Loaded some example sketches, controlled an old server(very cool!),
read and output data from memsic2152 accelerometer(totally cool!).
Now i want to start reading multiple sensors(gps, compass, and wind, gyros), perform calculations, display results on lcd(eventually), maybe store data on sd, maybe add some kind of wireless someday.
Before i go crazy i thought i should pole the pool of experts here.
How do you go about allocating processor resources for various sensors?
Some sensors like gps do a lot of the work for you, so if i need an update 4 times a second, and the unit outputs four times per second, then should be easy to read with lots of processor cycles to spare.
But the accelerometer(and other sensors i suspect) is noisy and if i need 4 updates per second i’m thinking that i’ll have read it far more often and then average or filter the results.
At some point i imagine i’ll have to dedicate a processor to pre-process sensors data, another to store and display data. Though perhaps i’m underestimating what an ATMega328 can handle?
I use a cooperative scheduler (not a preemptive RTOS). That and proper coding assures I/O gets what it needs. Serial port and other slow I/O is interrupt driven, buffered. With this, each I/O process can be a simple state machine written in C, where each is a separate function. These are called in round-robin form by the cooperative task scheduler. Underneath all this is a periodic clock interrupt, say, 100Hz.
There are a number of these around in freeware. I submitted one called OPEX on avrfreaks.net, with source.
If you want a simple but wonderful full preemptive RTOS for the AVR, free, download avrx from that same website. Ready to run, lean and mean.
I guess it depends on what you’re doing. Most of my projects deal with I/O in a particular order with no time dependency, so it’s not really that hard to program. Usually, it’ll be something like “read a temperature sensor, and adjust some output value depending on what you get”. Those situations don’t call for complex implementations.
On the other hand, I do have a project utilizing USB communications and for USB to work correctly, the cpu must be free to check in with the USB host periodically. In that case, the program utilizes a round-robin scheduler to ensure that each of the pieces of the program get their fair share of cpu resources. The only problem with that approach is that almost all of the I/O has to be interrupt driven to make sure the program doesn’t hold up the scheduler.
If you aren’t having any problem getting the readings you need at the frequency you require, I wouldn’t worry about having a separate cpu to process sensor data. You’d likely be surprised just how much processing power is available in an AVR at 16MHz - especially since most instructions complete in one clock cycle. I know for a fact that most of my projects spend a lot of time wasting cpu cycles regardless of how complex the project actually is.