Hacker News Reader

Comment by bArray | Hacker News Reader

The "high-end" modern MCUs are pretty great, you have the NRF offerings, but also the likes of the ESP32 where you can get Bluetooth and WiFi in a single package.

Personally these days I would lean towards the ESP32, they continue to iterate on it nicely and it has great community support. I'm personally developing a smart watch platform based on micropython.

View on HN

While the ESP32 is great for many applications, it’s not for battery operated stuff. When an nRF draws 1-2 mA when using BLE, ESP32 will draw 40 mA. And the chip they selected is even more efficient.

The low power chips can also run in low power mode without BLE running using micro amps, something the ESP can’t match.

I really like ESP32 and I hope they have a low power chip on their roadmap.

Sure I agree, but the WiFi functionality is a killer feature. As mentioned in another comment, it means a smart watch stops being a smart phone addition and can actually operate as a stand-alone device.

Years ago I had a "smart" watch that had a sim card and was a full mobile phone within its own right, I think it was just 10 years or so too early.

Concur. With nRF, you have to bolt on a separate 70002 Wi-Fi Chip.

And this chip isn't a normal QSPI chip where you read the datasheet. You have to use NRF connect, and Zephyr.

So, this brings up the obvious question: What if I don't want my whole firmware to be Zephyr nRF-connect, just for a Wi-Fi chip?

Manufacturer lock-in can be quite a problem. I'm not saying the ESP32 solves this fully, but you can mix and match as you like, and it's highly encouraged. I think with the ESP32 most build upon Free RTOS but I'm not aware of a strict requirement.

Of note, you can just pull in a lib to use Wi-Fi and BLE on an ESP32 (C-3 at least). I've done it. It doesn't imply any changes to your firmware architecture. That's the part that bothers me about Nordic's approach.

pretty sure you can use 7002 with any MCUs and vice versa. I dont know what would be the technical limitation

Aren't ESP32s way more power hungry than typical BT-only parts though?

Not insanely for a smart watch. Your smart watch battery will be something like 200mAh, so for 20 hours you need to average 10mAh. With zero optimisation, screen refresh rate at 30+fps, I have smart watch chewing 30mAh.

Getting down to 10mAh is not so bad. If you're not actively driving the display, you can under-clock significantly [1], if you're not using WiFi you can turn the modem off [2].

[1] https://docs.espressif.com/projects/esp-idf/en/stable/esp32/...

[2] https://docs.espressif.com/projects/esp-idf/en/stable/esp32/...

no, esp32(the original one) is insanely power hungry, especially its radio.

Also 20 hours of runtime is horrible.

I'm getting 10 hours run time with the screen continuously running and drawing graphics every refresh in micropython - extending this time out is definitely possible.

There are many ESP32 variants, depending on what you pick some may be more compelling for your use-case.

Well, we are talking about smartwatch use case.

Even some newer variant like S3 or C6 only has acceptable power consumption, if what you are after is run-time they are not the best fit.

It might be just-about acceptable for a smartwatch. But anything the micro takes out of the power budget means less screen and radio time, which does add constraints.

PineTime, based on NRF52, will get you 4-7 days of practical usage.

Can confirm, I regularly get about 9 days of charge on my PineTime, running the latest PineTimeOS release. Its gotten better and better over the years, and the functionality keeps coming ..

I used to use the PineTime with PineTimeOS, but mine eventually broke (corroded inside), but not having WiFi made it annoying to develop for. With WiFi suddenly you don't need to communicate regularly with a phone and the possibilities really open up.

I get that kind of experience with the Watchy… but the problem is, its quite a bulky device and gets a bit tiring to wear after a while.

There are ESP32 watches. One I have[1] comes with quite thick 940mAh battery but my understanding is the battery life still isn't that amazing (just got it, haven't really tested the battery) - something like less than a day of constant runtime or few days if you turn it off constantly

[1] https://lilygo.cc/products/t-watch-s3-plus

I have a similar one with a microphone, I dread to think how the GPS module and LoRa of that variant affects battery life!

Yeah I got one of those as well. An the older non-S3 version. Fun for developing, very powerful. I use it for developing ML applications for watches etc (emlearn project). Great device for that, but battery life is not its strong point.

Does this apply to C-3 and C-5 as well?

I would not consider ESP32 high-end MCU, it still lacks many peripheral(DSP, GPU), its core clock is not high(only 240mhz iirc).

Recently they release ESP32P4, with very strong performance, but like you guess, without Radio

We are talking about an MCU, not a CPU :)

I think once we start talking about GPU, MMU, USB, display, etc, we're getting towards a CPU of sorts.

Speaking of a low-end CPU, I want to test out the RV1103 Rockchip, those crazy little chips are running Linux apparently [1], and even able to run Python [2]. Depending on power draw, a Linux-based smart watch could be on the horizon.

[1] https://www.luckfox.com/EN-Luckfox-Pico

[2] https://wiki.luckfox.com/Luckfox-Pico/Luckfox-Pico-SDK

ESP32-S3 has all that minus a GPU. Runs Linux.

Looking at that now [1], seems like something I need to run a test with!

[1] http://wiki.osll.ru/doku.php/etc:users:jcmvbkbc:linux-xtensa...

USB is trivial for most modern MCUs; even low-power/minimal-cost ones.

Yes, we are talking MCU, it's very common now that mcu has gpu now.

For ex: Bes2700bp and bes2800 has 3d GPU iirc. Their spec is very impressive, too bad that their SDK is kind of limited to non-Chinese vendor

You got downvotes but im a firmware eng and can point out more esp deficiencies. #1 completely fake FPU that they lie aboutm. #2 awful memory bandwidth. Not only slow but unpredictable. #3 small onboard memory. #4 low clock speed.

Reply on news.ycombinator.com