4 ms·

* which doesn't need batteries or plugging in * So, uh, it has to be solar powered only? That sounds fantastically niche and not like something someone would w

by unwind 5y ago

* which doesn't need batteries or plugging in * So, uh, it has to be solar powered only? That sounds fantastically niche and not like something someone would want to design/build. I think any reasonable "work" performance level would require too large an area of solar cells in order to be practical, especially if it should work indoors.

kragen 5y ago
Solar power does seem like the most reasonable option, although other possibilities include energy harvesting from keyboard interaction, piezoelectric shoe soles like those that drive those LED-flashing shoes, or a pullstring. You need some energy storage, but at low power levels a modern ceramic capacitor is more than adequate in between pullstring pulls or whatever. Many of my earlier notes on the topic are in https://dercuano.github.io/notes/keyboard-powered-computers.html https://dercuano.github.io/notes/keyboard-powered-computers.... and https://dercuano.github.io/topics/energy-harvesting.html https://dercuano.github.io/topics/energy-harvesting.html; more recent ones are in http://canonical.org/~kragen/derctuo http://canonical.org/~kragen/derctuo and http://canonical.org/~kragen/dernocua http://canonical.org/~kragen/dernocua. But last year I learned about two innovations that have been brought to market that dramatically increase the potential abilities of such a device. — ⁂ — It's entirely possible that your definition of 'any reasonable "work" performance level' is orders of magnitude higher than my "reasonably convenient programming environment". The VAX reference point is 1 Dhrystone MIPS, and the Macintosh SE (a 7.8 MHz 68000) was also about 1 Dhrystone MIPS. Current ARM7 Cortex designs deliver about 2 Dhrystone MIPS per MHz, so we're talking about 500kHz of ARM7 instructions here. Without any fancy circuitry at all I was able to squeeze 8 mW out of a 38-mm-square solar panel from a dollar-store garden light, in direct sunlight. Theory predicts it should be capable of 200+ mW (16% efficiency, 1000 W/m²) so hopefully I can get better results out of other panels. The amorphous solar panels normally used on solar calculators, which work well indoors as well as in direct sunlight, are nominally about 10% efficient, which is to say, 10 mW/cm² in direct sunlight or 100 μW/cm² in office lighting. It's easy to imagine dedicating 30 cm² of surface area to solar panels, which would give you 300 mW outdoors or 3 mW indoors. (38 mm square is 14 cm². 30 cm² in medieval units is about 4⅝ square inches, depending on which inch you use.) — ⁂ — So, what kind of computer can you run on a milliwatt or so? Ambiq sells an ultra-low-power Cortex-M4F called Apollo3 Blue with 1MiB Flash plus 384 KiB RAM; the datasheet claims that, when fully active, at 3.3 volts, it uses 68 μA plus 10 μA per MHz running application code, and it runs at up to 48 MHz bursting to 96 MHz. So at, say, 10 MHz (20 VAXen or Macintosh SEs), it should use 170 μA or 550 μW. At 48 MHz (100 VAXen or Mac SEs), 550 μA or 1.8 mW. I haven't tested it yet. SparkFun sells a devboard for US$22 at https://www.sparkfun.com/products/15444 https://www.sparkfun.com/products/15444. Remembering, of course, that benchmarks are always pretty bogus, we can still roughly approximate this 20 DMIPS performance level as being roughly the processing speed of a 386/40, 486/25, or SPARC 2, and the 200 DMIPS peak as being roughly the processing speed of a Pentium Pro, PowerMac 7100, or SPARC 20 — but with enormously less RAM, an enormously lower-latency "disk", and a lower bandwidth budget for the disk. And no MMU, so no fork() and no demand-paged executables. You do get memory protection, hardware floating point, and saturating arithmetic, but no MMX-like SIMD instructions. — ⁂ — If the computer's output isn't going to be just an earphone or something, though, you may need to spend substantial energy on a screen as well. Sharp makes a 400×240 "memory LCD" display (0.1 megapixels) used in, for example, Panic's Playdate handheld game console (https://youtu.be/uziFTK5c29k https://youtu.be/uziFTK5c29k) which seems like it should enable submilliwatt personal computing; the datasheet says it uses 175 μW when being constantly updated with a worst-case update pattern at its maximum of 20 Hz. Adafruit sells a breakout board for the display for US$45: https://www.adafruit.com/product/4694 https://www.adafruit.com/product/4694 A VT100's character cell was 8×10 (https://sudonull.com/post/30508-Recreating-CRT-Fonts https://sudonull.com/post/30508-Recreating-CRT-Fonts), so its 80×25 screen was 640×250, 0.16 megapixels, while the Macintosh SE was 512×342, 0.18 megapixels. Both of them were 1 bit deep: a pixel was either on or off. So two of these LCD screens together gives you more pixels than either of these two reference-point computers. However, the pixels are physically a lot smaller, which may compromise readability. (On the other hand, as you can see from the Playdate videos, you can do a lot of things on this display that a VT100 or Mac SE could never dream of doing because of lack of compute and RAM.) — ⁂ — So, I think it's eminently feasible now, although it probably wasn't feasible ten years ago. But it's going to be a challenge; I can't just compile Linux and fire up Vim. Even if Linux could run on these super-low-power computers, they don't have enough memory to recompile it.
- int_19h 5y ago
  We compiled C code just fine on machines with less than a megabyte of RAM back in DOS days. I wouldn't expect gcc to work on such a machine, but some older compiler (lcc? pcc?) should be feasible.
  - kragen 5y ago
    Yeah, even older versions of GCC ought to work, though they don't come with ARM7 backends. (Normally GCC uses fork() to run different compiler passes, but DJGPP demonstrates that it can run without virtual memory without extensive surgery.) C was developed on the PDP-11 where the per-process address space was 64 KiB — and though I think the PDP-11 hardware supported separate stack, data, and code segments, I think the Unix environment (and C in particular) didn't. And the BDS C compiler supported most of C under CP/M on the 8080. (It's free software now, but unfortunately it's written in 8080 assembly.) Separate compilation was helpful not just for speeding up the edit-compile-run cycle but also for handling high-level languages in small memory spaces; if your compiler ran out of memory compiling a large source file, you could split it into two smaller source files and link them together. Getting Linux to compile that way would probably be more work than writing a new OS from scratch. More inspiringly, though, Smalltalk-76 ran on an 8086 with 256KiB of RAM, all kinds of MacOS software ran in 512KiB of RAM, and the Ceres workstation built at ETH in 01987 to run Oberon had 2 MiB of RAM. So I'm confident that a fairly polished IDE experience is possible in 384KiB of RAM and 1 MiB of fast Flash, especially if supplemented with larger off-chip fast Flash. It ought to be possible to do much better than a C-compiler-on-DOS kind of thing. But you can clearly write a usable GUI environment using a C compiler on DOS or a Pascal compiler on a Mac SE.
    - int_19h 5y ago
      C isn't difficult to parse, so you could probably automate splitting of C source files on e.g. function boundaries. But then again, with a single-pass compiler, it shouldn't matter how large the input is, no? I know there are forks of tcc with ARM support...
      - 5y ago

