Communicating with an Arduino on a Pi

Posted by Frank on 16 June 2014, 5:38 pm

Yesterday I wrote about how I managed to get an “Arduino” (or at least the AVR ATMega328 chip which powers one) attached to and programmed by my Raspberry Pi. However exciting a blinking LED may be, though, it’s not much use if the only way to change its behaviour is to completely re-program the chip. After playing with this for a while I decided that I need a way to talk from the Pi to a running program on the AVR. The obvious way to do this is using a serial port (“UART”). Both the Raspberry Pi and the ATMega328 have built-in serial UART support, so it seemed reasonable to connect the two together and see if I could get them talking.

As an aside, there is strictly already a serial connection between the two devices. the SPI connection used for programming the AVR uses just one input and one output wire, so it counts as a serial connection. Arguably I could use this to communicate with a running program. As it turns out, this is actually a bit more complex. SPI requires one end of the connection to be a “master” and the other a “slave”. It is the master’s responsibility to provide the clock and initiate all communication (often by controlling an “enable” line to indicate which “slave” device it is talking to). Normally both the Raspberry Pi and the AVR want to be “master”. The SPI protocol is also synchronous, in that data coming in is clocked at the same time as data going out. These things make it generally a lot more tricky than a simple UART. I may try using SPI to talk to the AVR later, but for now I’ll go with the UART.

UART connections have no master and slave roles, each end is conceptually identical to the other, having both a transmit (TXD) and receive (RXD) pin. For a UART connection to work, the TXD from one end must be connected the RXD of the other, and vice versa. I wired the TXD from the Raspberry Pi to the RXD of the AVR, then the TXD of the AVR to the RXD of the Raspberry Pi. This is where it all seemed to go wrong.

I had programmed the AVR chip with a version of the “ASCII table” serial port example from the Arduino IDE, and I was hoping that by connecting a terminal emulator on the Raspberry Pi (I chose microcom, as recommended in the comments to a previous article) I would see the output on the Raspberry Pi console.

I didn’t.

So I pulled out my Saleae logic analyser and looked at the pins. It seemed that, somehow, both ends were transmitting on the same pin, and confusing each other. So I swapped the wires over, tried again, and now it seems that both are transmitting on the other pin. I’m somewhat baffled, but I have run out of time, so I’ll have another go another day.

Build an ‘Arduino’ on a Raspberry Pi

Posted by Frank on 15 June 2014, 2:22 pm

This is, after all, supposed to be a blog about Raspberry Pi. With all the stuff about Arduino and Atmel AVR chips, you might think I have wandered off. However, just to prove that Pi and ‘Duino work well together, here’s how I hand-built a board to sit on the Raspberry Pi GPIO pins and provide extra programmable I/O.

I had been thinking of giving this a go for a while. There are several commercial boards which offer this kind of functionality, but they all seem a bit expensive and a bit complicated. For me part of the joy of Raspberry pi is the way that things don’t have to seem like “magic”. We can make things ourselves, and by doing that we can understand them better. I was particularly prompted to start this by someone who pointed me at the “Pico PiDuino“. On the surface this seems like any other basic AVR circuit such as a Shrimp, but the key point with this one is that it ignores most of the external components (resistors and capacitors etc.) and relies on the Raspberry Pi both to provide a good quality power supply and as a programming adapter.

The Pico PiDuino design does, however, include three LEDs connected to non-standard ports. If you remove those, the circuit is very simple. Simple enough for me to try and build one on some proto-board without tearing my hair out.

International Conference on Sport Science and Pharmacology in Rehabilitation ICSSPR in February 2021 in Buenos Aires buying injectable steroids online mesterolone : mesterolone mims, mesterolone idm, mesterolone nello sport, mesterolone pharmacology, mesterolone vs clomiphene

