Finite state machine development.

Go To Last Post
128 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have found in many places that finite state machine is useful tool to solve complex problems. But so far i've never needed FSM.

I have gone through wiki page https://en.m.wikipedia.org/wiki/State_diagram

But I do not understand how to use the FSM in embedded programming. I do not know what is the benefit of drawing state diagram.

I want to learn FSM how to create a state diagram but i don't know where to start.

Please suggest a simple way to create a state diagram

Edit -
https://www.embedded.com/programming-embedded-systems-the-easy-way-with-state-machines/

Regards
Djsarkar

This topic has a solution.
Last Edited: Tue. Aug 25, 2020 - 08:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Personally, I don't use state diagrams (just as I don't usually use flow charts for general programming). I just create the FSM as needed. Oh, I do "design" it, but not with a state diagram.

 

Jim

 

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

 

 

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

ka7ehk wrote:

Personally, I don't use state diagrams (just as I don't usually use flow charts for general programming). I just create the FSM as needed. Oh, I do "design" it, but not with a state diagram.

 

Jim

OK Thanks, when do you need a FSM?

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

>> Please suggest a simple way to create a state diagram

 

Generically: https://en.wikipedia.org/wiki/St...

Probably most popular in professional circles (and best for your CV): https://en.wikipedia.org/wiki/UM...

 

In context: https://barrgroup.com/embedded-s...

https://barrgroup.com/embedded-s...

 

Last Edited: Thu. Aug 6, 2020 - 05:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Djsarkar wrote:
I do not know what is the benefit of drawing state diagram.
Design review, execution of the design (simulation, desk test precursor to bench test, ...), then possibly source code generation

Djsarkar wrote:
I want to learn FSM how to create a state diagram but i don't know where to start.
Ragel is one way

Djsarkar wrote:
Please suggest a simple way to create a state diagram
not simple are some tools

 


Tools and Tips | The Embedded Muse 314 (Ragel)

Tools and Tips | The Embedded Muse 402 (Ragel)

[CODE][C] Parsing strings flexibly/efficiently with Ragel | AVR Freaks

Simple State Machine Architecture in NI LabVIEW - National Instruments due to https://www.avrfreaks.net/forum/labview-now-free-non-profit-use#comment-2958986

QM: About QM™

 

"Dare to be naïve." - Buckminster Fuller

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

Djsarkar wrote:

ka7ehk wrote:

Personally, I don't use state diagrams (just as I don't usually use flow charts for general programming). I just create the FSM as needed. Oh, I do "design" it, but not with a state diagram.

 

Jim

OK Thanks, when do you need a FSM?

 