by unwind 5y ago

kragen 5y ago

Solar power does seem like the most reasonable option, although other possibilities include energy harvesting from keyboard interaction, piezoelectric shoe soles like those that drive those LED-flashing shoes, or a pullstring. You need some energy storage, but at low power levels a modern ceramic capacitor is more than adequate in between pullstring pulls or whatever. Many of my earlier notes on the topic are in https://dercuano.github.io/notes/keyboard-powered-computers.html https://dercuano.github.io/notes/keyboard-powered-computers.... and https://dercuano.github.io/topics/energy-harvesting.html https://dercuano.github.io/topics/energy-harvesting.html; more recent ones are in http://canonical.org/~kragen/derctuo http://canonical.org/~kragen/derctuo and http://canonical.org/~kragen/dernocua http://canonical.org/~kragen/dernocua. But last year I learned about two innovations that have been brought to market that dramatically increase the potential abilities of such a device. — ⁂ — It's entirely possible that your definition of 'any reasonable "work" performance level' is orders of magnitude higher than my "reasonably convenient programming environment". The VAX reference point is 1 Dhrystone MIPS, and the Macintosh SE (a 7.8 MHz 68000) was also about 1 Dhrystone MIPS. Current ARM7 Cortex designs deliver about 2 Dhrystone MIPS per MHz, so we're talking about 500kHz of ARM7 instructions here. Without any fancy circuitry at all I was able to squeeze 8 mW out of a 38-mm-square solar panel from a dollar-store garden light, in direct sunlight. Theory predicts it should be capable of 200+ mW (16% efficiency, 1000 W/m²) so hopefully I can get better results out of other panels. The amorphous solar panels normally used on solar calculators, which work well indoors as well as in direct sunlight, are nominally about 10% efficient, which is to say, 10 mW/cm² in direct sunlight or 100 μW/cm² in office lighting. It's easy to imagine dedicating 30 cm² of surface area to solar panels, which would give you 300 mW outdoors or 3 mW indoors. (38 mm square is 14 cm². 30 cm² in medieval units is about 4⅝ square inches, depending on which inch you use.) — ⁂ — So, what kind of computer can you run on a milliwatt or so? Ambiq sells an ultra-low-power Cortex-M4F called Apollo3 Blue with 1MiB Flash plus 384 KiB RAM; the datasheet claims that, when fully active, at 3.3 volts, it uses 68 μA plus 10 μA per MHz running application code, and it runs at up to 48 MHz bursting to 96 MHz. So at, say, 10 MHz (20 VAXen or Macintosh SEs), it should use 170 μA or 550 μW. At 48 MHz (100 VAXen or Mac SEs), 550 μA or 1.8 mW. I haven't tested it yet. SparkFun sells a devboard for US$22 at https://www.sparkfun.com/products/15444 https://www.sparkfun.com/products/15444. Remembering, of course, that benchmarks are always pretty bogus, we can still roughly approximate this 20 DMIPS performance level as being roughly the processing speed of a 386/40, 486/25, or SPARC 2, and the 200 DMIPS peak as being roughly the processing speed of a Pentium Pro, PowerMac 7100, or SPARC 20 — but with enormously less RAM, an enormously lower-latency "disk", and a lower bandwidth budget for the disk. And no MMU, so no fork() and no demand-paged executables. You do get memory protection, hardware floating point, and saturating arithmetic, but no MMX-like SIMD instructions. — ⁂ — If the computer's output isn't going to be just an earphone or something, though, you may need to spend substantial energy on a screen as well. Sharp makes a 400×240 "memory LCD" display (0.1 megapixels) used in, for example, Panic's Playdate handheld game console (https://youtu.be/uziFTK5c29k https://youtu.be/uziFTK5c29k) which seems like it should enable submilliwatt personal computing; the datasheet says it uses 175 μW when being constantly updated with a worst-case update pattern at its maximum of 20 Hz. Adafruit sells a breakout board for the display for US$45: https://www.adafruit.com/product/4694 https://www.adafruit.com/product/4694 A VT100's character cell was 8×10 (https://sudonull.com/post/30508-Recreating-CRT-Fonts https://sudonull.com/post/30508-Recreating-CRT-Fonts), so its 80×25 screen was 640×250, 0.16 megapixels, while the Macintosh SE was 512×342, 0.18 megapixels. Both of them were 1 bit deep: a pixel was either on or off. So two of these LCD screens together gives you more pixels than either of these two reference-point computers. However, the pixels are physically a lot smaller, which may compromise readability. (On the other hand, as you can see from the Playdate videos, you can do a lot of things on this display that a VT100 or Mac SE could never dream of doing because of lack of compute and RAM.) — ⁂ — So, I think it's eminently feasible now, although it probably wasn't feasible ten years ago. But it's going to be a challenge; I can't just compile Linux and fire up Vim. Even if Linux could run on these super-low-power computers, they don't have enough memory to recompile it.

