[anujdeshpande]

Espressif is taking quite a radical approach as compared to other semiconductor companies. They provide everything from a Cloud SaaS for their chips, to open source phone apps that connect over BLE/WiFi to their chips, reference hardware designs, integrations with voice assistants, and more. Typically, semiconductor companies have shied away from providing anything comprehensive because they don't want to upset their distributors and partners who provide the missing services - but not Espressif.

I think if the US-China chip war hadn't been going on, and customers wouldn't have been paranoid of using a Chinese chip (and being in a tough spot like Huawei customers), Espressif chipsets would be waaaaay more popular.

Disclaimer/source - worked at Espressif for a bit (2017-2019)

[exmadscientist]

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

[girvo]

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!

[warangal]

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 ?

[girvo]

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…)

[warangal]

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 ?

[girvo]

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

[skupig]

Ha, I've also used Nim on the ESP32! Are you using Nesper? The author posts on here regularly.

[girvo]

We are yeah! I’ve contributed to it a bit :)

[m00x]

Just curious, what do you use it for?

[girvo]

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/

[cptskippy]

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

[exmadscientist]

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.

[037]

From what I recall, the ESP8266 was originally just a module designated to provide WiFi capabilities to other circuits, but over time, hobbyists discovered that it had much more potential. Its incredibly low cost sparked its popularity. Espressif did an excellent job of designing the ESP32 to accommodate the demands of the emerging audience. But I could be mistaken; I might be missing a part of the story.

> The ongoing US-China chip war has created a situation where users hesitate to use Chinese chips, wary of ending up like Huawei's customers. Without this scenario, Espressif chipsets might have enjoyed much greater popularity.

These chips are intricate enough to potentially contain backdoors. While it is something I never thought about with respect to Espressif, it does seem plausible that they could be a target.

[Vespasian]

Yes compared to the "classical" way of using an Arduino and maybe some ethernet shield, ESP8266 felt like a real revolution (in the hobbieist space).

They were powerful enough to do useful work and you didn't have to worry about RAM.

[037]

What really sparked my interest was having WiFi in a chip that only cost maybe 2 usd at the time. Plus, you could find great usb dev boards for less than 5 usd.

If I had this stuff as a teenager, I would've lost my mind...

[gh02t]

Yeah, important to remember that the old Wifi module for the Arduino was like 20-30 bucks and was basically just an AT modem that still needed a host Arduino. Barely anybody ever used them that I saw. The original ESP-01 for a couple bucks was a very exciting product for hobbyists just as a serial-to-wifi adapter even with minimal English documentation, and then it went bonkers when they released Arduino support and a package with enough IO to do useful things. Espressif has also been pretty nice to the hobbyist community in general once they realized what they had done.

[otherme123]

The first time I saw a 8266 I thought "why am I struggling with Arduino or Raspi if this thing is all I need to make a sensor + wifi mesh". Also being powered through the USB is a plus, lots of unused USB ports around in 24/7 machines.

[HankB99]

Agreed. Hobbyist (and retired professional here) who fools around with IoT stuff at home. I've done lots of things with Raspberry Pi Zeroes that can be done with an ESP8266/ESP32 and with the benefit of on board analog inputs. Some of the devices I've used (like the Bosch BME280) seem to work better on the ESP and I suspect that's because the serial communication does not suffer from the risk of missed data due to managing the protocol in user space. The ESP is easier to program for real time either using FreeRTOS or just bare metal. Espressif's SDKs are a bit cumbersome to install but the VS Code extension helps to manage a lot of that. And it all works well on Linux.

[int0x2e]

> These chips are intricate enough to potentially contain backdoors. While it is something I never thought about with respect to Espressif, it does seem plausible that they could be a target.

As the old saying goes, "the S in IoT stands for security" - I choose to trust Google/Amazon and their peers to have an Internet-connected device, but everything else (95% the IoT devices I have) gets sectioned off to a dedicated VLAN & WLAN with no Internet access (and no access to the rest of my network).

This keeps me safe, and keeps the devices safe from each other (micro-segmentation in the access level). No need to trust what has minimal interfaces, and then I don't worry as much if I don't roll software updates every week...

[squarefoot]

> These chips are intricate enough to potentially contain backdoors. While it is something I never thought about with respect to Espressif, it does seem plausible that they could be a target.

