Doing fun stuff with digital picture frames

Introduction

You might have come across them, be it on one of those gadget stores or websites for a few dollars: Tiny 2 inch or larger mini photo digital photo frames with color TFT, a bit of memory and a USB port. When you plug them in to your computer, they'd show as a CDROM including the software to download pictures. That's it. Is it? No!

Quite a while ago, all kinds of people who like to take things apart, have been examining and modifying code on those beasts to (ab)use them for other purposes, for example as a miniature status display on their embedded PC or satellite receiver. Honestly, isn't this a more useful purpose than showing stamp sized pictures to your friends?

It has turned out that there were two categories of the so called cheap DPFs (digital picture frames): One family is using a 6502 compatible CPU (remember the Commodore 64?), some have a little 8051 compatible chip built in. The latter is the one best available these days, and the one, I'd like to focus on.

If you have read that far, you are probably one of those who would rather like to create instead of consume. So you'd like to play some more? Maybe you are just starting to learn about embedded development? Never mind. You'll learn how to get at the internals later below. First, let's go for the applications.

USB display software

To use various LCD screens as status display under Linux, a software called "lcd4linux" has been out for a while. It is again OpenSource, so you typically compile it yourself. By adding a bit of support against our "dpflib", it can speak to our modified DPFs and display status information like on the above picture.

How to compile lcd4linux will be shown below. You will need a patch from our software repository to get it to recognize the DPF.

Using the dpflib, you can also write your own programs that do simple bit blitting. If you want to use the DPF as a simple text terminal, you will have to modify the firmware. That's the keyword for getting into the depths of embedded programming.

The internals

The AX206 from Appotech that lives in this little thing is a CPU using the good old Intel 8051 instruction set. This chip is about 30 years old and still not dying, it's found in many derivatives and even as free implementation that can be run in FPGAs. The AX206 is obviously specifically designed for these little DPFs and it uses much less power than the original 8051 while being a lot faster.

Getting at documentation is a bit more difficult: The original documentation resource seems to have moved, but the full chip specifications are found here [1].

To give you a quick summary about the AX206:

• 3 kB SRAM on chip
• 4 kB bootloader and auxiliary functions (JPEG decoding)
• 8 channel 10 bit ADC
• 2 PWM outputs
• 35 GPIOs, configureable as I/O, some have multiplexed functionality
• USB 2.0 full speed interface
• UART, SPI

As you could guess, most of the GPIOs are actually hooked up to the TFT screen. Next question might be: Where is all the data stored? I didn't mention the storage memory yet: This is a serial (SPI) flash memory of 1 up to 4 MByte, depending on the DPF model. On the other hand, we have only 3kB for program memory, not enough for a tetris game plus graphics. Turns out though, that the tools provide us with some technique called "bank switching" to be able to run larger programs: most of the code is externalized to the flash, the internal SRAM effectively works like a cache and variable memory.

If you are a software developer, writing code for this unit might force you to think like 30 years ago, when one had to squeeze complex assembly code into 1k. Don't worry, it will not that bad, you will be able to use a C compiler.

The SDK

When the first examination started of these devices, there was no officially available SDK. However, there have been many free 8051 tools out there, allowing to create executable code for these DPFs. There just needed to be a trick found to get the code onto these devices while having no documentation.

The default firmware is capable of quite a few things, the most interesting being the fact that data can be written to the flash using some vendor specific commands. Also, the built-in boot loader (which can be entered by holding MENU and pressing the RESET button with a needle) has basic remote procedure calling functionality which allows to download a little executable and run it.

Using that method, either a binary RAM image (< 3k) or a rudimentary flash file system image can be loaded onto the DPF. So why don't we write our own software for it? Here's a list of the tools you would need:

1. The SDCC compiler (http://sdcc.sourceforge.net/)
2. The GNU compiler (GCC) to compile some tools
3. A Python interpreter
4. Optionally: The d52 disassembler
5. The dpf-ax SDK (https://sourceforge.net/projects/dpf-ax/)

With all free open source tools, you might be required to tinker a little. If you are used to that, you might already have Linux running on your machine and the above framework is like old cheese for you. If you are a Windows user, you might become happy with Cygwin. Note though: the dpf-ax SDK is mostly designed for Linux, which would be the preferred cross-development environment.

Getting started

So you have installed all the tools? Then you could check out the SDK by

svn co https://dpf-ax.svn.sourceforge.net/svnroot/dpf-ax/trunk dpf-ax

Enter the dpf-ax folder and run 'make'.

A few modules will be built, plus the firmware for a few frame types, if all goes well. The firmware for the AX201 is in the src/ subdirectory, if you only want to build this one, enter it and run 'make' there. You might also want to edit the Makefile and set the model type. What's that?

Well, now you will hear about a somewhat unpleasant fact: There are a large number of different implementations of these DPFs. The CPU is the same, but TFT screen and SPI flash vary. Most SPI flashes are compatible, whereas TFTs are not. Have a look at src/config.h, you will notice a number of DPFMODEL_xxxx #define statements.

Identifying your frame type is a bit of a pain. You will need a somewhat reliable source of DPFs, see [2].

If the building procedure completes, you will end up with a intel hex (IHX) and a binary (BIN) file, e.g. fw_white.bin. The BIN is a full flash image, whereas the IHX contains only the program without the bootstrap code. The BIN is the one that will go to flash. Before you start manipulating stuff on your DPF, let's backup your code first. This is currently supported under Linux only. Plug in your DPF and enter the menu. Choose "USB connect" and wait until the device registers as CDROM. Enter the fw/ directory and run the fulldump.py script by specifying the SCSI device of the DPF (you can search the kernel log with 'dmesg' for the plug event or use the 'df' command to see mounted devices). For example:

python fulldump.py /dev/sr0

After completion, you should have a binary file 'full.bin' in your directory. Store it in a safe place.

Links:

[1] http://openschemes.com/2011/08/23/our-turn-with-the-ax206-digital-photo-frames/2/

[2]

Sign in