Gertduino - Review

Table of contents

RoadTest: Gertduino

Author: danringer

Creation date:

Evaluation Type: Independent Products

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: Arduino UNO, Arduberry, AlaMode

What were the biggest problems encountered?: All were assumed

Detailed Review:

     To begin, I'd like to thank element4 for the opportunity to evaluate the gertduino for this road test.  In hopes of this review actually reaching Gert, thank you to him for his dedication to the raspberry pi, broadcom, gert board, gertduino, and hopes of future products like this.

     My name is Dan, and I teach a STEM course after school at my local middle school, Upper Township Middle School.  For the past 2 years, we've been learning Raspberry Pi Programming with Python, Using a Pi Cobbler for beginning circuits, Servos, Steppers, and DC Motors, and currently we're building a RepRap Prusa i3 from  I've been an electronics hobbyist for far longer than that and a linux user for 20 years.

     I have an early Gert board, the self assembled kind with a 2 month back order.  I loved the ideas that Gert Van Loo discussed in his videos, "start with raspberry pi, and foray into micro controllers, then FPGAs" I was furious when the kit was switched to fully assembled, and I began a petition to bring it back, to no avail.  The gert board has an excellent instruction manual both for assemble as well as usage.  The amount of information gleaned from the build has fueled this hobbyist to reach into CPLD with a guzunty Pi, and countless other soldering iron projects.

     I followed the sites setup instruction except I started with Debian Raspian Wheezy 2014-01-07 image as, I feel, NOOBS like the dummies book series is admitting something I'm not willing to on these subjects.  Next, I expanded the root filesystem with raspi-config, rebooted then:

sudo apt-get update ; sudo apt-get upgrade -y

added avoid_safe_mode=1 to the end of config.txt with

sudo vi /boot/config.txt

this stops the Raspberry Pi from rebooting in safe mode, with larger text when a GPIO pin 5 is held low at boot time from the gertboard.

     I followed the rest of the setup from their page verbatim.  They did a great job with vanilla setup. Including downloading element14's version of the instruction and software downloads and gordon's version.  Gordon wrote some great avrdude scripts and patches for the gert board and followed that with even better versions and software setup for the gertduino.  Any reviewer with less that stellar reviews hasn't found Gordon's software.  I was able to set fuses to both atmegas and send blink to the 328 which blinks the 6 leds from the gertduino in sequence.

     The portion about sh: can't access tty; job control turned off  did not apply to this reviewer but follow up on the forums for the gertduino trace the problem back to testing software on the m48p which should have been erased before distribution.  Gert himself weighted in on that one, as he and Gordon are frequent commenters there.

     As I like to give a detailed review, I began to work on the serial port access.  http:// has another well written HOWTO, detailing exactly how to disable kernel and boot messages to the serial port as well as disabling the getty or login terminal which also is running by default on raspian.  After the file modifications are made and the pi is rebooted the gertduino should have access to the pi's rx/tx pins which have been routed to the UART/RS-232 header on the gertduino.

     I use the gertduino on my 3rd raspberry pi on my LAN.  My occidentalis install from is my "production" machine for our class and the only one attached to a monitor, the other 2 pi run headless on a predominantly mac network.  The easiest way I found to run the arduino IDE from raspian on the mac is to install XQuartz and forward X11 using ssh -X to login to the gertduino/pi.  Its a little slower than the default client running on a mac but very usable.

I loaded their sketch and Uploaded Using Programmer from the file menu in Arduino IDE with the correct jumpers installed to program the 328 and straps installed to connect the 328's RX/TX to the pi, did a quick:

sudo apt-get install minicom
minicom -b 9600 -D /dev/ttyAMA0
Welcome to minicom 2.6.1

Compiled on Apr 28 2012, 19:24:31.
Port /dev/ttyAMA0

Press CTRL-A Z for help on special keys

Led 5 turned on                                                              
Led 0 turned on                                                              
Led 1 turned off                                                             
Led 3 turned off                                                             
Led 5 turned off                                                             
Led 1 turned on                                                              
Led 2 turned off                                                             
Led 3 turned on                                                              
Led 4 turned off                                                             
Led 3 turned off                                                             
Led 2 turned on


