TMC9660 - SPI support

[dmartauz]

Only UART is currently supported for TMC9660. Is there a plan to support SPI as well?

[trinamic-LH]

Hello,
Yes - the SPI support is currently in the works and should get published in the coming weeks.

[dmartauz]

@trinamic-LH is SPI daisy-chaining going to be supported?

[trinamic-LH]

Yes, daisy-chaining will be possible.
The general approach with the TMC-API is that the API sends data bytes to be sent to the IC over a bus and expects the chip's reply back. It sends that via the callback functions the user application must implement. Whether that data transmission at the physical bus happens with an exclusive SPI bus or a daisy-chained one is outside of the TMC-API boundary and must be handled in that callback implementation.
Do note that this also implies that any sort of compositing datagrams (sending commands to multiple daisy-chain members at once within an SPI transaction) is entirely out of scope of the TMC-API and must also happen at the user application level.

As an example flow:

• The application calls a chip accessing function (i.e. tmc9660_bl_sendCommand).
• The TMC-API uses the bus-specific callback to inform the user application what to send to the IC (i.e. "Send these 5 bytes and give me the reply" - this would occur during the bootloader protocol stage, where the TMC9660 SPI datagram size is 5.)
• An application with a daisy-chained SPI bus must then identify what to send to the physical bus. If for example, the TMC9660 is first in the cahin followed by other ICs with a combined datagram size of 3, the physical bus must then send 5+3 bytes, inserting the TMC9660-specific bytes at the right location for the send bytes and extracting the TMC9660-specific bytes from the 8-byte reply.
• This must repeat for any subsequent bus access (via the callback)
• Once the TMC9660 access is complete, the chip accessing function (i.e. tmc9660_bl_sendCommand) returns the result of that access.