This article is the second part of the first one where the basic pairing logic of Earphones is designed using a simple State Machine. Here, we would handle the case when the user long presses the power button with the help of a separate State Machine running in parallel to the first one.

Also, this example would showcase how running parallel State Machines facilitates breaking down a complex system into multiple event-driven State Machines running concurrently.

We would design State Machines on an abstract layer by assuming function names that perform Bluetooth-specific operations for us. The actual function names and signatures would differ from platform to platform.

Using a tool helps design State Machines faster, and ensures that future maintenance is easy. We will use FsmPro to design State Machine logic.

Design and Implementation

Let’s name the State Machine responsible for handling execution tasks when the power button is pressed during power-on as stm_power_interrupt.

As mentioned above, the software module BLE_Interface provides us with the API’s at the abstract layer which internally is assumed to call Bluetooth API’s. This helps us in skipping the intricacies of Bluetooth stack implementation and focus on the application layer design instead.

In the figure below, the Software module BT Logic which houses our State Machines interacts with the module BLE Interface for dependencies. For simplicity, it is shown with sample function calls.

The Power Interrupt State Machine

In State Machine terminology, the Initial state gets called first by the system. Let’s name this state init_power_interrupt.

On Power up, Initial State is also the entry point of any State Machine. The initial condition is the optional condition to executing the initial state which means the Initial state won’t get executed till the initial condition is not satisfied. In this case, we do not have an initial condition.

In the init_power_interrupt state, we check if the power button is pressed long enough to consider it as an intentional press with the help of a minimum debounce period.

if((true == powerButtonStatus) && (getPressInterval() > MIN_DEBOUNCE_PERIOD))
{
    //Execute the init_power_interrupt state initiating the state machine
}

The screenshot below shows the implementation of the tool. Note that there can be only one initial state for any given State Machine. Also, we have defined the macro for a minimum debounce period with a value of 500 milliseconds. Any button press of less than debounce would be ignored by the State Machine.

The power button can be long pressed for 3 different purposes depending on the duration of the press in ascending order:

• To play/pause current audio
• To switch off the device
• To initiate pairing with an external device

We’ll get the press interval from the abstract function getPressInterval() in milliseconds to compare the interval for which the button is pressed. The following code snippet shows we can get the interval and execute the respective code. Note that it is very important to decide the order in which conditions are placed.

if((true == powerButtonStatus) && (getPressInterval() > MIN_DEBOUNCE_PERIOD))
{
	int local_btn_time = getPressInterval();

	if(local_btn_time <= PLAY_PAUSE_DELAY)
	{
		//Execute code for play pause bluetooth operation
	}
	else if(local_btn_time <= SHUTDOWN_DELAY)
	{
		//Execute code for Turning device Off
	}
	else if(local_btn_time > SHUTDOWN_DELAY)
	{
		//Execute code for pairing external device
	}
}

Play pause Event

When the duration of the press is less than or equal to a programmable delay of the play pause event, State Machine considers it as a play pause event trigger. The Bluetooth Interface is sent a signal that a power button interrupt has been received.

State Machine then transitions to the state play_pause_triggerred() and executes the function ble_play_trigger() to play or pause the audio at the hardware level. Notice we have included the file “ble_interface.h” in the top right corner.

After executing the play pause event at the hardware level, State Machine transitions back to the initial state with a simple transition with no condition as shown above.

Power off Event

Now if the duration of the long press of the button is more than the play pause delay which is 1 second(configured at the top) but less than the shutdown delay, State Machine then transitions to shutdown state where it calls the BLE interface functions to clear cache and stop ongoing operations and perform a system shutdown.

As expected the device would shut down after the event meaning State Machine would cease to exist.

External pair Event

An external pairing event is triggered when the duration of the button press is more than 2 seconds. The Bluetooth device makes itself available for pairing to any external device after successful completion of which the newly paired device is connected for audio playback and added to the list of paired devices.

Control reaches the connected state when the connection request from the external device was successful.

