eeboy wrote:
> I am bringing up my first ARM project (based on LM3S1439) and am looking
> for some advice. In my particular target application the processor will be
> communicating with several peripherals via SPI (2) and UART, maintaining a
> file system, keeping track of time and date as well as performing a lot of
> GPIO manipulation. The board is also designed with a few external
> communications ports so that future additions can be accommodated.
>
> I can see lots of wait states in the manipulation of the GPIO. For example
> I might have a function that sets a pin, waits for 500ms, then clears a
> pin. I could probably get away with software delays at this moment but,
> given the fact that the design can scale, I don't want to introduce this
> inefficiency now only to have to remove it a few months down the road. That
> 500ms could be precious later on. I have several timers at my disposal but
> I can foresee 'running out' in the future. I can think of some elaborate
> solutions to this problem but it makes for messy code.
>
> In general I was thinking I could implement a system tick which generated
> an interrupt at a known interval (say 1ms). Upon each tick, I could examine
> counters associated with the periodic tasks to see if they are due for
> execution. The random interrupts would be handled by the specific interrupt
> handler for that peripheral (example UART receive). That seems straight
> forward to me. However, how best handle (cleanly) the toggling of a pin
> after a certain delay? It's not a periodic task.
>
> Should I use a full blown RTOS? If not how should I structure my
> application? I've had a look at FreeRTOS but it looks to be much more than
> I need and slightly intimidating.
>
> Any suggestions? Please feel free to speak to me like a child as I am not
> extremely knowledgeable of operating systems or software architecture(I am
> a EE). Also, if you can point me to or provide examples that would be
> extremely helpful! Help me wrap my brain around this problem.
>
> Thanks!
>
>
eeboy,
Some guidelines I have found true are to use a RTOS when you have a
number of asynchronous interrupts, and used a timed loop (as you
suggested) when everything is predictable. For example, a RTOS is
good when dealing with a pumping station where you are controlling
some pumps and valves based on fluid quantity flow or in a tank. You
have no idea what the situation will be moment to moment, but the RTOS
will let you assign priorities to various tasks and run the most
important ones as soon as possible (there are no zero latency interrupts).
On the other hand, let's say you were designing an engine controller.
You could use a timed loop (and most of them do) to check the mass
air flow sensor, the coolant temperature, the battery voltage, and
engine position (% revolution), then calculate the plug and injector
firing time and duration.
Since I don't know your application well enough to advise, you will
have to ask yourself which model is closest to your needs. Keep in
mind that the RTOS involves more learning time and more over-head, but
it is more flexible. Also, some RTOS's do file systems, others don't.
Some will work on your processor, others won't.
Dave,
|
Linear Mode