int_19h 5y ago
We compiled C code just fine on machines with less than a megabyte of RAM back in DOS days. I wouldn't expect gcc to work on such a machine, but some older compiler (lcc? pcc?) should be feasible.
- kragen 5y ago
  Yeah, even older versions of GCC ought to work, though they don't come with ARM7 backends. (Normally GCC uses fork() to run different compiler passes, but DJGPP demonstrates that it can run without virtual memory without extensive surgery.) C was developed on the PDP-11 where the per-process address space was 64 KiB — and though I think the PDP-11 hardware supported separate stack, data, and code segments, I think the Unix environment (and C in particular) didn't. And the BDS C compiler supported most of C under CP/M on the 8080. (It's free software now, but unfortunately it's written in 8080 assembly.) Separate compilation was helpful not just for speeding up the edit-compile-run cycle but also for handling high-level languages in small memory spaces; if your compiler ran out of memory compiling a large source file, you could split it into two smaller source files and link them together. Getting Linux to compile that way would probably be more work than writing a new OS from scratch. More inspiringly, though, Smalltalk-76 ran on an 8086 with 256KiB of RAM, all kinds of MacOS software ran in 512KiB of RAM, and the Ceres workstation built at ETH in 01987 to run Oberon had 2 MiB of RAM. So I'm confident that a fairly polished IDE experience is possible in 384KiB of RAM and 1 MiB of fast Flash, especially if supplemented with larger off-chip fast Flash. It ought to be possible to do much better than a C-compiler-on-DOS kind of thing. But you can clearly write a usable GUI environment using a C compiler on DOS or a Pascal compiler on a Mac SE.
  - int_19h 5y ago
    C isn't difficult to parse, so you could probably automate splitting of C source files on e.g. function boundaries. But then again, with a single-pass compiler, it shouldn't matter how large the input is, no? I know there are forks of tcc with ARM support...
    - 5y ago