In the connected state, device playback drivers are enabled. Earphones routinely communicate with the paired device to perform audio playback functionality.

However, In this state Earphones could lose connection with the external device for multiple reasons like the connected device getting turned off, going out of range, etc. Hence, it is essential to continuously check for connection errors in this state.

When a connection error occurs, Earphones confirm the error by reproducing it for a certain amount of configurable time. We use a macro MAX_CONN_ERROR_RETRY with the value 60 as the retry parameter.

If the connection error sustains for more than 60 times it is checked in the transition shown below, Earphones then confirm that an error has occurred and makes themselves available again for connection to paired devices.

On zooming out in the tool, the complete State Machine diagram now looks as shown below. Notice the macro MAX_CONN_ERROR_RETRY is defined in the top right corner of the figure.

Notice the control also transfers to the initial state init_power_interrupt from the connected state on confirmation of the connection error.

Final thoughts

In this way, we’ve designed a State Machine which handles all the operations when the power button is long pressed by the user when the earphones are powered on. This State Machine is designed in such a way that it runs in parallel to any other State Machine running in parallel to handle its respective task.

You can find the project file here and get the tool here. Note that if you click run and generate code, you will get a compilable code as an output with two files stm_power_interrupt.h and stm_power_interrupt.c. You can make any changes you would like to the design made above and use the code files to integrate your main function or scheduler however you choose to interface.

In this article, we will design and implement the pairing and connection logic of Bluetooth Earphones using State Machines. The logic relatively remains the same for most Bluetooth devices.

This example will showcase how using State Machines facilitates breaking down complex logic into smaller independent tasks. We will design the State Machine on an abstract layer by assuming function names which perform Bluetooth-specific operations for us. The actual function names and signatures would differ from platform to platform. Using a tool like FsmPro helps in designing State Machines faster and ensures convenient project maintenance.

Project Creation

To create a project in FsmPro, simply use the file menu (File ->New Project). A project would be created with the default project hierarchy. The default project hierarchy consists of a Hardware Module layer which contains a Microcontroller layer which contains a Software module layer which in turn contains a State Machine layer. The project hierarchy is simply used to structure a project and you can add, modularise or rename any element in the hierarchy as you want.

In the image below, the top-most layer is opened which shows the Hardware module as a process item; All abstract hierarchy elements are process items in FsmPro and it is possible to link them with function calls or APIs and even add global variables in the form of memory items which shall see later in the design.

Let’s name our project Bluetooth Controller with two software modules: BLE_Logic to house our state machine design and BLE interface to provide the APIs to call Bluetooth stack operations.

Design and Implementation

As mentioned above, the software module BLE Interface provides us with the API at the abstract layer which internally calls Bluetooth-specific implementation. This helps us in skipping the intricacies of Bluetooth stack implementation and focus on the application design instead.

In the figure above, the Software module BT Logic interacts with the BLE Interface module for dependencies. For the sake of simplicity, the interaction is shown with dummy function names.

Let’s name the State Machine responsible for handling execution tasks when the device is powered on as stm_power_on.

Power On State Machine

In State Machine terminology, the Initial state is called first by the system. Let’s name this state power_on.

Upon Power up, the earphones should attempt to connect to a device it was previously connected with. To achieve this, let’s use a global variable for retrieving the address of the previously connected device. Using the BLE Interface, the previous address can be retrieved in the code as follows:

unsigned long long int prev_addr;
prev_addr = getPrevDevAddr();

On the tool, the above code can be represented graphically as shown in the screen capture below. An Initial State is shown with a black dot on top of the state in FsmPro. Notice that we included the header file ble_interface.h to access Bluetooth stack APIs using the text item feature of FsmPro.

Now that we have the address of the previously connected device, let’s check if the device is available for connection. If available, Earphones would attempt to connect with it. This could be achieved with the following code:

