You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently I started playing with the new Arduino UNO R4 boards (MINIMA and WIFI) - and yesterday I thought I would try it
So I pulled out my Dynamixel Servo Shield and plugged it into the Minima. I made sure my libraries were up to date.
Which completely screws up anyone else who use these words in any way, including yours which should be safe,
as yours are contained in an enum, which is in a namespace, which is nice and clean.
I created an issue yesterday: arduino/ArduinoCore-renesas#64
Which they blew off and closed it with the response: I suggest you open an issue with the Dynamixel library, we are likely going to keep those defines.
So here it is.
Not sure how many libraries, documents, examples, and the like this might impact. Nor if there are any other now new magic words, which may show up with additional testing.
Edit: If it were me, my fix for this would be to add something like this in your header file:
Note: currently even if you "fix" this, their serial subsystem has lots of issues, including Serial1.flush() does not work, and as such the direction pin will change state before it should, and the packets are corrupted.
For example I had 18 servos and it only found 5... Some of this could be wiring connection issues, but mostly issues with their subsystems.
I have experimented with some updates to their serial code base (arduino/ArduinoCore-renesas#59), but this has not gained any traction, so not expecting that any of these issues will be fixed anytime soon.
The text was updated successfully, but these errors were encountered:
Hi, it's been a while talking to you :)
Yes, there are some definitions that are identical from the Arduino boards, and LED colors.
It seems even if we make modifications on those definition, it may not affect to our library.
However, there were a few cases when the Arduino users wanted to keep the LED_COLOR function so that they can control their own LED lights for other purpose.
I'll see if I can find some other workaround to resolve this issue.
Thanks for reporting
Been mostly playing around with Teensy boards and the like. Thought I would try out the new UNO boards.
They feel far more like an Alpha or Beta release than a real production release.
As for preserving the usage of their #defines, I personally would not worry much about that.
They maybe have a slight possibility of usage on MINIMA (keyword slight)
On MINIMA - P011 is not connected, P012 is connected to TX , P013 is connected to RX .
On WIFI - P011-P013 are connected to their 8x12 led matrix, which require knowledge on the setting of the different IO pins on the matrix. Charlieplexing
Recently I started playing with the new Arduino UNO R4 boards (MINIMA and WIFI) - and yesterday I thought I would try it
So I pulled out my Dynamixel Servo Shield and plugged it into the Minima. I made sure my libraries were up to date.
Loaded the scan_dynamixel.ino example sketch and tried to compile it which failed. More details in the forum thread:
https://forum.arduino.cc/t/robotis-dynamixel-shield-code-does-not-compile/1150975
Found the issue was that Arduino defined: LED_RED and LED_BLUE
Which completely screws up anyone else who use these words in any way, including yours which should be safe,
as yours are contained in an enum, which is in a namespace, which is nice and clean.
I created an issue yesterday: arduino/ArduinoCore-renesas#64
Which they blew off and closed it with the response:
I suggest you open an issue with the Dynamixel library, we are likely going to keep those defines.
So here it is.
Not sure how many libraries, documents, examples, and the like this might impact. Nor if there are any other now new magic words, which may show up with additional testing.
Edit: If it were me, my fix for this would be to add something like this in your header file:
Note: currently even if you "fix" this, their serial subsystem has lots of issues, including Serial1.flush() does not work, and as such the direction pin will change state before it should, and the packets are corrupted.
For example I had 18 servos and it only found 5... Some of this could be wiring connection issues, but mostly issues with their subsystems.
I have experimented with some updates to their serial code base (arduino/ArduinoCore-renesas#59), but this has not gained any traction, so not expecting that any of these issues will be fixed anytime soon.
The text was updated successfully, but these errors were encountered: