XTEink isn't using ESP32-S3 but C3. That S3 dev board from OP also comes with 8MB PSRAM (xteink/C3: 384kB RAM only) which IIUC makes quite the difference when it comes to building an embedded OS.
Being instant-on is so, so cool. I really like seeing projects like this and Adafruit's Fruit Jam as they really show "Yeah, by having all this junk in the way, we do lose some things"
Absolutely would give something like this to a kid as a first computer.
The value for money is crazy on these boards, in my opinion. I'm planning on using these as a cheap replacement to a KVM. Flashing esp bus pirate (https://github.com/geo-tp/ESP32-Bus-Pirate) and leaving it connected to whatever device I want to control ( remotely in my case), is quite handy. The power draw is negligible so I just leave it always on connected to my wifi.
How do you manage display sharing using it? Another device? I have a bunch of refurb servers, which I'd like to keep access to not waiting for an engineer to visit it. The budget is tight so proper KVM is not an option.
Some parts of it, very likely. The shell is just linenoise with some glue code. How are things with ELF loading on rp2350, I did not check. May be possible, the question is, how much effort. In ESP-IDF that is a standard component now.
Right, people were asking about the shell used in the xcc700 demo, so that is released now too, and I tried to make it convenient to reuse as a component.
Esp32-s3 can do so much more, we are just scratching the surface. You might remember FabGL, that ran some nice demos in the realm of games and DOS emulation. Unfortunately, seems to be hard to update for modern versions of ESP-IDF. I am trying to build something more modular, with hope that some parts of it will survive longer.
I think someone also ran an old version of MacOS simulated on it, too, that is also an indication of the general capability.
Doesn't the lack of a flat memory model make a genral os difficult? The amiga1000 had far less processing power and about the same memory, with no mmu, but that memory model was flat. Did you have to do weird things to work around it?
The memory model is flat enough. The problem with the memory is, you only have about 200kB traditional RAM. But then, you have 8MB of PSRAM. But it requires strict 4-byte alignment, and is noticeably slower.
What makes traditional OSs difficult on this platform, is the lack of memory protection. But I am a simple man, I am not writing an OS, all I wanted was a usable shell and an apps installer, so I made that work.
Things change when the underlying assumptions change. Memory protection is mostly useful for multitasking, but traditional multitasking isn't always needed when your entire app starts faster than Windows can minimize a program.
What makes general OS difficult on a SoC is usually the lack of hardware virtual<->real RAM address translation accelerator, the MMU.
I guess it's not that important if developers had no raw pointer access so that object can be anywhere dynamically assigned(Java!!! also JavaScript and all interpreted langs). But basically all desktop OS apps are written in C and they always want single consistent virtual addresses to jump around in and none of apps work without the hardware dynamic translation.
C semantics account for segmented storage, that is why two pointers holding the same bitwise address are not considered to point to the same object, when they are derived differently.
This is my introduction to Breezybox and THAT I am really excited about. I hate that for some reason I have to care about Wifi configuration and updates, I just want to write my application. I never understood why we don’t have simple microcontroller OSes that care about that stuff for us.
This looks like a great basis (or maybe even all that’s needed) for one.
Does it have a good setup flow for headless deployment (e.g. supply Wifi config while flashing, remote shell access/web UI for deploying apps)?
BreezyBox is at an early development stage. What you see in the demo is mostly all there is so far. There is no telling if it will catch on, with more developers adding apps and features.
Some sort of web access for remote config should be possible, if anyone cares to implement that. The web server is already there; getting it to run some server side code may take extra effort.
It should be possible to get most of it compiled for C3, C6, or P4. But xcc700 is specific to the Xtensa CPU, so that would be a bigger effort. And the ELF binaries you install with eget would need to be recompiled (with existing gcc) and published for RISC-V. When it gets to that, we should make some minimal manifest support to eget and the release conventions, to distinguish between ELF files for different platforms. Also keep in mind how much PSRAM is available, if any.
Are you interested in having xcc700 ported to RISC-V, or want to keep it focused on Xtensa? I have a dream of building a simple C89 compiler that targets RISC-V and Wasm and runs on esp32-c6 someday.
I would like to explore the RISC-V systems more as well eventually, but for the nearest future I will probably stick with one platform, try to get my actual device to do more of the fun things I like.
Very cool project. Congrats. I will be trying this out.
Two other project I saw that are somewhat related for those interested:
1. reddit community (r/xteinkereader) building an OS like ebook reader app for a small chinese ereader based on esp32-s3
2. Linux port for the esp32-s3. Interestingly, the S3 has an MMU but I don't think it was used in this project.
https://github.com/ESP32DE/Boot-Linux-ESP32S3-Playground?tab...
XTEink isn't using ESP32-S3 but C3. That S3 dev board from OP also comes with 8MB PSRAM (xteink/C3: 384kB RAM only) which IIUC makes quite the difference when it comes to building an embedded OS.
Being instant-on is so, so cool. I really like seeing projects like this and Adafruit's Fruit Jam as they really show "Yeah, by having all this junk in the way, we do lose some things"
Absolutely would give something like this to a kid as a first computer.
I am looking forward to $20 laptops on aliexpress running this thing!
Well, I know what I'm doing next weekend.. I was already gonna pick up an esp32-s3 for another project, now I need two...
They are really cheap, get an esp32-c6 while you are at it.
https://www.espboards.dev/blog/esp32-soc-options/
I'm loving my C6, and the P4s look like an absolute beast. I'm not ready for that kind of firepower yet.
The value for money is crazy on these boards, in my opinion. I'm planning on using these as a cheap replacement to a KVM. Flashing esp bus pirate (https://github.com/geo-tp/ESP32-Bus-Pirate) and leaving it connected to whatever device I want to control ( remotely in my case), is quite handy. The power draw is negligible so I just leave it always on connected to my wifi.
How do you manage display sharing using it? Another device? I have a bunch of refurb servers, which I'd like to keep access to not waiting for an engineer to visit it. The budget is tight so proper KVM is not an option.
Would it be possible to port it to run on the rp2350?
Some parts of it, very likely. The shell is just linenoise with some glue code. How are things with ELF loading on rp2350, I did not check. May be possible, the question is, how much effort. In ESP-IDF that is a standard component now.
rp2350 supports freertos, so a similar port should be fairly trivial.
The io DMA code is a little special on the Pico. Very capable little chip. =3
Hey you're the xcc700 guy! Very cool stuff. I've been interested lately in using MCUs for general purpose compute. I wonder how far you could push it.
Right, people were asking about the shell used in the xcc700 demo, so that is released now too, and I tried to make it convenient to reuse as a component.
Esp32-s3 can do so much more, we are just scratching the surface. You might remember FabGL, that ran some nice demos in the realm of games and DOS emulation. Unfortunately, seems to be hard to update for modern versions of ESP-IDF. I am trying to build something more modular, with hope that some parts of it will survive longer.
I think someone also ran an old version of MacOS simulated on it, too, that is also an indication of the general capability.
https://github.com/evansm7/pico-mac
Mac on the RP2040.
Very cool! We need to get this on M5Stack Cardputer ASAP
Doesn't the lack of a flat memory model make a genral os difficult? The amiga1000 had far less processing power and about the same memory, with no mmu, but that memory model was flat. Did you have to do weird things to work around it?
The memory model is flat enough. The problem with the memory is, you only have about 200kB traditional RAM. But then, you have 8MB of PSRAM. But it requires strict 4-byte alignment, and is noticeably slower.
What makes traditional OSs difficult on this platform, is the lack of memory protection. But I am a simple man, I am not writing an OS, all I wanted was a usable shell and an apps installer, so I made that work.
Things change when the underlying assumptions change. Memory protection is mostly useful for multitasking, but traditional multitasking isn't always needed when your entire app starts faster than Windows can minimize a program.
Just like MS-DOS and CP/M did great with such hardware constraints.
I still think many don't understand how much is possible with a plain ESP32.
We should have an argument about how WASM would be the perfect app format for this.
Like USCD Pascal P-Code, M-Code, Taos, IBM TIMI, JVM, CLR, Parallax Propeller, and many others.
What makes general OS difficult on a SoC is usually the lack of hardware virtual<->real RAM address translation accelerator, the MMU.
I guess it's not that important if developers had no raw pointer access so that object can be anywhere dynamically assigned(Java!!! also JavaScript and all interpreted langs). But basically all desktop OS apps are written in C and they always want single consistent virtual addresses to jump around in and none of apps work without the hardware dynamic translation.
C semantics account for segmented storage, that is why two pointers holding the same bitwise address are not considered to point to the same object, when they are derived differently.
Can you expound on this problem a bit? I'm still pretty new to MCUs.
This is my introduction to Breezybox and THAT I am really excited about. I hate that for some reason I have to care about Wifi configuration and updates, I just want to write my application. I never understood why we don’t have simple microcontroller OSes that care about that stuff for us.
This looks like a great basis (or maybe even all that’s needed) for one.
Does it have a good setup flow for headless deployment (e.g. supply Wifi config while flashing, remote shell access/web UI for deploying apps)?
BreezyBox is at an early development stage. What you see in the demo is mostly all there is so far. There is no telling if it will catch on, with more developers adding apps and features.
Some sort of web access for remote config should be possible, if anyone cares to implement that. The web server is already there; getting it to run some server side code may take extra effort.
I visited ESPboards.dev website and S3 version is “Best for AI & Machine Learning Applications - Hardware-accelerated neural network processing”.
Deep rabbit hole…
Thanks.
Bit of a noob question: is this limited to the S3 or can I try running it on a C3 too?
It should be possible to get most of it compiled for C3, C6, or P4. But xcc700 is specific to the Xtensa CPU, so that would be a bigger effort. And the ELF binaries you install with eget would need to be recompiled (with existing gcc) and published for RISC-V. When it gets to that, we should make some minimal manifest support to eget and the release conventions, to distinguish between ELF files for different platforms. Also keep in mind how much PSRAM is available, if any.
Thank you, will just give it a whirl on a S3 instead.
Are you interested in having xcc700 ported to RISC-V, or want to keep it focused on Xtensa? I have a dream of building a simple C89 compiler that targets RISC-V and Wasm and runs on esp32-c6 someday.
I would like to explore the RISC-V systems more as well eventually, but for the nearest future I will probably stick with one platform, try to get my actual device to do more of the fun things I like.
Would love this with Zig installed
Obviously the dependencies are way too heavy currently, but I do wonder long term if we'll have simple, highly portable zig compilers.
This seems like magic. I know it’s not, but it goes against everything I knew about ESP! Nice work.
ok, I can run fuzix, why using this?
Mostly if you like the usual ESP-IDF setup and ecosystem.
Cool project!
Sorry to noob here but is this free of blobs?
When I tried an ESP a few years ago, running it involved binaries.