Normally CS is asserted between messages then deasserted after the final
one. Setting cs_change to 1 deasserts CS between messages, but if set on
the final message it causes CS to remain asserted until the next transfer.
Counterintuitively, in the single message case, setting cs_change to 1
prevents CS from changing, while setting it to 0 allows it to change after
each message/transfer.
Some device, like the MFRC522 rely on a change of CS for synchronisation,
and you wouldn't want to leave multiple devices selected simultaneously,
so cs_change should be zero.
This issue was previously masked by the use of the BCM2835 hardware chip
selects, which don't allow CS to remain asserted between transfers.
Normally CS is asserted between messages then deasserted after the final one. Setting cs_change to 1 deasserts CS between messages, but if set on the final message it causes CS to remain asserted until the next transfer. Counterintuitively, in the single message case, setting cs_change to 1 prevents CS from changing, while setting it to 0 allows it to change after each message/transfer.
Some device, like the MFRC522 rely on a change of CS for synchronisation, and you wouldn't want to leave multiple devices selected simultaneously, so cs_change should be zero.
This issue was previously masked by the use of the BCM2835 hardware chip selects, which don't allow CS to remain asserted between transfers.
See: https://github.com/raspberrypi/linux/issues/1547 https://github.com/lthiery/SPI-Py/issues/17