search

nrf-rs / microbit

A Rust crate for BBC micro:bit development
BSD Zero Clause License
276 stars 61 forks source link

WIP: port of microbit to embassy #130

Closed lulf closed 2 months ago

lulf commented 9 months ago

Here is an early show of what an (untested) port to Embassy would look like (Issue #125). I've only modified the existing display-blocking and display-nonblocking examples:

Arguably the display is the most HAL/PAC reliant part of this crate, things using RTC directly can use the 'system timer' instead, but having a custom timer for the display should work.

Most of the peripherals have just changed types.

Next I plan to modify the RTIC example, and also add an async variant of the display driver, reusing some ideas from microbit-bsp combined with the nonblocking driver that is there.

lulf commented 9 months ago

@mattheww since you voiced some concerns about changes to use embassy-nrf, this may be of interest ^^

mattheww commented 9 months ago

Is this based on a branch of embassy? The nonblocking display uses ticker.next_blocking(), but I don't see that in embassy main.

It looks like Board is willing to make RTC1 available to its owner, but embassy-nrf is programming it for its own purposes.

Does embassy have any equivalent of the GPIO typestate stuff that used to guarantee (for example) that if you had a DisplayPins instance then the pins were already configured as push-pull? If not, then maybe DisplayPins or Board should take over responsibility for ensuring that.

lulf commented 9 months ago

Is this based on a branch of embassy? The nonblocking display uses ticker.next_blocking(), but I don't see that in embassy main.

The original code used Instant to implement the ticker behavior, but I figured it makes more sense to put this blocking functionality into the ticker itself, I will PR it to embassy soon. Another reason I was using a branch is that there are some unreleased api changes that I wanted this work to build upon.

It looks like Board is willing to make RTC1 available to its owner, but embassy-nrf is programming it for its own purposes.

Good catch, this should probably be removed.

Does embassy have any equivalent of the GPIO typestate stuff that used to guarantee (for example) that if you had a DisplayPins instance then the pins were already configured as push-pull? If not, then maybe DisplayPins or Board should take over responsibility for ensuring that.

Currently DisplayPins does this configuration in degrade(), but it can be done earlier too.

mattheww commented 9 months ago

Is ticker.next_blocking() putting the CPU to sleep or busy-waiting?

lulf commented 9 months ago

Is ticker.next_blocking() putting the CPU to sleep or busy-waiting?

The next_blocking() essentially polls the RTC1 used for time-keeping in the HAL in a busy loop. Each poll in the loop ends up here checking the 'current time': https://github.com/embassy-rs/embassy/blob/main/embassy-nrf/src/time_driver.rs#L214-L219

lulf commented 2 months ago

Closing this as I think there are maintainers again for the microbit crate, and I will keep async stuff in the microbit-bsp for now.