Hacker News Reader

Comment by mrheosuper | Hacker News Reader

Interesting they did not go with 2-chip design(1 for main application, 1 for BLE stuff). Which is sometime makes sense because high power mcu usually does not have RF

View on HN

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.

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.

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

the more chips you have, the more complex the project becomes. BOM is one thing, every chip needs support passives and oscillators, but now you also need to coordinate communication between the chips, you need to devise a way to update firmwares and access both chips for debugging purposes... that might be worth to trade off for less battery life.

in my experience they are not that much difference between 2 design. The BLE FW is a binary blob that you will download at boot with 2 chip-design, or load it to correct address with single chip-design.

From the CPU perspective, they are the same

From a PCB layout and supply chain perspective, it’s a big difference.

> in my experience they are not that much difference between 2 design.

Depends!

If the two chips use UART or SPI for intercommunication, okay, you need two lines between the CPU and two GPIO lines for wakeup, and JTAG can be shared anyway.

But if you use stuff like shared memory, or want to do stuff like updating the display not just from the high-power chip but also from the low-power one, suddenly design becomes much more complex.

The Cortex-M33 core in the SiFli chip will be much faster than the M4 cores that the fastest released Pebble watches used, so a faster MCU than this is not something that's needed. However, more battery life is very welcome, and the fact that they're using MCUs with integrated Bluetooth this time seems to be a huge part of the upgrade from about a week of battery life to about a month of battery life.

It's just a watch. You don't need a full UNIX computer to tell time, or to record heart rates or pinging AWS for those matters.

Interesting comment, because according to https://en.wikipedia.org/wiki/PDP-7 the PDP7 (the first computer "UNIX" ran on) had ~9.2KB of memory (supporting up to 144KB).

Most contemporary SoCs will have more memory (and compute power) than that.

That's a complete non sequitur. Just because UNIX can run on lower end hardware doesn't mean "a full UNIX computer" is the best tool for the job.

And frustratingly all "lacks MMU" and V6 UNIX binaries don't just run. Imagine the world where random IoT gadgets all run backported GPLv2 GNU/Unix systems and crashing left and right.

Instead there's a massive gap between Linux-capable systems and RTOS-focused systems despite, like you said, the latter now being bigger and better than real shared UNIX systems.

Reply on news.ycombinator.com