5 ms·

CPU -- we all have opinions on uCs. I see that your chosen uC has very low active power consumption, less than 10uA per MHz, suggesting under 1mA full tilt. Ha

CPU -- we all have opinions on uCs. I see that your chosen uC has very low active power consumption, less than 10uA per MHz, suggesting under 1mA full tilt. Have you run any tests to see if active mode is indeed the mode you're in most of the time? Or is it possible that other uCs that could have better sleep current can beat your uC of choice? Screen -- I like the Sharp in pixel memory LCD screens, though 4 inches is a bit small. A bigger screen would be what I'd be searching for, but I also know that monitors use a surprising amount of power, and 4 inches is the biggest memory-LCD screen in my area as well. E-ink, for all of it's faults, does climb to 7+ inches and beyond. But changing eink screens is surprisingly power hungry. Bluetooth -- lol, there goes the power budget!! This uses what? Probably 10x more power than everything else combined? I/O is a necessity and it's a good feature, but I really do wish* it used less power.

bee_rider 4y ago
I wonder if a combination of eInk and pixel memory LCD could be good? Use them as two monitors, keep vim on the LCD, web browser or other documentation on the bigger eInk.
- kragen 4y ago
  The Barnes & Noble Nook did this, except that they were using a conventional backlit color active-matrix LCD rather than a memory-in-pixel LCD like this. There is clearly a crossover point at which this combination would use lower power, because the e-ink display uses zero power when not updating, and the memory-in-pixel LCD uses power even to retain the display. So as the update rate goes low enough, at some point the e-ink display will use less power. My vaguely remembered estimate of this crossover point is that the e-ink display starts using less power than the memory-in-pixel LCD when the update rate is less than about one update per hour.
  - rerdavies 4y ago
    lol
  - canadianfella 4y ago
    [dead]
  - kragen 4y ago
    to answer hellbanned canadianfella, if you think one per hour is wrong, i'm interested to see your calculations probably without showing evidence, neither of us will convince the other
    - Firmwarrior 4y ago
      Presumably someone working on an e-ink device at some point ran the same calculation, and decided to use the e-ink display. Which means that e-ink being more power hungry if you update it more than once per hour wouldn't have been true
      - kragen 4y ago
        People building e-paper devices after calculating their power usage definitely doesn't mean that my calculation is wrong. First, they started doing it 16 years ago, and things have changed since then, in ways that have made e-paper less popular; second, power usage is far from the only consideration in product design. E-paper has some real advantages over memory-in-pixel LCDs: as I said in the other thread, the whites are whiter, it's not glossy, it can do grayscale, some versions can even do color, it's available in larger panel sizes, it existed in 02007 when Amazon launched the Swindle, and it can continue to display Amazon advertising even when the device is entirely powered off. None of these are true of memory-in-pixel LCDs (though the Playdate does display advertising on its memory-in-pixel screen when it's "off"). Moreover, the computing power budget for the Swindle and similar e-readers is also measured in hundreds of milliwatts, just like the screen. There's not much reason to worry about whether your screen uses 100 microwatts or 100 milliwatts if your CPU is using 200 milliwatts. Reducing your power consumption by 50% or 5% is never a critical factor in the success or failure of your product, because you could just add another 50% in battery weight if it were. Ambiq didn't even exist until 02010, and didn't sample the Apollo3 until 02018, so to get even a single order of magnitude improvement in CPU power usage, Amazon (or competing vendors) would have had to cut the compute budget for e-readers by an order of magnitude, probably resulting in major increases in space usage, reductions in rendering quality, sluggish interactions, or all three, and certainly increasing development cost. Ambiq's CPUs are fast enough, but you can't just drop them into a new model of Swindle or Kobo and keep the same software; they have tiny onboard RAM, little support for offboard RAM (which would make power consumption balloon anyway), and no MMUs, so they can't run either Linux or any of the other e-reader software that's been developed for existing devices—it needs way too much memory.
reerdna 4y ago
Yes, it's nearly always in active mode now. I haven't done much to use the sleep modes at all, only "sleep until next keyboard interrupt" when the program calls (get-key). Measurement, selected portion is while rendering a fractal - so "100% cpu" - at 1.5mA. https://cdn.hackaday.io/images/4389961676068300828.png https://cdn.hackaday.io/images/4389961676068300828.png I'm sure other uCs could sleep at lower power, but active mode was what I wanted to optimize for.
- kragen 4y ago
  This is wonderful information! Thank you! That's 1.49 mA at 3.3 volts?
  - reerdna 4y ago
    Yeah, matching pretty well the advertised 5mW. But uLisp is probably not using the CPU very efficiently and so not driving it to the max that could perhaps be seen with something like a well-implemented FFT.
    - kragen 4y ago
      Is this at 48 MHz or 96 MHz? I'm so confused about the 96 MHz stuff in the datasheet. There must be some drawback to 96 MHz, because if not, what's so special about 48 MHz? Is that using the FPU, or are you doing all the fractal math in integer? I have this vague idea that using the FPU might cause it to use more power than integer code will (and might or might not be faster for fractal rendering).
      - reerdna 4y ago
        Using the FPU I believe but quite inefficiently, most cycles are probably spent in integer operations and chasing linked lists for the lisp parser. http://forum.ulisp.com/t/barnsley-fern-in-ulisp/1087 http://forum.ulisp.com/t/barnsley-fern-in-ulisp/1087 48MHz is the most power efficient mode, you can run it at 96Mhz "burst mode" but apparently it uses disproportionately more power, I have not measured how much.
