ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266 | Hacker News Reader

ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266

cnx-software.com

232 pointszdw117 comments

Just recently, Bouffalo Lab introduced BL602 which is a RISC-V WiFi-BLE chip with ESP8266 price. I guess Espressif had other plans for the competition!

[1] https://news.ycombinator.com/item?id=24877335

[2] https://news.ycombinator.com/item?id=24916086

Skimming over C3 datasheet, it seems it doesn't have DAC but has one I2S. BL602 has DAC but no I2S!

I2S is also handy for bit-banging protocols without using CPU time—it's popular to use it on the ESP* chips to drive WS2812B and similar strips without hassle.

Curious question, is it just I2S that is used for this purpose? I'd assume you could use any serial protocol for bit banging purposes right?

I use the RMT (Remote Control) devices of the ESP32 from FreeRTOS for this. They were intended for generating on-off-keying of carrier modulated wave forms to blink an IR LED for a remote control.

If you leave off the carrier modulation you end up just specifying a list of on and off times and get absolutely rock solid waveforms in hardware.

There's a bunch of them, I forget, maybe 8? So you can drive a bunch of chains at once.

You can also use these for rock solid reading of input signals too. Say you have a weather station that sends some god awful protocol up a wire at you… you just collect a list of the high and low times and get notified when it stops wiggling the signal. Then you sort out the data from the transmission. The timing might be way off because it's cold and the sender's electronics are really cheap, but you can analyze the signal and see what they meant.

That’s handy sounding. There’s some use cases I was thinking about needing to read in high speed IO lines, above 1Mhz. SPI has odd timing requirements. Can you point to example code for this technique, or is it just a matter of using(abusing) the i2s library? And the horrible wire protocol is all too common.

I hadn't looked at the RMT peripheral before... Based on what you describe and from a quick skim of the documentation this also seems perfect for a simple logic analyzer!

I used SPI to generate analog video signal (with extra hardware, of course).

Espressif is no longer alone in the ultra low cost hobby WiFi SoC space. Pine has started working with the Bouffalo BL602 which seems to be a fairly similar RISC-V powered part: https://www.cnx-software.com/2020/10/28/the-quest-for-a-blob...

It will be interesting to see which one gains critical mass in community use.

It’s all about the software & documentation.

There’s lots of “competitors” to esp32, pretty much none of them except STM have the software for developers, which makes their offerings close to useless.

The only way to gain critical mass is relentless deep commitment to developer tools/libraries and documentation.

In many cases these competitors actually try to hide their documentation and keep secret how their chips work.

I’d be interested to hear if there’s other chip vendors with software/documentation as impressive as Espressif but I haven’t heard any, except as I said STM.

It just means it isn't made for hobbyists... Hardware companies don't care about the lack of good software - they just pay some embedded code monkey a lowish salary to 'just make it work'.

"embedded code monkey"