the LEDs turned on and off as indicated by the serial output.  This satisfied me that the serial test was a success, now on to the m48.

As I'm sure that if you've read this far you realized that the gertduino is not in the ball park of the AlaMode or AduBerry, and far outshines the namesake Arduino Uno by adding 5 additional LEDs, 2 buttons, irDA receiver, RS232 serial, and RTC battery.  Same goes for the interests of this reviewer, can I talk serial to the other atmega on board m48pa.  I switched the jumpers to program the m48 again, compiled Gordon's m48 program, and loaded it to the atmega from the command line program:

pi@gertduino:~/Gertduino$ ./program_48 m48.hex

it failed, the -p argument in the script needed to be changed from m48pa to m48p and I needed to add -i 5 to the avrdude command line to stop the mismatch errors.  Once corrected, I was able to load the hex to the m48:

pi@gertduino:~/Gertduino$ ./program_48 m48.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e920a
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "m48.hex"
avrdude: input file m48.hex auto detected as Intel Hex
avrdude: writing flash (3610 bytes):

Writing | ################################################## | 100% 2.30s

avrdude: 3610 bytes of flash written
avrdude: verifying flash memory against m48.hex:
avrdude: load data flash data from input file m48.hex:
avrdude: input file m48.hex auto detected as Intel Hex
avrdude: input file m48.hex contains 3610 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 1.99s

avrdude: verifying ...
avrdude: 3610 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

looks successful but no activity on the minicom serial output, nothing from the modules for the RTC.  What's wrong?  Back to the manuals, forums, google searches.  Reloaded the hex file while running minicom, nothing.  After all that I read again from Gert's manual that the reset pin is pulled high from the Pi which holds the m48 in reset state.  Either remove the Re jumper or run the reset script included in both the software download packages.  While listening on minicom while switched to 115200:

Gerduino ATmega 48p control processor                                        
Copyright 2013 Gordon Hendeson <>                         
GPLv3: This is free software with ABSOLUTELY NO WARRANTY.                    

So now I can program the m48 and read serial data from it.  From Gordon's c file comments, I expected more output from the serial line when the Irda receiver sensed a signal but nothing.  However, the RTC worked exactly as desired:

[   28.368620] rtc-ds1374 1-0068: rtc core: registered ds1374 as rtc0
[   28.368693] i2c i2c-1: new_device: Instantiated device ds1374 at 0x68

check the RTC off the list, but jury is still out on the IRDA interface.

Days of researching ir libraries and sketches and failures led me to a raw ir read sketched developed by adafruit.  The common irda libraries are too large to include in compiling for the m48 due to the lesser amount of memory versus the big brother 328.