qvaetrain 4y ago
I too have been investigating using eink displays, but the biggest issue I've found is refresh rates are often terrible especially with colour displays. Have you found eink displays with refresh rates <1s?
- reerdna 4y ago
  No, I did spend some time reading eink datasheets but in the end it seemed too hard for me to do on my own. There's the Kindle and Freewrite so it seems possible
- kragen 4y ago
  The E-Ink displays also use a lot of power at reasonable reading rates, like one Swindle screen update per minute seems to use about 100 mW. That's about three orders of magnitude more than the 2.7" memory LCD, which I guess is about an order of magnitude less area, so it's about two orders of magnitude more power per area. But the memory LCD updates at nominally 20 Hz and potentially much faster, so it's three orders of magnitude faster, so in some sense it's five orders of magnitude better than E-Ink. I have seen a Swindle do partial screen updates much faster than 1000 ms. In fact, I originally wrote http://canonical.org/~kragen/sw/inexorable-misc/tetris.html http://canonical.org/~kragen/sw/inexorable-misc/tetris.html to play in the browser on a Swindle, with update times of more like 100 ms. And I successfully used IRC on it, too. The E-Ink display does have some good points: it's not glossy, it's available in bigger sizes, its whites are whiter, and it can do grayscale. But, for interactive computing, I think those aren't a good tradeoff for being orders of magnitude worse at power consumption and update times.
Laaas 4y ago
You could theoretically simply buy multiple of these screens and place them in a grid. Would be slightly annoying when you want to split one window across multiple screens, but I imagine it would still be much more useful.
- dragontamer 4y ago
  I've played a Japanese arcade game called Jubeat, that's made up of... I think a 4x4 grid of small touch screens. With the right interface and design, it feels fine. In particular, Jubeat has a different note assigned to each screen so the divisions feel very natural. First hit from YouTube: https://youtu.be/LSGOAkyFW7I https://youtu.be/LSGOAkyFW7I Or maybe just natural to people who put in a bit of practice, lol. This is an expert level song pattern, it's not so bad at earlier levels. But it still shows off how the 4x4 screen effectively communicates a variety of button press timings to the player, combo counters, life, scrolling and other such details for this game.

bee_rider 4y ago

I wonder if a combination of eInk and pixel memory LCD could be good? Use them as two monitors, keep vim on the LCD, web browser or other documentation on the bigger eInk.

kragen 4y ago
The Barnes & Noble Nook did this, except that they were using a conventional backlit color active-matrix LCD rather than a memory-in-pixel LCD like this. There is clearly a crossover point at which this combination would use lower power, because the e-ink display uses zero power when not updating, and the memory-in-pixel LCD uses power even to retain the display. So as the update rate goes low enough, at some point the e-ink display will use less power. My vaguely remembered estimate of this crossover point is that the e-ink display starts using less power than the memory-in-pixel LCD when the update rate is less than about one update per hour.
- rerdavies 4y ago
  lol
- canadianfella 4y ago
  [dead]
- kragen 4y ago
  to answer hellbanned canadianfella, if you think one per hour is wrong, i'm interested to see your calculations probably without showing evidence, neither of us will convince the other
  - Firmwarrior 4y ago
    Presumably someone working on an e-ink device at some point ran the same calculation, and decided to use the e-ink display. Which means that e-ink being more power hungry if you update it more than once per hour wouldn't have been true
    - kragen 4y ago
      People building e-paper devices after calculating their power usage definitely doesn't mean that my calculation is wrong. First, they started doing it 16 years ago, and things have changed since then, in ways that have made e-paper less popular; second, power usage is far from the only consideration in product design. E-paper has some real advantages over memory-in-pixel LCDs: as I said in the other thread, the whites are whiter, it's not glossy, it can do grayscale, some versions can even do color, it's available in larger panel sizes, it existed in 02007 when Amazon launched the Swindle, and it can continue to display Amazon advertising even when the device is entirely powered off. None of these are true of memory-in-pixel LCDs (though the Playdate does display advertising on its memory-in-pixel screen when it's "off"). Moreover, the computing power budget for the Swindle and similar e-readers is also measured in hundreds of milliwatts, just like the screen. There's not much reason to worry about whether your screen uses 100 microwatts or 100 milliwatts if your CPU is using 200 milliwatts. Reducing your power consumption by 50% or 5% is never a critical factor in the success or failure of your product, because you could just add another 50% in battery weight if it were. Ambiq didn't even exist until 02010, and didn't sample the Apollo3 until 02018, so to get even a single order of magnitude improvement in CPU power usage, Amazon (or competing vendors) would have had to cut the compute budget for e-readers by an order of magnitude, probably resulting in major increases in space usage, reductions in rendering quality, sluggish interactions, or all three, and certainly increasing development cost. Ambiq's CPUs are fast enough, but you can't just drop them into a new model of Swindle or Kobo and keep the same software; they have tiny onboard RAM, little support for offboard RAM (which would make power consumption balloon anyway), and no MMUs, so they can't run either Linux or any of the other e-reader software that's been developed for existing devices—it needs way too much memory.