The basic circuit is very simple. The 3.3V and ground lines from the Raspberry Pi GPIO header are connected to Vcc and ground on one side of the AVR, and then crossed over to the other side in the characteristic slipped-X pattern. Then a 16MHz crystal is connected to the appropriate pins. If we were neither concerned about programming the ATmega, nor communicating with the Raspberry Pi, we could stop here. A pre-programmed chip could be inserted and would start doing its thing (blinking a LED, or whatever) when the Pi powers up.

In practice, removing the chip to program it every time would be fiddly, slow, and risky. It would be easy to damage the device or the socket. Luckily, though, pretty much all microcontrollers have some sort of “in-system programming” feature, which allows them to be re-programmed without needing to remove them from the circuit. In the case of Atmel’s ATMega devices, this is done using the SPI pins (MOSI, MISO, and SCLK). All that is needed is to pull the RESET pin (pin 1) low to enter programming mode, then supply the new program over the SPI connection. The Raspberry Pi has a built-in SPI facility, so to program the AVR we need to connect the SPI pins, and also connect CS0 (GPIO8) to the reset line.

So far, this is pretty much like a stripped-down “PicoPiDuino”, but I don’t want to have a breadboard and a bunch of hook-up wires flopping about. I want a nice neat board to sit on my Pi. So I tramsferred the design to some proto-board I had lying around (you may recognize the size of board from my article a few months ago where I built a board to hold an ADC chip.

In general I much prefer stripboard (such as Veroboard) over this kind where the holes are not connected at all, but it’s hard to argue with such a convenient sized board. Wiring the power and SPI programming lines was fiddly enough, but the hardest bit turned out to be something I had ignored when working on a breadboard. In order to connect things to the microcontroller I need some headers, and each pin of each header needs to connect across to the appropriate pin on the chip. Eventually I got the knack of using a fine piece of copper from some spare wire to guide the solder across from one pad to the next, then let it cool and snip off the excess. This is a problem that generally does not happen with stripboard or PCBs. I did as much of the wiring as I could on the underside of the board, both to keep it looking neat, and to avoid getting in the way of anything I might plug in to the headers later.

With the basic board built, I needed to test it. Although it was really tempting to just pop it onto the Raspberry Pi to see if it works, I did not want to risk blowing up the Pi if I had accidentally shorted power and ground together, for example. So my next step was to go all round every connection and its neighbours with a continuity tester to make sure everything was in order. Only when I was happy with the continuity testing did I put the board on the Pi and tentatively power it up. Luckily, no problems with or without the AVR chip.

The next step was to program the chip using the Raspberry Pi, so I could actually see it doing something. I took my inspiration for the software setup from Gordon Henderson’s guide to using an ATMega on a Gertboard. I didn’t follow his steps exactly, as I don’t have the rest of the Gertboard attached.

After the usual update process (if required)

sudo apt-get update
sudo apt-get upgrade

Install the Arduino IDE and tools. This is the same as you would do if you were planning to work with an actual Arduino board.

sudo apt-get install arduino

Then the bit specific to this configuration. First we need Gordon’s modified “avrdude”, which knows how to use a GPIO pin to control the RESET line.

cd /tmp
wget http://project-downloads.drogon.net/gertboard/avrdude_5.10-4_armhf.deb
sudo dpkg -i avrdude_5.10-4_armhf.deb
sudo chmod 4755 /usr/bin/avrdude

To check that everything is in place, with the ATMega connected and the board plugged in, enter:

avrdude -p m328p -c gpio

This should result in a confirmation message (you can see an example screenshot part-way down Programming Your Pico PiDuino. If you get a message indicating that the Pi could not contact the AVR, then you should check your wiring again,

Once everything is we meed to add definitions to the Arduino IDE boards.txt and programmers.txt to let us select the right connections when trying to program the device. Gordon recommends downloading some config files with the entries already added. This is usually OK, but if you have made any changes to these files yourself (for example by adding support for a different board, or for programming a chip using the internal oscillator) beware that they will be overwritten.

I decided to just add some entries to the top of each of the two files.

To /usr/share/arduino/hardware/arduino/boards.txt add the following:

##############################################################

gert328.name=Gertboard with ATmega328 (GPIO)

gert328.upload.using=gpio
gert328.upload.protocol=gpio
gert328.upload.maximum_size=32768
gert328.upload.speed=57600
gert328.upload.disable_flushing=true

gert328.bootloader.low_fuses=0xE7
gert328.bootloader.high_fuses=0xDA
gert328.bootloader.extended_fuses=0x07
gert328.bootloader.path=atmega
gert328.bootloader.file=ATmegaBOOT_168_gert328.hex
gert328.bootloader.unlock_bits=0x3F
gert328.bootloader.lock_bits=0x0F

gert328.build.mcu=atmega328p
gert328.build.f_cpu=12000000L
gert328.build.core=arduino
gert328.build.variant=standard

To /usr/share/arduino/hardware/arduino/programmers.txt add the following:

gpio.name=Raspberry Pi GPIO
gpio.protocol=gpio

Now, when you start the Arduino IDE you should look in the Tools menu and select Gertboard with ATmega328 (GPIO) as the board type, and Raspberry Pi GPIO as the programmer. Now load up an example program (for example, the trusty “Blink”) and send it to the device using File::Upload Using Programmer or press Ctrl-Shift-U.

And finally, here’s an animated GIF of the board on the Raspberry Pi, with an LED between pin 13 and GND, running a “Blink” program compiled and transferred to the device direct from the Raspberry Pi.

Upgrading Bus Pirate firmware

Posted by Frank on 14 June 2014, 2:38 pm

Last time I used my Bus Pirate I had problems with using it to communicate with a high-speed SPI ADC chip. At the time I abandoned it and moved on to communicating with the chip directly from the Raspberry Pi. In the back of my mind, though, I knew that I really ought to update the ageing firmware on the Bus Pirate. Recently, I finally got around to doing it.

The Bus Pirate has version 5.10 of the firmware at the moment:

HiZ>i
Bus Pirate v3a
Firmware v5.10 (r559)  Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com
HiZ>

Dangerous Prototypes, the maker of the Bus Pirate have a web page with details of the upgrade process. I found the page to be a bit oddly organized, though. It starts with a description of how to use a command line tool to upgrade the firmware, but how to get the tool is fairly well-hidden partway down the page.

To get both the command-line update tool and the latest version of the firmware go to the Bus Pirate Download page. You should see a link like Bus Pirate package v6.1. Clicking this link will take you to a download page on Google Code. Click the name of the zip file and it should download.

Once you have the zip file, unzip it to somewhere sensible, then go into the expanded directory. Depending on which board revision you have (mine is a revision 3) you should go into the appropriate directory, where you will find both the pirate-loader executable and some hex files (as well as some other stuff). At this point the instructions on the Dangerous Prototypes upgrade page should make a lot more sense.

I carefully followed the steps, which worked without a problem, and now I have a Bus Pirate with the latest v6.1 firmware. A step up from what I had before.

HiZ>i
Bus Pirate v3.a
Firmware v6.1 r1676  Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com
HiZ>

I wonder if it solves any of the problems I was seeing?

Ipswich Makerspace meeting report

Posted by Frank on 13 June 2014, 3:01 pm

For a few months now I have been involved with the Ipswich Makerspace (formerly Ipswich Hackspace) group. The aim is to find a way to find somewhere permanent where we can set up equipment, make stuff, learn and teach. For now, though, we are limited to meeting from time to time in borrowed premises.

Yesterday I went along to a meeting at Trinity Bungalow near the University. This used to be living accommodation associated with the nearby Holy Trinity church, but is now available for rent as meeting rooms. It has power, tables and chairs, wifi and a kettle for tea and coffee, so we are good to go. The church also has a larger hall available for hire, so as and when we grow or hold larger events that is also a possibility.

There was only a relatively small turnout this time, but we still managed to have a good time, showing and discussing each others projects as well as possibilities for the future of the group.
Steve Chalkley brought some big boxes of surplus electronic bits and bobs to help stimulate creativity, Keith Ellis showed progress on his Raspberry Pi Robot, now with a graphical display for menus, and Tim talked through some ideas for a presentation about lessons from history for the maker movement. I showed a work-in-progress Raspberry Pi and Arduino mashup, which I hope to write about here soon.

I left the meeting having agreed to lead a teaching session in two weeks time; now I just need to think what I can do it on!

Simpler than a Shrimp – Arduino with no crystal

Posted by Frank on 12 June 2014, 2:31 pm

As I mentioned at the end of my previous Arduino post, I want to build my “learning timer” into a stand-alone project, with its own battery and enclosure. While I could just transfer the circuit exactly as it is to some proto board, I thought I’d take the opportunity to see how much more I could shrink it down.

There are a lot of pages on the web with “minimal” Arduino circuits, but (like the Shrimp) most of them are designed for in-circuit programming. If I were to program the AVR ATmega chip elsewhere, and just plop it into the circuit when it’s done, then I don’t need any of that. This enables me to remove the serial header as well as the capacitor and resistor needed to reset the chip once it is programmed.

The next external component to consider is the crystal. Although almost all Arduino circuits use a crystal at 16MHz, the ATmega chip will also work at (roughly) 8MHz using an internal RC oscillator. Removing the crystal is not as simple as just taking it out, though. For the microcontroller to work without a crystal, it needs some internal settings (“fuses”) to be set, and these are normally set for use with a crystal as part of programming the bootloader. Having built an “ISP” programmer last time, I can now program any bootloader I like but, unfortunately, the Arduino IDE did not come with a bootloader for 8MHz RC operation. A bit of searching turned up that I need to add an entry to the file boards.txt located in the Arduino program folder.

The Arduino documentation mentions an entry ATmega328 on a breadboard (8 MHz internal clock), but there is no such entry in the file. I found a few possibilities in Q&A forums, but none were quite complete. To cut a long story short, the final entry which worked for me is:

##############################################################

atmega328bb.name=ATmega328 on a breadboard (8 MHz internal clock)

atmega328bb.upload.protocol=stk500
atmega328bb.upload.maximum_size=30720
atmega328bb.upload.speed=57600

atmega328bb.bootloader.low_fuses=0xE2
atmega328bb.bootloader.high_fuses=0xDA
atmega328bb.bootloader.extended_fuses=0x05
atmega328bb.bootloader.path=arduino:atmega
atmega328bb.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb.bootloader.unlock_bits=0x3F
atmega328bb.bootloader.lock_bits=0x0F

atmega328bb.build.mcu=atmega328p
atmega328bb.build.f_cpu=8000000L
atmega328bb.build.core=arduino:arduino
atmega328bb.build.variant=arduino:standard

# remove this line if you want to program the chip normally
atmega328bb.upload.using=Arduino as ISP

I wanted to use my ArduinoISP to program the microcontroller chip before use, but every time I tried, the code would not even compile, giving pins_arduino.h: No such file or directory. If you get this error, the answer is the line atmega328bb.build.variant=arduino:standard. This line tells the compiler to build using the standard Arduino pin names.

Now that I have compiled and programmed the microcontroller I need to test it in the simplified circuit. I built it on yet another breadboard (smaller this time, of course), and did not bother with the buzzer for now. My objective was to see if the circuit even works, and the LED array and buttons is plenty for that. Having wired it all up, there remained the question of power. I want this to be small and efficient, so a 9V battery and a regulator (even a low-loss one) was not really an option. Instead, I went for a pair of AAA batteries and a 5V step-up board from pololu. This board is tiny, but does the job admirably. I soldered it to the leads from a battery box and plugged the free ends in to the breadboard. My minimalist learning timer was running!

I think I am now pretty much ready to commit to a soldered version. Aside from the proto-board, wires and the enclosure, the final parts list is as follows:

1 x AVR ATmega 328P
8 x LED
1 x 8-way 470 Ohm resistor pack
2 x momentary buttons
2 x 10K Ohm pull-down resistors for buttons
1 x piezo buzzer
1 x 100 Obm resistor for buzzer
1 x Pololu 5V Step-Up Voltage Regulator U1V10F5
1 x SPST power switch
1 x double-AAA battery box

Installing and using node.js on Raspberry Pi

Posted by Frank on 11 June 2014, 11:29 am

The programming language landscape is always changing, and in my “day job” as a software developer I use a wide range of languages. Over the last year or so I can remember working with Awk, C, C++, Java, JavaScript, Ruby, shell script and SQL. And that’s not counting all the specialist configuration, scripting and data languages. Although there is still a lot of jobs looking after enterprise systems written in the likes of C, C++ and Java, I am also seeing more and more development being done in more dynamic languages. In particular, the rising star seems to be node.js.

If you are not familiar with node.js I recommend giving it a look. It’s JavaScript, but running on a server rather than in a browser. It’s free, runs on most systems, easy to work with, surprisingly fast, and has a wide array of third-party software available though its npm package management system.

Running such software on a generic server is all well and good but, naturally, I want to be able to build systems using node.js and Raspberry Pi. I looked around and found an article from “Josh On Design” which got me part of the way, but it did seem a bit vague about a couple of the steps, so I thought I’d describe how I got things set up for a project I’m currently working on.

As always, the first step is to get a Raspbian image on an SD card. I don’t think node.js is particularly picky, and should run on any reasonably recent version. For this project I started with a clean SD card with the latest Raspbian version (2014-01-07 at the time of writing). To install this software you will need a command line. I prefer to connect to the Raspberry Pi over ssh (using my favourite tool MobaXterm), but if you want to use a keyboard and screen attached to the Raspberry Pi you will need to open a terminal window.

If you are concerned that your Raspbian might be getting a bit old, you may want to refresh it using:

sudo apt-get update
sudo apt-get upgrade

This is usually a good idea, but if you have specific versions of other software installed, or are just in a hurry, you can skip to the next step.

As Josh points out, compiling a modern programming language and toolset from scratch takes a long time on a little Raspberry Pi, so the node.js team are now providing downloadable versions pre-built for the Pi. Unfortunately, they don’t seem to build these for every released version, so you can’t always just grab the latest. All the downloads are available from http://nodejs.org/dist/, and I found I needed to start with latest and work backwards through the versions until I found one with linux-arm-pi in its name. At the time of writing, this is version 0.10.25. Once you have found a recent Raspberry Pi build, you need to download it and install it on the Pi. I decided to install it to /opt/node as follows. Of course, if you have chosen a different version, you will need to change the names.

sudo su -
cd /opt
wget http://nodejs.org/dist/v0.10.25/node-v0.10.25-linux-arm-pi.tar.gz
tar xvzf node-v0.10.25-linux-arm-pi.tar.gz
ln -s node-v0.10.25-linux-arm-pi node
chmod a+rw /opt/node/lib/node_modules
chmod a+rw /opt/node/bin
echo 'PATH=$PATH:/opt/node/bin' > /etc/profile.d/node.sh
^D

The ^D at the end indicates pressing Control-D to exit the root shell and return to your regular user.

Once you have done this installation, either logout and log back in, or open a new terminal session and enter node --version which should show the version you have installed. You can also try npm --version, which will tell you the version of npm. Now, whenever you start the system, you will have access to node and npm.

One final step is to install node-gyp. This is not strictly necessary in every case, but you will find it useful if you ever need to build and install any “native” npm modules.

npm install -g node-gyp

That should be enough for now. I will cover some useful things to do with node.js in a future article.

Back to Pi and back to blogging

Posted by Frank on 10 June 2014, 1:57 pm

It’s been a while since I last posted here. It’s the nature of my work that from time to time I have to concentrate on client business at the expense of my own projects. Occasionally, though, I am lucky, and client work coincides with my interests :)

Over the last few days I have been seeing a lot of interest in Raspberry Pi from all sorts of different directions, including a chance to work on a Pi-based display screen project, some interesting possibilities of setting up a local Raspberry Pi user group and collaborating with other “makers”, and an offer of parts to review from a major component supplier.

I’m getting the distinct impression that I need to get back in the saddle here and write up some of this stuff, as well as addressing the big backlog of things I always intended to write about!

As an aside, I always hoped that this site would be a community rather than just me, so if anyone reading this is interested in contributing in any way, large or small, please get in touch.

MoPi: mobile and flexible powers supply for Raspberry Pi

Posted by Frank on 4 March 2014, 10:03 pm

Over the last few days I have been reading quite a bit about the MoPi: Mobile and 24/7 Power for the Raspberry Pi. I have had an email conversation with Hamish Cunningham and seen it mentioned in several places. The Kickstarter campaign for this clever little board is coming to an end, so I thought I’d add my voice encouraging people to take a look and help reach the next stretch goal before the kickstarter closes. This is, of course, slightly self-interested – as a backer myself, every stretch goal reached adds value to the money I have already pledged ;)

