Arduino Tamagotchi – Part 2

This post details the final implementation of my Arduino Tamagochi as introduced in my previous post.

The aim of this project was to create a ‘Tamagochi like’ pocket friend based on the Arduino platform for a friend for her birthday, with the intention of making the creature inside the device, her. I will not delve into intimate detail of the construction and programming, but I will step through the overall build, and share the final result.

After receiving my enclosure from a friend, I was initially somewhat disappointed with the result. It was printed in PLA instead of my desired ABS, and exhibited signs of pitting; the back piece was also warped. Although hesitant, I took his advice on painting the enclosure which actually came up really well – far exceeding my expectations. If this was to have been ABS without imperfections I would have likely done minimal surface preparation and retained the 3D printed charm.


I primed the print initially with British Paints ‘Prep 4 in 1’ which was a poor choice for this application. It was easy to apply, and absorbed imperfections with ease, however it was soft once dry and not pleasant to sand. After realising this I immediately moved to spraying and sanding the enclosure with Dulux Duramax, and sanding after each layer had dried. Duramax is easily the most pleasant spray paint experience I have ever had; the result was not tacky like I expected, hard wearing, and dried really quickly with great adhesion. Although the coats where noticeably thinner by a large order of magnitude, after approximately 8 rounds of application and sanding the defects of printing become invisible and the finish began to look really beautiful and more like a nice plastic than painted surface. Using a paint of this quality has changed my perception of using canned spray paints.


The buttons where a little painful to install, however I anticipated this might be the case. I pressed in a spare tactile push button (with more force than I would apply to a button I intend to use) a few times to wear the enclosure sides down. It was a little tricky to keep the button head aligned with the enclosure hole as it descended the square shaft, but I was able to stabilise the opposing side using the rear of a drill bit of suitable size. Eventually the buttons would slide in and out of place with minimal effort, and no damage. I soldered fine wires to the rear of these buttons, daisy chaining them with a common endpoint and securely potting with hot glue and levelling off. The channels which I cut into the enclosure’s model worked well for managing the wires, and the dimensions printed suited the wire gauge used. If I was to do this again however I would use a finer gauge wire to make internal routing easier, or just bite the bullet and print a PCB.

I tested the input immediately after installing all buttons because with the hot glue and fitted shafts I would expect these to be tedious to remove. This yielded positive results and I moved on to the screen and microcontroller.


I performed a final test on the screen and re-secured the display on its breakout board before installing and temporarily securing with hot glue. I then prepared the Arduino Nano by removing all the header pins, LED circuitry, and filling the through holes with solder. Once complete I fixed this on top of the display board with a good quality double sided tape; thick enough to absorb the components dimensions and allow everything to sit parallel and neatly. I hastily mocked up the screens connections and tested the display again to ensure it was not exhibiting signs of insubordination.

The speaker was next, and this was something that I hadn’t prototyped at all. I connected this via a 100 ohm resistor to the Arduino and ran the Tutorial code proving everything worked, although the sounds where horrible. Luckily this was easy to fix in the implementation.

With all the user experience parts in place, I set about removing all the mocked up wiring and replacing with more attentive detailed work, and careful routing. I spent quite a lot of time getting this right, with the body firmly fastened in a vice, protected by an ugly rag which I can only assume was once someone’s much loved frog pyjamas. I used SMD resistors, FETs, and Capacitors where needed to implement pull-up/down practices, switch the display and backlight on and off from the micro to reduce power consumption, and manage power generally. There was a few engineering challenges to overcome with respect to power consumption and prolonging battery life using out of the box hardware, but it was more or less straight foreword to construe a solution by carefully selecting switching components and using interrupts and sleep on the Arduino.

I was really happy with how the final result was taking form however installing the rear panel proved to be my downfall.

After connecting the batteries, installing the plastic safety tab I had macgyvered from a plastic bottle, and testing the power switching components, I attempted to install the back cover. Despite the distortion, with a little pressure the parts aligned and it was easy to install the 4 screws. Unfortunately the pressure from the warped rear was enough to strip two of the screws threads as the printed case gave way. I have done this sort of thing without issue using ABS on my own printer, and believe it happened due to a combination of the material used, and the print settings applied limiting wall thicknesses and infill.

I decided to glue everything closed, as given its use the likelihood of wanting to replace batteries would be pretty low, there is a USB mini port for power, and realistically I could manufacture another and reuse expensive parts with minimal effort. The gluing was successful using epoxy. Unfortunately the clamps I used (despite my best efforts) damaged the enclosure where pressure was applied. Again, I believe this is due to the fill settings when the model was prepared for print. Irrespective, the results are still pleasing. I attempted to touch up the damage, carefully rewording the housing in situ.

With regards to the software, I overhauled my content compiling system to accept midi files, and it now produces a series of resource files with a references header file to permit name references and readability in the main program. I incorporated a sound player into the game loop which allowed tracks to be enqueued for play, queues to be swapped or cleared, and simplified dealing with sound overall. I didn’t quite get as far as full text support or better image support, but given the amount of interest I have received in this project, I speculate that avoiding doing so will be impossible.


The final sketch had a smaller than expected footprint, and relied on minimal library functions. The device allows the user to play rock paper scissors with the device, feed it an assortment of foods, and give it coffee. Pressing the middle button on the home screen changed states to show the birthday messages and resume normal operation when subsequently pressed. The creature increases in happiness as it wins games and gets what it wants. Repetitive losses, and undesired feedings sadden her. She also gets tired and enjoys her sleep.

I have been hesitant to share code and designs for this at present due to the amount of work I have invested, and the devices purpose. I have spent many hours designing, manufacturing, developing, writing tools, and testing this device for a really special friend. Since this is a gift, I don’t feel that it would be right to immediately share my work.

