SDA - The best new PDA

Do you miss those old small devices in your palm? Don't be sad, you can always build your own!

Similar projects worth following
I want my PDA to be pocket-size open-source hardware platform, with similar capabilities to the third-gen Palm devices (Palm IIIc, Handspring Visor).

SDA (in its current form) is powered by STM32f4 micro controller and it runs custom OS. It can load applications from SD card, using custom scripting language. SDA can be used to take notes, view calendar, make to-do lists, read e-books and it also can play some games. You can try the software in a web based simulator. The device can be left in standby for about five days or it can be used for more than six hours on 60% backlight.

Used 3rd party software is MIT and BSD-style licensed, all custom software for SDA is MIT licensed. You can get the full software and hardware sources on GitHub.


About a year ago I bought an used Palm IIIc and I felt in love with that small device. It was quick, simple, reliable and worked for at least a week on one charge. It can't do much, but what it does, it does well, also it's not connected to the internet, so you can do stuff in distraction free environment. It was a really new and fresh user experience in the world of smartphones. But using a fifteen year old device have few shortcomings:

  1. software is hard to get
  2. hardware is hard to get
  3. it is closed-source, the platform is dead and it's hard to develop new apps fot it
  4. (also my first language is a one with some funny letters in its alphabet and Palm don't support those)

Solution for these problems is obviously to throw this old PDA in a bin and use a modern smartphone, but this is hackaday, and l decided to build myself a fully custom PDA.

About the device

I aimed for easy way to create new applications for my PDA and also better compatibility with new tech than the Palm could provide. After more than two years of development (described bellow) I ended up with a reasonable replacement of my old Palm. Well, it doesn't do everything the Palm can do, but fixing something on Palm is nearly to impossible. With my own PDA I can fix its shortcomings easily.

Do you want to try the SDA_OS yourself? Check out the new in-browser simulator!

A bit of history

Prototype 1

I started with a nucleo board with STM32f103 MCU and a cheap Chinese resistive touch display.

On this crude prototype I developed simple library for user interface with buttons, text input and software keyboard. I wanted to be able to update my applications  without re-flashing the firmware, so I developed small interpreter of simple script language and used FatFs library from ChaN to read scripts from the SD card. From here it was just a little step to move the graphics library and script interpreter from STM32 to x86 and make emulator for pc to test and debug the applications before moving them on the real hardware.

This worked reasonably well and I used it for a few school projects, but it was not portable at all, which leaded to the second prototype.

Prototype 2

I had plans to make a PCB and make it all nice and shiny and small and fit it in some small case, so I draw the schematics and ordered most of the parts. Then life happened and I did'n have enough time to finish the layout (also I hate designing PCB's).

Later I realised that I don't really need a PCB that much, I had all the parts and I also had an universal QFP PCB so I could just cobble it together. So I did exactly that. MCU got upgraded  to STM32F405RGT6 and I also used some LDO regulator and old USB powerbank to power the thing. And the SDA was born. Buttons and soft power switch was added later, the device also includes small speaker.

Then I fitted it in a small cardboard box and here it was, didn't looked much, but I was able to fit it in my pocket and use it.

I didn't know if the device would be of any use, but I ended up with a few simple applications like calculator, calendar, alarm clock, to-do list, notepad, "e-book" reader (it just reads really long text files) and minesweeper. The SDA was a nice toy to carry around and I decided to make it more aesthetically pleasing and more durable.

Prototype 3

I was again hoping to design PCB and again didn't do it.  So it is basically the second prototype, but made more tightly so it fits the new printed case, inside it's still mess of loose wires and hot-glue. But on the outside it looks much better. I did not have to disassemble the previous one, because I bought...

Read more »


First revision SDA schematics, check out SDA HW GitHub repo for full sources, updates and known bugs.

Adobe Portable Document Format - 245.33 kB - 10/31/2018 at 21:26


Manufacturing resources for main board, check out SDA HW GitHub repo for full sources, updates and known bugs.

Zip Archive - 119.68 kB - 10/31/2018 at 21:24


Manufacturing resources for LCD connector board, check out SDA HW GitHub repo for full sources and/or updates.

Zip Archive - 9.78 kB - 10/31/2018 at 21:24


STL files for the case, check out SDA HW GitHub repo for full sources and/or updates.

