Page 1 of 1

Gameduino 2

Posted: Fri Jan 17, 2014 3:28 am
by feilipu
I'm sure that the Gameduino 2 is a familiar Shield. It is a great 4.3" capacitive touch screen, that is driven directly from the Arduino Pre-R3 pin-out.

One great thing about the combination of the Goldilocks and the Gameduino 2 is that, because of the need to wrap a LCD signal lead around the end of the shield, there is no possibility to use the R3 pin-out. This means that the more capable Arduino devices need to be hacked before they can use the Gameduino 2. Not so with the Goldilocks, that has its SPI bus in the right place.

Whilst there is an Arduino library provided with the Gameduino 2, I've gone back to FTDI, the source of the FT800, and used the original drivers. An early version, with a test application and APIs, is now available on Sourceforge AVRfreeRTOS.

Besides applications in gaming, this makes a very nice control screen for a home automation system, or similar.

I'll write some more worlds on this soon, and link them here.

Re: Gameduino 2

Posted: Sun Jan 19, 2014 1:35 am
by feilipu
I've built an alternative library for driving the Gameduino2, derived from the example C driver code provided by FTDI. The library is available as part of my AVR ATmega freeRTOS code base, which can be found on AVRfreeRTOS on Sourceforge.

I've written some words about the Gameduino 2 on Goldilocks that explain all about the code.

Specifically to the Gameduino2, FTDI have provided drivers that cleanly layer the code into
  • a HAL, which I have optimised to use multi-byte SPI transfers and utilise the RAM saving PROGMEM capabilities of avr-libc wherever possible,
  • a FT800 Command layer, which is almost identical to the FTDI provided code, for easy maintenance,
  • and example API code, also provided by FTDI, which can be added or deleted from individual builds depending on which APIs are needed.
Some things I've removed from the FTDI drivers, such as the Command Buffer Optimisation code. The ATmega SPI bus runs at SYSCLK/2, which means there is little gain from assembling commands into a buffer before transmitting them on the SPI bus. Also, there is typically not enough RAM in an ATmega to justify a 4kB command buffer.

The code is very usable currently. I made a demonstration video so you can get the idea of some of the APIs being exercised by an example application.

The Goldilocks 1284p hardware is the best platform for the Gameduino2.
  • The ATmega1284p MCU has 16kB of RAM and 128kB of flash which means that (for example) all of the FTDI API can be enabled simultaneously. With an Uno you are limited to 1 of 4 options.
  • most importantly, Goldilocks supports the Pre-R3 Uno SPI pins, which the Gameduino2 needs. Because the LCD screen connector attached to the back of the Gameduino2 wrap around the end of the shield, it was not possible to implement the SPI ICSP. This means that to get adequate RAM and flash for significant applications, you have to hack a Mega or Due to bring the SPI interface to the traditional Uno SPI location. This means Gameduino2 works on Goldilocks without any hacking or soldering.
  • Goldilocks supports 20MHz or 22MHz, so the SPI bus (providing commands to the Gameduino2) is running 25% faster than with a normal Arduino.
Anyway, not sure if it will be useful for anyone, but it is out there now.

Re: Gameduino 2

Posted: Sun Feb 02, 2014 9:09 am
by PeterM

Viewing your demo video from your post (Gameduino2 on Goldilocks), long story short why I am sending you this message, when Set2 starts you see the FTDI logo demo, right after that you should see the Calibrate function (asking to click on the 3 dots) but instead it jumps to the clock demo. If you skipped that routine fair enough ignore my message otherwise I will let you know how I know next time.


Re: Gameduino 2

Posted: Tue Feb 04, 2014 9:34 pm
by feilipu

It was an oversight. I forgot to put the Calibrate function back into the demo, before I made the video.

In developing, I must have calibrated the Gameduino 2 about a thousand times. And truly, it grinds my gears. Which reminds me, I need to write the calibration values to EEPROM.

Initially, I didn't always calibrate and then wondered why all my touch functions stopped working. I realised after some time that the calibration was not optional, but actually mandatory before using any touch function. So, then I actually put the calibrate function in the initialisation code, and at the same time commented it out of all the demonstration code.


Re: Gameduino 2

Posted: Thu Jun 25, 2015 6:22 am
by feilipu
I recently built this multi-oscillator synthesizer with the latest Goldilocks Analogue prototype.

Nicely showcases the FTDI EVE capabilities, as the GPU within the Gameduino 2, supporting graphical widgets with almost zero CPU overhead.