Anyone figured out how to get Trinamic's TMC5160 drivers working with LinuxCNC?

Can we other spi on rpi5 other than used by remora-spi to send config data to tmc5160. Tmc5160 spi config pins connected to rpi spi pins. And remora will treat 5160 as regular step/dir mode.

I am also communicating with cakeslob who is another developer for remora via discord.

amanker wrote:

Can we other spi on rpi5 other than used by remora-spi to send config data to tmc5160. Tmc5160 spi config pins connected to rpi spi pins. And remora will treat 5160 as regular step/dir mode.

I am also communicating with cakeslob who is another developer for remora via discord.
 

I should be able to make it work; all I have to do is to add an option when you load the module to specify the use of the second SPI channel.

I did some quick tests on RPi 4 with the use of ioctl controlling /dev/spidev0.0 rather than the bcm2835 library and it seems to be slower/less regular. I just quickly compared my read and write functions time. As I have also read in another thread (a RPi 5 thread on this forum) this morning that the spidev option was not real-time, I will stick to the same idea as the Remora SPI, meaning using bcm2835 and rp1 library for RPi 4 and RPi5.

One question. 5160 connected to rpi spi for its configuration only. Which will done one startup. So even if its not in real time. Since configuration only needed one time on startup. Does it matter that communication is slow as you said?
I am not a developer so I am asking.

You are right, it wouldn't be a problem for configuration only. But I'm using the module to use the TMC5160 without step/dir signals, so I need a fast communication.

I received my RPi5 this week-end and had to change some parts of my code to make it work. Also, with the RPi4, I could control the CS pin "outside" the SPI routine, and use how many pins I wanted to. With the RPi5, this does not appear to be possible. So I will need to make some more changes in the code. I will probably keep the freedom of CS pin choice for RPi4 and use the dedicated CS pins per channel on RPi5.

Are you planning to add support for daisy chaining of drivers?

Yes. On the video I posted all the 4 drivers are daisy chained. My plan is to allow to declare chains when loading the module, so you can have 2 chains of 2 daisy chained drivers, for example, or 3 "chains" of 1 driver, or what ever you want as long as you stay below the max allowed drivers (6 for now, but easy to change in the code). That's true for RPi 4, where the CS pin is managed as a GPIO pin. For the RPi 5, the max number of chains will be the max number of CS pin of the selected SPI channel (2 for SPI0, 3 for SPI1).