When exactly do you choose to use a RTOS (instead of a non-OS approach)?

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> But for many embedded systems, FSMs are (or IMNSHO ought to be!) a key
> component in structuring and expressing the design. Canonical examples
> are ATMs, car cruise control, comms/networking protocols etc.

I don't see a requirement for FSM's in any of those.  ATM's (I assume
you mean cash dispensers) just seem like they'd run normal business
code.  Cruise control sounds like a normal PID-like controller.  I've
written tons of comms code without FSM's.  On the other hand, maybe your
comm protocol involves checksums or error correcting codes.  Doing those
with FSMs would be straightforward in theory but ridiculous in practice.

On 07/01/18 21:41, Paul Rubin wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> But for many embedded systems, FSMs are (or IMNSHO ought to be!) a key
>> component in structuring and expressing the design. Canonical examples
>> are ATMs, car cruise control, comms/networking protocols etc.
>
> I don't see a requirement for FSM's in any of those.  ATM's (I assume
> you mean cash dispensers) just seem like they'd run normal business
> code.

You appear to have a very limited definition of what constitutes
an FSM. "Business code" often /is/ an FSM, even if it doesn't use
some specific implementation techniques.

See, for example,
http://www.conceptdraw.com/examples/fsm-state-machine-model-of-an-atm-system


> Cruise control sounds like a normal PID-like controller.

Modes, dear boy, modes. Speed maintenance using a PID
occurs in only one mode. You enter/exit that mode
when different events occur, e.g. pressing buttons
or brake pedals etc.

See, for example,
https://www.researchgate.net/figure/283902282_Figure-2-Cruise-control-system-finite-state-machine-diagram


> I've written tons of comms code without FSM's.

It depends on what you mean by "comms code".

But any comms _protocols_ will have many states
(e.g. connected, disconnected, idle, active,
throttled, retransmission etc) and transitions
between states will occur when defined things
occur. That's an FSM however you code it.


> On the other hand, maybe your
> comm protocol involves checksums or error correcting codes.  Doing those
> with FSMs would be straightforward in theory but ridiculous in practice.

Strawman argument; nobody has suggested that.

On Sun, 07 Jan 2018 13:41:55 -0800, Paul Rubin
<no.email@nospam.invalid> wrote:

>Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> But for many embedded systems, FSMs are (or IMNSHO ought to be!) a key
>> component in structuring and expressing the design. Canonical examples
>> are ATMs, car cruise control, comms/networking protocols etc.
>
>I don't see a requirement for FSM's in any of those.  ATM's (I assume
>you mean cash dispensers) just seem like they'd run normal business
>code.  Cruise control sounds like a normal PID-like controller.  I've
>written tons of comms code without FSM's.  On the other hand, maybe your
>comm protocol involves checksums or error correcting codes.  Doing those
>with FSMs would be straightforward in theory but ridiculous in practice.

Why would it be ridiculous to process the protocol frame with a state
machine ? How do you process the frame in the ISR without a state
machine ?

Especially in systems with user/kernel modes, processing the protocol
frame in user mode byte by byte requires a large number of
user/kernel/user mode changes for each byte, causing a lot of
overhead.

By completely processing the protocol frame in ISR state machine,
there will be only one user/kernel/user mode change for a full
protocol frame.

upsidedown@downunder.com writes:
> Why would it be ridiculous to process the protocol frame with a state
> machine ?

You'd need a ridiculous number of states to validate the checksum.

On Sun, 07 Jan 2018 23:05:07 -0800, Paul Rubin
<no.email@nospam.invalid> wrote:

>upsidedown@downunder.com writes:
>> Why would it be ridiculous to process the protocol frame with a state
>> machine ?
>
>You'd need a ridiculous number of states to validate the checksum.

Is 16 million states a ridiculous number ?

It fits nicely into 24 bits (3 bytes) state variable. 

It is easier to visualize the situation by dividing these 24 bits into
three separate byte variables, one is the actual state (such as
Read_header, Read_data, Read_checksum, Done), the second byte is the
remaining byte count and the third byte is the is partial checksum.

Stay in Read_data state as long as remaining byte count is greater
than zero. For each byte received, store character into result buffer,
add character to partial checksum and decrement the remaining byte
count and if it drops to zero, change main state to Read_checksum.

When checksum byte arrives, check if it is the same as the
(same/inverted/negated) partial checksum and set the main state to
Done.

This also works for CRC calculations as well as delimited data without
byte count. In principle the remaining bytes is then superfluous, but
it is good to have it to check for too long message frames.

It might be a good idea to pack these three bytes into a 32 bit DWord,
if it is visible outside the state machine to have atomic updates
visible to the external world.

On 08/01/18 09:06, upsidedown@downunder.com wrote:
> On Sun, 07 Jan 2018 23:05:07 -0800, Paul Rubin
> <no.email@nospam.invalid> wrote:
> 
>> upsidedown@downunder.com writes:
>>> Why would it be ridiculous to process the protocol frame with a state
>>> machine ?
>>
>> You'd need a ridiculous number of states to validate the checksum.
> 
> Is 16 million states a ridiculous number ?
> 

It is ridiculous for people who think of state machines as a table of
current state, event, action and next state (whether by case statement,
table with function pointers, or whatever).  It is /not/ ridiculous for
people who think of state machines more generally and are happy to
handle a whole set of states (like all values for your current checksum)
in common code.

On 08/01/18 07:05, Paul Rubin wrote:
> upsidedown@downunder.com writes:
>> Why would it be ridiculous to process the protocol frame with a state
>> machine ?
>
> You'd need a ridiculous number of states to validate the checksum.

That's as stupid and unhelpful as suggesting that a
TCP sequence counter should be implemented as an FSM!

It is unbalanced to insist on using a single implementation
technique for all designs.

It is sane (and good practice) to select the implementation
technique that most clearly expresses the design.

"Doctor, doctor, my head hurts when I bang it against
the number of states"
"Well don't do that then"

David Brown <david.brown@hesbynett.no> writes:
> It is /not/ ridiculous for people who think of state machines more
> generally and are happy to handle a whole set of states (like all
> values for your current checksum) in common code.

The term "state machine" stops having any meaning, once generalized to
include basically every possible program that doesn't allocate
potentially unbounded amounts of dynamic memory during operation.
I do believe we were discussing them in terms of state tables.

On 08/01/18 17:56, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> It is /not/ ridiculous for people who think of state machines more
>> generally and are happy to handle a whole set of states (like all
>> values for your current checksum) in common code.
>
> The term "state machine" stops having any meaning, once generalized to
> include basically every possible program that doesn't allocate
> potentially unbounded amounts of dynamic memory during operation.
> I do believe we were discussing them in terms of state tables.

To me and given the history of this subthread, coming
from you that seems a bizarre and incomprehensible response.

I really don't understand what position you are trying
to advocate.

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> I really don't understand what position you are trying
> to advocate.

There are many problems like communications protocols that people in
this thread have advocated solving with state machines, using a concept
of state machines in which all the states and transitions are written
out explicitly.  My position is that while it might be *possible* to do
those things with state machines, other methods are often preferable.