Is this really the case? :(

It's a pretty uncharitable description, but yeah. There are only two types of companies that do this though: companies where they're working at such a scale that spending a few extra months to years of developer time doesn't make a dent compared to the BOM savings. You're more likely to get vendor support by name recognition at these kinds of companies, so it's not as bad as the hobbyist experience. The second kind is where either the project or the company can't afford the capital outlay for better documented chips (or support packages). Stay the heck away from these if you value your sanity or know your own worth.

Is it even possible to make as much as the hype fields (webdev, data science, ML) in embedded? Is there opportunities for startups in HW sector?

Sadly no - apart from a very tiny number of silicon valley companies, everyone else in embedded tech seems to pay the people who write verilog and assembly the same as the people who make the schematics and the mechanical designs. That's sometimes only 40% of what people who write python and nodejs get in the same city...

I think that's partly due to market forces and the value produced per developer. A few Webdev's can write software that enables an entire web company in a few months. Due to the poor state of embedded development ecosystem the same is not true in hardware, compounded by the time/effort required to workaround bugs in the hardware plus working in error prone C. Then embedded developers/companies don't share workarounds via open source, so every team must spend time working around already solved issues. Personally, I'm using the ESP32 largely because of the open-source SDK, that didn't require an NDA or some crappy IDE, then I ported Nim to it. But normally it might take 2-3x more embedded devs to create products with comparable profits to similar devs in pure software

If you're doing automation of some kind in the bay, embedded has roughly comparable payscales to other dev jobs. Beyond that, no. You'll generally be paid slightly less than webdevs (but still far more than most engineers make).

In my humble experience, slightly less ≈ 30% to 40% less.

Wow, that's a much bigger differential than my experience. Are you comfortable sharing the general region so I can avoid it?

I have been involved in embedded systems for more than 25 years now, and I barely do "pure" embedded development these days. That is projects that comprise only designing a specific PCB hardware, or writing the firmware drivers and top level application for them.

Except for a couple of years I have resided mostly outside of California, but when doing consulting I have mostly engaged with companies in the Bay area.

In the past when I did pure embedded development I had to fight tooth and claw to get rates close to $100/hour, while at the same time iOS app developers or webdevs were starting at $120-$140/hour easily, even after the mobile app craze. Despite taking into consideration that I am both a hardware and a software engineer, and rates outside of California were much lower ($45-$70/hour at the time). Which was one of the reasons I pushed hard to find my clients in the Bay area instead.

These days since I have more experience and business contacts I have diversified into more complex projects that have embedded components and pay me better since they belong to regulated industries. Even now I work with full-stack software programmers in AWS/GCP cloud apps, React/Vue frameworks, modern databases and connected middleware that make around $200/hour. For comparison, in the last years I have been involved in the development of a medical device where I did the hardware design (MCU/FPGA, signal acquisition), HDL/firmware programming (Verilog, RTOS, Linux, BLE), technical host tools (C++, Python, Qt) and was paid $180/hour, and lately a mobile robot project where I did the hardware architecture, integration and system control loops (MCUs), and prototyped the high level software application (RT-Linux, ROS, Nvidia Jetson) for $150/hour. An acquaintance in the valley that was working for a similar project but entirely in the ML/CV stack was billing $270/hour. That may be a bit extreme example since ML is hot today, but nevertheless.

Is this the same in Europe or outside of Bay area? It really isn't fair since you are doing the actual full-stack (from F_freaking_PGA to C++/Vue on host) but the ML type is invoking an amalgamation of libraries to do something with 90% confidence level.

> Is there opportunities for startups in HW sector?

Yes, but certainly not in the Western hemisphere.

Starting out no, but there is plenty of demand for experienced people. If you don't have experience then build up a portfolio.

Your best bet is anti-trust:

Basically, if there more customers but smaller orders, the wasteful overhead of customers reverse engineering the produce will grow. But then there's more incentive for HW companies to overtake the competition by offering better docs.

Bouffalo apparently has been giving Pine64 the necessary documentation access to make their initiative for a full open software stack workable: https://www.pine64.org/2020/10/28/nutcracker-challenge-blob-...

Edit: a better reference is Bouffalo’s GitHub org showing the docs and mostly open code: https://github.com/bouffalolab

Not full. I managed to squeeze, like blood from stone, from Bouffalo a statement about absolutely no way they are open sourcing their radio interface.

>stm

gd32v is a stm32 (peripherals, memory map) clone, except using risc-v rather than arm.

That is going to put a dent in ARMs revenue. Even if that particular chip isn't a big seller, it means ST now has a drop-in replacement for ARM in their other SoCs. Soon people will realize that ISA is often irrelevant, but the peripherals, libraries, and tools are.

I'm not so sure. About ISA there is this : https://news.ycombinator.com/item?id=24958423

Any ISA can be dissected, but ultimately RISC-V's got the mindshare and the license.

There's no solution, only tradeoffs.

That's one opinion. Another ARM engineer who contributed one heck of a lot more to ARM's success (designed ARM7TDMI, Thumb, Thumb2) says RISC-V is great. See at 51 minutes in this https://www.youtube.com/watch?v=_6sh097Dk5k

That's not ST, it's by the Chinese company GigaDevice that makes (decent) clones of the STM32 series. Your point still stands though.

RISC-V so far is a turndown for a design, speaking honestly.

ARM have by faaaaar the best tooling in the industry, which are more open, than not, and the baseline is made on GNU toolchain, only with more fancy debug tools being paid/locked down.

RISC-V did not yet benefit from its openness for as long as tooling go.

However, RISC-V would still be infinitely better than Cadence, and them wanting $100k for a basic (and terrible) debugger with coresight-like functionality.

> gain critical mass is relentless deep commitment to developer tools/libraries and documentation

Which seems (IMHO) why the likes of Texas Instruments has failed. They've made a few attempts at jumping on the IoT bandwagon over the last decade and should have been in a perfect position to capitalize on the huge uptake but it just didn't fit their profit margin goals I'm guessing.

Nah, problem with TI was their ridiculous $20-30 price point for a microcontroller with build in Wifi.

This. If it doesn’t work with the Arduino IDE/platformio, I would rather not use it. What these manufacturers should do is invest in integrating with these SDKs instead of creating their own. And they should document everything to the level that IPFS is documented (just an example of excellent documentation that comes to mind). Do those two things and you got a winner even if the device itself isn’t technically the superior choice.

Because, to be frank, Arduino is a bit of a toy platform.

It is really good for beginners and for hobbyists to make embedded devices available to a wider audience, but nobody in their right mind would build an actual product on top of Arduino.

Well prusa did with their printers

They would be one of an exceedingly small minority, then.

Almost every consumer 3D printer out there runs on top of Arduino. Sure that’s a small market compared to all electronics. But it’s still a big market in absolute terms.

This was true three years ago. Plenty of 3D printers are now using ARM. The Monoprice MP Mini Delta has been out about two years now with a price of $175 US. Marlin 2.0 has support for ARM, I think it would be accurate to say "Almost every consumer 3D printer out there runs on top of Marlin", although there are a few alternatives like Smoothie.

People trying to build "real" products on top of Arduino usually do so in spite of, not thanks to, the platform.

Once you start trying to build a polished experience, not a quick hack, you quickly run into limitations that are solvable by dropping to lower levels. I ran into this when I tried to make an ESP8266 temperature sensor - the Arduino stuff didn't have working power management, so it would heat up skewing the measurements, nor anything like threading or coroutines for network handlers, so a single stuck network request would block all others. Ironically, the Arduino port included a coroutines implementation under the hood, but used it in a silly way with a single coroutine. I rebuilt the thing on top of the ESP SDK, stole the thread switching code from Arduino, and used it to build a nice low power version that could handle up to 4 requests at once.

I don't think I've ever seen a well engineered product built on Arduino that wasn't trivial. They might've hacked on it until the user experience is good, but then you peek under the hood and it's clear the engineering isn't good. And that ends up creeping into the user experience in the end, or worse. (OnlyKey comes to mind, which is built on Arduino and also its authors clearly do not have the competence to be writing security/crypto code, but they seem unwilling to accept any criticism).

I know of a good production line that has seen improvements in efficiency and safety due to automation with Arduino. I’m sure there are better ways but in terms of bang for buck, it’s hard to see how a non-programmer could have done better.

That doesn't sound like using Arduino in a product, though?

No, they are on big bits of equipment.

What is the best open source alternative? Ideally one that works similar to PlatformIO where you aren’t tied to a specific IDE.

On things I've personally worked on, I tend to just use the basic libraries supplied by the vendor, or even just implement everything myself from reading data sheets. This is obviously realistic mainly for very small and simple systems, which is what I've usually worked with.

Agreed having recently bought an esp32 s2 board it does not yet have platform io support so I put the board aside and figure I’ll come back to it in 6 months and see if that is updated.

To my understanding, PlatformIO is (merely) a set of scripts to handle multiple toolchains and HALs in a consistent way. In esp32-s2 case, it means integrating ESP-IDF only. What stops you from directly invoking cmake using the ESP-IDF?

Just time. I only just started learning how to use Arduino this past summer and discovered I could platformio with a Makefile this fall - it’s been pretty cool so far. I will probably spend sometime later learning Esp-idf next

Meanwhile, the US government is worried about our dependence on Chinese tech, and security implications. What if these convenient and cheap little WiFi modules become ubiquitous and start DOS'ing the entire spectrum?

This is really nice, riscv plus Wifi and BT will be a dream for hackers provided the chip and firmware is well documented. The datasheet is also in the comments (https://mega.nz/file/nk41mSAL#R_d0njlKRb-aIoGuX6JXUB5eeflAdy... )(chinese pdf) : 160MHz 400k sram apparently single core.

Some reason this didn't work, someone made an English translation https://mega.nz/file/4VRGgLzK#YIzeMvj_Z-LayxY8KztL4WiifcmQYc...

The comment parent to yours had a closing parentheses and stuff after the link that broke it.

The link for the Chinese pdf is https://mega.nz/file/nk41mSAL#R_d0njlKRb-aIoGuX6JXUB5eeflAdy...

Good catch, corrected.

What will networking be like from SW POV?

This only lists features - 23 pages is hardly a data sheet.

The PDF is encrypted.

Nice. The XTensa cores always felt weird.

Too bad they only included the I/M/C extensions - no floats, vectors, or atomics. And USB would be nice (nevermind, it has USB :D).

But it's still very exciting. Maybe there'll be less conflict between ARM/XTensa/PIC32/etc. cores in the coming years.

I believe the problem was XTensas not being available in hard macros, or at least Chen will not sell them at a price point a mortal can afford.

That's a huge thing when power efficiency, and operation from battery mattered.

Why do you need atomics on a single core device?

There are ESP32 variants with a dual-core Xtensa processor (https://en.wikipedia.org/wiki/ESP32).

Interrupts and exceptions can happen at any point in a program's execution on a microcontroller, and they are free to modify memory and peripheral registers.

>Load <register>

>Modify register in memory

>>Interrupt happens and changes <register>

>Write incorrect value back to <register>.

These sorts of bugs can be pernicious to debug, and they are easy for novice developers to create.

That's horrifying. What is the fix/mitigation if you don't have proper atomics? I can't see how to properly avoid that.

Obviously interrupt code can't clobber registers like that, any shared register the ISR needs to share with ordinary code must be saved/restored on entry/exit somehow.

I think GP is talking about MMIO or some device register rather than the CPU’s register file.

You implement higher-level abstractions like mutexes. On a single core device this could be as simple as masking interrupts. You can use the mutexes to avoid the described race.

Only communicate in one direction. I write, you read. I can also provide a large coherent set of data so long as you dont read it until I mark it as ready. There are many other ways too.

You just guard those sequences by disabling and reenabling interrupts around them. It's a very common pattern in systems not designed for SMP.

You can disable interrupts when modifying locking primitives, and save/restore the CPU context when interrupts are entered/exited. You can also minimize the amount of changes that any interrupt handler can make within the interrupt context.

It's not really that bad, and plenty of microcontrollers lack atomic operations.

If you disable the interrupts, does that mean any incoming events get ignored, or simply queued for later? If the former, that sounds like you risk missing something important.

Queued for later.

Obviously with a certain max depth, most probably of 1, meaning you're still missing repeated interrupts.

The critical section is typically very small, usually just modifying a single variable. Interrupts can't happen faster than the CPU frequency anyway, so you won't miss much.

Sure, although I think "missing" has negative connotations that don't actually apply to this. When unmasked, your interrupt handler usually just runs until there is no more work to do, which is (again, usually) discoverable. Your device driver is still awoken promptly if the interrupt arrived during a critical section.

You disable interrupts for the three instructions it takes to emulate the atomic instruction. Which is barely slower than the atomic instruction would be anyway, because both have to read and write RAM, which is the slow part whether it's one micro-sequenced instruction or several standard ones.

Because you are likely still running a preemptive multitasking operating system.

> And USB would be nice.

The block diagram show "USB Device" in the peripherals block.

Oh yeah, cool - I missed that.

Finally! An Espressif chip with WiFi, Bluetooth, and USB!

Note that the USB device is not a full-function software-controllable device; it provides a built-in 'serial port' and JTAG debugger only.

Having a RISC-V based ESP also means it should be easy to add support in Renode [1].

[1]https://renode.io/

Rust is much easier to use on RISC-V [1] than on ESP32 [2]. I'm looking forward to making some small projects with this chip, assuming the software is usable.

[1] https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

[2] https://github.com/MabezDev/xtensa-rust-quickstart

Eicks! 10GB of disk space and 6GB+ RAM for the compiler? That’s seems crazy. No compiling that on most RPi’s. Maybe the cranelift project will help over time.

That's for compiling the compiler.

Specifically a compiler fork that needs to be locally compiled, AFAICT. It's doable on most developer's machines nowadays, but not all. Many laptops still only have 4GB of RAM.

It lists `USB Device` as well. This could be a really accessible device for building hybrid usb/bt devices, like wireless keyboards.

2$ wifi bad usb anyone?

It seems it only supports CDC and some JTAG mode. For keyboards and such, the USB stack should support HID which doesn't seem to be the case here. In other words, they've implemented a USB 1.1 FS stack just so far to make intermediary USB2UART chips like FTDI and CP2102 redundant.

I doubt they implemented CDC in hardware. If they have a low-level USB peripheral, all the high-level protocols you want can be implemented in software.

This is pretty awesome, ESP32s were great little Arduino nodes with wifi. Having an open architecture should open up more software. They previously had their own cpu arch

> Pricing will also be similar to ESP8266.

How can they possibly sell these chips at these prices? This is impossibly cheap. You can’t even accuse them of trying to flood and control the market because they already own the market!

what market are you talking about? hobby projects market? that's for sure, but that's not where the big money is.

consumer goods with builtin wifi like switchable lightbulbs, remote-controlled extension cords, etc are often esp32 plus a relais on the IO pins.

The "smart" home market. ESP chips are heavily used there.

You are seeing economies of scale (and cheap labour) in action.

And people have the gall to badmouth capitalism from the comfort of their Ikea couch on their Iphone.

After an 8-hour work day or on a weekend. Thanks capitalism!

I'm not sure people realize how cheap small chips are that aren't on the bleeding edge of the process.

I think you might of gotten that impression after years of being raped by TI/STM levels of margin. TI even tried to sell their microcontroller with wifi at ~$20-30 price point.

Sounds like the Bouffalo BL602 and BL604 that were recently revealed. Competition in this sector is very interesting, I hope the Espressif chip will be as open or even more open than the Bouffalo chip.

I believe Bouffalo has floating point.

Both are SiFive cores, so well documented and supported.

I’d love to see a similar hobby-oriented chip that supported Thread as well. It’s a low power IPv6 networking stack that’s designed for connected home automation.

I wonder how power consumption is? Power power use (especially when sleeping) is probably my main complaint with the ESP boards I've used

Hope it went for the better if the core is a hard macro. As far as I heard, they didn't change the process.

There are plenty of esp32 boards with 10-20uA deep sleep current, how low do you want it?

Mind pointing me in the right direction? The ones I have are more like 10-20mA (maybe that's a side-effect of having USB on board? I'm not really an expert, I just want my battery powered stuff to last months instead of days)

https://www.ezsbc.com/product/esp32-feather/

https://www.crowdsupply.com/unexpected-maker/tinypico

https://www.olimex.com/Products/IoT/ESP32-S2/ESP32-S2-DevKit...

Thanks, these are some neat boards! A bit higher cost than the Aliexpress ESP32s I'm used to, but maybe that's the price you have to pay for better design and components. It's neat that the TinyPICO lets you turn off the power LED without having to cut traces on the PCB.

https://www.tindie.com/products/kdcircuits/trigboard-ultra-l...

That one has extra circuitry to shut the esp down completely and wake it on either an external trigger or RTC based alarm. It claims 1.5uA sleep current.

The creator has a YouTube channel with lots of info about low power and other interesting tidbits https://www.youtube.com/user/kdarrah1234

LILYGO® TTGO T-Energy (http://www.lilygo.cn/prod_view.aspx?TypeId=50033&Id=1170&FId...) is my favorit. It has a 18650 battery holder and charging circuit.

With a BME 680, 2 seconds of measuring every 5 minute and esp-now protocol for sending, I estimate a 200+ day battery life. Esp-now protocol sends the message in a fracture of the time than wifi. Also you can tune the cpu & flash frequency depending on our workload. I have to wait 2s for the measurements to complete, so I lower the frequency to use less energy.

Just curious, have you been running it long enough to extrapolate that? I have some TTGO boards and they're a mixed bag. On one of the eink ones (which you'd think is the perfect scenario for deep sleep), they used a lipo chip that shuts everything off if the power draw is too low, so if you try to deep sleep the device never wakes back up

No, I did not, but I made tests with a configuration that was using more power. I measured total runtime per wakup, and number of wakeups until the battery was depleted. I used this data to estimate the runtime if I take a measurment only every 5 minutes. This does not fully take in account the deepsleep current & battery self discharge. But wake up from deepsleep is definitly working.

From 3.7V to 2.7V I coud activate 37'000 times with a total runtime of about 8h.

Schematic is found here: https://github.com/LilyGO/LILYGO-T-Energy/blob/master/t18_v3...

You also have the battery voltage on IO35 with a 2x100kOhm Voltage divider.

The setup is not perfect, but good enough so far, and practical.

If I start over, i would look into * taking a processor with lower speed und power. * taking CR 123 or a battery optimized for very low self discharge current. * Use a wireless protocol with very low overhead. I use ESP-Now now, WLAN would cut battery life in half.

I manage to get around 80uA in deep sleep, when it’s on it’s around 100mA because of WiFi and peripherals. You can use an Otii to track consumption too but that hardware is expensive, there are cheaper ones like uCurrent etc.

Issue is BLE, power consumption on BLE is still not BLE level power (eg. Nordic chips). It’s still at mA levels.

Dupe: https://news.ycombinator.com/item?id=25168302

I was wondering with these RISC-V processors is a minimum set of features required for Go code to work with them? Is there an easy way to determine if a RISC-V processor will run Go code?

Someone would likely have to port this: https://tinygo.org/

Seems to work on Silicon Hi-Five.

Any MOOCs on RISC-V?

Reply on news.ycombinator.com