Espressif's ESP32-C5 Is Now in Mass Production

Some places are wanting to go dual 5 GHz radios on APs (for general client density) rather than 2.4 GHz and 5GHz radios but 2.4 GHz only IoT devices force you into keeping a 2.4 GHz radio infrastructure active. These kinds of environments tend to turn the power down on 2.4 GHz anyways as "goes through walls" can actually be a bad thing for coverage when multiple APs are at play (SNR is more important than raw power).

For a typical consumer home use case continuing to use 2.4 GHz is most likely ideal though. Though some apartment complexes have such bad 2.4 GHz interference even that might not be universal.

In my opinion 2.4GHz is rapidly becoming a non-starter. Companies like Eero, TP-Link, and Spectrum are using 40Mhz wide swaths of 2.4GHz for their Mesh backhauls. Sitting in my home office in a single family detached home, I can see 24 different SSIDs all running 40mhz on the 2.4GHz band with 7 having a signal strength greater than -80dBm.

5Ghz doesn't propagate very far and putting IoT devices inside your home on 5Ghz makes a lot of sense. With 6Ghz coming on line and being reserved for high bandwidth applications, 5Ghz for IoT makes even more sense.

It's not the peak speeds, it's the spectrum use. The 2.4GHz ISM band has 100 MHz of available spectrum, the 5GHz wifi spectrum is 740 MHz wide, and is still occupied by fewer deployed devices.

To an IOT application, it's the difference between chatting with a friend at a quiet outdoor cafe and trying to shout at her in a crowded bar.

YMMV but in my house, with a commercial-grade wifi AP, I found that devices on 5 GHz get much better speed and range due to all the local noise on 2.4 GHz.

Pop open a WiFi scanner sometime. Unless you're living way out in the country, the 2.4GHz spectrum will be pretty much full. Everyone has a 2.4GHz router and you're likely to get a lot of interference.

Really it's the same reason computers moved to 5GHz, and now 6GHz.

Yes and no, depending on the environment. In an apartment building, the wall penetration is a liability, as the 2.4ghz spectrum, with only three channels, gets extremely congested. Going 5ghz helps immensely, with more channels available and less penetration, so you get more spectrum reuse.

I am afraid this is a very narrow reading of the CRA. Did you read the act yourself or some qualified opinion by a European lawyer? Security updates are the default demand of CRA and not having them is an exception that requires an assessment of risk (which I would assume mean that it's only viable for devices not directly connected to Internet).

An (equally narrow ;)) quote:

"ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them;"

Thus, I expect RED to stipulate only radio firmware to be locked down to prevent you from unlocking any frequencies but the CRA to require all other software to be updatable to patch vulns.

> there are places where non-free makes sense too

Seriously now, where is that? The only scenarios I can think of are devices that could put others at risk. Large vehicles. But even, many countries allow modified vehicles on the road.

But everything else should be game. If it's my device and only me at risk, why should anyone else get a say.

From what I've seen very little. I _think_ it's something to do with the kind of people who work on embedded systems generally wanting the freedom that comes with making things from scratch resulting in not that much interest in repurposing old things outside of making them work with their overall IoT network.

