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

Support non-blocking serial/SPI/... communication #128

Open
dflemstr opened this issue Jan 22, 2020 · 0 comments
Open

Support non-blocking serial/SPI/... communication #128

dflemstr opened this issue Jan 22, 2020 · 0 comments

Comments

@dflemstr
Copy link

I'm working on embedded-platform and am targeting nrf52840 devices as the first use-case.

Currently, I'm using this code to support serial writes: https://github.com/dflemstr/embedded-platform/blob/f9ae5e7b686fdbf66ee3f172c755aea543d4c102/platforms/nrf52840/src/serial.rs#L19-L23

I haven't started on SPI/I²C/... mappings but I suspect there will be similar challenges in making the code non-blocking.

The execution model I have chosen is to have the main thread always run wfi when there is nothing happening, and rely on interrupts to wake it up, poll a main future, and do some work, before going back to wfi.

Ideally, the baseline behavior I would like to see is to break apart some of the blocking transactions into multiple steps. Let's look at this section for example:

https://github.com/nrf-rs/nrf52-hal/blob/90a8c3c7dbdb478b49580fd2bf2f89bdb9286cc2/nrf52-hal-common/src/uarte.rs#L145-L154

This could either be modeled as an explicit state machine (e.g. an enum) where during each state transition, there is some sort of polling method instead of a while loop. So imagine a SerialTransaction object with a poll() method that would eventually return a successful status.

If this approach sounds sane, I can make it into a PR.

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

1 participant