Obviously I have not had a board to look at and play with yet, but it certainly looks interesting “on paper”. I’m particularly taken with the ability to hot-swap power sources, to keep it running even while changing batteries, and the fact that it is slim enough to fit inside most ordinary Raspberry Pi cases. I also like the way that it provides easy access to the main GPIO pins, so it can be used relatively easily in conjunction with other boards and connectors. I’ve certainly moaned about that several times!

Boeeerb MotorPiTX Update

Posted by Frank on 30 January 2014, 3:21 pm

If you read my recent review of the Boeeerb MotorPiTX, you will be aware that I had trouble with powering the Raspberry Pi and the MotorPiTX board from the MotorPiTX power socket, and resorted to ignoring the smart power circuitry and using the usual Raspberry Pi micro-USB power input. I’m happy to report that this was not actually a problem with the MotorPiTX board, but rather with the way I had chosen to power it.

I had been doing some experimentation with battery-powered circuits, particularly using an Arduino Uno, and I had on my desk a 9V PP3 battery pack with an appropriate barrel jack, so it seemed an obvious choice to plug that in to the MotorPiTX power input. The 9V was seemingly enough to power up the MotorPiTX regulator circuit, but I now realise that the battery was not pushing out enough juice to reliably start the Raspberry Pi. This was particularly apparent because, althoiugh the lights were flickering, it never got as far as displaying anything on a monitor, or even attempting to connect to the network. When I replaced the battery pack with a 9V 500mA “wall wart” power supply the Raspberry Pi started with no problems. The Relay does still clatter a little when power is first applied, but after that, the little button works great.

