"load" option for hardware SPI?

[RoGuE_StreaK]

About to start my first experiment with SPI, and need some advice. Actually, the target device uses a not-quite-SPI interface; there is no addressing etc., it simply uses bytes of data received serially to determine which outputs to turn on/off, with only those devices on the line. After receiving a byte (or two bytes, for 16pin output models), a "latch enable" pin needs to be toggled to "lock in the data". This is where I need help.

The devices are the Texas Instruments TLC5917 (8 outputs, one byte) or the TLC5926 (16 outputs, two bytes).

I would like to use the remappable hardware SPI of the PIC24FJ64. Is there a way to setup a "load" pin to associate with hardware SPI, which auto-toggles after a byte is sent? #USE SPI has this, but isn't setup_spi() the newer better method for hardware? Or am I getting things mixed up?

I have two TLC5926's only on this SPI line, and no other SPI devices being used. Overflow data from the first 5926 becomes input for the second one.

PIC24FJ64, 20MHz OSC, 10MHz clock. CCS 4.120
From how I read it, TLC5917/26 works optimally with a clock pulse of 20ns, and the latch pulse should also be 20ns, which gives a clock divider of... ?

[ckielstra]

Several remarks:
1) The TLC5917 doesn't use SPI or a derivation there of. It is just a serial-in parallel-out shift register that needs to be clocked. A lot like the good old TTL chip 74595 and derivatives (74LS595, 74HC595, etc). Check the CCS drivers directory on your harddisk for an implementation example (74595.c)

2) Yes, it should be possible to use the SPI hardware to drive these chips but there is very little to gain from that. Transfers will be slightly faster compared to software driver but you'll waste a lot of time in figuring out the right configuration settings.

3) #use SPI is the new CCS driver for SPI and setup_spi() is older. #use SPI is more versatile but less well tested (i.e. more bugs) and more difficult to configure because of undocumented features and strange default settings.

4) the 20ns timings are minimum values. No maximum is specified so if you want to take hours before toggling the next bit that is fine to the hardware. BTW, with a clock divisor of 1, a 20ns clock equals 50MHz. Your PIC is much slower, so even at the fastest clock settings you will always meet this minimum timing.

[RoGuE_StreaK]

Thanks ckielstra, I'll check out the samples when I get a chance (on a different PC at the moment).
My desire for hardware use may be misguided; I'll be using a pseudo state machine for other operations, driven by an interrupt of 16kHz, and thought that, like hardware PWM, hardware SPI would take less overhead in code, ie. just say "do this" and the hardware goes off and takes care of the guts of what it has to do, rather than a software operation that cuts into other operation times?

Does setup_spi() have a feature to auto-toggle a pin after transfer, like #use SPI does? I couldn't find anything in the docs or forum, but didn't know if I was using the right terms. That's probably my main problem, trying to figure out how to get the timing right for the "Latch Enable" toggle, without using any delays etc.

RE: clock, so any old divisor will suffice? Keep it at 1 for fastest possible, but well within specs for the 5917/26?

[FvM]

Hardware SPI can be appropriate for a simple serial IO port extension if you are intending it to be quite fast. In this case, you should look for those SPI features that are actually implemented in PIC hardware. I presume that the "load=pin" option of #use SPI is a pure software feature and you don't get any speed adavantage compared to controlling the pin in your software directly.

PIC24 offers a hardware sync output in framed SPI mode, that isn't specifically supported by CCS C. If you come to the conclusion that framed SPI mode meets your requirements, you'll need to set some SPI special function registers in your code directly. This is always an option if built-in functions don't provide what you want.

[ckielstra]

[RoGuE_StreaK]

[FvM]