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

spi: specify expectations regarding peripheral state between transactions #565

Open
Artur-Romaniuk opened this issue Jan 11, 2024 · 2 comments

Comments

@Artur-Romaniuk
Copy link

Currently, SPI device traits deal with a transaction concept, which implies transmission of some data, while the CS is set for the whole duration. There is currently no guidance on how should the peripheral behave between transactions.

Issue

Certain SPI devices require bus synchronization, which means that the bus must not be disabled for the entire communication sequence and all lines must be kept in a known state (especially CLK). Communications sequence spans multiple SPI transactions.

Cause

Some HAL implementations disable SPI after each transaction, some don't. Some do it only after DMA transaction, some do it after each transaction. This unpredictable behavior of bus lanes, prevents a creation of generic device drivers that require synchronization.

Proposed solution

Embedded-hal should allow for specifying certain expectations regarding SPI bus state, to allow for correct behavior of device drivers for different HAL implementations.

@Dirbaio
Copy link
Member

Dirbaio commented Jan 11, 2024

Certain SPI devices require bus synchronization, which means that the bus must not be disabled for the entire communication sequence and all lines must be kept in a known state (especially CLK). Communications sequence spans multiple SPI transactions.

can you share examples of chips requiring this?

@Artur-Romaniuk
Copy link
Author

E.g. Qualcomm QCA7000 series chips

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

No branches or pull requests

2 participants