Sunday, July 31, 2011

Shield-compatible breadboard Arduino


Breadboard Arduino
Click on the image for an annotated version.

Background
My experience with my Arduino web server has shown that the 32kB program memory of the Uno isn't enough to run a full-featured web server and do other interesting things at the same time. As I'm using an Arduino Mega2560 memory isn't an issue at the moment. Unfortunately taking these ideas beyond the prototype stage means either using one of the surface mount ATmega line or experimenting with the ATmega644P/ATmega1284P, both of which are available in a convenient dual in-line package. Before attempting a shield-compatible Sanguino clone I wanted to be sure I could make a standard Arduino clone based on the ATmega328. This has been done many times before; I found the ITY tutorial helpful (see also the updated version on the Arduino web site). As far as I can find no-one has built a shield-compatible breadboard Arduino before.


Offset headers and the 0.16" spacing problem
For reasons I don't understand the designers of the Arduino chose to space two of the headers by 0.16", which causes problems when using breadboards and stripboard (Veroboard), both of which haves holes at 0.1" spacing. Fortunately 8 pin offset stackable headers can be used to solve this problem.

8 pin offset stackable header
Offset header for use with Arduino shields.


Breadboard layout

Breadboard Arduino
Ethernet shield removed to show the ATmega328 and wiring. Click on the image for an annotated version.

I basically followed the ITY tutorial so I'll just report the differences.

I clipped together two Wisher WBU-TJ breadboards, with the ATmega328P straddling the join. The two parts from the Wisher WBU-DJ breadboard are fitted at the top and bottom to provide power rails. I chose to align A5 with pin 28 on the ATmega328P. That aligns D0 with pin 1 (reset). Since the headers are fitted to a different section of the breadboard that is not a problem.

I chose not to connect AREF, see this warning.

In addition to fitting the AVR programming adapter I also fitted a 2×3 header connected via wires to send the ICSP/SPI signals to the ethernet shield.

I adapted the reset circuitry to allow auto-reset.
Auto-reset circuit.


Breadboard Arduino
Note the offset header used for D8-D13. Click on the image for an annotated version.

Parts list
  • Breadboard (e.g. 1 × Wisher WBU-DJ, 2 × Wisher WBU-TJ)
  • 1 × ATmega328P microprocessor
  • 1 × red LED
  • 1 × 16MHz crystal, 18pF load capacitance
  • 1 × 1kΩ resistor
  • 1 × 220Ω resistor
  • 1 × 10kΩ resistor
  • 2 × 22pF capacitors
  • 3 × 100nF capacitors
  • 1 × 100µF capacitor
  • 1 × FTDI breakout board (Sparkfun DEV-09716)
  • 1 × AVR programming adapter (Sparkfun BOB-08508)
  • 1 × ICSP lead (2×3 pins), else use 6 wires
  • 4 × 6 pin stackable headers (Sparkfun PRT-09280)
  • 3 × 8 pin stackable headers (Sparkfun PRT-09279)
  • 1 × 8 pin offset stackable headers (Sparkfun PRT-09374)
  • 1 × reset switch
  • 22 AWG wire
The next step
The next step is to try this with the ATmega644P before moving the circuit to stripboard.

Wednesday, July 13, 2011

Web server for Arduino

For my magnetometer project I've been using the Arduino micro-controller system to measure and log the magnetic field strength. For real-time data the Arduino sends a UDP packet to a remote server, using the ethernet shield. The shield also contains a microSD slot, allowing data to be logged in case of network outage. What I really want to do is fetch the archived data from the microSD card without disrupting data logging. I could use TFTP but HTTP clients are much more widespread. Using HTTP also gives the potential for a friendly interface to control the magnetometer, not just fetch the data.

There is already the webduino library but it doesn't serve files from the SD card, and it processes the HTTP request as one task. For my purpose I need the HTTP request to be split into many tasks so that web clients cannot disrupt data logging. For this reason I've created my own WwwServer library, which can be found on Github: https://github.com/stevemarple/WwwServer. At a convenient place in loop() make a call to processRequest() so that any pending or ongoing requests can be processed. You must pass a buffer for the web server code to use, but you are free to use the buffer for other purposes before or after the call to processRequest().

If you plan on using the code you'll need a beta of the upcoming 1.0 version of the Arduino IDE (the new-extension branch on Github). This is a big improvement over the 0022 release, DHCP is built into the Ethernet class and the SD library supports multiple open files. The beta release from January 2011 has a bug which breaks DHCP offers containing more than one DNS server. I've made some binaries available of my version at https://github.com/stevemarple/Arduino; it includes a fix for the DHCP bug.

How well does it work? Serving a 40KB file from the SD card takes several seconds, so its not very fast. The important thing is that worst case call to processRequest() is completed in under 30ms. That's over 10× faster than the blink of an eye, and fast enough that I only need add a small amount of 'guard time' to ensure that web requests don't affect data logging.

A simple magnetometer for detecting auroral activity

I've been playing with the idea of creating a simple magnetometer which can be used for detecting times when the aurora might be visible. AuroraWatch UK already provides a service for this, with email and Twitter alerts. The AuroraWatch web pages also show how to build a simple pop-bottle magnetometer, and a compass detector, but I wanted something which could easily output digital data. Now I've found a suitable sensor, I've started building a prototype using the open-source Arduino micro-controller platform.The recent Howduino workshop at Lancaster was very helpful in finding (and fixing) a few bugs in the DHCP support.

Arduino with protoyping shield 

A short test at home didn't reveal much, except that cars cause far too much disturbance to the magnetic field. The next test will be at a more remote location but first I need to extend the sensor lead and add some buffering and protection circuitry. It's unlikely I'll have a network connection for time keeping so using NTP won't be possible so I'll probably add a real-time clock.