Remora - Rpi Software Stepping Using External Microcontroller via SPI

Hmm ok that confirms it. I did most of my octopus functionality testing on the octopus v1.1, I didnt like the buzzer on the pro. The octopus PRO has level shifters on the UART lines. When I jumper the TMC UART line to another pin, it configures fine. That is the only thing I can think of. But this overlaps with another issue Im having with another board, that also has a level shifting circuit on the UART line.

Scott, if you can provide input/assistance on this issue, it would be appreciated.

Im trying to support this mellow flyCDY3 board, but the uart isnt working. I tried changing the baudrate, but no luck. Thankfully my buddy mdroberts is much smarter than me, so he collected some data for me on the issue.

It looks like i cant upload the excel file he made, but here is what he said

Further to the TMC2209 read-back. I used the scope UART decode feature to confirm that the programmed values sent to the TMC2209 seem reasonable and consistent with the registers, but the TMC2209 doesn't put any data out after a register read is requested. The sequence after resetting the board is provided in the attached.

I just don't see any output from the 2209 when a register read is done.

So nothing i can do against it right now?
 

For those who may be interested. I've updated the remora-spi component to now interrogate the device tree to determine the hardware being used.

github.com/scottalford75/Remora/tree/mai...omponents/Remora-spi

I've been a little quite online lately. Been busy working on the STM32H7xx version of Remora with a lot of refactoring and hardware abstraction in preparation for the next steps to a common code base. I've also managed to get PlatformIO up and running for development and debugging. Important to be able to support multiple boards.

For those interested, the testing repo is:https://github.com/scottalford75/Remora-STM32H7xx-PIO

Inspired by the great work done by Sean McCully, github.com/seanmccully , the Remora code base has been significantly been reworked:

Remora is now a class of it's own
Communication is now handled via a comms handler, with hardware abstraction via a CommsInterface class
Hardware agnostic by creating hardware specific classes in main and then passing them over to the Remora constructor

The next steps....
Setup a organisation repo for Remora. We need a repo name as Remora is already taken
Setup the core Remora repo
Test the submodule approach with the STM32H7 work to date
Test with STM32F4 etc

BTW, TMC5160 support is working in the H7 testing repo so were not too far off having this across other boards as well.

Thanks for all the hard work Scott. The PIO install went really smooth, all I needed to do was update my ststm32 lib and it compiled no problem. Next steps for me is doing a H723 port, and figure out how this new repo works. Regarding hardware abstraction, (as always) I have notes on that based on the PIO stuff I did with Drew on the W5500 ethernet branch.


Hmmm call it something like Remora Motion Controller or something? ReMot? ReMOC? RemoraCNC?

Thanks Cakeslob, which board is the H723 being used? This will be a good test to see if we can get PlatformIO working happy with multiple targets. The code will need #ifdef's and compiler defines for each board to select the code changes needed for each H7 variant.