Live data from Hacker News

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

cnx-software.com

81–90 of 119 posts

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

#81

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

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.

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

#82

Earlier quoted context omitted.

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-20 m A (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)

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.

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

#83
post #77

Earlier quoted context omitted.

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.

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

#84
post #82

Earlier quoted context omitted.

Mind pointing me in the right direction? The ones I have are more like 10-20 m A (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)

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

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

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

#85
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

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

#86
post #83
post #77

Earlier quoted context omitted.

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.

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

#87
post #75

Earlier quoted context omitted.

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

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.

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

#88

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.

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

#89
post #82

Earlier quoted context omitted.

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

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.

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

#90
post #4

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

This only lists features - 23 pages is hardly a data sheet.
Post reply on HN