image-gallery VS tock

https://www.invisible-computers.com/invisible-calendar/image...

Two:

https://github.com/Invisible-Computers/image-gallery/blob/ma...

Both of these require rendering the content via an HTTP endpoint and both of these currently still require the content to be proxied through the device backend.

> I can buy an ESP32 e-ink screen and run esphome or any of several other open source projects and put a piece of wood on the front of it, too.

Yes, you can! And if you do this, you have absolutely no need to use my e-paper smart screen.

I am hoping to add third party apps, that's why I have created the API for 3rd party apps:

https://github.com/Invisible-Computers/image-gallery/blob/ma...

But right now, I understand that building an app for my platform is

a) more hassle than just pointing to a URL

b) limited upside, because the audience that you can charge for a subscription isn't very big yet.

However, I think that a good app could generate its own audience (aka drive ppl to buy the displays) and then make money by charging them a small monthly subscription fee.

I'll ship within Europe as soon as I have bootstrapped the 7000 Euro necessary for CE certification.

In terms of openness, there is this:

https://www.invisible-computers.com/invisible-calendar/image...

and this:

https://github.com/Invisible-Computers/image-gallery/blob/ma...

I also want to make the esp32 controller itself more hackable in future, but I don't want to promise anything because that's quite a lot of work for me.

Here is the API description:

https://github.com/Invisible-Computers/image-gallery/blob/ma...

And here is the sample app:

https://github.com/Invisible-Computers/image-gallery

Admittedly, I am not the greatest technical writer, but I compensate by being pretty responsive. :)

This display offers a simple API to build applications for it:

https://shop.invisible-computers.com/products/invisible-cale...

https://github.com/Invisible-Computers/image-gallery/blob/ma...

The API doesn't require any special knowledge about e-paper displays, it just expects an image URL in the correct resolution and will then render it to the display.

You can buy the display off the shelf, and if you are interested in building an app, contact me at [email protected] for a developer account :)

Feel free to go to town on it :)

Hi! This is Daniel from OxidOS Automotive (stating this for disclaimer purposes).

Yes, our OS is based on TockOS, and our CEO (Alex Radovici) is #7 in the contributors list (https://github.com/tock/tock/graphs/contributors), with other colleagues contributing in the past years.

I'm definitely not the best person to answer this, but honestly it's not bad. Here's an example of a moderately complex peripheral, the cortex-m MPU, and how one rust OS handles it:

https://github.com/tock/tock/blob/3a0527d586702b8ae8cb242391...

Reads and writes turn into volatile reads, so everything works out under the hood. You get the benefits of everything having good names, declared sizes, and proper typing on your register accesses. You can extend that to bit accesses as well.

Rust still has a few areas it isn't competitive in, like your hyper limited or obscure chips (e.g. 8051s, XAP), mature tooling around formal methods, and a certification story for safety critical code. People are working on these latter two issues (e.g. ferrocene) and supposedly very close to public delivery, but you know how slow the industry is to adopt new things even then.

There's Tock (https://www.tockos.org/), which is written in Rust (with sprinkles of assembly).

Yeah, and I like I mentioned in the earlier comment, omitting the frame pointer reduces code size by 10% on RISC-V targets, which is huge when dealing with embedded flash: https://github.com/tock/tock/pull/1660

Tock is an excellent embedded OS written in Rust and has some good industrial support. I think Tock gets a lot of stuff right and I highly recommend some of the talks the developers gave on it.

Unfortunately, it increases the code size by 10%. I was looking into this just last week, and can confirm that it's still a problem on the latest version of Rust nightly: https://github.com/tock/tock/pull/1660

I wish we could have frame pointers, because they would make working in embedded land so much easier and more reliable, but a 10% increase in code size just isn't worth it.

TockOS was the first rust RTOS I found. Coincidentally, it has had support for the esp32c3 for over a year now.