This link (https://www.state-machine.com/qpc/index.html) is an excellent start as to when you might decide on using FSMs, they also have excellent application notes in the "Example applications" and "State machine design patterns" section of their application notes here

Hope it helps to clear up your question

 

Ilya

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


Djsarkar wrote:

OK Thanks, when do you need a FSM?

 

I use them to drive the user interface of some products. Consider a simple front panel...

 

 

This is used to operate the unit but also to setup various options and parameters.

 

What each button does depends on what button(s) was/were pushed before.

 

Press a number and and it registers on the display. Press another button and the display accumulates the entries but push one of the other buttons and you might accept the previously entered number or you might abandon them.

 

That's a state machine.

 

This is the original state diagram I sketched out in the early stages of the project...

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Well there is a good tutorial right here in AVRFreaks on FSM: https://www.avrfreaks.net/forum/...

I have found them handy to parse incoming serial streams, say from a GPS (NEMA) or a serial sensor (S.N.A.P protocol), or modem (x,y, or z modem protocol).

Just to name a few.

 

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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


Djsarkar wrote:
finite state machine is useful tool to solve complex problems

Not necessarily "complex" problems.

 

Funnily enough, this turned up in my Twitter feed only the other day:

https://twitter.com/Elektor/stat...

 

https://www.elektor.com/programming-the-finite-state-machine

 

It says "PIC" - but that really shouldn't relevant when programming in 'C'.

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The simplest FSM is a light bulb. It has two states, on and off. There is no middle or 3rd state. When you operate the light switch, which is an external event, the light changes state from one to the other.

 

I have a project that operates a stepper motor. I have defined 5 possible motor states: stopped, slow forward, fast forward, slow reverse and fast reverse. I also have a couple of pushbutton switches. Operating the switches in various ways (single press, press and hold, release, etc) causes the state machine to transition between various states, according to the rules I have defined.

 

This diagram (stolen from https://brilliant.org/wiki/finit...) describes the FSM of a traditional mechanical turnstile (common example of FSMs):

 

It has two states: locked and unlocked, and two external events, push and (insert) coin. The diagram shows how the states change according to the external events.

 

e.g. you cannot open the turnstile until you have inserted a coin, i.e. pushing before you have inserted a coin does not change the state from Locked. Inserting a coin and then pushing the turnstile (to enter the building) causes the turnstile to return to the locked state, stopping the person behind you from getting a free ride, until they in turn insert a coin and push.

 

Inserting a coin into an unlocked turnstile does not change its state ... and is therefore a pointless waste of money.

Pushing a locked turnstile does not change its state ... and is therefore a pointless waste of energy.

Last Edited: Thu. Aug 6, 2020 - 10:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Get a book, or link on digital logic...look at mealy & more state diagrams...you will see a lot.   Really, grab a pad of paper & start drawing, to start learning.

The state machine can really untangle logic that looks like a completely twisted mess & organize it into a maintainable & understandable states (you might feel more comfortable calling them modes).

If you have some course in digital logic, you probably will cover some basics of state machines.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Let me start with simple example, there is LED and Switch, When switch is OFF, LED will OFF and when switch is ON LED will ON

 

My state diagram

 

As you can see in the picture, I do not understand two arrows they turn around and come to the same place. What it does mean in state diagram?

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

Wouldn't that tell you that you remain the same state (led  on or off)?  That highlights a potential input or condition that might have traveled elsewhere (to another state, except, it just stayed where it was).

 

For example,  you are in the state of  "enter last name"  you hit the clear entry button input, and they design it so you remain in the same state, entering last name.  Now if someone wanted to, they could instead have clear entry button inputgo to a different state like: open trap door.

 

Consider the state diagram to be somewhat like a roadmap connecting  places (states together).   There may be more than one path that leads from point A to B...or there may be only one very specific path.  In some cases there is no way out back out...for example

 

timerzero state===>10 second warning state===>explosive detonation state   

 

 

Don't make something simple, hard...Draw yourself a state diagram going from sleeping state to arriving at work and many states in between.  Inputs could be time, weather, food, sickness, call from the boss, body odor,  etc.   Depending on the inputs, you might end up back in the bedroom sleep state, or  the  coffemaking state.   Forgot keys input, may lead to  locked out state.   

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Aug 7, 2020 - 03:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Modified version 

 

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

Something more complex one motor and four switches

 

Start motor when button 1 press

Run forward when button 2 press

Run reverse when button 3 press

Stop motor when button 4 press

 

How to make state diagram

 

 

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

So once you get to stop you can't leave stop!!!  Does that make sense to you, don't you need a way back to start??  You are also neglecting to label your arrows with your inputs..how do you expect the diagram to show what is going on  if you don't bother to put the information on it?  look up mealy & moore state machine before doing anything else.

 

what exactly do you mean by this?

 

    Start motor when button 1 press

 

How is it different than your other choices (forward  or reverse)?  Think carefully before you write.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Aug 7, 2020 - 05:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Always think about current state and transition. What am I doing now and how do I get to the next state?

 

currently your drawing has only one conditional transition.

 

otherwise start will goto reverse then stop. then stay there

 

A common example of a FSM is traffic lights, or another simple one is an up/down counter.

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

avrcandies wrote:

what exactly do you mean by this?

 

    Start motor when button 1 press

 

How is it different than your other choices (forward  or reverse)?  Think carefully before you write.

I apologize to you,  there are three button and one motor  in my example,

when user press first button, motor will start and run in forward direction

When user press second button , motor will start and run in reverse direction

When user press third button , motor will stop

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

Kartman wrote:

A common example of a FSM is traffic lights, or another simple one is an up/down counter.

 

 

I understand the counter Table for 3 bit UP counter

 

 

 

Last Edited: Fri. Aug 7, 2020 - 09:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have to make clear what kind of states you have, and how to move between them when you press the keys.

 

states:

stopped

running cv

running ccv

 

that's all (in this simple case)

 

Then the arrows (your keys) get's added.

And then it gets clear if you really want to be able to go from cv direct to ccv or it have to be stopped first (or perhaps you need make a extra state (or two) that mean change direction) 

 

Edit: spelling

Last Edited: Fri. Aug 7, 2020 - 11:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For things like this I actually prefer the diagram form of Backus-Naur Form

 

This is the syntax of pascal (how the compiler would read it), but I use it to get a picture of what is legal in the different menus etc. 

 

  https://condor.depaul.edu/ichu/c...

 

Add:

the diagram form is at the end of the file :)

Last Edited: Fri. Aug 7, 2020 - 10:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The small circle means that the external event has no effect, e.g. pushing a locked turnstile, or putting coin into an open turnstile, doesn't cause a change of state.

 

Can the motor change state from running CW to running CCW, or does it have to pass through the 'stopped' state first ? That may have important implications in a real-life application, e.g. a car, where it would inadvisable to engage reverse gear whilst travelling forward at 50mph, even if the mechanism permitted such a change of state.

 

 

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


When I read through the TWI section of the AVR-0 series datasheet, I was overwhelmed.   I realized writing down the specification in a state diagram was the only way to go.   In addition, this lets one identify the required states of the software (here, the mode, and the count of bytes to read or write).   This could potentially be all implemented in interrupt handlers with a handful of global state variables.

 

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

MattRW wrote:
I realized writing down the specification in a state diagram was the only way to go.
Concur for design review though there's the issue of change visibility; PCB designers have that issue (version control of graphics)

Department of Computer Science and Technology – Raspberry Pi: Introduction: What is a Turing machine? | Finite state machines

by Robert Mullins

...

Instead of a state table, the program can also be represented with a state diagram:

...

What’s the Difference Between Version-Control Systems for Software and Hardware? | Electronic Design

 

"Dare to be naïve." - Buckminster Fuller

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

Does it make any sense?

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


Djsarkar wrote:

...there are three button and one motor  in my example,

when user press first button, motor will start and run in forward direction

When user press second button , motor will start and run in reverse direction

When user press third button , motor will stop

 

 

Djsarkar wrote:

I understand the counter Table for 3 bit UP counter

 

Why not finish one example first before lurching on to another one?

 

Your motor example, if you took your words literally, could be drawn like this...

 

 

...however, as others have said, going from CW to CCW might not be a good idea. So this might be the correct implementation...

 

 

The above is a completely unambiguous description of how your motor machine works.

 

Don't worry about clever software tools for diagramming your state chart until you can draw one with pen and paper.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

One that I can't detail because of commercial confidentiality: my cat feeder has a state table sufficiently large that (a) it required some interesting gymnastics to reduce its in-memory representation and (b) is so complex that it has to be autogenerated from a spreadsheet to ensure that a change in design is properly represented in the C code that implements it (as a great big array). Each state[1] has the possibility of being acted on by any of the system events[2] and either remaining where it is, or moving to a new state; on the way to the new state it can perform arbitrary atomic actions0.

 

Then there are other state machines that run above or below this one, sequencing the operation of the program, handling 2.4GHz protocols, driving the weighing chip etc... turtles all the way down.

 

[1] nothing_happening, cat_opened, user_opened, cat_feeding etc

[2] lid_stopped, lid_button_pressed, weight_measurement_complete etc

 

Neil

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

Kartman wrote:
A common example of a FSM is traffic lights,
As I was reading this thread I was about to post that traffic lights was a good way to learn about state transitions, then I read this, so I'll simply add "+1000"

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

clawson wrote:

Kartman wrote:
A common example of a FSM is traffic lights,
As I was reading this thread I was about to post that traffic lights was a good way to learn about state transitions, then I read this, so I'll simply add "+1000"

 

In it's simplest form, the control events are all timer-driven. If you extend the definition to pedestrian crossings, then humans pressing buttons come into the equation.

 

The lift (elevator) in my apartment building is another example (which I sincerely hope is well coded !).

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

I think this state diagram is perfect for motor

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

Djsarkar wrote:

I think this state diagram is perfect for motor

 

It's not complete though. See post #26.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Brian Fairchild wrote:

Djsarkar wrote:

I think this state diagram is perfect for motor

 

It's not complete though. See post #26.

At Start forward state and start reverse state why do you think there should be b1 or b2

 

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

Djsarkar wrote:

At Start forward state and start reverse state why do you think there should be b1 or b2

 

What happens if you press B2 and you are running forwards? You have said that their is no state transition when you press B1 while in that state but what about B2. The art of good program design is to be consistent and unambiguous.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Last Edited: Fri. Aug 7, 2020 - 03:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can often simplify things a great deal by categorizing what is happening in states:

 

Things that always happen once when entering the state (example: when entering state:  begin_cook_chicken, dispense 1/2 cup flour)

 

Things that happen repeatedly while in the state  (example:  check timer value for time's up, check temperature, blink cooking led)

 

Things that always happen once when leaving the state (going to any other state) (example : open oil drain valve) 

 

While this arrangement is not absolutely necessary, it can save writing a lot of logic conditions within the states or duplicating the same actions in multiple states. 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Aug 7, 2020 - 04:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another thing that hasn't been mentioned it that each arrow can contain some type of output action information.  For example, maybe each arrow outputs a message to the terminal, or it could be any action...open a trap door,  make a pin go high,  turn on a siren...

 

So

all arrows heading towards FWD state send out "forward mode" message on the terminal

all arrows heading towards REV send out  "reverse mode"  message

all arrows heading towards  STOP send out  "stop mode" message

    Note that is a strong reason for arrows that go from one state back to the exact same state...it gives a place to specify an output for that input condition in that state, for example "no change", or whatever you like to say....it's up to you.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Aug 7, 2020 - 04:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Not to toot my own horn but you might want to also look at an article I wrote;  Finite State Machine for embedded systems

Happy Trails,

Mike

JaxCoder.com

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

I liked the nice, clean layout of your pages. Well done.

 

About the only nit-pick I had was your use of external interrupts for switches. Coupled with the use of a timer for debounce, the 'better' solution (better meaning a more robust method) would be to just poll the inputs in the timer isr.

 

The reasons behind this are:

1. mechanical switches (and systems) are generally quite slow in relation to the speed of the microcontroller, so having microsecond response via an interrupt is not required.

2. external inputs are open to the real world. Coupled interference and the usual switch bounce are sources for multiple interrupts. Worst case, unfiltered inputs can give a storm of interrupts - crippling the system.

3. As part of a robust filtering method, you want to sample the input multiple times.  

 

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

Kartman wrote:

 

The reasons behind this are:

1. mechanical switches (and systems) are generally quite slow in relation to the speed of the microcontroller, so having microsecond response via an interrupt is not required.2.

 

This may be another question but I do not understand your point. 

 

microcontroller is very fast as compare to external devices such as switch buttons, relays, LCD etc. 

 

I don't understand reason How is interrupt related to time?

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

That's a very interesting and informative tutorial--good explanations....lots of goodies in there.  Time to break out  my C++ hat

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

I don't understand reason How is interrupt related to time?

You question doesn't make sense...what is an interrupt for ??!!

 

Anyhow, too many interrupts all at once can overload the system.  So potential switch bounce inputs should be avoided.  There is no need at all to respond to each and every switch bounce event.

Remember when you press the button once you could get 1, 10, or 1000 requests, depending on the amount of bounce.   To a certain extent, similar things can happen on the button release.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Aug 8, 2020 - 02:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why interrupts are required is a different question. It's not related to state diagram. It's the question in the response of kartman reply

I appreciate all your advices, I got a good start for making a state diagram.

Last Edited: Sat. Aug 8, 2020 - 06:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman & avrcandies - Thanks for the kind words.

Happy Trails,

Mike

JaxCoder.com

Last Edited: Sat. Aug 8, 2020 - 01:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi 

I am struggling at some place, I do not understand how many states there should be, transition  like I take example of UART communication

 

I have taken four states

 

 

 

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

You really know how to confuse yourself!

 

Transmit and receive in a u(s)art are two independent processes.

 

eg: for transmit the sequence is: start, bit 0,bit1,bit 2,bit3,bit4,bit5,bit6.bit7,stop. You could add a state to wait for a byte to be written to the holding register.

 

For receive, you basically have a state to wait for a falling edge to denote the start of the start bit, then delay half a bit time, sample the start bit to make sure it is a start bit then sample 8 bits every bit time then the stop bit and ensure the stop bit is a '1'. Rinse and repeat.

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

You don't try to apply a state machine to every last thing you come across because it's hip and trendy to do so. You simply need to know when a state machine would be useful and then see opportunities to apply one when you think it would make a good/clean solution.

 

So in the realms of UART use you are unlikely to use states for the simple process of just sending and receiving the bytes (unless you really are trying to operate "half duplex" and need to know when you should be sending and when you should be listening). But in UART use a common place where you maybe would try to use a state machine is for parsing/processing data/commands. Say you had a system where the AVR could be sent different "words" to tell it to do things. Maybe in it's command set, among other command operations it can receive "CHANGE" meaning "Change LED state" and "CLEAR" which means "Clear cycle counter" oh and maybe it can be sent "SLEEP" which means "put the AVR into SLEEP mode"

 

So you have an AVR that sits waiting for incoming characters. Now of those 3 commands: CHANGE/CLEAR/SLEEP you will receive a single character at a time. There may be other commands too but if you receive an 'S' then perhaps that is the only command that begins with 'S' so if you see that you almost don't need to wait for any more to arrive. As soon as you see an 'S' you know it must be "SLEEP" that is coming in. But say you receive 'C' now you know that it can only be CHANGE or CLEAR but you cannot know yet which one it is but the first C has already narrowed it down to one of these. So all you can now expect are 'H' (as part of CHANGE) or 'L' (as part of CLEAR) but if you get any other character then it cannot be a valid command as you can only expect 'H' or 'L' and anything else is "invalid command". So this is the kind of place where you might see the opportunity to apply finite state logic. The 'C' moves you from the 'waiting_for_command' state to "waiting_for_change_or_clear" state.

 

So don't think you have to turn everything into a state machine. Just apply state machine if it looks appropriate.

 

In fact in UART reception things are actually quite unpredictable. Unlike transmit where you might well know where you are in a sequence and what should therefore happen next, with reception the other end could send some data at any moment so it's operation is quite unpredictable. For instance you can't really sit in a "waiting for character" state as it could be 5 seconds, 5 minutes, 5 hours, 5 days or 5 years before the other end chooses to send the next item.

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

FSMs are very useful for event-driven programs, where the system is waiting for any of a number of possible external events to occur. Depending on the current machine state, the external event may cause the state to change, or it may be ignored. In embedded development, an external event may be an interrupt, or the result of polling a pin's state.

 

Imagine the turnstile example again. At any (unpredictable) point in time, a person may push the turnstile. But it will only move if a coin has already been inserted to unlock it. Otherwise the push has no effect and no state change occurs. The state changes would be: locked -> unlocked -> opening -> locked. The push only has an effect if the turnstile's state is 'unlocked'. You could argue whether 'opening' is a valid state or not ;)

 

You might use a FSM for receiving serial data; e.g. you begin in the 'waiting for a start bit' state, then receive bits ('receiving') until either the stop bit is detected ('complete') or an error occurs. At which point, you go back to 'waiting for a start bit'. https://hdlbits.01xz.net/wiki/Fs...

 

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

 

I think that, instead of trying to come up with imaginary cases, you need to write some real code using a state machine.

 

So here's a challenge...

 

Your project is to write the code for a digital lock for a money safe. The hardware team have already made the control panel...

 

A colleague started the project but has now gone on holiday so you need to finish it.

 

He has written the following functions...

 

uint8_t getkey(void) ...which will return the debounced state of any key press as the ASCII character of that key, or 0x00 if no key has been pressed.

 

...and ...

 

uint8_t lock(uint8_t state) ... which is passed 0x01 to unlock the safe and 0x02 to lock the safe. It returns 0x01 if the successful and 0x00 if unsuccessful

 

He has also arranged it so that 'printf()' will print ASCII text to the LCD display on the panel.

 

To open the safe you must enter '1396#'

 

If you enter the wrong code three times in a row you will be locked out of any furthers entries for 5 minutes.

 

Even when locked out, pressing a key will cause it to be displayed on the LCD.

 

 

Achieve this and you will understand a great deal about state machines.

 

PS yes, there are  couple of deliberate gaps in the specification.

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Last Edited: Wed. Aug 12, 2020 - 02:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am struggling at some place, I do not understand how many states there should be

That's like saying I don't know how many windows there should be in this house....there is not really a definite number....you break down the system into logical "states". 

Either a state that is a good stopping & waiting point, or a state that is accomplishing a particular step (or steps)...states can be high level or very low level

 

 

high level:

taxi mode

take off mode

landing mode

 

 

low level:

disk track located state

waiting for read pulse available state

measuring read pulse width state

stopping motor state

 

You are the one to determine the steps (states) to take.

 

Think about what you are doing ...list all the possible states you can think of...some will become states,, many just go in the trashcan

states:

filling tank state

flushing state

lid up state

lid down state

handle down state

handle up

low pressure

high pressure

leak detected

seat up

seat down

person sitting

overflow detection

clog detected

abort flush

 

You can tie some of these states  together to model a toilet system--some of these might be used as inputs to get to certain states (for example low pressure sensor might lead to abort flush state, or you might have a low pressure system state).....now you try making one up yourself.   Running the fireplace,  making  cookies... driving to your aunt's .....you name it

 

.... don't worry about any coding yet, this is logic flow

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Aug 13, 2020 - 02:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have transient states that involve specific changes in the system. And, I have stable states where it may stay for some time. As mentioned above, there is no "right" number. It completely depends on how you divide things up.

 

Jim

 

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

 

 

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

I will add that nothing should be be bigger than one sheet of paper.

 

 

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

Um, my cat-feeder state diagram took up three 4ft by 8ft whiteboards... but it was much smaller once we photographed it :)

Pages

Topic locked