I intend to use the SC18IS602B to control a multiplexed line of LEDs using i2c. For this, I would need to use three GPIO pins to control a 3:8 demux chip and one GPIO pin to toggle the latch enable signal of a shift register. Then I can use the MOSI and SPICLK pins to sink data into the shift register. According to the SC18IS602B datasheet, as far as I can tell, this should be fine.
However, in practice, it appears that attempting to write SPI data to a slave will not work if that slave's slave select pin has been set for use as GPIO. That means that enabling all four GPIO disables the SPI output. SPI data can be sent to any combination of slaves, but as far as I can tell by the datasheet it can't be sent to zero slaves.
The datasheet claims that there is up to four GPIO and makes no mention (that I can see) that using all four disables SPI output. Is there something I'm missing here?
Thank you for the direct answer. I kindly suggest that you revise the wording in the datasheet to reflect that the chip is capable of up to four GPIO and up to one SPI interface, or otherwise indicate that SPI communication is impossible if all four GPIO are enabled. Have a good day!
I don't really see how this is relevant to my question. Here's the way I have the IC on my breadboard. Can the SPI interface be used with all GPIO enabled or not?
If you have an oscilloscope or a logic analyze, check the output of MOSI and SPICLK to verify if SPI interface is active or not when sending a bunch of write commands.
If SPI is active, it's likely the SPI slave IC requires a falling edge (high to low transition) on its SS input and the actual problem is there.
If SPI is not active, and you are using a 0x00 function id (no slave selected), check what happens if you use a function ID with one of the SSn selected (in case SPI requires at least one of them selected to be enabled), even if that SSn pin is configured as GPIO (in case SSn is just ignored when the same pin is configured as GPIO).
If you don't have an oscilloscope or a logic analyzer either try "blind tests" to check if one of the options solve your problem or get yourself a super-cheap "USB oscilloscope" after checking reviews/etc to make sure it fits your needs, even a decent "hobbyst" USB oscilloscope is quite handy to check is a data/clock line is alive etc.
I should have mentioned that I do have an oscilloscope. I've used it to verify everything that I stated in the first post, sorry for being unclear.
I've tried using all function IDs from 0x00 to 0x0F and here are my findings:
0x01-0x0F: The SPI transmits as normal as long as at least one of the selected slave pins is not set to be used as GPIO. If that condition is not met, no SPI transmits at all.
0x00: Never does anything. The chip acknowledges my command and does not SPI transmit. It's worth mentioning that according to the data sheet, this is not actually a function ID. You and I both would assume that this does something since 0x01-0x0F are all SPI transmit functions and the last four bits determines which slave pins are being used, but this particular function ID is not listed and unfortunately it looks like that's correct.