They could indeed be, as already are all PC's, phones, TVs and any smart connected household appliance, no matter if they're built in China. I would never ever consider building a IoT home system wthout putting it behind a dedicated and firewalled hardware subnet that protects from the outside and from the inside. Ok, the firewall hardware itself could contain tampered chips with firmware instructing them to encapsulate and redirect certain traffic outside of the rules without reporting it, but that's another story; when in doubt, I prefer to consider every piece of hardware that is closed and connected as potential spyware.

[ajsnigrutin]

They already are very popular. They're embedded in devices from smart home gadgets to washing machines and smart appliances.

The great thing I find about them is, that they are "hackable". Don't want to depend on some weird company and their cloud, especially with long-lasting appliances (which outlast the company cloud or even the whole company)? Just buy something with esp8266/esp32 inside, and there's a high chance, that there is some opensource firmware (tasmota, esphome,....) available.

(disclaimer: some times the "hacking" part involves soldering irons, wires, usb->serial adapters and knowledge of electronics safety, especially with mains powered devices)

[int0x2e]

I totally agree.

It's also great to see how with a little technical know-how, you can avoid paying 100s of dollars for some IoT tech that is reliant on more people buying overpriced hardware for it to work in the future, and instead - go for DIY or cheap hardware (e.g.: SonOff) which gets a huge audience due to their low prices, which guarantees someone like me will spend the time to get it properly supported soon enough...

All of a sudden, the premium product becomes the inferior product, because it will have a smaller market share, and therefore, fewer hackers :-)

[auxym]

A lot of grey-beard type embedded programmers, who programmed in assembly through the 80s and 90s, really got attached to their architecture of choice, whether that is AVR or MSP430 or 8051. That crew tends to be very conservative with tech choices, for both good and bad reasons.

Some then learned to tolerate ARM Cortex M.

But Espressif, this weird new and unknown Chinese manufacturer, came out with their own arch and instruction set that no one else uses (xtensa). A lot of old timers were wary.

Their price to feature ratio is unbeatable though. That go them in the maker/hobby community fast, and lately I've heard of more and more companies using esp32 for actual professional products.

[packetlost]

Xtensa is licensed from Tensilica which is both an American company, but also used extensively in non-consumer facing industrial systems. It's not that nobody uses it, it's that you're likely not even close to the target market they're made for. Espressif is a fabless semiconductor company, they don't actually make their chips, they license a bunch of parts, design some developer boards, and write software around it. They're much closer to a software company than a hardware company.

[ranma42]

Athereos wireless cards (ath10k) have also used Xtensa. And the audio DSP in newer intel chipsets (e.g. Apollo Lake) is also Xtensa-based, but unfortunately quite locked down (signed firmware only). See https://thesofproject.github.io/latest/platforms/index.html Also ISTR that older Radeon graphics cards used Xtensa (e.g. in the Unified Video Decoder).

[kps]

There was a period centered around the late '90s where new architectures were a dime a dozen, as access to fabs opened up, and small companies with an idea hoped to become the next Intel.

Anyway, ESP32-C3 is RISC-V, and I suspect they won't do any more new Xtensa cores.

[packetlost]

They've explicitly stated it's all RISC-V from here on out.

[adolph]

Yes, the announcement of the ESP32-P4 certainly makes it look that way.

https://www.espressif.com/en/news/ESP32-P4

[kkielhofner]

I can't agree with this enough. Willow[0] (disclaimer - I'm the creator) just wouldn't be possible without the robust Espressif ecosystem, libraries, code samples, docs, etc. Let alone all on a finished product (ESP BOX, $50) available worldwide through their distribution channels! We have a lot of background and experience in this and related fields but the fact remains we went from concept to initial release in less than six weeks (with two part time devs - if you include me, which you shouldn't haha).

[0] - https://github.com/toverainc/willow/

[tyingq]

Wouldn't the newer RISCV based ESP32 models eventually add to the commercial popularity? Maybe some commercial users stayed away from the Xtensa powered ones, especially if they would have needed to do lower level work?

[kps]

ESP32s aren't really ‘lower level’ in the sense that anyone is likely to write assembly code for them (compared to, say, 8051 or PIC), other than maybe some driver author at Espressif. The big win from using RISC-V, other than name recognition, is mainstream compiler support (which is nothing to sneeze at, especially when it's largely funded by someone else).

When I worked on Matter¹, the Xtensa and RISC-V versions were basically fungible from the software point of view. (And really, so were other vendors' various ARMs.) We did find that Bloaty McBloatface² didn't support Xtensa, so I had to write an alternative.

¹ https://github.com/project-chip/connectedhomeip/

² https://github.com/google/bloaty