A LISP-programmable laptop with battery life measured in months

Public Chat
Similar projects worth following
It's summer, so I spend my free time sailing. Will continue this project in fall/winter

I got annoyed with my personal laptop always running out of battery when I wanted to work on my small programming projects, so I am building myself a laptop form factor device with the goal of having at least a full month of battery life, and hopefully much more!

It needs to have a good keyboard and a decent programming environment - compatability with existing software is not a priority, nor is powerful hardware - just the minimum required for a LISP environment. Writing a minimal editor, word processor, spreadsheet app etc. will be part of the fun!

My current working prototype is based on the Sparkfun Artemis module, running uLisp; and using a monochrome 4.4" Sharp Memory Display.

Why PotatoP?

  • The word "Potato" is often used to describe an underpowered/poorly performing device. "This video must have been filmed with a potato!" This device is intentionally underspecced to ensure long battery life.
  • The "toP" suffix refers to the intended eventual laptop form factor
  • The suffix "p" is used for LISP predicates - functions that return true or false, like "evenp" or "primep" for numbers. Is it a potato or not? It depends on your point of view!
  • It lets me call the OS PotatOS!

This project is heavily inspired by Technoblogy's super cool Lisp Badge, the Lisperati 1000, the Open Source Autarkic Laptop and ei2030 working groups, the playdate, various projects featured on r/cyberDeck and lots of other cool stuff I forgot about already!

  • Falling down rabbit holes

    Andreas Eriksen03/20/2022 at 22:07 0 comments

    To quickly sum up the progress I've made since last time - I can now type on the keyboard, and the words show up on the screen! Those letters in the picture are pretty chunky - but that is for your easy viewing pleasure. I can comfortably read with the default 5x7 font which lets me display 53x30 characters. Moving it closer and adding another one or two next to it should give me sufficient screen real estate.

    I've measured current consumption from the battery at 6mA, or about 22 mW, while scanning the keyboard and constantly updating the screen. That should give me about 83 days of battery life (given constant use) with the laptop-size battery I've ordered.

    It's certainly better than my standard laptop, but not quite as good as could be hoped for - it's 4x the quoted 5 mW power for the Artemis module. Disconnecting the screen or putting the CPU to sleep didn't seem to make much of a difference either, and that means I won't be able to recharge using only the solar panels, certainly not with indoor light at least.

    I suspect most of the power draw is from other components on the board, like the voltage regulator, power LED and possibly more. I've cut the traces to the PDM microphone earlier, but I don't want to start desoldering the other components just yet.

    The keyboard scanning rabbit hole

    I was able to get the timer driven interrupt working, and posted a simple example in the Sparkfun forums in hope that it might help others. The rest was supposed to be simple! But when I coded up the keyboard scanning routine, using the standard Arduino pinMode and digitalWrite / digitalRead calls, it was slow ... unacceptably slow.

    It took about two milliseconds to scan the whole keyboard matrix, which I had naively been hoping to do tens of thousands of times per seconds - but I could barely scan it 500 times per second, and even then the CPU would have been 100% busy scanning the keyboard and have no time left to do anything else.

    I realized I would have to leave the easy and comfortable world of Arduino tutorials, and started digging into the guts below. Happily I discovered that all the source code for the underlying software is included in my ~/.arduino folder!

    Turns out that Sparkfun's Arduino core for the Artemis boards is based on Mbed OS, and every call to pinMode or digitalWrite will spend some time looking up the right mbed::DigitalInOut object. Keeping references to and calling these directly saved about half of the time, getting it down to 1 ms per scan. Reducing the scan rate to 256 times per second seemed acceptable enough for now - that's 25% of the CPU, but I can fix it later.

    Or so you'd think, but I just couldn't accept that. So I dug down through another layer ... the implementation of Mbed OS for the Apollo3 ends up calling functions from the Ambiq SDK. These have somewhat more arcane names, like am_hal_gpio_input_read, but have even less overhead - calling these directly got me down to about 240 microseconds per scan, or about 6.6% of the total CPU time.

    There is yet another layer I could chip away at - there is a "fast GPIO" function, or I could even directly read and write from the I/O registers - but I spent a whole evening trying without much success, and 240 microseconds at 48Mhz is 11520 clock cycles, about ~103 clock cycles per key scanned, and I think I'll be able to live with that ... for now.

    The hardware SPI rabbit hole

    Once I had come to terms with the keyboard scanning, my next step was to display the results on the screen, and I promptly fell into another hole. Screen updates are just a little too slow with software-driven SPI for typing to be responsive. Using he same shortcuts as for the keyboard helps, but it's not great, and getting hardware SPI to work with the Adafruit library on the Sparkfun board is still giving me trouble.

    After consulting the display data sheet and programming app note I was able to write data to the display using hardware SPI without using the...

    Read more »

  • Prototyping progress

    Andreas Eriksen03/12/2022 at 21:33 0 comments

    The photo I originally uploaded shows an Adafruit NRF52840 Express board - this worked great for testing the display, but I wanted more GPIOs for scanning the whole keyboard matrix directly (14 column lines + 8 row lines).

    I had previously ordered the Sparkfun Artemis ATP board (48 GPIOS!) in the hope to get close to the extremely low power usage numbers they are quoting (5mW). Probably not if I'm using that many GPIO lines, but if I could get even close it would be amazing. Currently it idles at around 4mA@3.3V, so 13.2mW ... 

    That board sure took it's sweet time in the mail, but now that I have it I have been able to verify that I can get uLisp running on it, scan the keyboard matrix and read all the keys (from LISP). Success!

    What hasn't gone great is getting the display to work with hardware SPI. I must have tried a hundred different combination of parameters but no luck yet. Are there some assumptions in the Adafruit libraries that don't apply to the Sparkfun board? No idea. For now I'll ignore that display updates are kind of slow, and plod on with the next step ...

     ... which is scanning the keyboard at regular intervals, doing debouncing and turning it in to a nice and neat sequence of keyup/down events. I am lucky to have some code to go by from the uLisp author's own very cool lisp badge project:

    In parallel I'm 3D printing a very simple case for the display and breakout board. I learned the hard way that those FPC connectors are fragile, and ruined one 4.4" display - good thing I ordered extra. And hopefully I've learned my lesson now and the case will keep the next one safe.

View all 2 project logs

Enjoy this project?



initrd wrote 05/22/2022 at 14:54 point

Nice, I just completed a small test of a solar panel

  Are you sure? yes | no

Andreas Eriksen wrote 03/10/2022 at 15:54 point

My current estimate is 87 days of continuous use. I'm sure that will change as I refine my estimates, but I hope to keep it in that ballpark. If I can make low power sleep mode work when closed, it should be effectively perpetual. But I foresee some difficulties with self discharge of li-poly batteries.

And yes, I'm already testing solar! Using the "aemlion" board by Jasper Sikken and some Powerfilm low-light solar panels, I hope to be able to recover some power even indoors.

But take all of this with a generous pinch of salt! This is not my area of expertise, I'm just a software dev playing around for fun, not being very rigorous in my research and testing. Time will tell!

  Are you sure? yes | no

sup wrote 03/10/2022 at 09:47 point

how long this device work? week ? month?

meybe add solar panel? Many project (like fuzix) no need big cpu 

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates