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 - 619.87 kB - 02/04/2019 at 20:29


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

Zip Archive - 125.62 kB - 02/04/2019 at 20:27


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.64 kB - 02/04/2019 at 20:27


  • 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

  • Final log?

    brtnst01/22/2020 at 18:37 0 comments

    It's two years after I presented my PDA here on hackaday and it's about two and a half years since I started carrying and using some version of SDA every day. I am really happy with it, the hardware is holding up better than I expected and I tweak the software a bit from time to time.

    I don't think that the SDA is finished, it's a hobby project (and by far my greatest hobby project) and projects like these are never truly finished, but I don't think there will be many new things about SDA in the future.

    If you want to build your own, or if you have any sort of question, you can contact me here.

  • Few new bits and bobs

    brtnst02/08/2019 at 17:30 0 comments

    I don't spend too much time on the development of the SDA, because it now does more or less what I wanted it to do. Last year I moved from messy red prototype to more refined "SDA mk.2". This new hardware platform meets most of the goals that I gave myself in this post and I am very happy with it. I already did one video on how it's soldered and another on the final assembly.

    Messy mess of wires vs. the tidy new PCB

    DFPlayer again

    One of the great things on the mk2 SDA is its internal expansion slot, so in next iteration of the DFPlayer extension I connected it internally and the module is now part of the back enclosure. It looks very neatly from the outside and the external expansion port can be used for other things. Inside the SDA is now enough space for similar add-ons that could be connected to the internal header and if more space is needed, one can get the FreeCAD files and redesign the back part of the enclosure. I really like this kind of hackability and expandability.

    With MP3 player as an internal expansion.

    Software upgrades

    For the past two weeks I was working on the SDA OS. I was addressing some of the minor issues like messy applications folder and no way to define state of expansion pins after boot. This will be fixed in version 0.7.2 wich will also introduce new default image format. I was using binary ppm for the system icons and other images.

    It is easy to parse and gimp can generate it easily, but the resulting image is quite big and it takes too much time to read it from the SD card. I looked for some compressed image format, but didn't find anything useful, so I went the custom way. My new image format is just as simple as binary PPM, but uses only 16bit color depth instead of 24bit, SDA works with 16bit color anyway, and this saves about 1/3 of the file size. Also all the graphics used in the SDA_OS has big portions of the images filled with same-colored pixels, so I went with really simple compression scheme, that works rather well on most of the images used (about 1/7 compression ratio). It is rather stupid and can generate compressed image larger than uncompressed, but it will never be larger than the same image stored as PPM, so that's good. (It supports compressed and uncompressed mode, so in a case of bad compression ratio, I will just disable compression)

    Images: uncompressed vs. compressed a little

    The web simulator got new looks

    I worked a bit on the simulator and it now looks more like an actual SDA. It still does not work flawlessly in the browser, but the errors are bit strange and I don't know how to fix them. It looks like compiler optimizations throwing code away, but turning the optimizations off doesn't help, setting things volatile doesn't help, printf the missing data miraculously helps, but it's stupid... Also SDA_OS works reliably with -O3 enabled on the stm32 and native linux, so it should also work on the web. I am really out of ideas here. If you had and fixed similar problems with emcc, please let me know.

    Simulator now looks like this.

  • SDA Assembly

    brtnst01/18/2019 at 14:10 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 on a PC with some distribution of GNU/Linux. Browser based simulator is also based on this code.

    SDA_OS Wonder base

    Sources for the SDA_OS base for SDA mk. 2.

    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.

    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.

View all 18 project logs

Enjoy this project?



Jacob MacLeod wrote 10/06/2019 at 11:04 point


  Are you sure? yes | no

Andrei wrote 05/13/2019 at 10:32 point

Once I had an idea of making my own phone, but it looked too complicated. good that you have decided differently!

I suppose screen is a biggest power consumer. assuming this screen update speed - maybe you would like to consider using e-ink screen instead?  this will allow you to add some more options like GSM, wifi, BT, etc and still have quite good battery life time. 

I would like to help you with that, but i am currently working on my gps navigation system which takes too much time :(

  Are you sure? yes | no

brtnst wrote 03/27/2021 at 00:17 point

E-inks are interesting, but there doesn't seem to be a supply of nicely sized, touch enabled ones. The LCD consumes a lot of power, but it is turned off most of the time, the stand-by current of the device is the biggest problem in the long run.  (Around 8mA, which gives about four days of stand-by, this could definitely be improved in software, but I don't have the time for it and I am quite happy with the three or so days of standby.)
Features of any handheld are a thing of a personal taste. I don't see much to gain with wifi (too little processing power to do anything useful...) or bluetooth (use the device as accessory for a phone, maybe, but why use it instead of a phone...). GSM is a nice idea, I already have a SIM800 module, so I might take it the smartphone way.
Thank you for the offer of help, if you are familiar with power management on the STM32f4 platform, I am one big ear.
Also I am sorry for a two year late reply, but I don't come here very often.

  Are you sure? yes | no

Boris Bobylev wrote 05/12/2019 at 18:55 point

I would buy one even in the form in which it is

  Are you sure? yes | no

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

Christian W. 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

Christian W. wrote 01/26/2018 at 05:19 point

Thanks! I look forward to it.

  Are you sure? yes | no

Wenting Zhang 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