Six years on from the emergence of the Espressif ESP8266 we might believe that the focus had shifted to the newer dual-core ESP32. But here comes a twist in the form of the newly-revealed ESP32-C3. It’s a WiFi SoC that despite its ESP32 name contains a RISC-V core in place of the Tensilica core in the ESP32s we know, and uses the ESP8266 pin-out rather than that of its newer sibling. There’s relatively little information about it at the time of writing, but CNX Software have gathered together what there is including a draft datasheet whose English translation is available as a Mega download. As with other ESP32 family members, this one delivers b/g/n WiFi and Bluetooth Low-Energy (BLE) 5, where it differs is the RISC-V 32 Single-core processor with a clock speed of up to 160 MHz. There is 400 kB of SRAM and 384 kB ROM storage space built in.
While there is no official announcement yet, Espressif has been dropping hints. There’s been an OpenOCD configuration file for it in the Espressif repositories since the end of last month. And on Friday, Espressif Software Engineering Manager [Sprite_tm] answered a reddit comment, confirming the RISC-V core.
Why they are releasing the part as an ESP32 rather than giving it a series number of its own remains a mystery, but it’s not hard to see why it makes commercial sense to create it in an ESP8266-compatible footprint. The arrival of competing parts in the cheap wireless SoC space such as the Bouffalo Labs BL602 we mentioned recently is likely to be eating into sales of the six-year-old chip, so an upgrade path to a more capable part with minimal new hardware design requirements could be a powerful incentive for large customers to stay with Espressif.
We’re left to guess on how exactly the rollout will proceed. We expect to see similar developer support to that they now provide for their other chips, and then ESP32-C3 powered versions of existing ESP8266 boards in short order. It’s also to be hoped that a standard RISC-V toolchain could be used instead of the device-specific ones for current Espressif offerings. What we should not expect are open-source replacements for the blobs that drive the on-board peripherals, as the new chip will share the same closed-source IP as its predecessors for them. Perhaps if the PINE64 initiative to reverse engineer blobs for the BL602 bears fruit, we might see a similar effort for this chip.
More mutations, just like viruii, might be worth pursuing as the core is not proprietary and could well become more common in lots of devices. Maybe with more development tools…
Thanks for post
I want to know one thing: Am I still going to have to put up with an inscrutable blob constantly running in the background that sits between me and the wifi radio and has full access to the internet?
I’m very disappointed that nobody in the last 6 years has developed a replacement for this radio library, even as we’ve seen people tackle the Raspberry Pi’s VPU firmware.
Can this blob spy on traffic? There is a wifi repeater in Arduino ide. Can the esp monitor your passwords/websites/etc, and send the data to a 3rd party (possibly even if only .1% of the time to hide its mischief)?
Not likely, most traffic is encrypted these days. It could analyze your DNS requests to figure out what domains you are resolving. But once encrypted DNS becomes more common, this too will be less likely.
Very likely, as the blob is the one doing the encryption en decryption. There are calls into the library to open an ecrypted connection to a remote side, so the library gets unencrypted data, encrypts it to protect against in-transit-listeners and then sends it off.
Glad I asked! But will your pc, or phone encrypt before it sends any data to the wifi connection?
Although… not all RISC-V cores are open. Many are, many aren’t. The completely open thing about RISC-V is it’s Instruction Set Architecture, which anyone can implement without paying an architecture license. And there are some fairly decent open source core generators (BOOM, Rocket, etc.) But there’s more to a core than its verilog representation or the ISA and Si-Five’s business model is selling proprietary cores based on proprietary Rocket enhancements.
There are PLENTY of high-quality open source cores / generators available (Vex, Pico, Swerve, Rocket, etc.) But some commercial organizations appreciate Si-Five because they can: a) integrate proprietary IP on a SoC without violating the core’s license and b) have a team of people verifying the core’s correctness. (And they have a number of other professional services if you’re not hip to Route and Place or the black magic that seems to be interfacing with DRAM.)
Which is to say… it’s possible the CPU core might not be open.
Which is a very verbose way to say… a low-end single-core power-efficient FPGA in an ESP32 form factor w/ various peripherals with enough gates to implement at least one RV32 core would be pretty awesome. People could (if they really wanted to) experiment with modifying open cores like Pico or Vex to add new instructions or add new peripherals.
[Full Disclosure: I used to work for Si-Five, but certainly don’t speak on their behalf. I just got to see their verification and validation process up close and think they’re doing some interesting things.]
If I may ask why’d you leave?
Ooh, I’m definitely intrigued! Even with the proprietary blob, Espressif has otherwise wholly embraced the DIY-community and nowadays their ESP32 SDK is great. I totally expect something similar for this one as well.
Looking at the specsheet, it’s immediately got the leg up on ESP8266 in multiple areas: proper hardware I2C and PWM, both of which are software-based on the 8266, 2x 12bit ADC against ESP8266’s single 10bit, hardware AES and TRNG — that’s already quite a lot good stuff. Presumably lower power-consumption and more capable power-management features as well!
More than just 2x ADCs, it looks like there are 2x ADCs with 4 channels each. So 8 ADC channels (if i’m reading the datasheet right)
That’s what the ESP32 has, so that would be reasonable.
Really hoping they fork the series name, rather than having such a small naming change signify a whole different architecture. What if they keep doing C4, C5, C6, C7 etc with random switches between Tensilica and RISC-V cores?
I agree, love the chips, hate the naming convention. esp32-s2 should have been esp8288-s2, esp32-c3 should be something like esp34v or something..
8266-s2.. I should read it before posting..
How about the ESP55 or ESPVI?
Errrr I mean the ESP-V (I wish there were comment editing)
Espressif guy here: Because the core change in general is something our customers won’t really notice. You write your code in C (or Arduino, or MicroPython, or Lua, or…) and you compile it against ESP-IDF, just like all other processors. For our end users of the chip and sdk, things like amount of pins and peripherals is way more of a deciding factor.
Ah someone from the club, cool good to hear from you Sprite_tm, pray can you clarify:-
1. What’s the easiest path for assembler ie some IDE & loader suitable for the 8266 ?
2.Would that same IDE/method apply to ESP-32 ?
3. For either 1 or 2 is system source rom available as a published document or otherwise, perhaps under a NDA ?
4. I guess for this new ESP32-C3 with the core non proprietary the firmware published ?
Haven’t had the opportunity as yet to go through all the various paths, lot on my plate but keen to get back to the first 2 and this new configuration, thanks
You will be able to download ESP-IDF, as you have for the ESP32, and use it to compile code for the -S2 and -C3 that way. It pulls in gcc/binutils for the needed CPU core automatically. Not sure wrt ROM source code, but the stuff either is not that interesting (e.g. newlib routines) or we can’t easily release the sources (low-level PHY routines), so I don’t think that’s going to have a super-high priority. We’ll probably be releasing ELFs so you can at least see what functions are called into from your ESP-IDF program, but again, no promises there. On ‘non-proprietary firmware’ – what firmware do you refer to? Radio stuff will still be closed because of a plethora of reasons, and I don’t think we have any other blobs remaining in ESP-IDF anymore, but feel free to correct me if I’m wrong.
I think you’re underestimating the interest with something with a V core – I mentioned it to a few people today – who I haven’t been able to get interested in the esp32 – and they were instantly interested.
You also probably underestimate how many people (me included) build things with the esp32 (not s2) in them with the wifi and bluetooth very very turned off. I love two cores..
In fact, the only issues I’ve had with it is things that need real time deterministic timing (can’t do because of rtos etc, though can do some with the RMT), and the real crappy i2c slave support – I had to write my own from scratch as I’m doing a few things with two esp32 on board.. (the issues are mentioned many times on the esp32 forum..).
That’s a bit unfortunate.
I’d love to have access to the transmit and receive IQ registers of the DSP, the frequency setting register and the PA power control register.
But I can understand the RF side being closed due to IP licensing and regulatory reasons.
We did SDR reception on SiLabs EFR32 by reading from the DSP cores IQ registers, which thankfully ware documented.
The FM transmit and small frequency step stuff we had to reverse engineer from the “RAIL” RF HAL library provided by silabs.
But on the upside we got a 2400MHz handheld SDR radio and later one with 140-960MHz coverage in addition the 2320-2700MHz we had in the mono band 2400MHz version :)
An ESP based “geckokapula” would rock and the core in ESP’s is fast enough to run codec2 or some other digital voice codec. Unlike the 38.4MHz Cortex-M4F core in EFR32 series.
is power draw better with BLE on? Typical BLE chip draws microamps not miliamps when sleeping while advertising or having connection open.
It’s not a dedicated BLE chip, forget about very low power scenario, it’s not made for it (too much RAM, no onboard flash, too few power domains).
checked the datasheet linked above and it says “• State-of-the-art power and RF performance” and “Applications: smart watch and bracelet”, so should be made for it. e.g. Dialog DA1469x has larger SRAM , also SPI flash with no onboard flash is typical on such ‘dedicated’ BLE chips too. There should be no excuse. The BL602 referenced in article has wifi too so not sure what ‘dedicated’ means exactly.
Thanks for responding on this one, appreciate it.
One of my favorite things about Espressif stuff is that everytime there is a leak, release etc. an employee or former employee shows up the comments with something more than marketing speak to contribute.
Makes you wonder if these are indeed leaks, huh?
I suppose not noticing the core change depends on which customers you’re describing. All of your customers here would definitely notice and would appreciate a better naming scheme.
If it’s like VIA then there will not be a C4. C4 is an explosive, and VIA had to rename the VIA C4 the C5 because otherwise it was not going to pass through airport customs/security.
Lemme see if I can convince the marketing team to release the English draft; it should be more readable than the machine translation linked now.
Hi Jeroen
i read your Message and i uploaded the EN Version – no Leaked translating – it is the Origin EN version
here you are
https://twitter.com/eMbeddedHome/status/1330771756383162368
how cool is that ?
best wishes
rudi ;-)
That’s awesome, thanks Sprite!
Hi Jeroen, hi folks,
ESP32-C3 Family
Datasheet
Ultra-Low-Power SoC with RISC-V Single-Core CPU
Supporting 2.4 GHz Wi-Fi and Bluetooth LE
Including:
– ESP32-C3
– ESP32-C3FN4
– ESP32-C3FH4
Draft V 0.3 is updated
now
Prerelease V 0.4 is public online
public Info
BBS ESP32
https://esp32.com/viewtopic.php?f=5&t=18308
ESP32-C3 Datasheet
V0.4 27 Nov 2020
https://esp32.com/download/file.php?id=5461
ESP32-C3 技术规格书
V0.4 2020年11月27日
https://esp32.com/download/file.php?id=5462
best wishes
rudi ;-)
The pin compatibility part is mistranslated. The Chinese announcement says modules are pin compatible.
Both chips in 5×5 QFN 32 pin but look at the pinouts, pins different including antenna (pin 1 vs pin 2). PCB designs still need some changes.
The big question is how much RAM is left for apps once Wifi and ESP-IDF takes its share, and is it enough to do TLS plus an interesting app.
The datasheet is mum about the USB peripheral, except that the features list teases “USB 1.1 interface (USB to UART converter, USB to JTAG converter)”. Does that mean we’ll plug it into a USB port and not only get a console TTY but also JTAG debugging? That would be sooo coool! Does the esp32-s2 already have that and I’ve just been asleep?
Note that the datasheet still is a draft, so no official guarantees that anything will be in the final chip, but that’s pretty much our intent for that peripheral. The -S2 does not have it; it has a software-controllable OTG device instead which can be configured to act like either a host or a random peripheral, but doesn’t do JTAG.
I see, so rather than being a USB peripheral it’s more like an embedded usb-serial adapter with some extra features (jtag) thrown in?
Yep. Main reason is that this chip is a tad too small to ask our customers to dedicate 6 pins for flashing and debugging, but it’ll probably also help making tiny development boards.
Here’s hoping the move to RISC-V brings LLVM and Rust support to Esperiff microcontrollers!
GDB Stub. We’ve been using GDB to catch exceptions, watch variables, etc. on the 8266 already. No need for special JTAG hardware.
I welcome the new risc-v overlords. The name is odd though, what is the dual core version going to be called – c6, c3s2?
The C is not necessary an indicator of the core type, but more of the size/complexity of the entire SoC. A dual-core chip probably wouldn’t be a -Cx chip.
Now I hope your engineers go wild with their naming-schemes and release an ESP32-FTW or ESP32-FML :D
or the 4 core one I’d really really really like (particularly if I could run of them without any rtos etc) – it could be called esp32-WTF!
I hope it has a dedicated agnd so that the ADC can be useful.
This sounds like good news!
Is something still called a leak when its an official release of information? Seems click-baity to me.
Read the pdf.
Beautiful chip that ticks all the boxes as a IoT builder I’m looking for.
Is this Ethernet MAC compatible? It mentions WiFi MAC but not Ethernet.
That’s something we require for security and reliability reasons.
an*
I am so excited for this! I’ve wanted to connect an ESP to a STM32 for a while now for HMI projects, but now I can have BLE, WiFi, and USB in one chip!
I already made a clone of the Pro Micro with it! https://oshwlab.com/womeijer/nrf-pro-micro
looks like an interesting project, it does show how few support components the -c3 is going to need..
Ideally I would be able to add a SPI flash chip (left it off due to the lack of pins based on what I want to do) and I would not press the button on this project without getting someone to double check it, but I am very excited!
We have more info at: http://womeijer.com/discord
How would Bluetooth Mesh mode be implemented with this product, is much base for it included in factory firmware ?
If not sufficient in factory firmware then what needs to be added ?
Precisely what my organization needs! We are still working with ESP-12F modules (based on ESP8266), but more RAM would be beneficial.