Finite State Machine and software layers

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

Hello! I programed several times finite state machines to handle a gsm module. They worked fine, but I was never satisfied with the implementation. 

 

For example, to send a UDP message to the server I have to:

0- initialize pins, uarts, etc

1- drive low a power pin

2- wait for the module to drive high the "on" pin

3- send AT and wait for OK

4- read simcard CCID

5- configure context (apn, user, password)

6- register and receive local IP address

7- configure my udp connection to my server

8- send message

9- wait for reply, ack or remote command and procecss the received data

10- wait for another message to be sent, 

etc

etc

 

That implemented with only one big state machine was hundreds of code in a big switch(actual_state). 

The firsts tasks are hardware related, the seconds are network task, then my application layer (send and process data). Everything is mixed, and I'm starting to think that must be a better way to implement.

Maybe a state machine to ensure that the module is powered on and operational (including sending periodically AT and receive the OK), another state machine to ensure that the module is connected (and maybe check RSSI), and a third state machine to handle the application data sending and receiving.

 

What do you think? I don't want to complicate things but my last implementation was hard to maintain even from me (the programmer)

 

Thanks

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

Sounds like you need a table driven state machine.

#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

jorge.ar wrote:
... and I'm starting to think that must be a better way to implement.

Hierarchical State Machines | Key Concepts | Resources | Quantum Leaps

...

 

State Nesting

...

The value of state nesting lies in avoiding repetitions, which are inevitable in the traditional "flat" FSM formalism and are the main reason for the "state-transition explosion" in FSMs. 

...

jorge.ar wrote:
What do you think?
Sounds good

Frameworks, RTOS, and OS have features to ease communication between state machines (queues, pools)

 


QP/C: Examples for Third-Party Middleware

[lwIP]

 

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

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

I use, fairly often, one or more state machines inside one grand state machine. Works well. I do find it very helpful and important to use state names that indicate, strongly, which machine owns that state.

 

Jim

 

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

 

 

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

jorge.ar wrote:
That implemented with only one big state machine was hundreds of code in a big switch(actual_state).

...

Maybe a state machine to ensure that the module is powered on and operational (including sending periodically AT and receive the OK), another state machine to ensure that the module is connected (and maybe check RSSI), and a third state machine to handle the application data sending and receiving.

Almost certainly separating the FSM is the way to go, at application level you don't want to messing around with I/O pins to power up devices. Linking everything up with a controller of sorts looks interesting, I suppose that "controller" is actually a "device driver".

 

If you need to prevent your "SendMsg" function bocking, then callback functions can be useful up to the point where daisy chaining gets out of hand.

 

gchapman wrote:
Hierarchical State Machines | Key Concepts | Resources | Quantum Leaps

I read that article and have yet to find a use for it. It seems to help only when you have common event handling to many states so a higher order state can offload handling an event to a state lower down in the hierarchy.

 

I don't think it will help the OP because you still have one big FSM it's just structured hierarchically instead of flat.

 

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

Remember, with a state machine, you have many options, including:

 1) Taking actions when entering a state (coming from one or more other states)

 2) Taking actions whenever leaving a state (going to one of possibly several)

 3) Taking actions when repeating a state (such as monitoring as switch),  repetitively until leaving that state

 

Depending on how you use these (or can use these), it may greatly simplify the number of overall states needed or their complexity.

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