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 transactions in radiolib are super suboptimal #614

Closed
geeksville opened this issue Dec 31, 2020 · 2 comments
Closed

SPI transactions in radiolib are super suboptimal #614

geeksville opened this issue Dec 31, 2020 · 2 comments
Labels
enhancement New feature or request tech debt Code or lib references that are not up to date or propper standards

Comments

@geeksville
Copy link
Member

while working on pinetab support I noticed that the radio lib spi operations are super inefficent. Both for regular register operations and bulk packet read/writes.

The fix is to use the more modern two buf implementations of transfer() provided on the nrf52/esp32 (rather than single byte transfers). This will let the hardware SPI controllers do more of the work. This would also prevent the linux port from doing lots of extra USB operations/kernel entries.

@geeksville geeksville self-assigned this Dec 31, 2020
@geeksville geeksville added the enhancement New feature or request label Dec 31, 2020
@thebentern thebentern added the tech debt Code or lib references that are not up to date or propper standards label Apr 26, 2022
@thebentern
Copy link
Contributor

@caveman99 do you have any ideas on this one? I wonder if RadioLib updates might have possibly optimized the SPI transactions since the issue was created.

@garthvh
Copy link
Member

garthvh commented Sep 12, 2022

closed in favor of #1374

@garthvh garthvh closed this as completed Sep 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request tech debt Code or lib references that are not up to date or propper standards
Projects
None yet
Development

No branches or pull requests

3 participants