HW test projects using embot
environment: ems
, mc4plus
and amc
#434
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 adds minimal HW test projects using the
embot
environment for theems
, themc4plus
and theamc
boards.The projects can be used as template / demonstrators for developing / testing new HW device drivers.
Description
The most recent boards use the
embot
environment and new code will be strongly preferred to be in C++ and to run in this environment.So, it is normal that the HW test project for instance of the
amc
uses theembot
environment. But is useful that also theems
and themc4plus
can use theembot
features.So, this PR adds some simple test programs for the
ems
andmc4plus
that run theembot
environment. Theembot::hw
layer runs on top of the legacyhal2.ems4rd.ethdbg.lib
andhal2.mc4plus.ethdbg.lib
hardware abstraction layer libraries. And then, theembot::os
layer runs as usual.As a result, the test projects on the three boards all share a common environment to explore some topics that may be of interest.
They all launch a periodic thread called
tTEST
that can init some HW module and then tick it regularly. The details of what each board does are in the following.mc4plus
test project uses the HAL motor driver to impose a PWM to a motor and to read back the generated current. That can be the starting point for a beginner to understand how the TIM peripherals work to impose PWM and to retrieve ADC readings (such as the induced motor current) that are synchronized w/ the PWM.ems
test project demonstrates CAN communication using the HAL driver in a manner similar to what happens in the control loop. The CAN frames are received in the background and are parsed all together periodically at each tick. After that, the outgoing CAN frames are sent to the channel.amc
test project demonstrates CAN communication using theembot::hw::can
driver and also how to configure the objectembot::app::eth::theErrorManager
to redirect its messages onto the CAN channel. That can be the starting point for instance to implement / test HWembot
drivers for new high resolution SPI encoders.Tests
All the projects have been tested using an
ULINK Pro
and anSTlink
. They work fine. I just attach a simple printscreen.Figure. The
tTEST
thread flushes 8 CAN frames to the channel and we can see the 8 execution of the CAN IRQHandlerFDCAN1_IT0
.Mergeability
This PR does not change any feature, it just adapts the mandatory
embot::hw
drivers so that they can work on top ofhal2
. So, it can be safely merged.