5 ms·

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 h

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

mschuster91 1y ago
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.
- mrheosuper 1y ago
  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
  - Max-q 1y ago
    From a PCB layout and supply chain perspective, it’s a big difference.
  - mschuster91 1y ago
    > 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.
bArray 1y ago
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.
- jsheard 1y ago
  Aren't ESP32s way more power hungry than typical BT-only parts though?
  - bArray 1y ago
    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/api-guides/low-power-mode/low-power-mode-soc.html https://docs.espressif.com/projects/esp-idf/en/stable/esp32/... [2] https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/low-power-mode/low-power-mode-wifi.html https://docs.espressif.com/projects/esp-idf/en/stable/esp32/...
    - mrheosuper 1y ago
      no, esp32(the original one) is insanely power hungry, especially its radio. Also 20 hours of runtime is horrible.
      - bArray 1y ago
        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.
        mrheosuper 1y ago
        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.
    - 1y ago
numpad0 1y ago
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.
- znpy 1y ago
  Interesting comment, because according to https://en.wikipedia.org/wiki/PDP-7 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.
  - internetter 1y ago
    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.
  - numpad0 1y ago
    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.
ItsHarper 1y ago
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.

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

mschuster91 1y ago

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.

mrheosuper 1y ago
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
- Max-q 1y ago
  From a PCB layout and supply chain perspective, it’s a big difference.
- mschuster91 1y ago
  > 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.

bArray 1y ago

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.

jsheard 1y ago
Aren't ESP32s way more power hungry than typical BT-only parts though?
- bArray 1y ago
  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/api-guides/low-power-mode/low-power-mode-soc.html https://docs.espressif.com/projects/esp-idf/en/stable/esp32/... [2] https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/low-power-mode/low-power-mode-wifi.html https://docs.espressif.com/projects/esp-idf/en/stable/esp32/...
  - mrheosuper 1y ago
    no, esp32(the original one) is insanely power hungry, especially its radio. Also 20 hours of runtime is horrible.
    - bArray 1y ago
      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.
      - mrheosuper 1y ago
        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.
  - 1y ago

numpad0 1y ago

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.

znpy 1y ago
Interesting comment, because according to https://en.wikipedia.org/wiki/PDP-7 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.
- internetter 1y ago
  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.
- numpad0 1y ago
  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.

ItsHarper 1y ago

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.