real-time and state machine reference?

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm wondering if anyone can recommend a website or printed text the treats the subject of real-time systems and state machine programming in some detail. A reference that uses C for its examples would be ideal.

I've been working with AVRs for more than a year now, and think I understand the basics of main loop vs. interrupts, and have made some successful designs, but am interested to learn more in depth.

What are your favorite resources for learning more on this subject?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://en.wikipedia.org/wiki/State_machine

It contains a lot of links too, to relevant topics like Automata based programming or coroutines.

In general Wikipedia has a lot of interesting articles on computer science and relevant topics, some quite exotic too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For a book recommendation on realtime programming I'd offer this one:

http://www.amazon.com/Real-Time-...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a modest State Machine tutorial on my personal web site:

http://www.proaxis.com/~wagnerj

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice write-up Jim. In college they used the example of a pop machine for teaching state machines, similar to the stoplight. I like the bubble and arrow diagrams. (Very nice picture of Mt. Jefferson too.)

Another common example is textual pattern matching. In fact combining a state machine with a stack makes a very nice parser, useful for projects ranging from command processors to NMEA processing for example.

C: i = "told you so";

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

state machine framework:
http://state-machine.com
many application notes. The theory explaned very thoroughly.
And the book "Practical UML Statecharts in C/C++".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
I have a modest State Machine tutorial on my personal web site:

http://www.proaxis.com/~wagnerj

Jim

Very nice tutorial!

cs

I'm happy ytd, today, and tmr :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With some clever macros you can do some pretty nice things that under the hood create state machines like these using Duff's device; e.g. Protothreads and coroutinues. State machines in essence allow you to write good ol' spaghetti code without using an single explicit goto. The underlying algorithm can be less visible and readable.

Though state machines can replace code that's riddled with extremely complex deeply nested flag checking/setting code with a few clear states and as such is very useful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ucosII book is a good description of real time task switchers. So is the freertos manual.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
...state machines can replace code that's riddled with extremely complex deeply nested flag checking/setting code with a few clear states ...

Yeah but where's the fun in that? :twisted:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
jayjay1974 wrote:
...state machines can replace code that's riddled with extremely complex deeply nested flag checking/setting code with a few clear states ...

Yeah but where's the fun in that? :twisted:

Also, there are cases where carefully designed shallowly nested variable tests can replace extremely complex state machines.

Consider the case where state transitions are permitted on single-bit tests only due to design limitations.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Also, there are cases where carefully designed shallowly nested variable tests can replace extremely complex state machines.

I'd like to see some evidence where this is so. Obviously, if it is simple combinatorial logic, then a finite state machine would be inappropriate. FSMs are not a magic 'cure all' but another tool to help solve a problem in a structured and testable manner.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Also, there are cases where carefully designed shallowly nested variable tests can replace extremely complex state machines.

I would like to see the code first before putting money on it,
Quote:
Consider the case where state transitions are permitted on single-bit tests only due to design limitations.

If not all inputs are tested, and the designer chooses to do so having considered the consequences, they have simplified the STD for the machine. This is still very robust!

Writing non-FSM code "very carefully" for complex systems but without the rigor required when designing a FSM, whilst it can be made to work, will generally be more difficult to document, more error prone due to unforeseen inputs, more difficult to debug when it does occur and more difficult to fix & maintain.

BTW Jim Wagner resource is a good one and Smiley's book C programming for microcontrollers touches on state machines as well.

I suspect one reason FSM's are not as popular as they should be, is that they require some planning & documentation. Something that many programmers don't like to do! :P

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Consider a pair of n-bit up counter that increments on every external clock cycle (we assume that they don't have a metastable state for simplicity). I wish to find the sum of these two counters. I have no idea how one would encode all the possible counter states and combinations of outputs.

Whereas it would simply be output = a+b. Now if I relax the definition of state machine, and permit outputs to derive from some external variable, it would be one state with an unconditional transition to itself. But that would be cheating.

In my original post, I refer to the horrible mess of a Moore machine that the earlier versions of Synopsys generated. Yes. This means that something as simple as

always (@posedge stable_input)
begin
out <= ina + inb
end

became a two-page, 80-col pile of confusing state transitions. But that's an extreme case.