In the last several posts, we have been examining how to create our own customized board support packages and even export them as a pack. Today we are going to examine how to add frameworks and modules to a board support package along with important considerations that developers need to take into account when configuring frameworks.
When putting together a BSP, the best place to start is within the Synergy Configurator, which is the configuration.xml file that is automatically generated every time that a new project is created. Frameworks and modules can be added to the BSP through the configurators thread tab. Frameworks and modules are added not just to the project but are added to individual threads within the project. An example for how this tab looks after creating a blank Blinky with ThreadX project can be seen below:
A developer that wants to add a module such as an ADC driver to the project must first select the thread they want to add the module to. For example, a develop starting with the blinking project would first select the Blinky Thread (or even add a new thread) and then under the Thread Stacks area select the green add button. Adding to the stack will then reveal multiple choices to the developer such as
Driver
Framework
Renesas SYBD
XWare
Drivers provide low level hardware access and control through a hardware abstraction layer. In general, drivers should only be added stand-alone in this manner when there is a concern with performance and overhead for an application. In most instances, the recommendation is that developers instead add a framework. The frameworks are thread aware and in many circumstances, will show the developer which low level drivers the framework is dependent upon. An example for adding the block media framework that can be used to access an SD card can be seen below:
The reader will notice a few very interesting differences about the newly added block media framework compared to the ADC Driver. First, the second module down is highlighted in red. The red text is indicating that something is wrong with the way the module is currently configured. A developer can hover their mouse pointer over the module and in this case discover two errors:
Requires SDMMC Access Interrupt (ACCS) Enabled
Requires lower layer transfer driver
A developer needs to click on the g_sdmmc0 module and examine the properties tab. The developer needs to look through the properties until the ACCS Interrupt is found and then set the priority level.
Now the modules text is still red because the lower layer transfer driver still has not been resolved. This brings us to the second interesting observation, that modules seem to have different colors associated with them. There are three different colors that can be assigned to a module; gray, pink and blue. Modules with the gray color are modules that can only be used and accessed from within the current thread. The gray modules have no concept for multitasking and while they can be used in more than a single thread, these modules will behave independently in each thread. For example, a low-level driver, such as the ADC module shows up as gray because it will only be accessible within the current thread. A blue module on the other hand can be accessed by multiple threads. Blue modules tend to be high level frameworks that are thread aware or that a developer would only ever really need a single instantiation for in their application. An example would be using the USB stack within the XWare components. If multiple threads need access to USB, there would be no reason to create an instance in each which would drastically increase the memory footprint. Instead, the USB stack shows up blue and can be used across multiple stacks without duplication.
The pink modules are indicating that the module above it has an interface dependency that has not yet been met. The framework is coming right out and visually showing the developer that the framework has a driver dependency that needs to be handled! There is no need to add it separately as a stand-alone module. Clicking on the Add Transfer Driver module in the example above reveals a New menu option which when highlighted reveals the options to add either a DMAC or DTC driver. In some circumstances, there would be no need to add additional modules to the framework even though there is a dependency. In the block media example, there is a mandatory requirement that the transfer driver be provided. It is important to note below that once the additional module has been added and all the errors have been resolved, the colors all change gray as shown below.
The reader can also see that adding a USBX Host Class Mass Storage Device framework. The components in this framework appear blue. These modules can be used across multiple threads and are multithreading aware.
Once a developer has added a single framework successfully to their application, adding additional frameworks becomes straightforward. Don’t forget that each framework that is added to a thread is only available for use within that thread! In a multi-threaded application, it will not be uncommon to dedicate threads to handle specific framework elements and then use the messaging framework to pass data around the application. We will explore this in future posts.
One critical aspect to configuring frameworks that we did not discuss is how to handle callbacks. We will be discussing callbacks and their best practices exclusively in the next post.
In the mean-time,
Live long and profit!
Professor_IoT
Hot Tip of the Week
Have you noticed the new Renesas IoT Sandbox? The Renesas IoT Sandbox is a no-cost, no-installation developer area that provides cloud connectivity with Renesas products, smartphones, and third-party web services (OpenWeatherMap, Twilio SMS, Mandrill Email, etc.). It builds on two Synergy Kits- the SK-S7G2 and the S3A7 to implement a powerful and flexible IoT solution. Once logged into their Renesas IoT Sandbox accounts, users will find powerful IoT capabilities such as identity management, data storage, ability to visualize data with dashboards and, most importantly, the ability to derive intelligence from the data using flexible workflows, which unlike rules engines are 100% programmatic. Find out more at the below link:
https://www.renesas.com/en-us/docs/solutions/proposal/Sandbox_flyer_100316_Final.pdf