Re: RTOS Best practice
> Hi Martin,
> I'm using an LPC2148 with full Keil RV-MDK. Started the project just
> as that chip came out. It had the right mix of peripherials, speed
> and memory.
> Had good experiences with it coding up USB Mass Storage, SPI flash,
> GPS module, SD cards, along with 3 file systems (internal IAP, SPI
> flash and SD) but got myself into a mess with the management. The GPS
> is quirky, needs a lot of poking to intialize, and theres a dozen
> different ways the user can modify the operation of the device.
Hmm.. I would surely be tempted to isolate interaction with this
device using a thread/task.
> power-down a lot to improve battery life which involves reconfiguring
> the port functions and sleeping most of the time.
I don't know about an RTOS and power-down. I suppose that a shutdown
message could be queued to the threads that handle each peripheral to
instruct them to shut down their own stuff and reject further
messages. Some of this might have to happen serially if peripherals
are interdependent, so you might have to transport one 'shutDown'
message around several peripherals.
Just coded a SD
> firmware update mechanism and it seemed like a good time to think
> about a new structure.
I haven't got around to that yet. My secondary boot code can load
either bank of main application code from an SD card, but I have not
yet tried loading one bank from the other using IAP. That pleasure
comes later :(
> Thought RTOS might release me from the looping nature of my
> implementation. The idea of semaphore and task switching would
> simplify the function transactions for timing and data.
It can take one level out of state-machines since the OS is an
interrupt-driven state-machine in itself. It is very convenient to
just get, say, the UART handler code working and then just create four
of them :)
> I have plenty of flash/ram left so not concerned about that.
I am being careful with RAM - I only have the internal 16K and do not
want to get into trouble later. I use 127 small buffer objects for
all data transfer and inter-thread comms. On Windows, I would just
create all 255 objects and shove their references onto a pool queue
from which all threads could request and release from. That's fine if
you can afford space for 127 32-bit pointers.
On the little ARM, I have used an array of objects addressed by a byte
index. They all have 'succ and 'pred' bytes and are all linked up in a
double-linked 'free' list. These two bytes also allow linking of the
buffers onto inter-thread queues - such queues do not need any extra
space for queue storage. Methods of the pool, queues and messages do
all the indexing/pointer-arithmetic to push/pop the messages by
address, just like in a 'real' system with more than a teaspoonful of
> Have spent a lot of time with Mathworks Stateflow and though about
> using that to generate bare bones FSM code to enforce the logic (with
> custom code for functionality).
If you already have an FSM, you are probably 90% of the way there.
You probably do not need to throw it away, just drive it with messages
queued in from the peripherals. This serialises the decisions and
makes debugging easier than the alternative of making direct calls
into a mutex-protected FSM.
> Lots of options!! Just interested to hear about what has worked for
> people on similar projects.
Well, it's working so far....
I could not reply to your post earlier because of an err.. 'ongoing
critical functionality deviation' in the PC code that talks to my ARM