Zip Archive - 170.93 kB - 10/31/2018 at 21:23


  • 1 × Main PCB Sources and gerber files will be available on GitHub.
  • 1 × Display connector PCB Sources and gerber files will be available on GitHub.
  • 1 × Pin header 2x8 1.27mm pitch
  • 1 × Pin header 1x6 2.54mm pitch female
  • 2 × 47u 1210

View all 51 components

  • SDA Assembly

    brtnst5 days ago 0 comments

    In the previous video I shown how to assemble and verify operation of the PCB. In this next video I will fix some details on the PCB and show how the SDA is assembled.

    I did previously show some pictures of the parts for the new SDA, now you can see how it fits together. There are few quirks to the assembly, mostly because of imperfect 3D prints. But overall the assembly is quite simple and it can be also easily disassembled for modding or service, which is one of its main features.

  • Becoming a web developer, SDA in a browser

    brtnst11/26/2018 at 21:11 0 comments

    For a long time I was looking at all the cool web interfaces that (nearly) all the new hardware projects have. The idea of having an IDE inside a web page is great for people who want to just try to code or drag-n-drop together simple program without the need to get any software installed on their system.

    When I saw the Dodo playground for the Dodo: 6502 Game System here on hackaday, I knew that I have to create something similar for the SDA.

    How to do it

    First thing is to have a simulator running in a browser. I could like rewrite the SVS language interpreter and rest of the SDA_OS in javascript, but that would mean maintaining two codebases and I can imagine that the compatibility would bee poor. 

    Instead of it, I went with Emscripten, which is basically a compiler that makes C or C++ code run in a modern web browser (using javascript, webassembly and black magic I imagine). The best thing is that it already supports SDL2 and in theory I can just compile the existing SDA_OS linux port and be ready to go.

    SDA simulator in a browser

    First thing I did was to set up the emscripten using their documentation, I ran the helloword and it hellowed the world, that is always a good sign. Next I tried to compile the SVS interpreter, with some changes so that it would execute all its poor self-tests. Emscripten also emulates filesystem for your app and you can pack all the needed files in the web-enabled "executable", so I packed the self-tests with the SVS binary and it worked, so far so good.

    Then I tried to compile the SDA_OS and I ran out of beginners luck. It was crashing the browser tab. Solution was relatively simple, SDL programs are usualy running in a infinite loop, but you can not have this kind of loop inside browser. Emscripten will help you with this, look for emscripten_set_main_loop in their docs. So after some minor changes I ended up with a running SDA_OS in a browser. But It was running at something like 0.5 frames per second.

    It turned out that SDL_RenderDrawPoint, function that I used to draw everything is somewhat slow in emscripten. In the SDA_OS SDL base I have internal framebuffer that emulates the ili-like LCD, so the rest of the graphics stack can remain the same. This framebuffer was redrawn with the slow sdl function. After some attempts to make redrawing quicker I ended up using a texture, this texture is filled from the LCD framebuffer and then drawn on the SDL renderer, this is much quicker both on the web and on the PC.

    So now I have a mostly working SDA_OS simulator for your web browser. It still has some problems, just refresh the page in case of errors. (also you need to have a mouse, on touch devices it loads, but ignores touch input)

    You can try it here: SDA_OS Simulator

    As you can see, it is work in progress, but now I am much closer to some sort of web IDE for the SDA. At least I now have a simulator that anyone can run.

    In the future I will add something like a code window and a big red run button to run the new code in the simulator.

    And again, sources are available on

  • Soldering the PCBs

    brtnst11/23/2018 at 14:24 0 comments

    I got the second board revision made and I already soldered and tested it. I made a video of the process. It is really long and boring, because it is meant more like a video tutorial for anyone interested in building the SDA. I go through the tools needed for the job, I do some basic debugging of the board and I finish it with a working board for the new SDA.

  • ​ SDA Mk.2 goes Open Source

    brtnst10/30/2018 at 13:53 0 comments

    The PCB is fixed

    I fixed the PCB layout from the previous post, it seems to work well enough.

     Board revisions
    Red is the old one, green is the new one.

    What is tested and working:

    • LCD + Touch
    • SDIO connceted SD card
    • Power + charging
    • Speaker
    • Buttons
    • Onboard FTDI

    Not tested:

    • Internal and external expansion ports.

    Known bugs:

    Vcc is used as voltage reference, so when the battery goes under 3.3V it measures battery voltage incorrectly. The device works until about 2.7 V (battery voltage) and then it became a bit buggy and occasionally crashes filesystem on the SD card. If you keep the device charged, then you don't experience these bugs, but I wil be fixing them in a next board revision anyway.

    Known bugs will be posted or removed from readme file in the hw repo.

    Where to get the KiCad files & gerbers?
    On the SDA Hardware GitHub

    Update on the case

    I also updated the case and printed it in black (I run out of red filament). You can get the .stl files and the FreeCAD project on the SDA Hardware GitHub.

    The SDA, now without hotglue.

  • SDA has its boards

    brtnst10/12/2018 at 16:56 0 comments

      The new hardware is here! SDA is now officially a big boy project with it's own printed circuit boards! I got the PCBs from dirtyPCBs and they look just fine.

      PCBs were designed in KiCad, I was working on them for a long time, so they mostly work. Mechanically it is a good fit in the case, but there still are some PCB bugs and I will go through them.

      I am using two boards soldered together (kinda like iPhone X :D ). I went with this type of construction for two reasons:

      1. Volatility of the display market. Chinese sellers will eventually run out
        of the right type of display with the right flex cable. If the display connector was on the board itself, it would be cleaner and neater, but I would need to re-design whole board for every type of display connection.
      2. I wanted all SMT components to be on one side of the board. This way I can do that without the need of big hole in the middle of the board.

      This stacked PCB solution complicates the final assembly for a bit, but I think that its manageable.

      PCB Bugs

      Here are few of the mistakes I made on the first version of the PCB.

      ADC Vref

      Do not forget to connect voltage reference pin to some voltage. I will read the datasheet properly next time. It was actualy easy fix on the prototype PCB, I soldered the Vref pin on the mcu to the analog voltage source pin that is right next to it.

      Missing via

      I am still learning with KiCad DRC, short bodgewire fixed that.

      SDIO is not SPI

      The SDIO bus turned out to be quite different from the SPI. SDIO is the bus for quick communication with the SD card and it has its specifications that I did not read and so the SDIO is not working on the current PCB. Firstly my schematics was wrong (missing pull up and termination resistors) and I routed the SDIO traces carelessly over the board. I bodgewired it to the point where reads from the card were working about 20% of the times, that was not acceptable. I ended up rewiring the SD slot to use SPI for testing and I will be fixing it in the next board revision.

      What now?

      I got the hardware working in the end and that is what counts. I written drivers and base functions for SDA_OS to run on the new PDA and I will be using it for some time to test it. After the testing I will do second revision and if that works I will opensource the design.

  • Another boring SW log

    brtnst10/09/2018 at 20:16 0 comments

    While I was waiting on the PCBs for the new HW, I focused my attention to SDA software stack. I think that the code has matured enough to put most of it on github. The code is split to multiple repositories, I don't know if it is the best solution, but it is a solution for now. Currently you can build SDA_OS simulator and run (or develop) applications in this simulator.

    This log is written in a way that you maybe could try to clone, compile, run and develop apps for the SDA_OS, but reality is that you will most likely find out that it is broken in some way and get frustrated. I am the only developer and user for about a two years and I am walking around bugs and bad architectural decisions all the time. Do not expect a good experience.

    SDA Repos on github

    There are separate repos for each part of the software stack.

    SVS Script
    SVS can be used separately, so it makes sense to have it separate.

    The graphical and GUI library for SDA_OS. It was previously used in my other projects, so it is in a separate repo. It is written to be more or less platform independent it needs external functions to draw on the physical screen.

    This repository contains most of the SDA_OS code, the API for most of the functions and SDA_OS specific extensions to the SVS. This part is platform independent, it also needs external functions to handle the touch input and the filesystem.

    SDA Applications
    Default applications for SDA_OS, they are platform independent and run on top of SDA_OS.

    SDA_OS SDL2 base
    This provides all the functions to run SDA_OS and its graphical library on a PC with some distribution of GNU/Linux.

    Why is it this way

    I set it up in a way that you clone the base repo from git and all other system things are in this repo as submodules. You can build the SDA_OS base to get the executable. Applications directory is in gitignore, so you can separately clone the app repo as APPS directory or you can create it empty and fill it with your own apps. I do not know if specific version of applications for SDA will be dependent on a specific version of the base, so it is not a submodule for now.

    When I will have the new SDA hardware working, I will add another base, that will allow me to compile version of SDA_OS for the new device, while sharing most of the code with rest of the versions.

    Edit: While I was debugging the new main board for new SDA, I found out that building SDA_OS from scratch is not super simple, so I will simplify the process with something like make it-working option in the makefile, that will rename all .example files and do all other boring stuff.

  • Hacking the DF-Player Mini

    brtnst09/15/2018 at 19:50 0 comments

    Since I am still waiting for the PCBs for the new SDA, I turned my attention to the DFPlayer mini module.
    I use it almost daily to listen music from my PDA and it needed some improvements.

    Into the DFPlayer

    File names

    If you used DFPlayer, you know that the filenames of sound files must be named "001.mp3" "002.mp3" and so on, then copied to the SD card and then you can play them by their number.
    One would think that the DFPlayer reads the file names but that is not true. When you copy mp3 files with any name, it will still happily play them, but you do not know the order. Truth is, that you need to rename the files, so they got copied in the right order, because DFPlayer does not read the names, it simply lists the directory. And if you do directory listing, you get files in the order filesystem throws them at you. You can do this with a simple shell command:

     find . -maxdepth 1 -name '*.mp3'

    Now I can index the files in the order the DFPlayer will read them and store the index in my PDA. With the index, I can view the file names and play the songs on demand.

    Playback status

    There is still a problem, that I don't know when the DFPlayer stopped its playback. Option one is to read the "busy" pin on the player, but I am out of pins in my expansion port. Second option is to send some message to the player that will give me its status. That is nice, but serial receive API on my PDA is still a bit wonky. Third option is to index duration of the mp3 files when indexing the file names. Then the PDA can wait for the song to stop playing and send command to play next song, while updating the "currently played" information.

    I ended up with this:
    It lists the files, creates command queue with AWK, pipes it to bash and outputs it to my database file. In the future I can also read and index id3 tags this way.

    find . -maxdepth 1 -name '*.mp3' \
    | awk 'BEGIN{ a=0 }{ printf "echo \"%d=%s\" & mp3info -p \"%d_len=%%S\\n\" \"%s\" \n", a, substr($0,3),a, substr($0,3), a++ }' \
    | bash > mp3-list.dat

    Random playback

    Last thing that is a bit weird on the DFPlayer is its random playback feature. It is too much random. Imagine you have thirty songs, when the player is choosing what song to play, it does something like play_song(random() % 31). On the first glance this seem right, but fire up random number generator of your choice and try it. You end up repeating one song quite often and that's not what you want from random playback. You need at least to check for repetition and perform another random throw when it happens.

    This is the end result, the new player has smarter random playback, you can select the songs by their name (yes, they are still numbered in the screens, but it works with any name, trust me;) and it will show you the current song and position in the song.


    Index your SD Card if you want to step-up your DFPlayer game. It is simple and efficient.

  • Short update on the software

    brtnst09/09/2018 at 22:20 0 comments

    For the past half a year I was mostly working on the software. There are few new software features and the simplest way to show them was to make an update video.

    Task switching

    The largest new feature is task switching. It is only task switching and not multitasking, only one application is running at any given time. I made some modifications to the graphics library and the application runtime so the full state of a running application can be stored on the SD card. When tasks are switched, the currently running task is stored and the new task is launched or restored.

    New applications

    There are few new apps, most of them were described in previous logs (MP3 Player, GPS, snake), but there are also few new ones. SDA Commander is a simple file manager, it can browse folders, edit text files, show pictures and run executables (SVS scripts). I also met one of the design milestones and that is self-programmability of the PDA. It is not very usefull for now (it is limited to about 1kb of code), but as a proof-of concept it works. I had some problems typing in the video and that is mostly because I was looking on the PDA through the camera viewfinder.

    Also the overall system stability was improved, in the first video I had to reset the device at the start of each take to get consistent results. Here I just picked up the PDA, did the demo and everything worked without a glitch while the system was running for about fourteen days with four hours of screen on time.

    Since I am waiting for the PCBs to continue with the next design iteration of the hardware I am refactoring the code and writing some basic documentation for the SDA_OS github repo that will be up in a few weeks.

  • Short update on new hardware

    brtnst09/04/2018 at 22:16 3 comments

    I am still working on my PDA. I have some software updates, but I will make a separate video about that in the future.

    The main thing is that I am finally designing new version of the hardware.

    Main features of the new PDA:

    • It will have a fancy PCB.
    • The new 3D printed case will not need too much hand fitting after print.
    • It will all hold together with screws instead of hot glue and duct tape.
    • It will use BL-5C nokia battery.

    It looks very similar to the previous PDA, but I mostly redesigned the hardware from scratch. Software will be mostly the same. Now I am in the phase of verifying the design and I will open-source it after I will have a working prototype.

    The PCB is still work in progress,  All the SMD components are on one side, so they eventually can be placed by machine and soldered with reflow, the board will still need a bit of hand soldering and some fitting of a few THT components.

    On the photo is actually only the new case with a LCD, I do not have the PCBs to go inside, yet.

  • Addon Addendum

    brtnst07/03/2018 at 13:44 2 comments

    DFPlayer Mini module and the SDA

    I saw some projects that were using this module, so I also gave it a try. And the result?

    I'd buy that for a dollar!

    Basically DFPlayer Mini is the ESP 8266 of MP3 playback. It is MP3 player in one small module, it can play audio files (mp3, wav) from its SD card (or USB flash drive) directly to your headphones. Module can be controlled over its serial interface or directly with buttons. There are some limitations, like that the player needs specific file structure and file naming on the storage media and somewhat poor documentation. There are few arduino libraries for it and the protocol is simple.

    Getting it running

    After a bit of struggle with error code 04, that was not mentioned in a datasheet that I had, I googled a bit and found datasheet for the FN-M22P Embedded MP3 Audio Module which looks like it is using the same protocol as DFPlayer. Datasheet for FN-M22P actually mentions all error codes and is written in normal English. The only difference between the FN-M22P and DFPlayer I found is that the DFPlayer does not support commands without checksum (but I did not try everything).

    Hardware is held inside improved version of the addon case used in the GPS module. It is more sturdy and holds better on the PDA. Inside there is just the DFPlayer with its DAC pins connected to 3.5 jack. Its control app is written in 120 lines of SVS. It is quite limited in its functionality and it has no idea what is the state of the module. It is good for now but there is also space for some improvements.


    The DFPlayer just works enough to be usefull. You do not have much control over the playback, you can't read metadata from the songs or do anything with the files. In my case the sound quality is good but not great, there is always a quiet hiss that can be heard if you focus on it. It could come from power supply of my PDA, but I don't have the equipment to pinpoint source of that distortion.

