Sequential programming Vs FSM Vs RTOS

 Sequential programming Vs FSM Vs RTOS

Hi All,

I've completed a nice data logger project including USB, SD/MMC support, GPS and other SPI devices using sequential programming.

I'm now looking for best practice on how the functionality I've created could be better structured and that leads me towards structuring the functions into a State Machine or use an RTOS to go the threading route.

I've done some research on RTOS but it would be good to hear from practitioners. Any experiences or links to resources regarding correct use of RTOS would be greatly appreciated.

Thanks,

Robert.

 RE: Sequential programming Vs FSM Vs RTOS

A lot depends on amount of data to retrieve, max transfer rates and max allowed latencies.

 A lot depends on...

Some processors are not well-suited to an RTOS - eg, the 8051.

RTOS and State-Machines are not mutually exclusive...

 RE: A lot depends on...

Robert;
I encourage you to continue your efforts toward the RTOS approach.
On this forum, many treat RTOS as a true four letter word ;-)
I agree with the two earlier posts but withhold total agreement about the 8051 not easily supporting an RTOS.
Looking at your listed devices, I'm assuming that you will be using some type of ARM device but maybe not.
But none of the listed devices require super determinate service. In fact the devices in normal operation can be started, stopped and re-started with minimum concern of data loss. You can certainly verify that statement as you programmed your USB tasks.
With RTOS you will need to think about program flow in a different manner but not as strict as you would with a straight SFM scheduler.
And remember, you still have the option to operate outside or parallel of the OS or RTOS via interrupt routines.
How to start? I suggest that you look at the examples in your Keil toolset. Again I'm assuming the ARM MDK tools. Open the Manuals of the "Complete User's Guide".
Click on the "Contents" tab and select "RL-ARM Real-Time Library User's Guide".
There are a number of example projects as well as a pretty good overview of RTOS operation.
The RL-ARM(RTX) comes with the MDK tools. Additional Library tools are available but not necessary unless you want the source code for many of the lib routines.

 RE: A lot depends on...

Too many people on this site - and around the world - uses RTOS in their embedded systems for it to be a 4-letter word in the derogatory sense.

An RTOS gives simpler and clearer loops, but instead requires critical sections or similar to protect the threads from corrupting each other. The individual stacks also increases the RAM requirements.

It takes a bit of information about the goals to know if an RTOS is meaningful or not. An ARM are well suited for an RTOS but that doesn't mean that an RTOS helps for a specific application. An '51 can run an RTOS, but for applications that are complex enough to really warrant an RTOS, there might be an idea to look at other processors instead.

 RTOS debate

Hi all,

Thanks for the insight.

My current target is a 32-bit ARM device (LPC2148). The project started 2 years ago and the LPC had the right mix of speed, flash and perpherials for my project.

The projects grown from a simple gps logger to a fully featured device with many more interfaces and higher level requirements. I had the gps logging to an SPI flash but recently added a SD card which greatly complicated matters and got me into all sorts of exception handling problems which prompted me to re-evaluate. I'm investigating adding a webserver and an rf module which will further complicate the flow so now is the right time to consider a better structure.

Thanks,

Robert