I was interviewed on a famous podcast (again)! I got to chat with the amazing folks on the embedded.fm podcast! We talk about Pixelblaze V3 launching on Crowd Supply, LEDs of course, art, Tindie, hobby-business, soldering, and even Halloween candy.
If you haven’t checked it out already, they run a really fun podcast about gadgets and embedded electronics and are great interviewers!
So Ben, looking forward to the new ESP32-C3?
That should fit into your existing board design but be a totally RISC V set of code.
It’s 160Mhz and has little memory if I am reading it right. It could actually be slowed than the ESP8266 and certainly slower than a ESP32. I believe RISC V is open hardware but besides that what’s the benefit? I’m Curious
It absolutely won’t be slower than an esp8266, or they wouldn’t bother. Keep in mind the ESP32 is dual core, this would be single core. The goal is to replace esp8266 in all ways, which esp32 didn’t.
It’s still in the planning so time will tell.
I specifically mentioned this here cause Ben touched on this issue in the podcast.
Ah, cool. Thanks for the info
Yes absolutely!
Ever since I wrote the compiler for Pixelblaze and a virtual machine, I’ve wanted to try both spitting out native xtensa instructions, and designing a CPU in an FPGA that could run the Pixelblaze CPU instructions natively.
It’s not that I really want to go about writing compilers and virtual machines, but they were what appeared to be the best way to achieve the goal of real-time compiling and fast patterns. The first prototype of Pixelblaze was fully interpreted, and V1 tokenized expressions, and had a RPN style evaluator, but wasn’t fully a virtual CPU like V2 is. All in the name of FPS and keeping real-time compilation.
Getting docs for the xtensa instruction set architecture has been a challenge. There are some leaked docs, but they are old and from what I’ve read have out of date information about the FPU, which is where I’d probably do most of my work. I poked around in GCC to see if perhaps that compiler could give hints, but it was easy to get lost in that codebase.
So the combination of a lot of work, and the fact that this instruction set is used on so few CPUs (basically just the ESP32 if I went with FPU instructions), kind of put a damper on going down the xtensa native route, though it’s still a contender, it will be a significant amount of work.
On the FPGA side of things, the open source tooling and available reference CPUs are awesome. I had a blast playing with the ECP5 in the Hackaday Supercon 19 badge. But I have no other experience in a hardware design language, nor extensive digital logic or CPU design experience so I face a learning curve (a fun one, to be sure, but I also want to be productive). There are RISCV implementations that can run on these, indeed the badge came pre-configured with one (and room for a 2nd).
So RISCV has benefits on both sides of that interest. More and more real CPUs are becoming available with RISCV CPUs, so I don’t feel like it would be a dead-end. And on the FPGA side of things, RISCV CPUs provide a good reference design for a custom CPU, with possibly a way to extend the instruction set with new powerful extensions to boost Pixelblaze pattern performance. Maybe even a GPU. Much of how patterns are written lends itself naturally to parallelization.
So yes, a RISCV + wifi chip is quite interesting! I could picture a future where the compiler targets RISCV without extensions and runs on this processor for many projects, and a path where a processor with extended instructions and other hardware accelerations could scale that up in a high end model.