As mentioned above, I have received a lot of interest and support for this from friends who have seen it in various states of construction, and if I was to continue this project I would likely make a utility to generate software entirely rather than just content, with a simple user interface and storyboard. I would also expand the feature set a little more creatively. It has overall been a really fun project. I have learned a lot I wouldn’t have otherwise thought to investigate regarding the implementation of the Arduino platform, discovered a painting method which produces pleasing results, explored the composition of Midi files, and I have a deeper understanding of the XNA content pipeline which I investigated when looking for inspiration for my content compiler.



Arduino Tamagotchi – Part 1

This is the first of two posts detailing the build of my current project – an Arduino based Tamagotchi.

Late last year, whilst discussing trivial everydaynesses with my dear friend Tina over pancakes, I learned of how she never owned a Tamagotchi in her childhood. Later that night I arrived at the idea of making her one of herself for her upcoming birthday. I hastily ordered all the long lead-time components and awaited them in the mail. Unfortunately her birthday passed, and the screen had still not arrived. Last Friday (some 5 months later) my order of screens arrived out of the blue, and I devoted the bulk of this weekend to creating an awesome birthday present!

In principle the build is pretty simple:

  • Arduino Nano
  • Nokia 3310/5110 Screen
  • Piezo Speaker
  • 2x 20mm Batteries
  • 5x 6mm Tactile Buttons

There will be a number of resisters required to reduce the voltage to the screen to a safe level and pull up/down the buttons. I will likely also introduce simple switching on the screen and backlight to reduce power consumption when the micro is sleeping.

I spent the bulk of Friday night measuring all my components and drawing them in Solidworks meticulously; then permitting the design of a simple enclosure. The final result still hasn’t quite grown on me yet. It’s a little big in all the wrong places. I feel its current state is as compact as it can be however without designing a custom circuit board, whilst looking somewhat proportional, and being safe to print with confidence.

Projects - Tamagotchi 02 Projects - Tamagotchi 03 Projects - Tamagotchi 01

All going well, the printed parts should arrive this week (from a friend and his Robox), and allow me to test the overall assembly and ‘prototype’ the hardware ;). In the meantime I have persevered with just connecting the screen and evaluating the requirements of controlling output. I initially took to googling, and came across Kyle Kuepker’s blog, which allowed me to hit the ground running, however I quickly hit a few interesting walls in doing so.

Firstly, the method used to store bitmaps was not sustainable. All data was being stored in global static char arrays which leads to rapid consumption of the 2 kilobytes of memory available on the Arduino Nano (each bitmap is approximately 504 bytes). I tried a number of agricultural ways around this, but eventually discovered the PROGMEM keyword, which ensures data is stored in only Program Memory. A special function must also be used to recall these values; note that the compiler will not Warn or Error on the inappropriate use of PROGMEM when recalling data.

// Declare Array
const PROGMEM byte MyArray[] = { ... };

// Use
byte tmp = pgm_read_byte_near(myArray + i);

The second major hurtle I encountered was the way in which data is written to the display. In accordance with page 8 of the datasheet, information is written in columns 8 pixels high, from left to right, top to bottom, with the msb being the lowest pixel of that column. Once this was identified after seemingly hours of confusion, I was able to make a content compiler to run as a prebuild step in C# to take any Bitmap image, resize it to suit the display, and generate an ino file out into the Arduino project with all the necessary data. I will likely rework this however.

The majority of this functionality stemmed from either dealing with the Bitmap, or File/Directory operations, and is pretty simple overall. (Highlights Below, yes, that’s all…)

// Read a pixel
Color pixel = resized.GetPixel(x, y);

// Note that to compare colours, they should first be converted
if (pixel.ToArgb() != Color.White.ToArgb()) ... ;

The last major issue I encountered was with the displays construction. During use the display contrast would walk, sometimes the image would disappear completely or skew, and other times bytes would get lost. I assumed this was due to the contact between the screen and the PCB, which later proved to be the case. After folding the screens mounting tabs in tighter, the issue was resolved for a while, but when it reoccurred I found the solution was to push the display on the PCB side to side and up/down until it stabilised, and solder the securing tabs in place. In the final build I may remove this PCB and attach directly to the screen if it continues to cause issue.

Like all Arduino projects I undertake, I used Visual Micro to manage everything – and I can’t recommend this enough. I did encounter a draw back this evening when trying to include custom build steps adding multiple (non-arduino) projects to the solution. This didn’t result in the expected outcome, but realistically is only a minor set back.

Projects - Tamagotchi 04 Projects - Tamagotchi 05 Projects - Tamagotchi 06 Projects - Tamagotchi 07

A tool I recently discovered is Aseprite. When it comes to working with images, everyone I know recommends either the Adobe suite, or Paint.Net, usually depending on their background. Whilst I do have a Creative Cloud account, I am not proficient enough with Adobe products to get a to-the-pixel image confidently. on the other hand isn’t really a contender in my opinion as it falls too short of higher end products, and is clumsier (and uglier) than lower end products. Even when I didn’t have a Creative Cloud account I would preference doing without, and using Inkscape for vector work. As far as bitmaps are concerned, I usually get away with using mspaint and I am reasonably quick and proficient, but I found drawing these sprites somewhat hard on my small high resolution screen as I couldn’t zoom in far enough (mspaint stops at 800%) to work at a comfortable pace. Aseprite was the perfect tool for the job, and I am in no way disappointed with the requested donation for a licence. It is attractive, promotes workflow, and is specifically focused at pixel art, with active developers.

I will add Part 2 when the project nears completion, and exhibit the final result.