I am building a printer with a print-head consisting of 88 nozzles, that need to be switched with a timing in the millisecond range. I have settled on using SPI-based shift registers to control the 88 outputs.
I thought it would be simple to write a plugin that would send out SPI-commands in between some G0/G1 moves and control the valves, however, I found out that spi_transfer&spi_send do not end up in the task scheduler, and therefore do not meet my timing requirements.
I was wondering, as I see a lot of other code using spi+scheduling (usually periodically querying a sensor): Is there a good reason why ordinary SPI commands are not scheduled in the current Klipper version. Has this just never been a useful feature? Or are there any fundamental/practical reasons to it?
And as I want to implement my own scheduled SPI, do you have any tips/examples, or are there perhaps already initiatives on including this (couldn’t find anything in the PR’s).
The short answer is because precise timing of SPI commands was never needed. It was thus simpler to perform the timing in the host and avoid the complex buffer management for requests and responses in the micro-controller.
I suspect it would be a challenge to implement precise timing of SPI commands in Klipper. One would likely need to ensure all the architecture specific SPI code was capable of running from IRQ context and utilizes IRQ completion notifiers. Even with this, it would still be difficult to get reliable timing due to the SPI bus being a potentially shared resource.
I have settled on using SPI-based shift registers to control the 88 outputs.
FWIW, it is probably simpler to deploy multiple micro-controllers and avoid shift registers. Klipper is able to precisely control many micro-controller simultaneously. It’s also possible to find micro-controllers that are roughly the same cost as a shift register.