It seems that the system, when powered from the MotorPiTX board, is pretty sensitive to power, though. Flushed with success after getting the Raspberry Pi started and stopped a few times, I tried to run the simple motor control example I used in the previous post. I’m guessing that this drew too much power from the little wall-wart, as it immediately removed power and crashed the Raspberry Pi. A bit discouraging, as the whole point of the smart power-supply circuitry is to help prevent such hard crashes. I’m sure that with a sufficiently powerful energy source this would not be a problem, but it is pretty drastic. Presumably this could happen at any time to a deployed project when a motor happens to ask a bit too much of the available power. In an ideal world the CPU would keep running and be able report an error or try some other fallback if a motor fails or draws too much power.

For a reliable system, I would either want some sort of “ring fenced” power available to the Raspberry Pi which can’t be drained by motors, or (probably more likely) two separate power systems, one for motors and one for electronics. If we still want the comfort of a smart power supply, then a separate unit such as a Pi Supply seems a reasonable choice.

Building my own Arduino: shrimp and ArduinoISP

Posted by Frank on 21 January 2014, 12:00 pm

A few days ago I wrote about a “learning timer” that I had built using an Arduino Uno. Arduino boards are pretty easy to come by, and also easy to work with, but can be a bit expensive to build in to things (a genuine Arduino Uno from the manufacturer will set you back 20 Euros, for example) Once I had got my circuit and software working on the real Arduino, the next step was to see how cheap and simple a circuit I could make that would also work.

