In many instances, developers working in a real-time environment need to know whether a driver or framework component that they are working with is going to exhibit blocking or non-blocking behavior. A blocking component will prevent any other component or function from executing while the component is being called. A non-blocking component on the other hand will start to perform the work but will allow other components and calls the ability to access the CPU to get useful work done when the non-blocking component doesn’t need it. A developer might wonder which Renesas Synergy™ Software components are blocking and which are non-blocking. Let’s dig into the details.

 The logical place to start is at the HAL / driver layer. In most cases, the HAL / driver layer modules are implemented as non-blocking. A developer would expect this since the HAL / driver layer directly interacts with the microcontroller hardware. In many circumstances, the hardware has interrupts implemented so that hardware events can notify the driver that something important has happened. The HAL / driver module therefore takes advantage of the hardware interrupts which allows the HAL / driver module to be non-blocking.

Not all HAL / driver layers modules thought are non-blocking. There are rare instances where they are blocking. The easiest way to determine if a module is blocking or non-blocking is to examine the interface in the Synergy Configurator. If a module has a Callback associated with it, as shown below for the g_timer0 module, then the module is non-blocking. Callbacks are typically the implementation for when there are interrupts built into the hardware that can notify the software that an event has occurred. 


At the framework layer, modules will block by default. A framework may be dependent upon a driver module that is non-blocking but the behavior for the framework is that it will run its function until completed. Now at the framework level, don’t forget that there may be an RTOS that is being used. If this is the case, then blocking really isn’t truly the case. The RTOS will determine which task has the highest priority and even if the MCU is busy running a blocking framework module, there may still be a context switch to another task if it has a higher priority. Most framework components are implemented such that if they reach a point where they must wait for an event or something to complete but don’t need the CPU, they will yield the CPU to another thread so that they don’t needlessly eat-up clock cycles. Developers should also keep in mind that when a hardware interrupt fires, its code blocks the RTOS and any application code that is executing which is why it is so imperative that interrupts are short and execute as quickly as possible. Framework level modules also sometimes include a timeout parameter so that they don’t block other functions indefinitely. A great example are the read, write and writeRead functions in the SPI framework. These functions will block until completed or will return an error if a timeout occurs before the function completes. An example for the SPI read function can be seen below:

ssp_err_t SF_SPI_Read(sf_spi_ctrl_t *const p_api_ctrl,

  void *const    p_dest,

uint32_t const             length,

spi_bit_width_t const             bit_width,

uint32_t const             timeout


It is important that a developer understand which modules are blocking and non-blocking in order to maintain the real-time performance that their end applications require. At the HAL / driver layer, the RTOS is not used and its therefore time critical that non-blocking implementations be used. At the framework level, the framework is blocking but since the RTOS is implemented, the blocking mechanism is minimized. Using a non-blocking implementation helps ensure that developers can maximize their MCU processors throughput.

In the next several posts, we’ll be examining  the module guides and how they can be used to quickly get up and running with a specific hardware module.


Until next time,

Live long and profit!




Hot Tip of the Week

Don’t forget that the SSP User’s Manual is an excellent source of information on the basics of using e2 studio and the SSP. If you ever find that you are having trouble with some of the fundamentals of either of these tools, it might be time for a refresher and Chapter 2 of the SSP User’s Manual covers the details of SSP architecture and BSP architecture.

Chapter 3 includes the e2 studio ISDE User Guide that takes you all the way from installing to running your first project. The often overlooked sections with key tips on topics like using TraceX, modifying the toolchain and e2 studio usage notes can save time when you are learning a new feature in the e2 studio based ISDE.

The PDF and HTML versions of the SSP User’s Manual is available on the Synergy Gallery here: