Dynamixel2Arduino does not compile for STM32

[Duffmann]

Issue
Any Ardunio sketch for STM32 CPUs/Boards that tries to #include <Dynamixel2Arduino.h> fails to compile/build.

Reason
actuator.h defines the enum "ControlTableItemIndex" which uses the keyword "LED_GREEN".
For Arduino boards using the STM32 core "LED_GREEN" is defined as macro for the Arduino pin number of the onboard LED. In case of Nucleo-64 / Nucleo F446RE it simply evaluates to 200 and hence cannot be (re)used as a keyword in an enum.

Solution

• Adding #undef LED_GREEN right in front of the definition of ControlTableItemIndex in actuator.h (might have side effects)
• Or rename keyword to e.g. "LED_GREE" in actuator.h, actuator.cpp and keywords.txt

[ROBOTIS-Will]

@Duffmann
Thanks for the suggestions.
DYNAMIXEL2Arduino is specifically designed to support the Arduino boards and it may not fully compatible with other boards.
Undefining the LED_GREEN will restrict the easy access for onboard led of the Nucleo while renaming the control table item causes confusion in using the API as the keyword will be used to access a specific address of DYNAMIXEL.
At the moment, I can't think of a proper way of integrating this without restricting both Nucleo and Arduino boards.
Please let me know if you have any good idea.
Thanks!

[Duffmann]

I can confirm that DYNAMIXEL2Arduino works like a charm also with Arduino STM32 cores. So thanks for this great piece of software!

I am using STM32F4/G4 MCUs since they are affordable, come with an FPU that is great for inverse kinematics. Additionally, they support half-duplex serial out of the box. Thanks to the nice PortHandler inheritance concept of DYNAMIXEL2Arduino all you need to drive a (RS232 TTL) Dynamixel servo is a single simple wire plus a power supply.
(https://github.com/stm32duino/wiki/wiki/API#enable-half-duplex-mode).

Note: I have not tested speeds beyond 115kBaud.

LED_GREEN: I feel the issue is less on your side but more on STM overusing macros for simple const values (https://luckyresistor.me/knowledge/avoid-preprocessor-macros/). Only way I can think of here would be a (breaking) change by prefixing all ControlTable keywords with e.g. '_dxl'. This would also reduce chances of future conflicts with macros for other generic keywords like "SHUTDOWN" or "ID".

[ROBOTIS-Will]

Hi @Duffmann

Oh, the single wire half duplex feature of the MCU looks promising. TTL implementation without a need of additional ICs would make the circuit a lot simpler.

In regards with the control item index renaming, maybe I can come up with another solution by adding a prefix or a postfix(such as DXL_) underneath the API level so that I wouldn't break the backward compatibility.
I'll put this on my to do list, but please understand that this update may take quite long as supporting 3rd party boards is not our priority at the moment.

Cheers!

[PerennialNovice]

@ROBOTIS-Will: I got the Dynamixel2Arduino lib running on a custom STM32L4R5 board.
Changes needed, apart the ugly #undef mentioned above, were very small.
Just added

#ifdef ARDUINO_ARCH_STM32
  else{
    port_.enableHalfDuplexRx();
  }
#endif  // ARDUINO_ARCH_STM32

after each time that dir_pin_ was set to LOW

In the main application, all that has to be done is define the Serial that will be used for the Dynamixel as Half-Duplex, which is done by simply passing only one Pin to the constructor, i.e.:

HardwareSerial Serial5(PA_0);

be cautious with the STM32-Pin notations, though. See https://github.com/orgs/stm32duino/discussions/2319