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
I am trying to use EspSoftwareSerial to talk bidirectional UART with a TMC2209 stepper driver (a Silent 2209 V3.0 stick to be precise](https://wiki.fysetc.com/Silent2209/#v30) using the TMCStepper library.
On my WT32-ETH01 there are no more built-in serial pins available, because they're used for the ethernet.
Why opening a ticket here?
Other people had success in communicating bidirectional UART with TMC2209 sticks using Arduino SoftwareSerial or built-in ESP-32 serial pins with TMCStepper, so in principle this works fine.
As described below, I got the correct signal on the oscilloscope, but could not capture the data via EspSoftwareSerial at the same time.
Quirks to be aware of
TMC2209 stepper driver sticks come in different versions and the pinouts found on the internet are totally messed-up and confusing.
Relevant here:
RX on the driver stick is where it sends data.
TX on the driver stick is where it receives data (it's labeled CLK on my "Silent 2209 V3.0" version..)
The chip only as one PDN_UART and both of the above pins connect to it as shown here 👇
This is some kind of weird "UART but over one wire" design, not to be confused with 1-wire which is a totally different thing.
How it should have worked
I ran out of pins and had to use GPIO2 (for TX) and GPIO12 (for RX) for the UART connection. EspSoftwareSerial refuses to use GPIO2 by default (#261 and #249), but one can override it:
Probing the TX pin shows the query to the 6F address made by the call to test_connection():
We can also see the bleed-through of the response from the other side of the 1K resistor!
Probing the RX pin 👇 gives a clear response signal.
To me this looks like TX signal (via the 1K resistor) to the RX pin causes the interrupts to fire, and then something happens on the microcontroller side which disrupts the signal, causing the 00-00-00-00... from above?
When looking into the EspSoftwareSerial code, I found mentions of the one-wire mode, so I though that this might implement ignoring the interrupts while TX is firing?
Setting TX == RX
When setting TX and RX to the same pin I expected the library to work in a one-wire mode and ignore RX interrupts while firing TX.
Instead, there was no more signal at all!
The GPIO12 pin remains stable at 3.22 V even without anything connected to it.
If I would see the TX signal, I would like to connect GPIO12 directly to PDN_UART of the TMC2209, expecting the same signal pattern as above.
Conclusion/Questions
Why is the signal disrupted by enableRx(true)?
How is one-wire mode supposed to work? Could I use it here?
@dok-net could you give me a hint I am looking at a bug, or a misunderstanding on my side? thanks!
The text was updated successfully, but these errors were encountered:
We're still stuck on this matter. With Arduino SofwareSerial we were able to do bidirectional communication, which appears to confirm that it's a software bug. Maybe @dok-net or @plerup can help us with interpreting these symptoms?
thanks!
Hello,
first of all thank you for writing this library!
I am trying to use
EspSoftwareSerial
to talk bidirectional UART with a TMC2209 stepper driver (a Silent 2209 V3.0 stick to be precise](https://wiki.fysetc.com/Silent2209/#v30) using the TMCStepper library.On my WT32-ETH01 there are no more built-in serial pins available, because they're used for the ethernet.
Why opening a ticket here?
Other people had success in communicating bidirectional UART with TMC2209 sticks using Arduino SoftwareSerial or built-in ESP-32 serial pins with TMCStepper, so in principle this works fine.
As described below, I got the correct signal on the oscilloscope, but could not capture the data via
EspSoftwareSerial
at the same time.Quirks to be aware of
TMC2209 stepper driver sticks come in different versions and the pinouts found on the internet are totally messed-up and confusing.
Relevant here:
RX
on the driver stick is where it sends data.TX
on the driver stick is where it receives data (it's labeledCLK
on my "Silent 2209 V3.0" version..)PDN_UART
and both of the above pins connect to it as shown here 👇This is some kind of weird "UART but over one wire" design, not to be confused with 1-wire which is a totally different thing.
How it should have worked
I ran out of pins and had to use GPIO2 (for TX) and GPIO12 (for RX) for the UART connection.
EspSoftwareSerial
refuses to use GPIO2 by default (#261 and #249), but one can override it:With this, I can initialize and test the UART communication:
StepperSerial.begin(115200); driver.test_connection();
This gives a garbage signal, looking like this on both
TX
andRX
:enableRx(false)
gives a clean signal (but receive does not work)By disabling the RX functionality...
...suddenly the signal clears up!
Probing the
TX
pin shows the query to the6F
address made by the call totest_connection()
:We can also see the bleed-through of the response from the other side of the 1K resistor!
Probing the
RX
pin 👇 gives a clear response signal.To me this looks like TX signal (via the 1K resistor) to the RX pin causes the interrupts to fire, and then something happens on the microcontroller side which disrupts the signal, causing the 00-00-00-00... from above?
When looking into the
EspSoftwareSerial
code, I found mentions of the one-wire mode, so I though that this might implement ignoring the interrupts while TX is firing?Setting
TX == RX
When setting TX and RX to the same pin I expected the library to work in a one-wire mode and ignore RX interrupts while firing TX.
Instead, there was no more signal at all!
The GPIO12 pin remains stable at 3.22 V even without anything connected to it.
If I would see the TX signal, I would like to connect GPIO12 directly to PDN_UART of the TMC2209, expecting the same signal pattern as above.
Conclusion/Questions
enableRx(true)
?@dok-net could you give me a hint I am looking at a bug, or a misunderstanding on my side? thanks!
The text was updated successfully, but these errors were encountered: