ESP32 uses the Xtensa instruction set. As far as I understand this is a custom instruction set, which is surprisingly popular in low power applications.
Investigating this lead me to an interesting polish company called semihalf who were recently acquired by google.
https://www.youtube.com/watch?v=qLh1FOcGysY
Apparently they added some Xtensa support to clang. I guess that means xtensa is very important in the android context.
Xtensa is from Tensilica (now Cadence) but, as sibling comments point out, new Espressif designs use RISC-V. There's a bit of an overlap point: the ESP32-S2 and ESP32-S3 are recent designs that use Xtensa, and they were released at roughly the same time as the ESP32-C3 (I believe the first Espressif RISC-V part).
Here's the ISA summary for Xtensa LX as used by the ESP32: https://www.cadence.com/content/dam/cadence-www/global/en_US...
The S2 & S3 are more powerful and capable than the currently available Espressif RISC-V microcontrollers. Perhaps it's best to think of them marking the summit or climax of Espressif's Xtensa parts. But the future clearly lies with RISC-V.
The Xtensa support in LLVM/Clang appears to have resulted (at least in part) from Espressif's active support for Rust on their microcontrollers. The recent Rust 1.81 release merged support for the ESP32, ESP32-S2 and ESP32-S3 into upstream rustc. It's great to see a microcontroller vendor directly support the use of Rust on its parts, and not just its "new" parts.
Edit: To be clear, the ESP-IDF framework is a huge C project, so Espressif working on LLVM support for Xtensa is clearly _not just_ for Rust. And "easy mode" Rust-on-Espressif (std support!) relies on the ESP-IDF so merging their patches into LLVM is beneficial all-round.
Xtensa is an interesting "instruction set" because it's not one single instruction set but it's a "parametric instruction set" (hence the name which hints at "extensible")
When instantiating an xtensa core you can choose how many registers you want, whether you want to have register windows or not, and many other options.
If you want a compiler that targets a given instance of that architecture you have to tailor it to those parameters.
BTW I wrote a gdb-protocol speaking software debugger component for the esp8266 (before xtensa wrote/published their own)
I had to reverse engineer a lot of details (number of registers, Layout of the stack frame in various kinds of interrupts and traps etc) because xtensa didn't publish the actual parameters of their xtensa instantiation
There are ESP32s that use RISC-V, see https://www.espressif.com/en/products/socs/esp32-c3
All of their models released after a certain point are RISC-V, though there's still gaps in the capabilities of their RISC-V range (e.g. no LCD controller or USB OTG) which means it can't cover all of the Xtensa models use-cases yet.
This was already posted back in the day, but gained zero points, which seems unfair, given the tooling applied here. Playing with one TTGO with small display, this all in the article makes lotta sense, and perahsp to others too.
The demoscene trickery is not very significant and is only a tiny part of the article. Great project though, so still worth reading.
I have been screwing around with ESP01s lately (based on the ESP8266, which is the predecessor to the ESP32). It’s amazing how much power you get in a <$5 microcontroller, plus WiFi.
This is great. I shudder a bit over doing all that dev work from Windows, but they made it work very nicely.
A testament to how well designed and executed the ESP-IDF framework is. Paired with VSCode I’ve found it a joy to work with IDF and my ESP32-S3.
ESP-IDF is astonishingly well done. As someone who used to install Linux from stacks of Slackware floppies and used open source code back in the days when the install instructions were: configure; pray; make; figure out which of the 11,000 warnings are important; hope it’s simple; give up —— to grab an example, change a couple constants for pins and number of LEDs and have everything just work, _without even any warnings_ was just incredible.
If that piques your interest—-even if, like me, you feel a bit intimidated by hardware—-I tried to write down as much of the journey and learning as I could: https://github.com/zellyn/weblight
For those on *nux wishing to play with Rocket, I've found emoon's GL editor preferable over the Qt one bundled with the library.
Emoons' editor is featured in the article. I don't understand these kinds of comments.
The one actually linked in the article when mentioning emoon's is Ground Control [0], which I mistook to be another of emoon's projects, but doesn't seem to be.
The one I highlighted is a work-in-progress GL based editor that isn't windows-specific [1], and is indeed the one they were criticizing for the small font/not dpi aware, my mistake. They didn't link it in the article, which is why I felt compelled to link it.
No need to be a twat about it. I have commits in emoon's GL editor and GNU Rocket, these aren't some uninformed b.s. drive-by comments.