LED display driver

[mattheww]

I have written some code to drive the micro:bit's LED display.

It includes:

• an interrupt-based driver, with varying levels of brightness
• simple 5×5 greyscale and black-and-white image types
• a copy of the 'pendolino' font from the micro:bit runtime
• some support for scrolling text

Do you think some form of this ought to live in the main microbit crate?

The current crate is at https://github.com/mattheww/microbit-blinkenlights/ . I haven't published it on crates.io.

The rustdoc is at https://mjw.woodcraft.me.uk/2019-mb/microbit_blinkenlights/ .

[therealprof]

Oh wow, very cool! There's already a LED driver but improvements in this area would be really cool.

I'm not sure how much of it makes to include in the microbit or whether this should rather be in a generic dotmatrix crate and just be referenced/supplemented in here. But regardless of how we achieve this, any improvement is very much welcome.

[mattheww]

I'm inclined to keep this code microbit-specific rather than trying to make something more generally useful.

That's mostly because part of the point of the microbit is to try to have a computer that's simple enough that a young programmer could understand the whole thing from hardware up, like the 1980s micros. Generalised code gets in the way of that a bit.

Where do you see the microbit crate heading? Is it essentially a board-support crate, or should it move towards being a fuller runtime system like the 'Lancaster' C++ microbit DAL?

[therealprof]

I'm inclined to keep this code microbit-specific rather than trying to make something more generally useful.

I think it would be great to have something that doesn't only work with the micro:bit.

That's mostly because part of the point of the microbit is to try to have a computer that's simple enough that a young programmer could understand the whole thing from hardware up, like the 1980s micros.

And a general LED multiplexing driver defeats that idea how exactly? If anything that could be used to explain how row/column scanning works (electrically) and why the human eye sees a full image.

Generalised code gets in the way of that a bit.

I don't see it. Of course we'd still have a specialised version with the exact same functionality and interface which just works(TM).

Where do you see the microbit crate heading? Is it essentially a board-support crate, or should it move towards being a fuller runtime system like the 'Lancaster' C++ microbit DAL?

TBH I started this as a learning tool for me (to get deeper into embedded Rust and experiment with generic traits and implementations covering other vendors than my usual vendor STM) and my kids. I was hoping that a community would emerge taking care of evolving it into something bigger which really hasn't happened.

If there's interest and effort to turning it into something bigger, that'd be awesome. If not then this is going to remain a BSP.

[mattheww]

There are two main things that would need generalising:

• move the current initialise_pins(), display_row_leds() and light_current_row_leds() into a new trait analogous to the current DisplayTimer;

• generalise all the image-like types to no longer be hard-coded to 5x5.

There are good chances that doing the first will make the code cleaner anyway.

But I think doing the second one probably ought to wait for const generics to be available (and ideally more powerful const fn too).

I think this probably isn't the place for a discussion of why I think that adding layers of abstraction gets in the way of self-directed learning, but I do think it's a real problem. When the display code in the microbit DAL wants to set a timer there are five layers (in mbed) before it gets to the nrf51 SDK call, and I'd like to avoid getting so far away from the hardware.

[therealprof]

I think you're spot on. Unless there're any licensing issues (e.g. with the Pendolino font) there don't seem to be any obstacles to integrating your code into this crate.

I think this probably isn't the place for a discussion of why I think that adding layers of abstraction gets in the way of self-directed learning, but I do think it's a real problem.

I fully agree. That's why it is up to more experienced people to not add abstraction for the sake of disguising what's going on/reusing whatever is already there but to break down complexes into small and understandable blocks. This may not always be possible but I think it's a goal worth striving for.

[mattheww]

I've separated out non-microbit-specific code into a tiny-led-matrix crate (just the LED manipulation, not the 'image' types).

The separation came out a bit uglier than I'd hoped, mostly for two reasons:

• Rust doesn't yet let us use a trait associated constant for an array size (so it's hard to make the library provide the concrete 'Frame' type, which needs one entry per row).

• The coherence rules means I've had to introduce newtypes to implement the 'interface' traits like DisplayTimer, rather than implementing traits directly for nrf51::TIMER1 &c.

I'll submit a draft pull request with the core of the microbit implementation for your consideration.

[therealprof]

I think we can close this now?

[mattheww]

Yes.

The font and scrolling-text stuff is currently sitting in https://github.com/mattheww/rmicrobit . I don't think I'm likely to have time to turn it into PRs, but you're welcome to take anything you like from there.

[therealprof]

I won't have time to look into it either, but since people seem to be on fire to get the micro:bit support in shape, maybe someone else will pick it up.