1. Home
  2. Embedded Programming
  3. Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)?
  4. Page 2

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

Yes.

That is the way in which I, you, and probably everybody except Mr Rubin, is using the term the term FSM in an embedded context.

I have come across young maintenance programmers working on comms protocols and business rules that did not recognise the comms protocols and programs /were/ FSMs. To them an FSM was something they vaguely remembered from university as being something to do with parsing in compilers.

I would not have thought someone using a usenet group on embedded systems could be classified as "young maintenance programmer".

Now a computer is, in a very deep sense, nothing more than a large FSM. However, attempting to design and implement non-trivial systems _solely_ at that level is a concept that had never occurred to me, except possibly when we have all had too much to drink in the pub :)

Reply to
Tom Gardner
Loading thread data ...

Excuse me, one of the claimed advantages of the FSM approach was that you could validate an FSM implementation by enumerating all of the states and making sure each transition does the right thing.

If you widen the idea of an FSM until you can have 100s of bits of state variables and still call it an FSM, that approach becomes impractical. You're back at the verification methods used for arbitrary programming. In that case, I don't see what's so great about calling something an FSM rather than just ordinary code.

Sure, I find that idea crazy too, but that's what I think was being presented here. Otherwise, what is the difference between an FSM-based implementation, and a non-FSM one?

Reply to
Paul Rubin

You can indeed. Nobody except you conceived that might mean _all_ aspects of a design specification and implementation were coded as an explicit FSM.

The number of bits is unimportant. What is important is to use good taste in implementing a design in such a way that there is a visible correspondence between the specification and the implementation.

And for many purposes an FSM is the most natural way to express and then specify important aspects of an embedded (or other!) system. Hence it is also the most natural way to implement those parts of the design.

No, that wasn't being advocated.

Reply to
Tom Gardner

It varies.

If you take the VxWorks driver course, they have a "three-layer" solution where the lowest layer ( ISRs ) is minimal, the middle layer is a kernel-mode ( or user mode ) task and the upper layer is just plain-old userspace code. But the middle layer is still a task.

In that, the "middle layer" manages the protocol FSM. I'm afraid I don't remember much detail beyond that.

I think the concern then would be the sheer size of the driver and whether or not the ISR coudl turn interrupts back on or not ( probably can, usually ).

--
Les Cargill
Reply to
Les Cargill

*EVERYTHING* on a computer is a FSM as a computer is a FSM. What's your point? 
--

Rick C 

Viewed the eclipse at Wintercrest Farms, 
on the centerline of totality since 1998
Reply to
rickman

Read the context in which I made the statement, especially the comments by Mr Rubin.

Reply to
Tom Gardner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.