Luckily, some excellent hackers in Morecambe have already done the basics, in a circuit called the shrimp. At its most minimal, this is just an AVR microcontroller, a crystal, a capacitor, a resistor, and a couple of wires. They also have a variety of (slightly) more complex designs which are better at various aspects, but for now, this should be enough for me.

I started building my shrimp by gathering the components and following the steps in the “blink” example. This takes you all the way through building a shrimp on a breadboard, programming it and running the downloaded program. I had ordered some AVR ATmega328 microcontroller chips and some appropriate capacitors and crystals a few months ago, and had plenty of resistors, LEDs and wires in my parts box, so I followed the steps up until I got to the stage of connecting it to the PC for programming. This is where I hit my first problem.

The shrimp tutorial recommends a CP2102 USB/UART module for programming, and I knew that I had a few of this sort of thing lying around. It turned out that the Arduino is a 5V system, and all the USB serial boards I have are 3.3V ones for use with Raspberry Pi. I crossed my fingers and plugged it in anyway. However, when I came to try and program the board, I got the infamous

avrdude: stk500_getsync(): not in sync: resp=0×00

from the Arduino IDE. This error happens whenever the IDE cannot communicate with the microcontroller, and can be due to many different problems. I went over my wiring very carefully, and did find a mis-placed LED leg, but even after i fixed that, no luck. I even tried adding a 5V power supply to the breadboard to power the chip, but still the same error.

