Integration of an existing project into the sequencer (UTIL_SEQ)?

[TomC]

I wish to add BLE functionality to an existing project on an STM32WB55. It appears that use of the sequencer (UTIL_SEQ) is encouraged if not mandatory for employing the BLE coprocessor on the WB55.

My understanding of the sequencer is that it's simply an optimized while loop and so any existing interrupts (Timers & DMA) I have utilized will continue to function as normal and I should take what's running in my current super loop (while(1) loop) and slot them into functions that I then register as tasks and set with the sequencer.

Are the assumptions I've made regarding interrupts correct and is the approach of integration I have described straight forward and reasonable?

Here is a list of resources I've found relating to use of the sequencer with the STM32WB55:

STM BLE Tutorial

Building wireless applications with STM32WB Series microcontrollers

STM32WB Bluetooth® Low Energy (BLE) wireless interface

STM32WB – BLE SW Application Architecture

[TomC]

I am also wondering if I need unique flags for tasks if I don't intend to pause/resume any tasks before their completion

[TomC]

I am wondering as well how best to reset tasks that I want to always be set without causing other tasks to starve

[Christophe Arnal]

Hello,

Your understanding of what the sequencer is doing and what you would need to do to migrate your application on top of it is perfect.

It is correct as well that it will change nothing regarding code execution in your interrupt handler.

Regards.

[Christophe Arnal]

Hello,

I am not sure I got the point regarding the flags. Each task should have one dedicated flag. However, it is possible to run in a single tack register to the sequencer a couple of functions that where previous running in your while(1) loop. The sequencer does not care whatever is running in a task that is registered.

So you could mode from

while(1)
{
fct_a();
fct_b();
fct_c();
}

to

my_seq_task()
{
fct_a();
fct_b();
fct_c();
}

and register my_seq_task() to the sequencer. The associated flag should be set when one of your 3 tasks need tp be executed.

If this does not answer the question, that would be great if you could post a simple exemple.

Regards

[Christophe Arnal]

Hello,

I am not sure about the meaning of "reset tasks". Regarding tasks starving, there is a round robin mechanism that ensures that each task has some opportunity to run is all associated flags are set for ever ( assuming they all have the same priority).

That would be great if you could post a simple example to illustrate your query.

Regards.

[TomC]

You've answered my question thank you. I was wondering what the best way to have a task perpetually set such that I wouldn't cause others to starve but the round robin mechanism prevents starvation, thank you.

[TomC]

Thank you, you've answered my question, which was essentially should each task have a unique flag. I believe the answer is yes each task should have a unique flag.

[TomC]

Thank you for your response. Was I correct in assuming that it's recommended that the BLE peripheral for a STM32WBXX should be implemented using the sequencer. I say this as the code generated when you activate the BLE peripheral using CUBEMX is already integrated into the sequencer.

[Christophe Arnal]

Hello,

Generally speaking, it is recommended to use the Sequencer for any bare metal application running on any STM32. it provides the required mechanism to avoid race condition ( especially when entering low power mode).

CubeMx generates bare metal application based on the Sequencer. It is possible to implement a BLE application without the Sequencer ( this is done in BLE_Peripheral_Lite project) but in that case, you will get no CubeMx support to generate the full application. CubeMx could still be used to generate some part of code to use a peripheral and you will then need to merge this code in your dedicated application.

However, as long as there is no reason to not go with the Sequencer, it is strongly advised to use it.

Regards.