Description
In the current implementation, the SD card's CS (Chip Select) pin is expected to be hardwired to GND, effectively keeping the SD card always selected on the SPI bus.
While this works fine when the SD card is the only device on the SPI bus, it prevents the use of additional SPI peripherals (such as a CC1101 transceiver, displays, or sensors). According to the SPI protocol, only one device should be active on the bus at a time, selected via its CS line.
Problem
Hardwiring CS to GND violates SPI specifications.
It causes bus contention when trying to use multiple SPI devices.
This limits extensibility and compatibility with common use cases.
Suggestion
It would be highly beneficial to:
Allow configuring the SD card's CS pin via firmware (e.g., via a #define, build flag, or menuconfig option).
Alternatively, provide a way to disable the SD card interface if not used, or tri-state it when idle.
This would make the firmware more flexible and usable in complex embedded applications.
Description
In the current implementation, the SD card's CS (Chip Select) pin is expected to be hardwired to GND, effectively keeping the SD card always selected on the SPI bus.
While this works fine when the SD card is the only device on the SPI bus, it prevents the use of additional SPI peripherals (such as a CC1101 transceiver, displays, or sensors). According to the SPI protocol, only one device should be active on the bus at a time, selected via its CS line.
Problem
Hardwiring CS to GND violates SPI specifications.
It causes bus contention when trying to use multiple SPI devices.
This limits extensibility and compatibility with common use cases.
Suggestion
It would be highly beneficial to:
Allow configuring the SD card's CS pin via firmware (e.g., via a #define, build flag, or menuconfig option).
Alternatively, provide a way to disable the SD card interface if not used, or tri-state it when idle.
This would make the firmware more flexible and usable in complex embedded applications.