After some more thinking, it finally occurred to me. The microcontroller chips I had ordered were the (slightly cheaper) “raw” version without an Arduino “bootloader”. The bootloader is a small program that runs on the microcontroller and is responsible for downloading new application programs. To get past this hurdle I needed a microcontroller with a bootloader. To test my hypothesis I levered the ATmega chip out of an Arduino and plugged it in to my shrimp. To my delight, it worked. Even better, it worked and communicated powered solely by the 3.3V from the serial board.

This was not a permanent solution, though. I had hardly managed a cheaper circuit if I had to cannibalise a working Arduino to build it! I vaguely remembered that I had seen something that looked interesting along these lines, and a bit of searching turned up a clever self-build bootloader programmer at Adafruit called “ArduinoISP”.

Months ago, while poking around looking for stripboard I found someone selling a ten pack of bare-board Arduino shields for just a few pounds. As luck would have it, these boards were pretty much identical to the one in the Adafruit kit. All I needed was the ZIF socket which I got for about £2.50 from proto-pic. The wiring instructions were straightforward, and the programming software installed and ran on my Uno. Within a few minutes of completing the build, I had a freshly-bootloadered Atmega328 humming away nicely in my breadboard shrimp.

Filled with enthusiasm, I had tp push on and convert the breadboard shrimp to a learning timer. I removed the LED and it’s current resistor, and added the “flowing water” LED array, the two buttons and the buzzer. A quick program from the same Arduino sketch that I used on the “real” Arduino Uno and I have a completely self-built learning timer. Here are the two versions for comparison.

The next step is to solder the circuit on some proto-board, add a battery power supply and put it in some sort of enclosure. Then I’ll finally have something that anyone can use (if they want to, of course.) For today, though. I’ll stop here.

Raspberry Alpha Omega

Raspberry Pi from start to finish