View all 16 project logs

Enjoy this project?



prosto wrote 08/07/2018 at 08:58 point

palm? this is compatible to Haiku OS (beOS) ?

  Are you sure? yes | no

brtnst wrote 08/08/2018 at 18:30 point

It is not compatible with Haiku. My PDA is just inspired by Palm devices, it does not share any software or hardware features with them. It doesn't have enough horsepower to run any desktop OS. Also Haiku seems to run on x86 CPUs only.

  Are you sure? yes | no

Ondřej Petrlík wrote 01/25/2018 at 12:40 point

Good work/Dobrá práce!

  Are you sure? yes | no

Shree Kumar wrote 01/25/2018 at 04:46 point

Nicely done! This showed up on the hackaday front page.

Loved the way you've put everything together - electronics to 3D printing. 

  Are you sure? yes | no

CWC wrote 01/24/2018 at 21:08 point

Congratulations. It is a very creative way to tackle your project. I like the way how you present the project evolution. The concept of being able to develop applications on the device itself is a great one too. 

If you don't have any issues with sharing your sources and schematics, please let us take a look on your thinking process (for some reason I cannot download the SDA_OS.tar.gz file). It does not matter if you consider that your code is ugly. Code will evolve naturally in each iteration and maybe you will get some people interested in collaborate with the OS and the applications. 

Please keep posting. I would like to see how your PDA evolves.

  Are you sure? yes | no

brtnst wrote 01/24/2018 at 21:19 point

I actually uploaded the gz file and then deleted it later because I realized that I don't actually know what packages it needs for compilation. I will upload it again for those who want to look at it and I will put it on github with some documentation in a few days. Project schematics are actually in a worse shape than the source code, but I am also working on fixing that.

  Are you sure? yes | no

CWC wrote 01/26/2018 at 05:19 point

Thanks! I look forward to it.

  Are you sure? yes | no

Wenting Z. wrote 01/24/2018 at 18:12 point

It looks awesome!

  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