reerdna 4y ago

Yes, it's nearly always in active mode now. I haven't done much to use the sleep modes at all, only "sleep until next keyboard interrupt" when the program calls (get-key). Measurement, selected portion is while rendering a fractal - so "100% cpu" - at 1.5mA. https://cdn.hackaday.io/images/4389961676068300828.png https://cdn.hackaday.io/images/4389961676068300828.png I'm sure other uCs could sleep at lower power, but active mode was what I wanted to optimize for.

kragen 4y ago
This is wonderful information! Thank you! That's 1.49 mA at 3.3 volts?
- reerdna 4y ago
  Yeah, matching pretty well the advertised 5mW. But uLisp is probably not using the CPU very efficiently and so not driving it to the max that could perhaps be seen with something like a well-implemented FFT.
  - kragen 4y ago
    Is this at 48 MHz or 96 MHz? I'm so confused about the 96 MHz stuff in the datasheet. There must be some drawback to 96 MHz, because if not, what's so special about 48 MHz? Is that using the FPU, or are you doing all the fractal math in integer? I have this vague idea that using the FPU might cause it to use more power than integer code will (and might or might not be faster for fractal rendering).
    - reerdna 4y ago
      Using the FPU I believe but quite inefficiently, most cycles are probably spent in integer operations and chasing linked lists for the lisp parser. http://forum.ulisp.com/t/barnsley-fern-in-ulisp/1087 http://forum.ulisp.com/t/barnsley-fern-in-ulisp/1087 48MHz is the most power efficient mode, you can run it at 96Mhz "burst mode" but apparently it uses disproportionately more power, I have not measured how much.

qvaetrain 4y ago

I too have been investigating using eink displays, but the biggest issue I've found is refresh rates are often terrible especially with colour displays. Have you found eink displays with refresh rates <1s?

reerdna 4y ago
No, I did spend some time reading eink datasheets but in the end it seemed too hard for me to do on my own. There's the Kindle and Freewrite so it seems possible
kragen 4y ago
The E-Ink displays also use a lot of power at reasonable reading rates, like one Swindle screen update per minute seems to use about 100 mW. That's about three orders of magnitude more than the 2.7" memory LCD, which I guess is about an order of magnitude less area, so it's about two orders of magnitude more power per area. But the memory LCD updates at nominally 20 Hz and potentially much faster, so it's three orders of magnitude faster, so in some sense it's five orders of magnitude better than E-Ink. I have seen a Swindle do partial screen updates much faster than 1000 ms. In fact, I originally wrote http://canonical.org/~kragen/sw/inexorable-misc/tetris.html http://canonical.org/~kragen/sw/inexorable-misc/tetris.html to play in the browser on a Swindle, with update times of more like 100 ms. And I successfully used IRC on it, too. The E-Ink display does have some good points: it's not glossy, it's available in bigger sizes, its whites are whiter, and it can do grayscale. But, for interactive computing, I think those aren't a good tradeoff for being orders of magnitude worse at power consumption and update times.

Laaas 4y ago

You could theoretically simply buy multiple of these screens and place them in a grid. Would be slightly annoying when you want to split one window across multiple screens, but I imagine it would still be much more useful.

dragontamer 4y ago
I've played a Japanese arcade game called Jubeat, that's made up of... I think a 4x4 grid of small touch screens. With the right interface and design, it feels fine. In particular, Jubeat has a different note assigned to each screen so the divisions feel very natural. First hit from YouTube: https://youtu.be/LSGOAkyFW7I https://youtu.be/LSGOAkyFW7I Or maybe just natural to people who put in a bit of practice, lol. This is an expert level song pattern, it's not so bad at earlier levels. But it still shows off how the 4x4 screen effectively communicates a variety of button press timings to the player, combo counters, life, scrolling and other such details for this game.