Cleanup of the amc application

[marcoaccame]

In short

This PR cleans up the amc application and improves the reporting of timing overflow of the DO phase plus reduces the duration of the TX phase of the RUN state.

In more details

Cleanup

The cleanup is about the following.

• It enables the correct compile optimizations for all files. Previously, some were left with the -O0 optimization used for debug.
• It cleans up code of the C++ objects used so far only for the amc.
• It evaluates and removes all the #warning pragmas which were added during development to remind about possible checks or minor things left over. Now the amc compiles with zero warnings.

The execution timing overflow is always enabled

The DO phase now always reports with a diagnostics message when its duration is higher than the requested budget. The advantage is that now we don't lose warnings anymore.

Optimization of execution time of the TX phase of RUN state

The request of the transmission of the CAN frames now starts at the end of the DO phase and not at the start of the TX phase.

The advantage is that we gain some execution time because the TX phase does not need to wait much for the CAN transmission to be over and terminates in a shorter time.

See next figure to see the timing details of the RUN state so far and now.

Figure. SO FAR: The case of CAN transmission request done in the tTX thread.
The tTX thread requests a CAN transmission and let the HW work. But the HW finds a busy channel because the attached CAN boards send 6 full length CAN frames every cycle. So the transmission will likely start some time after. Then it takes about 100 us to exit the CAN peripheral. So the tTX thread will likely be locked (see thread tIDLE executing) and wait for the end of CAN transmission. As a result we have a typical duration of the tTX thread of 200 us.

So far, we have placed the start of TX of CAN in the correct thread but we don't use in an efficient way the HW because we force the CPU to wait for the CAN HW peripheral to finish its job.

The following figure instead shows the if we anticipate the TX request of the CAN frames then we avoid that the highest priority thread tTX is locked to waste CPU time.

Figure. NOW: The case of early CAN transmission request done in the tDO thread.
In this case tTX thread is not blocked to wait for the end of CAN transmission. There is no execution of the tIDLE thread. As a result we have a much better duration of the tTX thread of about 100us.

Mergeability

I did tests on the lego setup and also on the wrist and all works fine. Also, there is no cgange in behavior for teh other ETH boards such as ems, mc4plus, mc2plus, so we can safely merge.

Associated PRs

There is an associated PR for the new binary of the amc:

• amc v1.2 icub-firmware-build#109