4
\$\begingroup\$

I was studying a project that involves implementation of a digitally controlled bridgeless power factor correction (BL PFC) converter. It uses PWM to drive the gate driver of the MOSFET switch and an ADC to sense V and I for voltage and control loop of the control system.

General Reference

I also found they've implemented a finite state machine for the entire system (in CCS .c file.)

Why was a FSM implemented? Is it standard practice in industry to implement a FSM for a project? Can you give example of FSM implementation on a simple embedded system application?

\$\endgroup\$
4
  • \$\begingroup\$ how else would you do it? \$\endgroup\$
    – Juraj
    Aug 20 at 8:58
  • \$\begingroup\$ Why didn't they directly started with conventional programming(i,e. programming for different peripherals) once knowing the requirement for the BL PFC topology ? \$\endgroup\$ Aug 20 at 9:05
  • \$\begingroup\$ When using FSMs, the states can be encoded as data. Changing the behavior of the FSM is as simple as changing the data. \$\endgroup\$ Aug 20 at 16:57
  • 1
    \$\begingroup\$ I might be blind, but - where is the state machine? I cannot find it. CCS is the development environment, which handles the .c and .asm files. The block diagrams are not FSM-s, they are an illustration of the program design unless I read it incorrectly? \$\endgroup\$
    – ghellquist
    Aug 20 at 21:31
8
\$\begingroup\$

A FSM is a structured method of constructing a sequential machine. The machine can only exist in a fixed number of discrete states - ie ‘finite state’.

FSMs can be formally proven for correctness. Other benefits are that they are easy to construct in code and debug. Going from a state diagram to writing code is a straightforward process.

Traffic lights are a common application used to demonstrate FSMs. There are zillions of examples on the web. A microprocessor is another example of a FSM albeit somewhat more complex.

\$\endgroup\$
3
\$\begingroup\$

When using a micro controller to implement a control mechanism like you describe, most programmers would intuitively build/program sort of a state machine anyway.

You do a specific thing at a time (state) and switch (transition) to a different behavior (next state) depending on external information.

There are code frameworks that can help to implement state machines in a clean way. That can be helpful if you have a high number of states with lots of state information and complex transitions.
But for very simple state machines, it is often enough to have a switch case reflecting states and some helper functions to manage transitions.

\$\endgroup\$
2
\$\begingroup\$

I couldn’t find the code: But what’s the alternative?

When you have steps (states) to run though an FSM is the best and obvious solution. It’s easy to draw diagrams for. An enumeration type for the states is a quick and obvious list of possible states. It generally results in easy to read and maintain code (just a switch case statement). It’s also low in memory and runtime requirements (just one variable for the state and a jump instruction).

The other option would be a loose collection of status bits/variables and if statements. Sometimes as code grows you start introducing such status bits. This is a good moment to pause and evaluate if an FSM wouldn’t be a cleaner and better way to implement your code.

I’m a digital design engineer, FSMs are our bread and butter. At least for RTL code the linting and code coverage tools usually “understand” FSMs and can provide helpful insights (e.g. state transitions which are not covered).

\$\endgroup\$
1
\$\begingroup\$

Here's the way I see it.
If the output of a system is determined by its current inputs, you can form a truth table and that truth table can be done by a logic tree (if..if..else....)
If some history is involved, the system has to have memory. And then, the output depends on current inputs and the values in memory.
If there is not just one output but multiple things have to happen depending on inputs and historical conditions, now you need a way to name each resulting condition depending on the trail(s) that can lead to that condition. You need to be able to name them so that you can reason about what should happen on further inputs in such conditions.
To make it possible for multiple people to talk about such systems, you need a paradigm. A way of looking at a system as a set of these conditions we talked about and the events that cause movement between these conditions, along with any other actions that happen along with the movement.
That paradigm is a state machine. State machines can have different states (conditions in the previous paragraph), events/signals (inputs) and transitions between states, along with possible actions on exit of a state, entry of a state, transition, etc.
Then we have UML having state charts, tools to generate code from visual state charts, check for dead-end states, impossible states, etc.
Essentially, FSMs give a new language for thought about systems and for expression of such thought. Something more than just code can do.

I tried to give you a justification that FSMs are a natural outcome !

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.