i want to understand how the handling of the chip select pins works:
i tried different libraries which need different CS-Pins, because multiple devices should be addressed.
now i realized that it also works fine if i take completely other pins, not the dedicated ones (4, 10, 52).
so my question is: what makes the dedicated CS-Pins so special? Or the other way round: is it bad coding/hardware design, if i use other pins? what could be the gaps when doing this?
I believe that the "dedicated" SPI CS pins come into play when the Due is expected to behave as the SPI Slave Device, rather than the master.
Thanks, westf. Can you explain the background of this fact- just in a few words...
When you write to SPI, you enable some CS pin to select which device you actually want to talk to, send your data, and disable CS. CS can change essentially as slowly as you want.
When you are an SPI slave, and your CS input is enabled, you have to be ready to start receiving data nearly immediately, so it's desirable to have the "select" be done in hardware, rather than requiring SW intervention.
(This is only "interesting" if you have multiple SPI slaves connected to the same clock and data pin "bus.")
I see, but then it also matters, if i am the master, because i have to tell my slaves exactly when they have to react or clos their line. Or is software switching normally fast enough in that case? It works in my case with 4 different spi devices on one bus, but i am not sure if i am just lucky and should take care, if my sketch needs eventually more runtime?
On the recent DUE/CH340 board versions, where SPI CS0=10, CS1=4 and CS2=52, you may use other CS pins, however, when setting alternate CS pins low to enable them, you must hold CS0, CS1 and CS2 high to simultaneously disable. Then you won't just be lucky...
IMO the major interest of using SPICSO/SPICS1/SPICS2 as CS pins is that SPI peripheral handles automaticaly these pin states, don't need to do that manually. However I don't know if SPI Library does it since I program directly SPI registers.
You can have 2 more "automatic" CS pins if you select USART0 or USART1 in SPI mode. Of course the SPI Library won't work in this configuration.
could you utilize the hw CS handling?
Yes I can.
Can you please share a working example? I try with this:
#define CS_PIN1 52 // software CS
#define CS_PIN2 10 // SPI hw CS
CS_PIN1 is the pin for software-based CS control
CS_PIN2 is the pin for hw-based CS control
I use a serial eeprom for test... It doesn't work with SPI hw controlled pin.