OSAL over cmsisos2 for ETH boards - step 1 #220
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a first step vs the use of a more modern RTOS in our ETH boards such as
ems
,mc4plus
,mc2plus
.Introduction
Our ETH boards use RTOS services w/ an abstraction layer called OSAL (OS Abstraction Layer). This SW design solution allows to maintain a consistent set of APIs with the upper layers w/out being tied to those of a specific RTOS. That was important because there were dozens of RTOS and all with different APIs. With OSAL we can use almost any underlying RTOS, as long as we provide a suitable implementation.
At the time of the design of our ETH boards the choice was to use RTX which provided good performances and was available in source code w/out license.
Figure. The ETH applications are built upon the the services of embOBJ (tasks, timer manager, IP network etc) which use OS services through the HAL library which is implemented with RTX v4.
This RTOS has served well over the years but it is now not maintained anymore because a new more modern version is available from ARM in here.
We already use this new RTOS version for some of our boards such as
mtb4
,strain2
etc as an alternative to OSAL and it is the chosen design for our latest boards such aspmc
,amcbldc
,amc
.For these latest boards we use RTOS services through a C++ thin layer called
embot::os::rtos
which uses directly thecmsisos2
library (aka a compiled version of the more modern RTOS version from ARM w/ very few modifications such as easier configuration in runtime and thread-safe memory management).Figure. The latest boards use a C++ namespaces which gets RTOS services through a layer called
embot::os::rtos
which allows tocmsisos2
(or OSAL or else) underneath.Update the ETH boards to use the latest RTOS
The idea for the legacy ETH boards was to continue using the traditional OSAL over RTX-4. However, recent problems probably due to the OSAL (see for instance #209, #213 etc.) has raised the idea to have an RTOS upgrade also for the ETH boards.
Our goal is to use the API of OSAL and to provide a new implementation for it which uses the latest RTOS.
The design of the new OSAL
The ETH boards can still use the OSAL API as long as its internal implementation uses
cmsisos2
. The use throughembot::os::rtos
can help a lot. This PR adds a new OSAL library based on these two modules.Figure. The design of the new OSAL over cmsisos2 allows to reuse all the legacy code of the ETH boards and reuse code which we have been testing for long time now.
The test of the new OSAL
The new OSAL runs on the
ems
and is able to execute a number of RTOS primitives such as some type of threads (periodic, event-based, message-based) and also the basic services of embOBJ such as the timer manager, callback manager, the LED pulser.The full execution of the ems application is still under test and will be reserved for a successive step.
The impact of this PR on legacy code
It is very limited. The ETH boards running on the robot are not affected. I had to change some code parts in
embot::os::rtos
and inembot::os::Thread
to make them more versatile for their use. These changes mildly touch the code of some of the latest boards such asstrain2
andmtb4
but the changes have been carefully tested, so there is no harm.What's next
I will test all the application code inside an ETH board, such as IP services offered by
EOMtheIPnet
(see in here a brief of it behaviour), the control loop, diagnostics, etc.