WIP: port of microbit to embassy

[lulf]

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:

• display-blocking
• display-nonblocking

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]

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

[mattheww]

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]

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]

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

[lulf]

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