I have observed that using the PA7 (A6) D21 pin of the OpenRB-150, any movement of a servo appears to ‘glitch’ the pin. Further, if an analog read to the pin is done before a getposition() call, the system freezes. Has anyone else noticed this behavior?
When I tried my own OpenRB-150 (QC #2234), I did not seem to have any problem reading A6 (when 3.3 V is connected to it) BEFORE or AFTER setting a Goal Position or getting a Present Position.
If there is nothing connected to A6, that pin will read random numbers between 300 and 400 (stray voltages?). But when 3.3V is connected, the A6 reading is stable at 1023 (as it should).
Once the system has started, the pin seems normal. During boot, it appeared to be driven, making it unusable for our application. I have seen Arduino pins on other architectures with similar behavior during boot.
When access to A6 during setup() is attempted, the pin’s behavior (other than that mentioned for booting) appeared as expected. But, during loop(), when dxl.getposition() was called after a analogread(), then the system would freeze. This behavior is only exhibited for A6.
My bad. I mistyped. Sorry. I was doing some digital use tests at the time I replied.
Interestingly, having now experimented with the pin in other ways more information can be provided. Given its designation as D21, one would think it could be used as digital IO. Again, if getposition() is called during the loop(), behavior is unpredictable. For instance, with getposition() in loop(), it appears that a digitalwrite() will not set the pin state. However, without getposition() in loop() the pin can be set high or low as expected. It seems like this pin is used by the Dynamixel control loop in some way that, so far, I have not found documented.
The OpenRB-150 is derived from the Arduino MKR Zero. They use the same MCU SAMD21 but the MKR Zero needs the MKR DXL shield in order to control the DXLs in half-duplex. And the MKR Zero happened to use A6 to manipulate Serial 1 from full-duplex to half-duplex. But all that are supposed to be cleaned up on the OpenRB-150! Can you use something else other than A6 for your work?
Actually, having scoped the signals on an open A6 pin, your explanation would make sense. I thought I’d read something to that extent somewhere, but couldn’t remember where, and couldn’t relocate the article. BTW, the boards we’ve used range from QC 2234 to 2418 and seem to exhibit similar behavior.
The design includes all of the available pins, so not including A6/D21 will be a matter of removing some functionality. It can be done, but it would have been nice to be able to use that pin.
Actually, that is what started the issue. I couldn’t get it to work as an analog pin because the OpenRB would freeze if a getposition() was used in the loop(). When I get some time, I’ll run your app and against my hardware.
When I dig in the file “variant.h” for OpenRB-150, I saw that A6 can be used when you are dealing with I2S devices, but that whole section is commented out by default.