Getting started with the Messaging Framework

In the last post, we started to take a deeper dive into the Renesas Synergy™ Platforms building blocks that contain drivers, Application Frameworks and threads. In a real-time embedded system that uses an RTOS, threads act as mini applications each with their own separate stack, memory allocations and priorities. An RTOS typically has mutexes, semaphores and message queues to synchronize threads and pass data around. While ThreadX® does have these features readily available, the Synergy Platform also has a Messaging Framework that simplifies and extends the capabilities for the queue messaging mechanism. In this post, we will explore the Messaging Framework capabilities and examine how to subscribe to an Application Framework Components messages.



From a high level viewpoint, implementing a Messaging Framework instance requires three pieces; a memory pool, sender thread and listener thread. The memory pool is a memory location that has been specifically allocated for passing messages between threads. The memory allocation can be specified and controlled by the developer as we will see in the example later in this post. A listener thread is waiting for a message to be placed within the memory pool. The listener subscribes to messages that are produced by a sender thread. The sender thread allocates message space within the memory pool, writes the message into the memory pool and then once complete posts that the message is completed. Any subscriber to the message, a listener thread, can then access the message through the memory pool.


The Messaging Framework provides developers with quite a few advantages over implementing queues at the RTOS level such as

  • Message management

  • Message buffering

  • Publish and subscribe mechanisms

  • Message formatting

  • Message prioritization


At first glance, using a message queue within an RTOS always seems complicated. With the Messaging Framework it has not just been simplified but has also been visualized. The simplicity is easily seen by loading a Synergy project and opening the Synergy configuration file. The Synergy configuration contains a few different tabs such as Clocks, Pins, Threads and Messaging. The Messaging tab is the easiest way to access the Message Framework capabilities. In the image below, a reader can see that there are three main areas to the Messaging tab; Event Classes, Events and Subscribers.



In a new project, the Messaging tab isn’t going to contain anything of much interest until a developer either creates a few event classes and events themselves or starts to pull in Application Framework components that also contain messaging mechanisms. In order to provide an example, I created a new blinky project using the new project wizard and added a touch screen framework component. After doing so, a Touch Event Class and then New Data events appear in the Messaging tab.


When an Application Framework component with a messaging mechanism is first added to the project, it will not have any subscribers associated with it. A developer can click on the event class of interest and add a new scriber. In the example below, The Touch Event Class is going to have the Blinky Thread subscribe to its messages.




Once the Blinky Thread has subscribed and the generate project content button has been pressed, the necessary information required to access the touch screen will be automatically added to the Blinky Threads generated files. A developer can see the new code added by looking at blinky_thread_func. As part of the blinky thread initialization, there is now a call to g_sf_touch_panel_i2c0.p_api->open. For those readers who don’t have an IDE open, this can be seen in the image below:





The Messaging Framework certainly simplifies how data is passed around an application. Many components with the Application Framework just like the Touch Framework use the Messaging Framework to communicate their data and functions to other threads and application areas. Developers can also configure and control these Messaging components. Take for example, the message pool associated with the Touch Framework. A developer can open the Threads tab from the Synergy configuration file and highlight the g_sf_message0 component to display the Messaging Framework properties that are associated with the Touch Framework. A developer would see that the Message Queue Depth is to 16 along with the fact that there are 2048 bytes in memory that are allocated to storing the messages.





The Messaging Framework is a great tool for embedded software developers. The Messaging Framework allows a developer to get away from the nitty gritty code details and into an abstraction that allows a developer to not only configure messages at a high level, but also see all available messages and subscribers in an application in one place. In a traditional development environment, a developer would have to go into each components source to figure out how the messages were configured. The Synergy Platform makes this easier by placing these details all in one place.


Next time we will dig into the Console Application Framework and see how quickly and easily we can get it up and running.


Live long and profit!





Hot Tip for the Week:


The features for each Application Framework within the Synergy Platform can be found in the Synergy Software Package (SSP) Datasheet. Each Application Framework also has expected code size and RAM usage for Synergy compilers. Check-out the latest datasheet at