/* Raw IR decoder sketch!
This sketch/program uses the Arduno and a PNA4602 to
decode IR received. This can be used to make a IR receiver
(by looking for a particular code)
or transmitter (by pulsing an IR LED at ~38KHz for the
durations detected
Code is public domain, check out and
for more tutorials!

// We need to use the 'raw' pin reading methods
// because timing is very important here and the digitalRead()
// procedure is slower!
//uint8_t IRpin = 2;
// Digital pin #2 is the same as Pin D2 see
// for the 'raw' pin mapping
#define IRpin_PIN PIND
#define IRpin 3
// for MEGA use these!
//#define IRpin_PIN PINE
//#define IRpin 4

// the maximum pulse we'll listen for - 65 milliseconds is a long time
#define MAXPULSE 65000

// what our timing resolution should be, larger is better
// as its more 'precise' - but too large and you wont get
// accurate timing
#define RESOLUTION 20

// we will store up to 100 pulse pairs (this is -a lot-)
uint16_t pulses[100][2]; // pair is high and low pulse
uint8_t currentpulse = 0; // index for pulses we're storing

void setup(void) {
  Serial.println("Ready to decode IR!");

void loop(void) {
  uint16_t highpulse, lowpulse; // temporary storage timing
  highpulse = lowpulse = 0; // start out with no pulse length

// while (digitalRead(IRpin)) { // this is too slow!
    while (IRpin_PIN & (1 << IRpin)) {
     // pin is still HIGH

     // count off another few microseconds

     // If the pulse is too long, we 'timed out' - either nothing
     // was received or the code is finished, so print what
     // we've grabbed so far, and then reset
     if ((highpulse >= MAXPULSE) && (currentpulse != 0)) {
  // we didn't time out so lets stash the reading
  pulses[currentpulse][0] = highpulse;

  // same as above
  while (! (IRpin_PIN & _BV(IRpin))) {
     // pin is still LOW
     if ((lowpulse >= MAXPULSE) && (currentpulse != 0)) {
  pulses[currentpulse][1] = lowpulse;

  // we read one high-low pulse successfully, continue!

void printpulses(void) {
  Serial.println("\n\r\n\rReceived: \n\rOFF \tON");
  for (uint8_t i = 0; i < currentpulse; i++) {
    Serial.print(pulses[i][0] * RESOLUTION, DEC);
    Serial.print(" usec, ");
    Serial.print(pulses[i][1] * RESOLUTION, DEC);
    Serial.println(" usec");

  // print it in a 'array' format
  Serial.println("int IRsignal[] = {");
  Serial.println("// ON, OFF (in 10's of microseconds)");
  for (uint8_t i = 0; i < currentpulse-1; i++) {
    Serial.print("\t"); // tab
    Serial.print(pulses[i][1] * RESOLUTION / 10, DEC);
    Serial.print(", ");
    Serial.print(pulses[i+1][0] * RESOLUTION / 10, DEC);
  Serial.print("\t"); // tab
  Serial.print(pulses[currentpulse-1][1] * RESOLUTION / 10, DEC);
  Serial.print(", 0};");

modified only from its source by changing the IR pin to 3 from the gertduino manual.

Uploaded with Programmer from the arduino IDE switching Board to Gertuino ATmega44, had to dive through boards.txt to verify it was actually for the m48p, and it worked like a charm.  Serial output below from an Apple TV remote ir output:



satisfied with myself for debugging the IR interface, I reloaded the m48 with the m48.hex from Gordon, reset the gertduino/pi to use the RTC and started digging further into the code for the m48.c and found that his program looks for specific ir pulses matching a generic remote he grabbed the timing for.  I can relax now, completely satisfied that   I have all the attachments from the m48 working; RTC, serial, and irDA.

     In the spirit of total understanding of the product, I plan to populate the onboard power supply which was pulled for legal reasons.  If both the Pi and the attached gertduino are both using walwart power supplies the inferior one can suffer due to the pi missing a reverse diode. I'm currently sourcing the parts from the circuit schematic.  And future plans include a little "home" automation project for our chicken coop.  With the pi as the base handling as a LAMP server, and the gertduino handling the precision work.  I'll need a few relays for timed lighting, antifreeze water dish heating, servos for ventilation doors, and sensors for temperature, ambient light.  Maybe I'll add a picamera for live streaming.  I feel this Pi/Gertduino is perfect for this, I'll let you know!

     In conclusion, I love the gertduino, I've read some other less than stellar reviews on it but I believe they missed the point.  The raspberry pi foundation says that they brought the pi to market to address the problem that Comp Sci student entering college have regressed over the last many years from the once capable students bred by the UK BBC computers and here in the US by Tandys, C64, and the like.  I had a laser 128K, it was an apple II clone.  Using a computer back then was a hobby, games and applications didn't even start by themselves. I digress.  The gertduino was a challenge to get all the above working as reviewed, it was fun to scour the forums, awesome to read and use the help from it's designer.  I think that this has helped me understand how an atmega works, teaches more about how the Arduino IDE functions, serial communication and minicom, and irda.  I can't wait til I finish the power supply.  This board is often compared to other raspberry pi add-ons but some of them are no better than the iPad they're trying to get away from, they're necessary, I know, "they" want to put something on their Pi too, but don't miss the point.  If its worth doing, its worth doing right, get a gertduino and learn something new.