examples: st7789: Initial commit

[alistair23]

This is a basic example of displaying data on a st7789 screen using Tock.

This requires a few dependencies, which unfortunately get included for all examples. The other issue is that the example fails to build unless FEATURES=rust_embedded is passed as part of the make command. What are people's thoughts on handling this?

[alistair23]

@jrvanwhy as I hope you have some ideas

[alevy]

I'm pretty split on this.

On the one hand, it's a cool demo that a rather involved set of embedded-hal libraries can work in libtock-rs.

On the other hand, while it works, it's a pretty non-cannonical way of writing a Tock process---really, the translation from "draw pixel" <-> SPI commands should happen underneath something like the Screen HIL in the kernel, so the application is natively portable, the screen can be divided or switched between processes, etc.

[alistair23]

On the other hand, while it works, it's a pretty non-cannonical way of writing a Tock process---really, the translation from "draw pixel" <-> SPI commands should happen underneath something like the Screen HIL in the kernel, so the application is natively portable, the screen can be divided or switched between processes, etc.

Yeah, it would be nice to do it in the kernel.

That's a huge effort though. tock/tock#3079 covers some of the things needed, which predictably have all stalled. It would also require a re-write of https://github.com/almindor/mipidsi in the kernel.

Doing it in userspace means we can handle all of graphics complexities there and also utilise the well supported rust-embedded ecosystem.

Maybe if you or someone else adds kernel support in the future we can update this to use that instead

[alevy]

That's a huge effort though.
...
It would also require a re-write of https://github.com/almindor/mipidsi in the kernel.

I'm not sure that's true. See for example the lvgl example in libtock-c which just uses an existing embedded graphics library, (not so different from the embedded-graphics crate).

Supporting embedded-graphics would only require implementing the DrawTarget, which is really one relatively simple method to implement.

[alevy]

The main problem I have, I think, is that this looks like The Right Thing(tm) to do if it's in examples. I'm similarly wary of maintaining such examples long term.

Two options that could solve both this problem and the specific problem of the dependencies living in the library's Cargo.toml:

1. Create a new repo called, say demos, that could house things like this which are: "look what you can do!" rather than "look how you should do things!" (it's possible that some of those are the current best possible thing to do without a lot of other work, but separating what's the vision from what's currently required is useful).

2. Create a demos subdirectory which in this library which can have a bunch of separate crates. Same basic idea as (1), just lighter weight than a totally new repo.

[alistair23]

I'm not sure that's true. See for example the lvgl example in libtock-c which just uses an existing embedded graphics library, (not so different from the embedded-graphics crate).

Ah true. There is also already a Tock port for the ST7789 that I didn't know about as well. Although there are so many displays supported by embedded-rust that we don't have in the kernel, so it doesn't help for the next display

A demos directory is fine with me. We need something different to the current examples anyway to handle all of the dependencies

[alistair23]

Updated to implement "Idea A" with a demo directory containing a separate crate