I recently reverse engineered an e-waste STEM toy from scratch ( https://github.com/padraigfl/awesome-arcade-coder ) and the general response I got from places were:

a. to salvage the microcontroller and other relevant parts (probably worth $4 off a board that would cost $100+ to replicate)

b. a weirdly hostile attitude about the ethics of reverse engineering regardless of the motives (guessing people have been burned a lot with people stealing their designs)

I've mostly worked on the frontend and don't have much knowledge of embedded systems at all but it wasn't anywhere near as hard as I expected. Keen to find some other ESP32 devices to tweak (suggestions welcome!). I guess even if making them unflashable becomes the norm it won't be too hard to just swap the ESP32 off the board with a new one.

Quite a bit in IoT market, especially in the low-mid tier and Chinese imports. There’s an entire ecosystem of custom OS’s for home automation that runs on these ESPs, ESPHome for example. I have flashed quite a few smart sockets to run Matt/kafka messaging client rather than unknown vendors software that has an open socket to offshore ips.

The ESP32 (and other ESP chips) are somewhat common in smart home/IoT gear, particularly for devices that are dependent on a cloud service to function. There's a growing trend in the smart home community of re-flashing cloud-dependent ESP32 based hardware with ESPHome, which makes the device fully local controlled, eliminating the risk of the cloud service being discontinued/enshitified.

It's not a particularly common thing yet, but smart home enthusiasts are becoming increasingly concerned about the expense and effort required to replace cloud-dependent hardware because the manufacturer decided the cloud service isn't worth maintaining anymore.

If the key is stolen, you can still protect your hardware.

This is explicitly for IoT manufacturers that want to lock out people easily modifying a device (or bringing it back to life after it receives an "update of death") or the kinds of industrial customers that need to check a box for a cybersecurity audit.

These IoT manufacturers keep making all of these new products but the thing is, an ESP32 from several years ago is not that much different than one from today. They don't need much compute, anything difficult can take place on the cloud. So how do you sell someone new hardware if the first gen device is still perfectly capable? How do you sell a premium version if it's just the same parts inside? For the former, you can EoL a product by blocking it from cloud services (like Nest this week). If the firmware is locked, a hobbyist can't just flash modified gen 2 firmware and have the device functioning like normal. For the latter, you can lock the bootloader firmware so that it will only load the firmware that you want it to run (i.e. the basic or premium version).

Let's say the chip was lockable, what would prevent someone from using a bit of hot air and flux from just swapping out your chip with whatever?

Sounds like you're trying to deprive CS students of their practical education :P

Yes, but this I think is a bit sad. Once you have proper hard to crack security a smart kid from CS won't find it hidden decide to hack it and write blog post about it how he has done it. As long as it is not something dangerous sometimes having less security is better

It counters evil maid attacks.

Means the Russians can't repurpose the washing machines to build drones.

How much capacitance? I built my own sensors based on ESP8266 and they've been flaky, and I wonder whether that's the issue.

According to that pdf the ESP32-C5 does have Zigbee.

Are we sure this is correct? The table shows ESP32-C5 supports CANFD but I cant find any info on CAN-FD peripheral, drivers, etc.

Does the Zigbee work well/as expected? Does it have lower power draw when doing Zigbee vs. wifi?

I bought a few of those, but at $8 they're a bit pricier than the $3 Espressif spoiled me with.

Espressif made a decisive shift to RISC-V[0], effectively abandoning Tensilica.

ESP32-S3 was, AIUI, their last non RISC-V chip.

It was announced in 2020 and released in 2022.

0. https://www.hackster.io/news/espressif-s-teo-swee-ann-confir...

Xtensa is a dead end, they said so on ESP32.com when someone pointed out the FPU ABI bottleneck

From the link

>Espressif Systems (SSE: 688018.SH) announced ESP32-C5, the industry’s first RISC-V SoC that supports 2.4 GHz and 5 GHz dual-band Wi-Fi 6, along with Bluetooth 5 (LE) and IEEE 802.15.4 (Zigbee, Thread) connectivity. Today, we are glad to announce that ESP32-C5 is now in mass production.

It's a big plus if you want to write code for it in something like Rust. LLVM support for the architecture they used on their older chips (xtensa) for a very long time required compiling a fork of LLVM and rustc in order to target the chips. It may still, I didn't keep up with the effort to upstream that target. RISC-V is an open architecture that has a lot of people excited so compiler support for it is very good. Though as far as why Espressif is using it, it feels likely they would use it because it means they don't have to pay anyone any royalties for the ISA.

It's a mix.

Better compiler support for RISC-V, but everything I've seen from them is a much shorter pipeline than the older Xtensa cores, so flash cache misses hit it harder.

Both RISC-V and Xtensa suffer from the lack of an ALU carry bit for the purposes of improving pipelining. But for these small cores it means 64-bit integer math usually takes a few more cycles than a Cortex-M Arm chip

Unless you're a shareholder of arm, hard to see how it's a bad thing.

Thanks for the link, but yeah as the other poster mentioned, this is for a dev board. I'd be interested in buying the module (which is somewhere between the bare IC and the dev board). Here is an example from their store of an ESP32-S3 module: https://www.aliexpress.com/item/1005006334720108.html?pdp_np...

That's a dev board.

The only listing they currently have is for the dev board, and it's not stocked yet.

The USB HID protocol is designed to support basically any device that regularly reports a set of values; those values can represent which keys are pressed, how a mouse has moved, how a joystick is positioned, etc. Now, different devices have different things that they support: joysticks have varying numbers of axes, mice have different sets of buttons, some keyboards have dials on them, etc. So, there's no single format for a report that simultaneously efficiently uses bandwidth and supports all the things a human interface device might do. To solve this, the HID protocol specifies that the host can request a "report descriptor" that specifies the format and meaning of the status reports. This is great for complex devices running a full OS; there's plenty of memory and processing power to handle those varying formats. However, these HID devices needed to also work in very limited environments: a real mode BIOS, microcontroller, etc. So, for certain classes of device such as keyboards and mice, there is a standard but limited report format called the "boot protocol". IIRC, the keyboard version has space to list 6 keys that are pressed simultaneously (plus modifiers), all of which must be from the same table of keys in the spec, and the mouse has an dX and dY field plus a bitfield for up to 8 buttons (four of which are the various ways you can scroll). To implement a more complex device, you'd want to be able to specify your own report format, which the ESP driver doesn't seem to allow you to do.

I'll give you my anecdote. I'm building a device that reads the input of a USB game controller. In my case, it's a Sim Steering Wheel. I ended up needing to incorporate a MAX3421e USB Host chip to read the HID input, because the ESP firmware doesn't have this implemented. Hardware wise, all ESP32 chips with hardware USB could do this, but they haven't prioritized it in software. Some keyboards and Mice use a protocol called "boot protocol", and you can get those to work. It's not very common in game controllers though.

Professionally I use the esp8266 a bunch because it's still cheapest - but the lack of 5Ghz is really starting to bite as customers complain it 'doesnt work'

Right. Sorry I meant development boards. This is low volume, probably will only make a few a year. The nice thing about the esp32 is I can get the board with lora/display built in, with a battery, for $25 each. The stm32 board and module is only a tiny bit less, for example. If I wanted to I could do this with a cheap 8bit microcontroller, I would just have to design a custom board with an oscillator to modulate the IR LEDs etc. I was gonna do that with PWM from the microcontroller to "simplify" things.

Edit: oh the MSP430 is neat! If I cared about battery life (driving 200ma of LEDs anyway...) I'd totally use that.

The XIAO RP2040 looks perfect for what I'm doing, actually, and draws less power.

If I needed to build a bunch I'd definitely go that route - that's a great deal!

Yep! Unfortunately the lipo setup is useless, not only would I not trust the lipo in the heat it will be in, I need to drive some other stuff and it will have a much bigger battery pack anyway. Other than that the heltech boards look great, but I'm gonna try something 1/2 the cost and should work fine, and be smaller.