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. Paint.net 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.

 

 

One thought on “Arduino Tamagotchi – Part 1”

Leave a Reply

Your email address will not be published. Required fields are marked *