Coffee Space


Linux PDA Part 3

Preview Image

This article builds upon the ideas iterated on in part 1 and part 2 on designing and building a Linux PDA.

The personal digital assistant (PDA) is a device concept that has been around since 1984, and really is the hardware equivalent of the Unix Philosophy (changes are mine 1):

  1. Make each program application do one thing well. To do a new job task, build afresh rather than complicate old programs applications by adding new “features”.

The original mobile phones were devices that did only a few tasks; you could expect to call, text, makes notes - but not much more. A modern ‘smart phone’ is essentially all of that, plus a browser, a payment processor, a navigator, media player, etc, etc. Each new iteration becomes forever more complex.

A PDA that is resource limited, by design, promising to do just one thing and do it well. It promises to be a personal digital assistant, an organiser, a digital replacement for pen and paper. It’s not trying to compete with a phone.

In part 1 I tried to leverage Pine64’s PineCube, but in part 2 I discovered that the optional touch display was not going to work. Not only this, but the form factor is completely wrong anyway, so it would only serve as a base for a future project.

Pine64 did hint at a PineCom more than a year ago, but nothing so far came of this discussion. They have some ongoing works in LoRa, but this could be years off as yet. They are still struggling to run a new production run of their ongoing commitments, such as the PineTab.

Other users on Pine64’s forum have requested similar projects as time has gone on, including a MP3 player - but this appears to be something Pine64 are also unwilling to pick up on.

All that said, I don’t believe Pine64 is a viable path for exploring the concept of a Linux PDA. In part 2 I discussed some potential alternative options, but none came with an appropriate chassis and would only serve as a starting point, not something that could be daily driven. I have been discussing a few interesting devices that have appeared in the market via the tag #linuxpda - but anything even remotely cool costs too much money.

So where does that leave us? I believe I have no choice but to drop my requirement for Linux. Whilst having Linux automatically allows us to leverage many very awesome ideas, it does significantly reduce the number of potential device candidates. To make this project work, I will therefore be looking to implement something that works cross-platform - which will of course will pose a significant technical challenge.

Hardware Requirements

In terms of hardware, I am looking for the following:

Nice to have hardware functionality:

M5 Stack Core 2

The M5 Stack Core 2

A device I am currently looking at is the M5 Stack Core 2, which for $46.90 offers the following features:

Resource Description
Processor ESP32-D0WDQ6-V3 240MHz dual core, 600 DMIPS, 520KB SRAM, Wi-Fi, dual mode Bluetooth
Flash 16MB
Input Voltage 5V @ 500mA
Interface TypeC x 1, GROVE(I2C+I/0+UART) x 1
IPS LCD Screen 2.0" @ 320 x 240 ILI9342C
Touch Screen FT6336U
Speaker amplifier NS4168
LED Green power indicator light
Button Power button, RST button, Virtual screen button * 3
Vibration reminder Vibration motor
I2S Power Amplifier NS4168
6-axis IMU MPU6886
RTC BM8563
USB Chip CP2104/CH9102F (two chip versions, there is no difference in function and use)
DC-DC Boost SY7088
TF card slot 16G Max
Lithium Battery 390mAh @ 3.7V
Antenna 2.4G 3D antenna
Operating temperature 0°C to 60°C
Base screw specifications Hexagon socket countersunk head M3
Net Weight 52g
Gross Weight 70g
Product Size 54 x 54 x 16mm
Package Size 75 x 60 x 20mm
Case Material Plastic (PC)
The M5 Stack Core 2 internals

Now we’re getting somewhere. Of course this won’t be running Linux anytime soon, but I believe this is something we can potentially work around.

Minimum Software Requirements

I’ve quite enjoyed working on the ytoff project - and I believe I understand why this was. I worked quickly to produce a minimal viable product (MVP) and was able to create a feedback cycle into the concept very quickly. This is something I want to carry over into this project also.

Looking at the main repository, there appear to be a series of projects already implemented. Looking at the documentation, this device has some nice functionality out of the box.

User Interface

It appears we can leverage the LCD API to draw graphics. But, this would only offer very basic capabilities.

