The Renesas Synergy™ Platform by default provides ThreadX® as a precompiled library. There is a huge benefit to doing this in that a developer doesn’t need to compile the source with their project which can dramatically increase compilation speed. There may be times though when a developer doesn’t want to use the default ThreadX configuration values. When this does happen, there is a simple process that developers can follow to add the ThreadX source to their projects and customize its behavior.
Adding the ThreadX source to a project is straight forward. First, open the Renesas Synergy configurator. Navigate to the threads tab and select the HAL/Common thread. Then just like any other component, click add, navigate to X-ware>ThreadX and then select ThreadX Source as shown below.
Once the ThreadX Source has been added to the project, a developer will notice that the component shows up with red text, indicating that something is wrong. By default, when sources are added to the project an error is generated. The reason for this is that there is a property within the ThreadX source named “Show linkage warning” that is automatically enabled. The reason for this is that it reminds the developer to make sure that there are not multiple ThreadX objects that can be linked to a precompiled library and the actual source code. To remove this warning, in the ThreadX Source properties, find the Module ThreadX Source properties and disable the “Show Linkage warning” option as shown below:
When the ThreadX Source component is added to the project, it is a good idea to clean the project or even delete the Debug folder to ensure that the precompiled ThreadX library doesn’t hang around and cause issues with multiple link sources. At this point generating the project will create a tx_src folder located under synergy>ssp>src>framework>el>tx. Developers interested in browsing the ThreadX source could now do so at their leisure. Developers should note that including the ThreadX source will slow down the compilation time on the first build. The reason is that all that source code that was precompiled library is now being compiled. Once the source is built, the object files will not need to be recompiled unless a developer changes the source properties or cleans their project.
There are several properties that developers can configure within the ThreadX source. The ones that I believe are the most interesting to developers are:
There are many more capabilities within the ThreadX properties but these are most interesting for several reasons.
First, Timer Ticks Per Second is used to specify how often the ThreadX scheduler will generate a tick per second. By default, the precompiled ThreadX library will generate a tick 100 times per second. How can a developer be certain? Well for one thing, if a developer creates the standard blinky with Threadx project using the project wizard, the blinky_thread_entry.c module defines a variable named threadx_tick_rate_Hz = 100. Since the LED code blinks LEDs at the desired rate and is dependent upon this internal timer, it’s a pretty safe bet that 100 Hz is the default. Increasing the tick rate will increase the RTOS overhead since the scheduler will run more which will increase the context switching and overhead. The tick rate cannot be changed without adding the ThreadX source to a project.
Second, a developer may decide that they want to change the minimum stack for a thread that is set by default. The default value is 1024 which is pretty typical but developers may decide that they want to increase or decrease this . In many cases developers will just use the default value which if larger than necessary could result in more RAM being used than necessary. The default stack size is a good starting point for most threads in an application but developers need to remember that they should always perform a worst case stack analysis.
Third, event tracing is turned off in a project by default. Event tracing is a great way for developers to peer into their application and see what it is actually doing rather than simply hoping that it is working as they expect it to. When event tracing is enabled, developers can use TraceX to receive events that are happening in their application such as memory allocations, tasks being pre-empted, semaphores being requested and so on. These events can provide a lot of information on how the application is behaving and is critical to quickly debugging an application.
Finally, there are several performance info API functions that can be used to monitor how well RTOS objects are performing. These include block pools, events flags and mutexes to name a few. A comprehensive list can be seen below:
There are many more capabilities that can be adjusted and tuned within the ThreadX source. We have examined several that developers will want to use during their development cycle. A developer can review the different parameters in approximately 10 – 15 minutes. I highly recommend that developers add the ThreadX source and become familiar with the properties that can be adjusted and consider how they can affect their applications.
Until next time,
Live long and profit!
Hot Tip of the Week
To find the most up to date version of a Renesas document that you have an old copy of, you can use the top of the window search function (just to the left of the Sign In button) which brings up a search results window like this:
An important trick is to not include the entire document designator (R11AN0023EU0116 in the previous example)- just include the first 5 characters of the designator which indicates the document type (In the previous example, “R11AN” which stands for a software application note) and the document number (the next four digits). Don’t include the rest of the document number (which is the language designation and revision level). Only the most recent document revision is usually stored on Renesas.com, so you won’t get a positive search result if you use the entire document designator that includes an old revision. Happy searching!