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.

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

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

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.

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

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

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

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

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.

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.

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.

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.

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.

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.

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.

I wasn't really clear there. The Linux-specific stuff wasn't caused by Cmake. They are two independent things that happened as part of the same upgrade.

Considering that they are supporting Linux, there was no real reason to make it so Linux-specific that all other Unix-like systems got excluded.

Hate it, definitely hate it.

I mean, I use it, but I'm not very happy about it.

I didn't mean to sound like a hard-core BSD enthusiast, sorry. I was just very frustrated when they moved to cmake in their newer IDF, they added useless things that excluded BSDs. In its current state, it's untenable to patch it to make it work. This wasn't caused by the use of cmake. They could've moved to cmake, but done so with other OSes in mind, esp since they're already in our neighbourhood.

Finally all the mom and pop chip fabs running out of a garage get a fighting chance.

Most of my Aliexpress electronics orders are shipped to a local US Aliexpress distribution center which then mails them locally. These come in small padded envelopes which are not expensive to ship.

>The really criminal thing is it only costs $8.43 to mail that thing from China to your house in the USA... it likely would cost you more to mail that same item to yourself from yourself.

These things are tiny and very cheap to ship. I could probably pack 40 of them into a USPS flat rate box shipped anywhere in the US for $9.30.

This was a decent argument when you could get things shipped from China for $0.50, but not now or in this case.

Well they all get made in China, why should i need to pay a US middleman

These are ones actually made by Espressif and limit is one per person (presumably supply issues as they ramp up mass production), certainly there will be dozens of clones soon.

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.

Maybe 320KB is the size of the bootrom? Although I don't see why that would be worth mentioning.

That's a dev board.

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

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

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

We've still got local US distributors though, regardless of everything being made in China. Like if you decide you need something tomorrow, you can go on Amazon and get most things pretty quick (despite overpaying 1.5-2x compared to Aliexpress). And there's a whole cottage industry of 3d printing shops selling canned solutions to people who don't want to hunt Aliexpress themselves.

It's been well over a decade since I was doing embedded design professionally, so my perspective is coming more from a hobby/3d printing/"maker" place. But it feels like one of the main results of these tariffs is that the bottom is going to drop out on Chinese and Chinese-adjacent sellers preloading so much stuff into US warehouses ahead of sale, and instead just shipping orders direct from China. Using a US warehouse means the seller has to front the money for the tariffs as well and takes a risk of them being lowered depending on Krasnov's whims. Whereas shipping direct from China, even if the seller is handling the tariffs (eg Aliexpress Choice), they've already got the cash in hand from a confirmed purchase.

I was just being facetious about the general pain we're feeling from the US's new tariff-based national sales tax. And I haven't been following any reciprocal actions for what is now expensive to get into China. Are -C5's only made in Taiwan or something?

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.

It counters evil maid attacks.

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?

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

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

This was about reusing the chip. Since these things are built using finite resources, maybe we should also design them with that reality in mind?

Usually in secure systems you can't read out all of the data from the old chip.

De-soldering an MCU and soldering on a new oneis typically far from trivial. We're typically not talking about dedicated big through-hole flash chips here. We're often talking about MCUs with integrated flash memory which are surface-mounted and often with pins on the underside.

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.

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

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

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

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.

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.

Alright, I figured that would have to be the case. Do you know any resources that break down what is exempt and what is not, without having to look up the individual HTS codes?