TL;DR: A bunch of technical details, blah blah boring stuff.
–
Ok.
The stepping is working. The UART scheme is where the Jackpot is different from the Tinybee and also from the FYSETC E4.
For completeness, UART is how it sets the microstepping and the current (and stealthChop and other junk but primarily microstepping and current) in contrast to the jumpers/potentiometer on the older stepper drivers.
The Tinybee doesn’t support the UART on the 2209. There is no connection so it won’t ever work unless you do some serious soldering.
The FYSETC E4 does have UART connection and assigns each stepper driver a different address 0 through 3 so they can all connect to the same wires. When the controller makes a request, it includes an address so only one of the controllers pays attention and responds. If two controllers had the same address and shared the wires then they would both take action (setting microsteps for example) and they would try to talk over each other in their responses.
There are only four possible addresses (limited by TMC2209) so it is ok for FYSETC E4 with four drivers, but to get five or more drivers you need another strategy. This is mentioned here. The solution wasn’t explained in detail (or my forum search couldn’t find it), but the idea is to have an analog switch to temporarily connect/disconnect multiple drivers that have the same address.
In the Jackpot implementation, the X driver has address 0, the Y driver has address 1, the Z driver has address 2, and A, B, and C all have address 3 but they essentially go through a 1-to-3 multiplexer that connects only one at a time of A, B, or C. (X, Y, and Z are always connected.) This is unique to the Jackpot board; no other board supported by Marlin has this.
My off-by-two error above I am pretty sure was just bad microstepping values as as a consequence of messed up UART communication (and my bug also made it incorrectly report OK when in fact it wasn’t). I think I have the I2S step generation solved, and I have X, Y, and Z UART solved, both of which are simply using the existing features that the FYSETC E4 and a couple other boards use.
The 1-to-3 multiplexer is (still) the difficulty.
The TMCStepper library is used by Marlin, and the TMCStepper library has a little bit of a UART multiplexing feature, but it doesn’t cover our use. One of the bigger problems is that it can only use “real” GPIOs, and it has no concept of the virtual pins that are the I2S outputs that Marlin defines.
Yet the TMCStepper code feels like the “right” place to add the multiplexing because it has a setup phase before it starts talking, perfect for configuring the multiplexer when it’s talking to the A, B, or C drivers. But it can’t use the I2S outputs. Adding the mux control at the point-of-use in Marlin would mean a much more complex modification spanning a ton of files, which is theoretically possible but extremely nasty.
My current thought is to add an optional callback function into the TMCSteppers so they can invoke a function during the setup phase before talking. Then the function is defined at the Marlin level and does the mux control and is able to use the virtual GPIOs.
That’s my next plan. Maybe it sounds complicated but it shouldn’t be that bad.