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.
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.
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.
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.