We could also leverage the LVGL library, that appears to already somewhat support the display. This gives layout, keyboard, Unicode, scalable fonts, languages, etc. This is by far the easiest entry towards getting something operational as quickly as possible. There’s a good chance the ILI9342C 320 x 240 display is supported out of the box too. The example code even looks pretty simple.

Using such a library would allow us to get operational as quickly as possible and proving out the hardware. Designing our own UI library will be extremely time intensive and is unlikely to yield a better result. There is also the possibility of writing apps that work cross-platform (i.e. on a desktop) through their simulator.


Why? I want people to be able to write different applications for the PDA and not crash the entire device. I also want to be able to have data syncing between Linux and the PDA (i.e. a shared RSS feed), being able to run the exact same binary across multiple architectures.

A while back I worked on multi-tasking project for Elk which turned out to be incredibly simple. Looking at the code, there wasn’t even too much going on under the hood. As a result, I am actively working on a project for a custom VM 3, where I will look to implement a small 8086 VM that can bind to C. Why 8086? It’s a relatively simple and well-known architecture, it’s fast and many tools exist to compile for it.

Another option that I am seriously considering in the meantime is to implement Wasm3, which appears to already support the ESP32 out of the box. The requirements of Wasm3 appears to be:

Minimum useful system requirements: ~64Kb for code and ~10Kb RAM

It’s a little high, but not so bad. We can afford it within the RAM we have. It also offers a feasible path for running the exact same Wasm application on the PDA and computer, cross-platform (in many senses).


Previously in part 1 I was discussing which apps would be nice to have. Here I want to get a very basic initial list of apps that makes this device immediately useful.


For the basic device, we will want to be able to configure a few things:

  • WiFi - We will of course want to list possible WiFi connections and have the ability to connect to them. Depending on the authentication process, we may also need to type in passwords, etc.
  • Power - To save power, we may want to auto-sleep the display, or set the brightness (if possible). We may also want some configuration to switch off device functionality when not in use (like the WiFi), or switch off the device entirely.
  • Time/Date - We will want to be able to set the time and date of the device.
  • Debug - We will likely want to adjust a series of other parameters, especially for the purpose of debugging. We may want to toggle some debug console overlay for example to readout interesting information.

Having a device that can perform calculations is already something interesting, especially if it can handle more complex mathematics. We should be able to find a library that is able to parse and handle complex mathematics on embedded devices. If not, it wouldn’t be so difficult to implement a basic version, as seen with gnome-calculator for example.

Gnome calculator example

This would be for the core HTML support only, no CSS or JS. Given the simplicity of the goal, it should be possible to implement a single parse HTML library as we will not be handling dynamic layout. This would allow us to browser all simple text based websites, including search engines and even Wikipedia. In theory, one could even operate dead social!

LVGL doesn’t support creating a browser out of the box, so this will represent a significant developer effort. Fortunately, LVGL does support scrolling relatively easily. We will likely be aiming for something simplified and text-based like lynx initially. We will need to be careful about the size of the content we are rendering also.

The reason for wanting to implement this is that the feed reader will need to also be able to open a browser to read content - or at the very least there will be a large amount of functionality overlap.

Feed Reader

The next step would be a feed reader. I have discussed wanting to write one of these before as I’m not happy about any of them that currently exist. This will of course be focussed on lightweight usage.

Some requirements are as follows:

  1. Database - A simple database that is operational on both embedded and non-embedded devices, that also scales well. It will need to be well designed in order to operate well on both scales.
  2. Syncing - I want to be able to sync across devices - the PDA is not saving me time if I then have to re-read content I’ve already read.
  3. Display media externally - The feed reader will not be responsible (or capable) of displaying media, and will therefore display it in another suitable application (as defined by the user). Initially we will send all HTML content (the majority of RSS feeds) to the browser.

Going Forwards

I’m pretty sold on the potential of this device, it appears to be of a decent form factor and has lots of software support. There appears to be sufficient existing libraries out there that a person could make a very good head start on creating something operational!

I think the next step now is to actually buy one!

Final battle from The Matrix

  1. The reason for changing the words used is to make the Unix Philosophy more applicable to other areas.↩︎

  2. Note that I purposely watered down the language here regarding the requirement for Linux↩︎

  3. Note that the article is unpublished at the time of writing this article.↩︎