Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose all the CS signals (The SPI hardware can take multiple CS pins and turn them on/off for each transfer. Software CS shouldn't be the long term solution for shared buses) #2795

Open
Tracked by #2494
bjoernQ opened this issue Dec 13, 2024 · 1 comment
Labels

Comments

@bjoernQ
Copy link
Contributor

bjoernQ commented Dec 13, 2024

No description provided.

@bugadani
Copy link
Contributor

We should probably expose a sort-of CS allocator. Devices should be able to request "CS tokens" (which essentially just stores the number of the CS signal) from the SPI driver, and the SPI driver should expose a setting to configure which CS token is in use, along with KEEP_CS_ACTIVE (#2797).

Something like:

let cs = Output::new(...);
let cs_token = unwrap!(spi.allocate_hw_chip_select(cs));

let device = SpiDevice::new(&spi, DeviceConfig::default().with_hardware_cs(cs_token)); 
// OR:
let device = SpiDevice::new(&spi, DeviceConfig::default().with_gpio_cs(cs));

This would mean a slight inconsistency in terms of how we set up a peripheral signal, but it also prevents routing a chip select to multiple outputs by accident. Since we don't clear existing peripheral output signal connections, that would be all too easy to do with just calling .with_cs0() multiple times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Todo
Development

No branches or pull requests

2 participants