if((prev_addr != 0) && (true == isDeviceAvailable(prev_addr)){
	bool connect_status = attempt_conn(prev_addr);
}

On the tool, this can be simply implemented with the help of a Transition. This transition would transfer the control in the State Machine from the initial power_on state to the attempt_connection state.

Now, If the previously connected device mentioned above is unavailable, Earphones would then make themselves available for connection to any paired devices by calling the function broadcast_as_available(). This is implemented in the state open_to_connect shown below.

Alternatively, the system transitions to the state open_to_connect if the connection attempt in the state attempt_connection had not succeeded for any reason. This is shown with the red transition below when the connection status returns false.

In the open_to_connect state, the device makes itself available to paired devices by calling a Bluetooth abstract function broadcast_as_available() which performs the broadcasting at the Bluetooth stack level.

State Machine control would stay in this state as long as no action is taken by a paired device interested in connecting with the Earphones. The system basically waits for an external paired device to initiate a connection request.

On the implementation level, the device keeps checking for a request from a paired device. If a request is received, Earphones attempt for connection with the help of the function attempt_conn().

When the connection to the requesting device is successful, the State Machine then transitions to the connected state as shown below.

In the connected state, device playback drivers are enabled. Earphones routinely communicate with the paired device to perform audio playback functions.

However, In this state, Earphones could lose connection with the external device for several reasons like the connected device getting turned off or the device going out of range; It is essential to continuously check for connection errors in this state.

When a connection error occurs, Earphones confirm the error by reproducing it for a certain amount of time(Configurable). We use a macro MAX_CONN_ERROR_RETRY with the value 60 as the retry parameter.

In this way, If a connection error sustains for more than 60 ticks of the controller, as is checked in the transition shown below, Earphones confirm that an error has occurred and makes themselves available for connection to paired devices.

On zooming out in the tool, the complete State Machine diagram now looks as shown below. Notice the macro MAX_CONN_ERROR_RETRY is defined in the top right corner of the figure alongside _global_conn_status — the global variable for connection status.

Note that the State Machine control transfers from the attempt connection state to the connected state had the connection succeeded in the first attempt.

Final thoughts

In this part one of this two-part series, We have designed the logic to connect Bluetooth Earphones with a previously paired device. In part 2, We will design another State Machine that runs in parallel and adds a new device to the list of paired devices when the power button is long-pressed. This article is intended to showcase the applicability of State Machines in solving a real-world problem and does not take into account all the intricacies of the Bluetooth stack.

The project file can be found in the examples section of the FsmPro. To get a compilable code, click generate code from the run menu and two output files stm_power_on.h and stm_power_on.c would be created.

This release of FsmPro includes some additional features along with improved usability and graphics performance.

Self transition

FsmPro now supports Self Transition where it is possible to create a transition to and from the same State in a State Machine.

Dot transition rendering

The Initial State would be shown with a Transition from a dot item following visual standard of State Machine rendering.

App tour

It is now possible for to take a tour in FsmPro to have a better understanding of each graphics item. The tour guides the user through the project heirarchy and State machines and each graphics element.

The App Tour is invoked by default after registration. Alternatively, you can also invoke the tour in Help→Take a tour. In addition, the graphics rendering has been improved across the tool for a smoother and reliable workflow.

In addition, we are working on adding support for C++ which shall be out soon.

Thank you for using FsmPro.

Please let us know if you have any queries with using FsmPro by email us at info@fmspro.io.

FsmPro 1.0.1 is available for download Windows and Linux distros.

To help you work across platforms, we have extended support on major Linux distributions: You can use the same project files across platforms.

Apart from adding support for Linux, this release has the following features:

• Added enable switch for autosave functionality to avoid crash for some users.
• Improved error checking prior to code generation.
• Beta period has been extended till end of the year 2020.
• Minor bug fixes

We highly value your feedback and support. Please report any issues or reuqest for features you’d like in FsmPro here.

Thank you.

Stay safe!

FsmPro 1.0.0 is available for download on Windows.

This is the first public release of FsmPro. We’ve made sure our users get all the features essential to design and codify State Machines.

FsmPro is available in beta for now. The beta is available until the end of October. As an early user, you will be shown windows smart screen warning, please ignore it by clicking “more info” and “run anyway”. The certificate builds trust as more users download and eventually stops.

Please feel free to submit feature requests and report bugs here.

FsmPro1.0.0 is released with the following features:

• Code generation from designs
• Support for unlimited state machines
• Unlimited Canvas size
• Graphics support for communication between software modules in a project hierarchy
• Custom project hierarchy
• Auto-update to new features with user consent
• Email support if needed

We highly value your feedback and support. We can’t wait to hear from you.

This release has bug fixes and support for native window support while creating new project. We’ve added the Save As feature as it was the most requested feature. Also, the trial has been reduced from a month to 14 days.

To update the lates release, open FsmPro and select “Check for update” in the “Help” menu or restart FsmPro. Please note that existing AppImage users should get their update through the Website.

We are always striving to make FsmPro more stable and flexible than before for our growing users. mailto:support@fsmpro.io”

We highly value your feedback.

Fit to window

Larger state machines meant you had to zoom out using the zoom tab on the toolbar. Also, you had to use the scroll bar to see your entire state diagram on the canvas at once. Now you can do that with just pressing the “space bar” or using the fit to window action on the toolbar. This makes it easy for you to work and think in terms of the complete state machine.

Shortcuts

We have added all the essential shortcuts to speed up working with FsmPro. Now almost everything you do on FsmPro has a shortcut:

• Escape key to go back to select(default) state from any insert state.
• Ctrl+= for zoom in and Ctrl+_ for zoom in. Zooming is now supported through mouse scroll wheel providing a virtually infinite canvas.
• Undo and redo with ctrl+z and ctrl+y respectively. This should’ve been present from the first release.
• Double click any project entity to show properties widgets. This saves a ton of time.

FsmPro would crash for some users when insert transition or link item was pressed. This issue has been resolved. We’ve moved from stand-alone executable to a Debian package on the Linux platform.

To update, select “Check for update” in the “Help” menu or restart FsmPro. Please note that existing AppImage users should get their update through the Website.

We are always striving to make FsmPro more stable and flexible than before for our growing users.

Please let us know if you would like FsmPro to have any specific feature. We highly value your feedback.

If you have a project built with the C language and depend on State Machines to handle time-critical business logic, FsmPro can help you design State Machines and integrate generated code files seamlessly into your project. There is no limit on the number of State Machines that can be designed and the interaction between State Machines and Software Modules can be graphically mapped for better understanding and maintenance.

FsmPro saves development time and helps in the maintenance of projects. In this article, We would take a tour of the tool by creating a project and walking through the features FsmPro has to offer for designing complex systems.

Creating a Project

To create a project, go to the file menu from the menu bar, click new and give a name to your project in the window. In this example, the name of the project is MyApp. A file with .rfsm extension would be created in the selected location. This is the only file you need to work with FsmPro.

Project Hierarchy

In the project browser, the hierarchy can be expanded to view the content at each level. By default, a project has a Hardware Module at level 2 which has a Microcontroller(level 3) that houses Software Modules(level 4) which in turn houses the State Machines(level 5).

Each item in the project hierarchy has an associated process item. You can change the label of any item in the project hierarchy by making changes to the associated process item(Shown in detail below).

Project Elements

To design State Machines, FsmPro provides several project elements at different levels of the project hierarchy as shown below. Note that State Diagrams can be designed only at level 6.

Process Item

A process item is an abstract project element that is used to denote an entry in the project hierarchy. For example, In the image shown below, MyApp has two software modules: Main Module and Engine Control. Both modules can contain one or more State Machines and have a dependency on each other for data and signals. Also, Main Module gets the Rpm value from Engine Control by using its get_Rpm() API and sets the engine speed using set_speed(int).

A typical Engine Control module could be of vital importance to a project and shall be changed only by a select few and can be shown in red colour. To add a process, simply select the process item(rounded rectangle) from the toolbar and add it to the canvas with a simple click. A real-world project could have several software modules and state machines denoted by process items with bi-directional dependency.

Link Item

Links represent dependencies between two process items. In the image above, Main Module is dependent on Engine control for RPM. It uses a link item to access Engine Control API getRpm() that returns an integer.

To draw a Link, select Link Item from the toolbar that would change the cursor to the shape of a link, click on the source process item and drag the mouse to the destination process item. A Link can only connect two process items.

It is possible to change the background colour of a Link Item by using its properties window. For all graphical items, the properties window can be invoked either by double-clicking on the item or by selecting properties from the context menu.

Memory Item

A Memory Item is used to denote global variables in FsmPro. A System might use global variables as a part of its design. Globals could be of any type: Integer, Struct, Enum, Float, etc.

In the image below, Main Module has two State Machines: Primary (primary_sm) and Auxiliary (aux_sm). The two State Machines could use a global integer variable for their individual purpose. In this example, a boolean global variable, app_status is shared between the two State Machines.

A project could have several memory items to represent variables of different types. To draw a memory Item, select the memory item option from the toolbar and click on the canvas to add it to the project.

Dataflow Item

A Dataflow item denotes the relationship between a Memory item and a Process item. The Dataflow item inherits its label from the connected memory item.

To draw a Dataflow, select the Dataflow option from the toolbar, click and drag from a source memory item to a destination process item or vice versa.

Initial State Item

The Initial State is the entry to the State Machine and is displayed in red. There can only be one initial state in a State Machine. Only in the initial state, an optional initial condition can be inserted. When the initial condition is true, the initial state action(shown below) is executed. The initial condition can be used to block the execution of a State Machine.

Initial condition and initial action can be inserted in the Initial tab of the Properties window of a State Item.

State Item

A state can be inserted in a State Machine by selecting insert state from the toolbar and clicking on the canvas. There is no limit on the number of states that can be inserted in a State Machine.

A State Item has the following properties:

• Label: This is shown on the top of the State Item and would be represented as a function name when code is generated.
• Action: This is the code for a given state and is shown in the body of the state. It is reflected as-is in the generated code. It is recommended to paste code in the action text field of the state properties window. Action code is executed as long as the condition for a given state is true while the control is in a given State.
• Description: It is a textual description of a given state which can be used for documentation purposes. It is available for all graphical items.

Also, like all graphical items, the visual appearance of a state can be changed in the properties window. Any state can be converted to an initial state by checking the Set Initial State checkbox on the properties window.

Transition Item

Transition Item represents a transition from one state to other. A transition is executed when its condition(shown in blue) is true. The action code of a transition is executed once before making the transition to the destination state. To insert a transition, select insert transition from the toolbar, click on the source state and drag the mouse to the destination state.

A Transition item has the following properties:

• Label: This is shown on the top of the Transition Item and would be represented as a comment in the generated code.
• Condition: This represents the logical condition for the transition to execute and is shown in blue. Note that brackets shall be maintained for the condition but there is no need to mention the if keyword,
• Action: This is the action code for a given transition and is executed once the transition condition is true before the control goes to the destination state. It is recommended to paste code in the action text field in the transition properties window.

Text Item

A Text item is a multipurpose graphics element. An instance of Text item can be present in one of the following modes:

• Macros: In this mode, a text item is used to define a macro which would be represented in the global section of the generated code file.
• Includes: This mode is used to include external files.
• Default: In this mode, global comments or compilable code snippets can be inserted which would reflect as-is in the global section of the generated source file.

The Mode for a text item can be selected at the bottom of the properties window and respective text can be provided in the action box.

Code generation

To generate code from State Diagrams, select generate code option from the Run Menu. Enter details in the dialog and click on generate. A header and source file is generated for each State Machine.

In addition, you can also take an In-app tour which can be invoked from the help menu. FsmPro is available to download for Windows and Linux distributions. If you have any queries about getting started with FsmPro, reach out to us at info@fsmpro.io. We’ll be glad to help.