Hacker News new | ask | show | jobs
by exmadscientist 1094 days ago
> Espressif chipsets would be waaaaay more popular

Oh, don't worry, they're getting a ton of attention from the "pros" these days. In hardware no one likes to be the guinea pig if they don't have to be. But these days Espressif is not seen as an exotic choice, and their low cost, excellent feature set, and good supporting material are big draws.

Honestly it feels like they're truly just eating this market, but it's just happening (what looks like) slowly.

2 comments

My job uses the ESP32-S3 (the 2MB PSRAM version, for some extra memory headroom) professionally (and with Nim for the firmware, which is fun). Super neat little SoC!
Interesting you use Nim, would you have some resources/pointers for using Nim on embedded devices. Do you use a native compiler or cross-compile it for this (RISC-V) chip ?
So the S3 is actually a Xtensa LX7 processor rather than a RISC-V one, but the process is the same: “--compileOnly” to output C sources from Nim, and point CMake to that nimcache output folder.

With #line macros injected into the compiled C output source files, JTAG debugging and other tools just work, which is quite nice.

That said, if I was on the C3 or any of the RISC-V chips I’d look at using the C toolchain directly: you can easily have “nim c main.nim” call out to a specific C compiler with your specific build and linker flags!

The one annoyance in all of the embedded toolkits when trying to use non-C/C++ languages is always CMake; companies build component systems and such on top of it which a naive C compiler usage can’t really leverage, which means you end up rebuilding the whole build toolchain again.

Easier to just stick within CMake and use Nim’s C output instead, at least for now (until I get some time to write a nimscript parser for a subset of ESP-IDF’s CMake file format…)

Thanks for a detailed response!

I also use Nim quite a bit on linux/windows for machine-learning purposes. But even on these systems, It is generally a pain to try to trick Nim into using a compiler not directly supported, as some original hard-coded flags would be incompatible with the one i am trying to use,for example NVCC .

Follow up question, Do you generally use Nim on ESP like chips which run some form of a RTOS, or also on bare-metal micro-controllers ?

Yeah, we deliberately have a fork of Nim that is purely for adding workarounds when we hit small internal things like that — though most of our changes are upstreamed proper now which is nice!

To answer your follow up question; both - we’re in the process of bringing up firmware for the STM32G0 and L4 microcontrollers, and CubeMX is such a pain to try and bind as-is, we started to play with svd2nim and see if we can’t bring up peripherals that way instead. That’s a less well tread path of course, but it’s promising so far. Only downside is that’s more like Rust’s approach of rebuilding the world, but oh well

Really cool to see your approach, didn't know about svd2nim project. Hopefully i will able be to use your approach for some hobby embedded projects.

Thanks again for taking time for a detailed reply!!

Ha, I've also used Nim on the ESP32! Are you using Nesper? The author posts on here regularly.
We are yeah! I’ve contributed to it a bit :)
Just curious, what do you use it for?
Run-time configurable box that acts as a IoT gateway to various sensors/protocols/etc, pulling data from a heap of different possible devices and kicking it to our web platform. Used to track all sorts of stuff across a few industries

I forget we actually have a website, probably easier to share that and answer specific technical questions instead! https://www.venturi.io/

> Honestly it feels like they're truly just eating this market, but it's just happening (what looks like) slowly.

I have an friend who works at ARM, he said there's a mix of people who don't understand what's happening and people who are freaking out but have no power to respond.

I have no idea what market share changes have been but speculation based on what I've heard is that EspressIf is large enough that ARM has awareness of their presence but doesn't comprehend their threat. It sounds like it's going to play out like typical market disruptor where the titans will respond too slow and too late to stop them.

The thing is, it's all about that radio. No one cares what the core is. ESP32 is ample evidence of that: neither their Xtensa nor their RISC-V cores are as good as an ARM Cortex-M, in terms of design quality, implementation quality, documentation, ecosystem, or general familiarity. And it just doesn't matter. No one even cares about the Xtensa versus RISC-V products. The toolchain, documentation, major features, and raw horsepower available are all that's important.

Which is a long way to say that ARM has no moat here.