I’ve been working with some adafruit DotStar LED strands, driving them with the RIO’s onboard SPI (using Java). I have them working, but to do so required I chunk the data to send into 128-byte sections, and call the spi.write() multiple times (once per section). This was done because the maximum return value I ever saw spi.write() give was 128.
I’m not horribly experienced with SPI - is this an implicit limitation of SPI in general? Or of the libraries and hardware we’re using for FRC? Perhaps also I forgot to set up some buffer properly. Has anyone else seen this?
Seems like it. The bit of research I’ve done on this seems to indicate SPI is implemented on the FPGA, which I assume means any buffers are of fixed length. What those lengths are, however, I’m not really sure…
Yes, it’s a hardware limitation. Per the Zynq documentation , the SPI read and write FIFOs are 128 bytes deep. This matches the behavior you’re seeing. Conceptually, functionality could be added to wpilib to do the outer loop for longer writes, but I think this case is rare enough (and there’s multiple ways to do it, e.g. use interrupts to determine when to continue filling the FIFO, or periodically check), that it’s better left to the user code to implement.