Rocketnumbernine

Installing AVR GCC on OS X

Andrew — Fri, 16 Dec 2011 07:17:00 +0000

I lost my AVR GCC installation on the upgrade to OS X Lion and I can't remember where I got the previous version from.

There's CrossPack and OSX-AVR binary packages, and you can compile the tool chain by hand to get the latest version (for example, see Option 3 at ladyada.net but you'll need to apply the latest gcc patches).

MacPorts can download, compile, and install AVR GCC 4.0.2, but since moving to Home Brew for other application installation I was disappointed to find there isn't an official AVR GCC formula yet, but as luck would have it Lars Immisch has written a set of formulas to install GCC 4.6.1, they haven't been pulled into the main Formula repository yet so the simplest way to install is:

1 2	git clone http://github.com/larsimmisch/homebrew-alt.git brew install homebrew-alt/avr/avr-libc.rb

If you don't have brew check its homepage for installation details (a one-liner)

avrdude is available in the standard formula set:

brew install avrdude --with-usb

Automating Gerbers from Eagle

Andrew — Wed, 14 Dec 2011 12:43:00 +0000

I was fed up with creating gerber files through the Eagle GUI and bundling them up manually before sending to get manufactured so created a shell script. It's not rocket science but I couldn't find that much help on the internet so the following may help others figure it out faster - have briefly tested in Eagle 6.0.0 and appears to work the same as 5.0.

Eagle gerb274x cam file screen

Gerber files, for example the top copper .cmp gerber file (created using the gerb274x cam file in Eagle pictured above), can be created from the shell using the following:

eagle -X -dGERBER_RS274X -oboard.cmp board.brd Top Pads Vias

Where Top, Pads, and Vias etc. are the eagle layers to be exported from board.brd to the board.cmp. This has to be repeated for each gerber file (silkscreen, solder mask etc.) required. "eagle -?" will display its command line options and you can assign offsets and mirror the output if you wish. If you're on windows "eaglecon.exe" should be used so it doesn't detach from the console.

Excellon drill files can be created using the following:

eagle -X -dEXCELLON -oboard.drd board.brd Drills Holes

If the board maker needs a (drl) rack file (you "run drillcfg" from within Eagle), the following lines of sed will produce the same contents from the dri file - I can't figure out how to run drillcfg without prompts without rewriting it. ). Note this only works as long as you don't adjust the drill sizes when prompted by drillcfg (which you probably shouldn't anyway):

1 2	cat board.dri \| sed -e 's/ $T[0-9][0-9]$ $[0-9.]..$./\1 \2/' \| \ grep -e "^T[0-9][0-9]" > board.drl

Finally, here's my script to create a zip of everything ready to send. Obviously use at your own risk - try creating through both the GUI and command line method and compare the output files to see what the differences are until you've tweaked it to your requirements.

#! /bin/bash
# andrew@rocketnumbernine.com - Use freely, for whatever, at your own risk.

EAGLE="/Applications/EAGLE/EAGLE.app/Contents/MacOS/EAGLE"

if [ $# -lt 1 ] ; then
        echo "usage $0 <path-to-board> [output-dir-and-file-prefix]"
        echo " e.g:  $0 my_boards/boardx.brd gerbers/board"
        echo "  will create gerber files with eagle in a directory called gerbers"
        echo "  and bundle into gerbers.zip"
        exit 1
fi

board="$1"
outputfile=${2:-"$(dirname $board)/$(basename $board .brd)"}
outputdir=$(dirname ${outputfile})

if [ ! -d ${outputdir} ]; then
        mkdir -p ${outputdir}
fi
set -e

# create top copper (cmp), bottom copper (sol), top solder mask (stc), bottom solder mask (sts), {top} silkscreen (plc)
${EAGLE} -X -dGERBER_RS274X -o${outputfile}.cmp ${board} Top Pads Vias
${EAGLE} -X -dGERBER_RS274X -o${outputfile}.sol ${board} Bottom Pads Vias
${EAGLE} -X -dGERBER_RS274X -o${outputfile}.stc ${board} tStop
${EAGLE} -X -dGERBER_RS274X -o${outputfile}.sts ${board} bStop
${EAGLE} -X -dGERBER_RS274X -o${outputfile}.plc ${board} Dimension tPlace

# create drill files
${EAGLE} -X -dEXCELLON -o${outputfile}.drd ${board} Drills Holes
# get drills used from dri file and create drl rack file 
# (like running drillcfg.ulp: ${EAGLE} -N- -C'RUN drillcfg.ulp; QUIT;' -o${outputfile} ${board}
cat ${outputfile}.dri | sed -e 's/ *\(T[0-9][0-9]\) *\([0-9.]*..\).*/\1 \2/' | grep -e "^T[0-9][0-9]" > ${outputfile}.drl

zip -r ${outputdir}.zip ${outputdir}

SMT Table Top Reflow Oven (part 3): Final Build

Andrew — Mon, 28 Nov 2011 12:00:00 +0000

Two previous articles described the my attempts to create a Reflow Oven. I finally thought it time to document the final construction.

Thermocouple

Reading a K-Type Thermcouple from a microcontroller with a MAX6675 chip was described here. I ruined several thermocouple wires when they got snagged/bent and the wire broke. To reduce the time to replace a wire I wrapped two together with kapton tape, so the backup can be plugged in if the first breaks. The two wires also makes the cable less likely to bend and break, particularly when further wrapped in some heatshrink tubing. The thermocouple was inserted through a hole in the oven and position just above the centre of the tray.

The MAX6675 code was wrapped in a simple C++ class with a read() method to return the temperature multiplied by 4 (as it comes back from the MAX6675) as an integer. See MAX6675.h and MAX6675.cpp

Rotary Encoder

By removing the existing front panel switches it was possible to mount a rotary encoder using the existing holes and fixtures.

Rotary Encoder Fit into the space from the ovens timer and 'on/off bar control' knobs.

Decoding was done as described here, except that the Arduino interrupt mechanism was used:

1 2	attachInterrupt(0, knob_turned, CHANGE); attachInterrupt(1, knob_turned, CHANGE);

This will result in the knobturned() method being called when pins 2 and 3 (connected to the rotary encoder) change level.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

void knob_turned() { _delay_ms(1); int pin0 = digitalRead(ENCODER_LEFT); int pin1 = digitalRead(ENCODER_RIGHT); if (pin0 != pinValues[0]) { rotary_encoder_change(0, pin0); } else if (pin1 != pinValues[1]) { rotary_encoder_change(1, pin1); } } void rotary_encoder_change(uint8_t changedPin, uint8_t value) { pinValues[changedPin] = value; // only increment for each 'click' of the dial - when both pins have gone back to 0 if (value == 0 && pinValues[0] == pinValues[1]) { unsigned long this_change = millis(); // if the change is within 50ms of the last then move 10 positions rather than 1 short multiplier = (last_changed != 0 && (this_change - last_changed) < 50) ? 10 : 1; target_temp += ((changedPin) ? 1 : -1) * multiplier; last_changed = this_change; }

The delay_ms(1) is used to debounce the encoder (the Arduino delay() method can't be used from within an interrupt).

Currently the target maximum temperature is set by the rotary encoder - to speed selection, the time when the last change happened is recorded and if the next change occurs within 50ms the temperature is incremented/decremented by 10 rather than 1.

The default Arduino interrupt library only supports 2 external interrupts - rather than resorting to AVR lib interrupt routine to capture when the push button is pressed - I simply polled it in the loop() method (which runs every 200ms). Pushing the button is used to turn the device on and off.

LED

The original oven had some kind of bulb that's powered by mains when the elements are on, this was replaced with a red LED controlled from the Arduino. Rather than using a current limiting resistor I just connected to one of the PWM pins (9) and used analogWrite to power for a fraction of the time:

analogWrite(9, 70);

LCD

I wanted the oven to be self contained so the screen needs to be big enough to display what's going on and to and display options etc. A 2x8 LCD was a little small, 2x16 just about big enough for all the information. There was no way to really house it neatly in the existing front panel so it was positioned vertically and some brushed aluminium sheet used to create a new panel.

New front panel showing LCD, Dial, and on/off LED button.

The standard LiquidCrystal Arduino library was used with the LCD connected to the analogue pins:

LiquidCrystal lcd(A0, A1, A2, A3, A4, A5);

The display was updated every 200 milliseconds. The current test sketch display is shown below, the display code is in the update_display() method in the sketch.

Close up of the Aluminium panel, with LCD showing actual Temperature, rate of change (°C/Second), whether the heating elements are on, the time since heating session started, and the target temperature.

Control

After completing the front panel construction I fitted the Arduino into an ABS box on the back of the oven - its cooler there and is easier to get to.

Arduino housed in ABS Box on back of oven.

I had originally intended to use a predefined reflow profile and a PID algorithm, but testing showed that with both the heater elements full on the oven reached peak (240°C) in approximately 300 seconds. The preheat is a little short and the soak and reflow stages a little long:

Temp/Time chart (for empty oven).

Using a PID algorithm won't make the reflow stage any quicker. To test I've used a small Arduino script that lets the user select the maximum temperature, the heating elements are then turned on until the max is reached. Usually open the door to increase the cooling rate.

The source can be found here, a few tests have shown acceptable results.

First Reflow solder test: SOIC 16, perhaps to little solder.

I'd bridged a few of the pads with smear of paste but the reflow process has successfully 'sucked' the solder onto the pad apart from a few beads.

Closeup of solder joint.

Conclusions

I've been using the oven for awhile now on simple boards with some success - the boards have been fairly simple and haven't had to fix any issues. I'm still deciding whether to spend the time implementing (and more importantly tuning) a PID controller for the oven. My feeling is that the ovens elements can't be made to increase/decrease the ovens temperature quick enough to make it worthwhile.

Others say that applying solder paste by hand and using an oven is as time consuming as using a soldering iron, but I find the process quicker, cleaner (even with a solder fume extractor), and less of an eyestrain - I find it easier to hold a syringe of paste under a microscope than a soldering iron.

References/Bibliography

Programming the AD9851 DDS synthesizer

Andrew — Tue, 25 Oct 2011 06:36:00 +0000

I don't have and have never really had the desire for a signal generator, but have wanted to play with the AD9851 DDS chip (a digitally controllable 0-180MHz sine wave generator) for awhile and managed to win an ebay auction for a "AD9851 Module DDS Signal Generator with Circuit Diagram" for $23.50 including shipping from China to Europe, that's cheaper than digikey charge for the chip alone!

AD9851 DDS Board

The board arrived in less than a week and was marked as "valued at $3" so no customs were charged. The Circuit diagram included on the ebay auction had no resemblance to the device I got, but it seems the design is the same or similar to most of the barebone AD9851 boards on ebay - just the chip, 30MHz crystal, header pins, bypass caps, and a low pass filter.

Approximate Schematic found on ebay (D7 and GND are swapped on my board but otherwise the components and PCB traces seem to just about match).

The device has 3 7-pin headers: 2 control headers (only 1 is needed for serial control), an output header providing the raw outputs provided by the AD09851, and 4 2-pin junction connectors, used to select serial/parallel mode, externally control the output current and for the generated sine wave itself.

The AD9851 is controlled (see the datasheet) by a 40 bit control word consisting of a 32 bit 'frequency tuning word' and an 8 bit 'control' word comprising of 5 bits of phase angle (so that multiple AD9851s can be controlled from the same clock outputing the same sine wave shifted by a different amount.), a shutdown bit, and a flag indicating whether the system clock should be multiplied (allowing the device to generate a 180MHz from a 30MHz oscillator).

The frequency of the sine wave produced is:

        <system clock> * <frequency tuning word> / 2^32

so the 'frequency tuning word' required to send to the device is calculated as follows:

        <desired frequency> * 4294967296.0 / 180.0e6;

Because the 'frequency tuning word' is a 32 bit integer, when it is incremented by 1 the sine wave increases by .0419Hz - also the minimum frequency - when the tuning word is set to 1 a slow rising signal can be seen on a scope.

The control word can either be transferred in parallel (byte at a time) or serially. In serial mode the chip can be controlled with only 3 pins (plus VCC and GND), basically a bit from the control word is written to the DATA pin, WCLK is pulsed high until all 40 bits have been sent and then FQUD is pulsed high to transfer the 40 bits from a buffer to the control register as shown below from the datasheet:

I found the reset pin could be left tied low in these simple tests but i'd do an explicit hardware reset pulse in an application. The following is some Arduino/C code to transfer the data to an AD9851 on pins DATA, WCLK, and FQUD.

#define pulseHigh(pin) {digitalWrite(pin, HIGH); digitalWrite(pin, LOW); }

// transfer a byte a bit at a time LSB first to DATA
void tfr_byte(byte data)
{
  for (int i=0; i<8; i++, data>>=1) {
    digitalWrite(DATA, data & 0x01);
    pulseHigh(W_CLK);
  }
}

// frequency of signwave (datasheet page 12) will be:
//   <sys clock> * <frequency tuning word> / 2^32
void sendFrequency(double frequency) {
  int32_t freq = frequency * 4294967296.0 / 180.0e6;
  for (int b=0; b<4; b++, freq>>=8) {
    tfr_byte(freq & 0xFF);
  }
  tfr_byte(0x01); // control byte - zero phase shift
  pulseHigh(FQ_UD);
}

Get the full sketch here

Note that a microcontoller SPI bus can also be used to talk to the device (SPI Mode 0, LSB first, replace tfrbyte() with SPI.transfer()) with SPI SCK and MOSI pins used for WCLK and DATA pins respectively. Doing it manually allows any I/O pins to be used, but is a little slower. Full source of a SPI arduino sketch is here.

Below shows a quick oscilloscope trace for a 1303Hz wave - it looks reasonable.

That's it for now - I might spend some more time looking at the output waveforms if I can find a use for the device.

References/Bibliography

Example Arduino Sketch

Example SPI Version Arduino Sketch

Using the ICM7218 LED driver

Andrew — Thu, 11 Nov 2010 13:24:56 +0000

Looking for something interesting to reach the minimum value on a component order, I picked up a couple of Maxim ICM7128 LED drivers, actually I got some Intersil ICM7228 which is interchangeable. The following shows some experiments to explore its capabilities - an Arduino is used but the C code extracts should be usable on any platform.

Overview

The two main issues with driving LEDs from a microcontroller is the number of IO pins required often exceeds that available, and the current drawn by the LEDs can exceed the maximum allowed from the device. Although Charlieplexing and driver circuitry can be used to get around these, an off the shelf chip that takes the burden can simplify a project.

The Maxim ICM7128 can drive up to 8 7-segment displays or an 8 by 8 matrix of individual LEDs with only 2 extra components (2 bypass capacitors). The 7218 comes in a number of varieties, for example, 7218A and 7218B variants provide support for common anode and common cathode circuits respectively.

The example circuit below is from Intersil ICM 7228 datasheet (exact pins vary between variants but functionality is same), the pins connected to switches are instead wired to a microcontroller.

Data can be output to the device in raw/undecoded mode which allows each 7-segment segment and the decimal point to be individually controlled (which would be used if an LED matrix were being used), or in Hex (0123456789AbCdEF) or Code-B (0123456789-EHLP ) format which eliminates the need for the microcontroller program to store the segments that need to be lit for each number.

Once the desired state of the LEDs is sent to the 7218, it takes care of multiplexing the LED matrix, each segment is lit every 1/250 of a second - which should ensure no flicker is visible.

The Maxim 7218A can provide a minimum of 30mA per LED. However, the common cathode version (7218B/7228B) only provides a quater of that.

Experiments

The 7228 is fairly simple to use, the 8 data bus pins: ID0,..,ID7 and MODE pin are set to desired values and the WRITE is pulsed low for atleast 250ns to indicate the device should read. Each interaction with the device follows the same pattern: a control byte followed by 0 or more data bytes containing data for display:

MODE is set to 0 and a byte of control data is written to ID0,..,ID7 and WRITE pulsed low.
MODE is set to 1 and 0 or more data bytes are written to ID0,...,ID7 each followed by a low pulse of WRITE.

The following shows some Arduino code to test the various features of the 7228, the full Arduino source can be found here.

First the 8 data pins and 2 control pins are connected to the arduino, we'll define some constants to simplify accessing them from code:

#define MODE_PIN 10
#define WRITE_PIN 11
#define ID0_PIN 2
#define ID_PIN(i) ID0_PIN+i

So the Mode and Write pins are on Arduino Digital Pins 10 and 11, to simplify the code we assume that pins ID0 to ID7 are connected to consecutive Arduino pins starting at pin 2, so we can define a function ID_PIN() to give us a particular pins number based on an offset, so to set ID4 high we can write:

digitalWrite(ID_PIN(4), HIGH);

To pulse the write pin low we write a 0 and then 1 (a digitalWrite call takes approximately 5Âµs on a 16MHz Arduino, which is longer than the 250ns required minimum low WRITE pin pulse width - see the write cycle timing in Figure 3 on page 7 of the datasheet).

void writePulse() {
  digitalWrite(WRITE_PIN, LOW);
  // 250ns delay not explicitly required
  digitalWrite(WRITE_PIN, HIGH);
}

In the following examples, we'll store the values to be sent to the ID0,..ID7 pins in the 8 bits of an unsigned char (with the value of ID0 in bit 0, ID1 in bit 1 etc). The following helper function takes the desired value of the MODE pin and an array of data, each bit is written to its corresponding IO pin and therefore the the 7218 input data line and then a writePulse sent to force the device to read the input.

void sendBytes(unsigned char data[], int length,
               boolean mode)
{
  // set the desired mode
  digitalWrite(MODE_PIN, mode);

  for (int i=0; i<length; i++) {
    for (int c=0; c<8; c++) { // for each bit
      digitalWrite(ID_PIN(c), data[i] & 1<<c);
    }
    writePulse(); // tell the 7218 to read the data
  }
}

Because a command to the 7218 device consists of a byte of control data sent with MODE pin high and then 0 or more data bytes sent with MODE pin low, we can abstract into a function, calling the sendBytes twice, first for the control byte and then any data:

void sendCommand(unsigned char control,
                 unsigned char digit[], int length)
{
  sendBytes(&control, 1, 1);
  sendBytes(digit, length, 0);
}

So for example, to send a control byte with ID4, ID6, and ID7 set High (and all others low), and then send 8 display data bytes held in array 'digits', we could use the following:

sendCommand(1<<4 | 1<<6 | 1<<7, digits, 8);

1<<4 sets the 4th bit (00010000 in binary) 1<<6 the 6th, and 1<<7 the 7th and we OR them together to get 11010000.

The table below summarises the meaning of the ICM7218 data pins in control mode (when MODE is High), each of the features is described below

ICM7228 Control Pin Descriptions
Pin	Name	if High	if Low
ID7	Sequential Data Update Select	Data Coming	No Data Coming
ID6	Decoding Scheme Selection (if ID5 Low)	Hex	Code B
ID5	Decode/No Decode Selection	No Decode	Decode
ID4	Lower Power Mode Select	Normal Operation	Display disabled
ID3	RAM Bank Select	Bank A	Bank B
ID2	Single Digit Address Mode Select (if ID7 Low)	Digit Address Bit 2
ID1	Single Digit Address Mode Select (if ID7 Low)	Digit Address Bit 1
ID0	Single Digit Address Mode Select (if ID7 Low)	Digit Address Bit 0

Lower Power Mode Select - ID4

Sending a control byte with ID4 = 0, puts the ICM7128 into low power 'shutdown' mode: the digits are blanked and the multiplexing oscillator is stopped. the datasheet claims the devices will use 10ÂµA when shutdown but about 3ÂµA was observed.

sendCommand(0x00, 0, 0);

If the device remains on but the the segments are turned off the device uses about 200ÂµA.

Decoding - ID5 & ID6

ID5 and ID6 control how the ICM7218 will treat the display data that follows, which can be in one of three modes:

No Decode (ID5 High) - each segment of the digits can be controlled individually by a bit of ID0-ID7. This mode would be used when a matrix of LEDs are being controlled rather than 7-Segment displays.
Hex Mode (ID5 Low, ID6 High) - the device will treat the input on pins ID0-ID4 as a number and display the according Hexadecimal character on the digit: "0123456789AbCdEF".
Code-B Mode (ID5 Low, ID6 Low) - the device will treat the input on pins ID0-ID4 as a number and display the according Code B character on the digit: "0123456789-EHLP " (the last digit is a space and can be used to blank a digit)

Note, that in all modes the decimal point is controlled by ID7 - a 0 value will turn it on and 1 value turn it off - the other way around would have seemed more natural. When Hex and Code-B mode is being used only 4 bits of data (excluding the decimal point) need to be stored - the 7228 makes use of this by providing ability to store two values for each digit, selected by ID3 - RAM Bank Select - the decimal point is set for both banks however. I can't see of many practical uses for this.

Sequential Data Update Select - ID7

After the control byte, display data is sent to the device, this can be a sequence of bytes for each digit (from digit 0, to digit 7) or a data for a specific digit:

ID7 High - Data Coming, the device will expect a succession of display data on each following pulse of the WRITE pin.

1 2	unsigned char digit[] = { 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87 }; sendCommand(1<<4 \| 1<<6 \| 1<<7, digit, 8);

ID7 Low - Data not coming, bits ID0, ID1, and ID2 form the 3 digit address of the single digit data that follows, so we can repeat the behaviour of the example above by looping over each digit:
1 2 3 4
for (unsigned char i=0; i<8; i++) { // i will fill the 3 low bits of the command byte(ID0, ID1, and ID2) sendCommand(i | 1<<4 | 1<<6, &i, 1); }

An example of using no decode mode is shown below, it loops around lighting each LED segment (stored in the 'segment' array) on each digit in.

unsigned char segment[] = { 1<<6 | 0x80, 1<<5 | 0x80, 1<<2 | 0x80,
       1<<3 | 0x80, 1<<0 | 0x80, 1<<4 | 0x80, 1<<2 | 0x80, 1<<1 | 0x80};
  for (int i=0; i<3; i++) {
    for (unsigned char digit=0; digit<8; digit++) {
      for (int j=0; j<8; j++) { 
        sendCommand(digit | 1<<4 | 1<<5, &segment[j], 1);
        delay(50);
      }
    }
  }

Although the examples above assume a 7 segment display, the ICM7218 could be used to control a 8x8 matrix of LEDs, here the advantage of offloading multiplexing to an external device is evident - if the desired on/off values are held in an 8 byte array, then the microcontroller can send the data to the device and continue processing:

1 2	unsigned char data[8] = ... sendCommand(1<<4 \| 1<<5 \| 1<<7, data, 8);

Finally, an example that counts up from zero. Each time the count is incremented the 8 digits are filled with the appropriate decimal digit value and the entire set of digits rewritten:

unsigned char digit[8];
 for (int count=0; count<999999; count++) {
   for (int power=1, i=0; i<8; i++, power*=10) {
      digit[i] = (count/power % 10) | 0x80;
    }
    sendCommand(1<<4 | 1<<6 | 1<<7, digit, 8);
    delay(50);
  }

Conclusions

The ICM7218 is a good all-rounder, in summary:

Simplifies control of upto 8 7-segment displays or a 8x8 grid of LEDs by reducing the components required and simplifying microcontroller code.
Fairly widely available in small quantities, although not cheap - the price varies widely between suppliers so its worth shopping around.
Available in through hole and SMD versions.
Incredibly simple to use API.
Common Cathode versions (B & D) have limited current output.
Not possible to adjust the power sent to the LEDs (either digitally or through a single trim resistor).
Uses 10 controller IO pins - although if using Hex or Code-B without decimal point only need to connect 6 pins (ID0-ID3, MODE, and WRITE), the others could be hardwired. See here for an example of fronting the ICM7218 with an I2C interface chip to reduce the number of pins to 2.

Other LED driver chips are available (for example see Maxim's range - with better LED intensitiy, or SPI/I2C control to reduce the number of IO pins required, but the 7218 has its uses.

References/Bibliography

Example Arduino Sketch

Maxim ICM7218/7228 Datasheet

Intersil ICM7228 datasheet

Use of ICM7218 with an I2C chip and only 2 IO pins

Decoding a Rotary Encoder

Andrew — Sat, 06 Mar 2010 22:03:02 +0000

This article details a simple approach to decoding the output of a 2 bit incremental Rotary Encoder. The example uses interrupts with AVR GCC on an Arduino platform, but the same interrupt setup can be used on most AVR chips and the approach will of course work on any device.

Rotary Encoder on Arduino prototype shield

Rotary Encoders can offer high precision, long life and a simpler/digital interface over analogue devices, such as potentiometers, for reading a rotational movement on a computer. They're often fairly expensive, but I recently picked up a bargain pack on eBay and Mouser also have a selection for around a dollar.

There are a number of interface and encoding techniques used by encoders, ranging from devices that provide a digital output of the angle of the shaft - with resolutions ranging from 8 to over 8000 counts per revolution, to simple 2 bit incremental encoders which report clockwise or counterclockwise movement of the shaft, this article looks at decoding the latter.

The rotary encoder indicates movement by toggling the output of two pins from high to low or vice-versa, the direction of rotation is indicated by which line goes high (or low first) as shown in the following diagram from wikipedia:

The waveform produced from the encoder I tested with when rotating clockwise then counter clockwise is shown below:

Decoding the Encoder

There are many ways of decoding the changes in pin logic level to direction of rotation, but I think the following is the simplest. If you look at the waveforms above, a clear pattern emerges: travel from left to right over the waveform above (simulating rotation the shaft in one direction), when the inputs are the same (both high or both low) the last input to have changed will be A, if the inputs are different then the last input to have changed will be B. If the shaft is rotated in the reverse direction (travelling from right to left over the waveform) the opposite is true. If we write these conditions in binary expressions: A is equal to B, last changed pin is A, direction is left we can create a truth table:

A==B	changedPin==A	direction==left
true	true	false
true	false	true
false	true	true
false	false	false

From this we see that the we can use a simple XOR to calculate the direction of travel (direction == left) = (A == B) ^ (changedPin == A)

Note, that the above generates 4 rotation signals on each complete quadrature rotation - with some encoders this is too high a resolution (the mechanical ones I've tested this with are 'stepped' - they click as the shaft is turned, resting with with both pins at zero). So it may be better to just record movement when both pins pins have fallen to the low state (A == 0 && B == 0) and ignore other changes.

Detecting Pin Changes

The two pins from the rotary encoder are attached to digital IO pins on the microcontroller and held to ground with a resistor until rotation causes them to be go high. Rather than polling for changes, interrupts are used to trigger execution of a handler function every time the line state changes. This allows for other operations to be done whilst waiting for input.

In this example AVR external pin change interrupts are used. These can be used to detect changes on nearly all of the devices IO pins. PCINT18 and PCINT19 are used below, these are triggered by changes to the AVR IO pins PD2 and PD3 - Arduino pins D2 and D3 respectively, see here for a mapping. Pin change interrupts are handled in 3 groups, PCINT0..7, PCINT8..14, PCINT16...23 and are controlled by the PCICR and PCMSK0-PCMS2 registers, we're using pins in the same group to simplify setup. Note that we have to use the same interrupt handler to receive events for both pins, the pin value is queried to see which has changed:

void setup()
{
  Serial.begin(19200);
  pinMode(2, INPUT); // 2 Encoder pins as inputs
  pinMode(3, INPUT);
  // enable interrupts on those two pins:
  PCICR |= (1 << PCIE2); 
  PCMSK2 |= (1 << PCINT18) | (1 << PCINT19);
  sei();
}

Debouncing

The mechanical encoder I tested with create multiple triggers on a single transition due to bouncing. The encoders datasheet claims a maximum bounce of 5ms, but I didn't see more than 1ms. The waveform below shows a very much worse case of a pin transitioning from high to low.

This is simply debounced in software by waiting for 1ms and then reading the pin values - if neither has changed from the stored value we ignore the trigger. Note, that this technique will fail if the shaft is being rotated to fast and the width of the cycle approaches 1ms or the two signals are less than 1ms apart.

volatile uint8_t pinValues[2] = {0,0};
volatile int position = 0;

ISR(PCINT2_vect)
{
  _delay_ms(1);
  int pin0 = digitalRead(2);
  int pin1 = digitalRead(3);
  if (pin0 != pinValues[0]) {
    rotary_encoder_change(0, pin0);
  } else if (pin1 != pinValues[1]) {
    rotary_encoder_change(1, pin1);
  }
}

The previous values are stored in a two value byte array and we refer to pins A and B as 0 and 1 in the code to simplify things. The Rotary Encoder decode logic is the simple boolean expression ((pinValues[0] == pinValues[1]) ^ changedPin) which returns true or false to indicate clockwise or counter clockwise shaft rotation. This is used to increment or decrement an integer counter, which the main loop prints back to the host computer.

void rotary_encoder_change(uint8_t changedPin, uint8_t value)
{
  pinValues[changedPin] = value;
  position += ((pinValues[0] == pinValues[1]) ^ changedPin) ? 1 : -1;
}

void loop()
{
  Serial.println(position);
  delay(100);
}

Conclusions

This is a fairly simple technique that works well for slow rotations of the shaft, but fast rotations of the shaft get lost or be reported in the wrong direction - good for replacing potentiometers as instrumentation dials but not for recording the exact movement of a motor etc.

Full source is here.

References/Bibliography

Wiki Rotary Encoder Page

Arduino/Atmega168 pin mapping

Atmega 168/328 datasheet - see chapter 11 and 12 for interrupt details.

External Time Capsule Fan

Andrew — Sun, 22 Nov 2009 15:24:00 +0000

My Apple Time Capsule runs hot - approaching 50°C to the touch - this isn't helped by the lack of space it has and the Apple TV stacked on top (I've added some legs to give some space below and above for air to flow. On large backups/restores during the summer - the device often went into over heat warning mode. There's also worrying reports of the power supply overheating and Time Capsules dying.

I originally thought of a standard PC fan with some kind of thermistor /thermocouple/sensor and a simple control circuit to activate the fan when temperature gets too hot, but stumbled across Arctic Cooling Pro TC F9 fan which has a temperature sensor on a 40cm cable to turn up the fan speed when the temperature rises above 32°C.

Replacing the plug with a 2.1mm power jack to fit a 12V wall wart PSU and creating a stand with a loop of wire coat hanger sleeved in heat shrink to give it a nice black cover to match the fans case and the unit was ready to go. Taping the end of the temperature sensor to the top of what felt the hottest part of the Time Capsule (over the power supply next to the power inlet) reduced the temperature to less than 30Â°C. I though the fan might be too low powered initially but it manages to cool all the devices on the shelf it's on.

The unit is silent - at least quieter than the ambient noise and hopefully will extend the life of the Time Capsule.

References/Bibliography

SMT Table Top Reflow Oven (part 2): Controlling the Heater Elements

Andrew — Thu, 27 Aug 2009 20:24:16 +0000

In a previous article I described insulation of a mini/toaster oven with the aim of using it for table top reflow soldering. Some manual tests have been encouraging. This article documents creation of the circuitry required to turn the ovens heating elements on and off under control of a microcontroller. I'm still not convinced that the oven can increase its temperature fast enough to warrant attempting to recreate a 'proper' reflow profile, but even if not, using a microcontroller to log and display the temperature and turn off the heating elements when the peak is reached will still be worthwhile.

The circuitry below involves mains electricity, don't try this unless you are sure you know what you are doing - check, test and insulate repeatedly and thoroughly.

There are a number of commercial relay control boards available, for example Futurlec and Elector.

The Hinari HTP033 oven has two elements and a total power rating of 630W - so each draws just over 1.3A at 240V (UK mains voltage), this obviously can't be provided directly from a microcontroller IO pin but requires some kind of relay. There's a huge range of relays available - I choose a IMO SRRHN-1C-S-5VDC, this can operate at 5Volts, draws 100mA (I actually found it took under 75mA) and is fairly cheap (a few Â£). Although a 5V device can be driven from a microcontroller IO pin, 100mA is too high a load, 40mA is the maximum for most AVR Microcontroller IO pins, although the maximum current drain for the entire device is around 200mA, so 40mA can only be driven on a few IO pins at once.

Driving the relay

A simple transistor/resistor circuit can be used to control the relay with much lower power drain. Basically the transistor (I used a 2N2222A) is being used as a current amplifying switch. When the transistor is being used in on/off mode - only approximate mental/back of the envelope maths are needed to calculate the values of the resistors (Search Google for more background).

From the transistors datasheet, when the 100mA of current required to power the relay flows from collector to emittor the transistor will provide a minimum gain of just under 100 - so atleast 1mA needs to flow into the transistors base, if the IO pin is high at 5V and there's a 1V voltage drop from the transistors base to emitter, a resistor of 4K will provide this (R = V/I = (5V-1V)/1mA). To cope with less gain and a lower Vbe voltage, it's best to provide much more current to I used a 1330R and measured 3.5mA going into the base of the transistor when on.

Resistor R2 connects the base to ground when the input is unconnected. This ensures the relay will be safely turned off during microcontroller startup. The 10K resistor ensures the current flowing through it when the input is high will be low.

The relay is just a coil of wire which acts as an electromagnet when current flows through it, unfortunately when the power is switched off it will act as an inductor pumping current back into the circuit - the diode protects the transistor when this happens by providing a 'return path' to the 5V supply.

Installation

The circuit (2 of them) was simple enough to build on a Prototype/Vero board (pictured above) and housed in a plastic box to protect from earthing. I bypassed the ovens element and timer controls and passed the live mains wire to the relay box with an output to each of the elements.

Some brief tests with an Arduino turning on the relay control pins showed that the relevant oven element came on perfectly, with a reasuring click from the relay as it switched. Now I have more control over the ovens elements the plan is to do more extensive testing to see how controllable the temperature is.

References/Bibliography

IMO SRRHN-1C-S-5VDC
Google Search: Using transistor as a power switch
2N2222A transistor datasheet
Commercial Relay boards: Futurlec andElector.
Some other relay control articles on the web SparkFun

Using SPI on an AVR (3)

Andrew — Fri, 03 Jul 2009 21:08:29 +0000

This is a follow up to Using SPI on an AVR (1) and Using SPI on an AVR (2) articles which illustrated using an AVR Microcontroller to communicate with some simple SPI Slave devices. This entry shows two AVR Micro controllers communicating with each other through SPI - one acting as Master and one as Slave. An interrupt handler is used in the slave to notify it when data is being received. One device is an at90usb162 on a Teensy Board running AVR GCC code, the other an Arduino (with ATmega328) although the code should run on most AVR microcontrollers and Arduino versions that are SPI capable.

AVR SPI Slave Mode

When a device is operating as the SPI slave device it receives data under control of the master:

The slave devices slave select (SS) pin is brought low by the master.
The master oscillates the SCK clock as it places bits onto the MOSI line and reads from the MISO line.
It's the master's responsibility to use the SPI mode the slave is expecting (whether data is written and read on the rising or falling edges of the clock) and to make sure the clock rate is not too high for the slave.

The AVR's built in SPI hardware takes care of receiving and processing the SPI data and placing the received data a byte at a time onto the SPI data register buffer, the program simply needs to consume the read bytes from the buffer fast enough.

There are two ways for the program to ascertain when data is ready, it can either poll the SPI status register to see when a byte has been received (SPSR = (1<<SPIF)) - the same send_spi() helper function that was developed in a previous article can be used. Alternatively the SPI system can be configured to generate an interrupt when a byte has been received and is ready to read from the buffer. This is achieved by setting the SPIE bit in the SPI control register (SPCR = (1<<SPIE)), I encapsulated this as a parameter to the spi setup helper function developed earlier.

setup_spi(SPI_MODE_1, SPI_MSB, SPI_INTERRUPT, SPI_SLAVE);

Example

To reduce the amount of code to be written, each program (the AVR GCC and Arduino) acts as both master and slave, and either part can be replaced with the other (ie. two Arduinos can be used etc.). The circuit is shown below, apart from the SPI connections each device has an LED and a push button connected.

When the push button on one device is pressed, the LED on the other flashes. This is achieved using the following logic:

The device is put into SPI slave mode so that an interrupt is raised when data is received on the SPI bus.
When the button is pressed the program puts the AVR into SPI master mode and sends the slave a message (a number of bytes) then goes back into slave mode.
The program's SPI interrupt handler simply stores the bytes received in a buffer until a terminating null byte (0x00) is received, it then parses and processes the message.
Currently a single message type is supported - FLASH_LED (0x00) which is followed by a byte containing the number of times the slave should flash its LED - so to make the slave flash its LED 5 times the master would send 3 bytes - 0x01, 0x05, 0x00.

With the SPI system in slave mode and with interrupts enabled the interupt service handler for SPISTCVect will be called when a byte has been received. All the handler implementation does (below) is save the byte received from SPI in a buffer (incoming) and checks if the byte received is null or we've filled the buffer, if so the parse_message() is called to process the data received. As stated previously the interrupt handler mu st return fast enough to handle the next received byte. Whilst the handler is running interrupts will be disabled and if it takes too long data will be lost.

ISR(SPI_STC_vect)
{
  incoming[received++] = received_from_spi(0x00);
  if (received >= BUFSIZE || incoming[received-1] == 0x00) {
    parse_message();
    received = 0;
  }
}

The receivedfromspi() function simply reads the byte read from the SPI pipeline and sets the value of the next byte to be sent - note the SPDR buffer is double buffered so the value can be written before being read.

unsigned char received_from_spi(unsigned char data)
{
  SPDR = data;
  return SPDR;
}

Using an interrupt handler to receive and process the SPI data allows the AVR to perform other tasks, or sleep, until all data is ready.

Sending a SPI message on button press

We also use an interrupt to trigger sending of a message when a button is pressed in the SPI master. We configure the AVR to trigger an interrupt when a pin goes low due to the button being pressed. The Arduino has a helper function to set this up:

attachInterrupt(0, button_pressed, FALLING);

This will result in the function "buttonpressed" being called when external interrupt 0 (Connected to Arduino pin D2) goes from high to low (FALLING). In native AVR GCC this takes a little more effort - we set the relevant bits in the EICRB register to receive an interrupt on a falling signal (ISCO1 and ISC00), enable external interrupts in EIMSK register, and then enable interrupts (sei()). See the External Interrupt Channel of the relevant AVR datasheet for details of the registers.

1 2 3

EICRB = (1<<ISC01) | (0<<ISC00); EIMSK |= (1<<INT0); sei();

The above configuration results in the handler named ISR(INT0vect) being called when the INT0 pin goes from high to low, both this and the Arduino's buttonpressed() just call the sendmessage function to transmit a message. This attempts to put the device into SPI master mode, checks that it was successful (If its select pin isn't low) and if so selects the other device, sends 3 bytes, then deselects the other device and goes back into slave mode:

void send_message()
{
  setup_spi(SPI_MODE_1, SPI_MSB, SPI_NO_INTERRUPT, SPI_MSTR_CLK8);
  if (SPCR & (1<<MSTR)) { // if we are still in master mode
    SELECT_OTHER; // tell other device to flash LED twice
    send_spi(FLASH_LED_COMMAND); send_spi(0x02); send_spi(0x00);
    DESELECT_OTHER;
  }
  setup_spi(SPI_MODE_1, SPI_MSB, SPI_INTERRUPT, SPI_SLAVE);
}

The AVR spec says the SPI clock frequency in the slave device shouldn't exceed the MCU frequency/4 - I've found frequency/8 is safer.

We've seen that the slave device just stores byte received until it receives the terminating null byte, it then calls parsemessage(). This checks the value of the first byte in the buffer and parses the remaining bytes accordingly. The current implementation just supports the single FLASHLED_COMMAND which reads the next byte and flashes an LED that number of times. If we receive an unexpected message the LED is flashed repeatedly:

void parse_message()
{
 switch(incoming[0]) {
 case FLASH_LED_COMMAND:
   flash_led(incoming[1]);
   break;
 default:
   flash_led(20);
 }
}

The complete programs are shown below and are also included as examples in the SPI helper library zip below AVR GCC:

#include <avr/interrupt.h>
#include <util/delay.h>
#include <spi.h>

#define FLASH_LED_COMMAND 0x01
#define OTHER_SELECT_PIN PB6
#define SELECT_OTHER PORTB &= ~(1<<OTHER_SELECT_PIN)
#define DESELECT_OTHER PORTB |= (1<<OTHER_SELECT_PIN)

#define BUFSIZE 20
volatile unsigned char incoming[BUFSIZE];
volatile short int received=0;


// flash led that's connected to pin PD7
void flash_led(int count)
{
 DDRD |= (1<<PD7);
 for (int i=0; i<count*2; i++) {
   PORTD ^= (1<<PD7);
   _delay_ms(75);
 }
}

// send a SPI message to the other device - 3 bytes then go back into
// slave mode
void send_message()
{
 setup_spi(SPI_MODE_1, SPI_MSB, SPI_NO_INTERRUPT, SPI_MSTR_CLK8);
 if (SPCR & (1<<MSTR)) { // if we are still in master mode
   SELECT_OTHER; // tell other device to flash LED twice
   send_spi(FLASH_LED_COMMAND); send_spi(0x02); send_spi(0x00);
   DESELECT_OTHER;
 }
 setup_spi(SPI_MODE_1, SPI_MSB, SPI_INTERRUPT, SPI_SLAVE);
}

// called when the button pushed and pin INT0 goes from 1 to 0
ISR(INT0_vect)
{
 send_message();
 _delay_ms(500); // 'debounce'
}

// parse the data received from the other device
// currently just knows about the FLASH_LED_COMMAND
void parse_message()
{
 switch(incoming[0]) {
 case FLASH_LED_COMMAND:
   flash_led(incoming[1]);
   break;
 default:
   flash_led(20);
 }
}

// called by the SPI system when there is data ready.
// Just store the incoming data in a buffer, when we receive a
// terminating byte (0x00) call parse_message to process the data received
ISR(SPI_STC_vect)
{
 incoming[received++] = received_from_spi(0x00);
 if (received >= BUFSIZE || incoming[received-1] == 0x00) {
   parse_message();
   received = 0;
 }
}

int main(void)
{
 // make sure other device is unselected (pin is HIGH) and setup spi
 DESELECT_OTHER;
 DDRB |= (1<<OTHER_SELECT_PIN);
 setup_spi(SPI_MODE_1, SPI_MSB, SPI_INTERRUPT, SPI_SLAVE);

 // raise interrupt when the button is pushed and INT0 pin goes
 // from 1 to 0 (pin PD0 at AT90usbXXX, pin PD2 on ATmegaXXX,
 // arduino pin 2)). The code in ISR(INT0_vect) above will be called
 EICRB = (1<<ISC01) | (0<<ISC00);
 EIMSK |= (1<<INT0);
 sei();

 // flash LED at start to indicate were ready
 flash_led(1);

 while (1); // do nothing
}

Arduino:

#include <spi.h>
#include <util/delay.h>

#define BUTTON_PIN 2
#define LED_PIN 3
#define FLASH_LED_COMMAND 0x01

#define OTHER_SELECT_PIN 7
#define SELECT_OTHER digitalWrite(OTHER_SELECT_PIN, LOW);
#define DESELECT_OTHER digitalWrite(OTHER_SELECT_PIN, HIGH);

#define BUFSIZE 20
volatile unsigned char incoming[BUFSIZE];
volatile short int received=0;

// flash led that's connected to pin PD7
void flash_led(int count)
{
 pinMode(LED_PIN, OUTPUT);
 for (int i=0; i<count*2; i++) {
   digitalWrite(LED_PIN, i%2==0);
   _delay_ms(75);
 }
}

// send a SPI message to the other device - 3 bytes then go back into
// slave mode
void send_message()
{
 setup_spi(SPI_MODE_1, SPI_MSB, SPI_NO_INTERRUPT, SPI_MSTR_CLK8);
 if (SPCR & (1<<MSTR)) { // if we are still in master mode
   SELECT_OTHER; // tell other device to flash LED twice
   send_spi(FLASH_LED_COMMAND); send_spi(0x02); send_spi(0x00);
   DESELECT_OTHER;
 }
 setup_spi(SPI_MODE_1, SPI_MSB, SPI_INTERRUPT, SPI_SLAVE);
}


// called when button pushed and pin INT0 goes from 1 to 0
void button_pressed()
{
 send_message();
 _delay_ms(500);  // 'debounce'
}

// parse the data received from the other device
// currently just knows about the FLASH_LED_COMMAND
void parse_message()
{
 switch(incoming[0]) {
 case FLASH_LED_COMMAND:
   flash_led(incoming[1]);
   break;
 default:
   flash_led(20);
 }
}

// called by the SPI system when there is data ready.
// Just store the incoming data in a buffer, when we receive a
// terminating byte (0x00) call parse_message to process the data received
ISR(SPI_STC_vect)
{
 incoming[received++] = received_from_spi(0x00);
 if (received == BUFSIZE || incoming[received-1] == 0x00) {
     parse_message();
     received = 0;
  }
}

void setup()
{
 // make sure other device is unselected (pin is HIGH) and setup spi
 DESELECT_OTHER;
 pinMode(OTHER_SELECT_PIN, OUTPUT);
 setup_spi(SPI_MODE_1, SPI_MSB, SPI_INTERRUPT, SPI_SLAVE);

 // raise interrupt when INT0 pin falls (arduino pin 2))
 // the function button_pressed will be called
 attachInterrupt(0, button_pressed, FALLING);

 // flash LED at start to indicate were ready
 flash_led(1);
}


void loop()
{
}

References

Using the MAX6675 Thermocouple-to-Digital Converter

Andrew — Sat, 27 Jun 2009 18:51:55 +0000

I've been asked for the code used to read the MAX6675 Thermocouple-to-Digital Converter used to measure the temperature in my ongoing SMD Reflow Oven project. The following is based on an Arduino (with a home built SPI helper library) but is fairly generic and should be applicable to most platforms.

Maxim's MAX6675 8-pin SOIC chip is a compact and simple to use solution for converting the output of a type K thermocouple to a digital temperature value read over SPI. It provides Digital to Analogue conversion of the voltage produced by the thermocouple, cold-junction compensation, noise reduction and processing of the result into a binary temperature value at a precision of 0.25Â°C.

SO - MISO (Arduino D12), SCK (Arduino D13), CS (Arduino D8)

Circuit used (from the datasheet sheet) is shown to the right. I used a breadboard for the circuit but created a breakout board for the (SMD) MAX6675 chip and decoupling capacitor with BatchPCB.

The thermocouple is connected to pins 2 and 3 - if connected the wrong way around the temperature output from the MAX6675 will go down as the end of the thermocouple is heated. Connecting the MAX6675 to the Arduino is straightforward - just power and the SPI MISO and SCK (clock) and chip select line (^CS). Pin D8 was used to select the device.

SPI Setup

From the datasheet we see that the MAX6675 transmits the temperature in 2 bytes - most significant bit first. The clock is expected to be idle low and data can be read when it is falling (SPI mode 1). The MAX6675 can take a maximum SPI clock rate of 4.3MHz - as the Arduino was running at 16MHz a SPI data rate of Clock/8 (2MHz) was specified so the device was operating well within its tolerances. The following sets up up the MAX6675 chip select pin (Arduino Pin D8) control pin, SPI and the Arduino Serial line:

#define MAX6675_SELECT_PIN 8
#define DESELECT_MAX6675 digitalWrite(MAX6675_SELECT_PIN, HIGH)
#define SELECT_MAX6675 digitalWrite(MAX6675_SELECT_PIN, LOW)

void setup()
{
  pinMode(MAX6675_SELECT_PIN, OUTPUT);
  DESELECT_MAX6675;
  setup_spi(SPI_MODE_1, SPI_MSB, SPI_NO_INTERRUPT, SPI_MSTR_CLK8);
  Serial.begin(19200);
}

Reading the Temperature

Reading the temperature value is equally straightforward. Select the device, wait atleast 100ns (this is close to the time that it will take the AVR to start sending data on the SPI bus anyway but I put in a microsecond delay to be certain), read the two bytes from SPI, and deselect the device.

SELECT_MAX6675;
 delayMicroseconds(1);
 unsigned char highByte = send_spi(0);
 unsigned char lowByte = send_spi(0);
 DESELECT_MAX6675;

The 16-bits read from the device in two bytes need to be processed slightly:

Bit 2 in the 2nd byte will be high if the device cannot detect an attached thermocouple, otherwise the 12 temperature value bits spread across the 2 bytes (6-0 of the hight byte, and 7-3 of the low byte) need to be shifted into a single numeric value (highByte << 5 | lowByte>>3).

The program simply prints the bytes received on an error and the temperature (divided by 4 to get the value in degrees) if it has been read successfully.

if (lowByte & (1<<2)) {
   Serial.print("Not connected ");
   Serial.print(highByte, HEX); Serial.print(" ");
   Serial.println(lowByte, HEX);
 } else {
   short value = (highByte << 5 | lowByte>>3);
   Serial.print(value/4); Serial.print(".");
   Serial.println(value%4 *25);
 }

The MAX6675 has a maximum conversion time of 0.22 seconds. If the device is sampled faster than this it will continue to output the temperature that was first read without any indication that it is being read too fast - I found a delay of atleast 250ms between readings the device worked well.

The complete sampling code is shown below:

#include <spi.h>

// MAX6675 connected to pin D9
#define MAX6675_SELECT_PIN 8
#define DESELECT_MAX6675 digitalWrite(MAX6675_SELECT_PIN, HIGH)
#define SELECT_MAX6675 digitalWrite(MAX6675_SELECT_PIN, LOW)

void setup()
{
 pinMode(MAX6675_SELECT_PIN, OUTPUT);
 DESELECT_MAX6675;
 setup_spi(SPI_MODE_1, SPI_MSB, SPI_NO_INTERRUPT, SPI_MSTR_CLK8);
 Serial.begin(19200);
}

void loop()
{
 delay(500);

 // select the device, wait > 100nS, read two bytes, deselect
 SELECT_MAX6675;
 delayMicroseconds(1);
 unsigned char highByte = send_spi(0);
 unsigned char lowByte = send_spi(0);
 DESELECT_MAX6675;

 // if bit 3 is high thermocouple is unconnected
 if (lowByte & (1<<2)) {
   Serial.print("Not connected ");
   Serial.print(highByte, HEX); Serial.print(" ");
   Serial.println(lowByte, HEX);
 } else {
   // temperature value is in bits 6-0 of highByte and 7-2 of lowByte
   short value = (highByte << 5 | lowByte>>3);
   // 1 bit is 0.25 degree 'divide' by 4 to show degrees
   Serial.print(value/4); Serial.print("."); Serial.println(value%4 *25);
 }
}

Conclusions

Compared with manual reading and conversion of the thermocouple voltage to temperature the MAX6675 is a delight to use. Although it is not a cheap device it is comparable to other thermocouple processing devices (for example the AC1226 and LTK001) but is fairly unique in having a digital/SPI output rather than a cleaned up voltage per Centigrade value that also requires a D/A converter.

Rocketnumbernine

Installing AVR GCC on OS X

Automating Gerbers from Eagle

SMT Table Top Reflow Oven (part 3): Final Build

Thermocouple

Rotary Encoder

LED

LCD

Control

Conclusions

References/Bibliography

Programming the AD9851 DDS synthesizer

References/Bibliography

Using the ICM7218 LED driver

Overview

Experiments

Lower Power Mode Select - ID4

Decoding - ID5 & ID6

Sequential Data Update Select - ID7

Conclusions

References/Bibliography

Decoding a Rotary Encoder

Decoding the Encoder

Detecting Pin Changes

Debouncing

Conclusions

References/Bibliography

External Time Capsule Fan

References/Bibliography

SMT Table Top Reflow Oven (part 2): Controlling the Heater Elements

The circuitry below involves mains electricity, don't try this unless you are sure you know what you are doing - check, test and insulate repeatedly and thoroughly.

Driving the relay

Installation

References/Bibliography

Using SPI on an AVR (3)

AVR SPI Slave Mode

Example

Sending a SPI message on button press

References

Using the MAX6675 Thermocouple-to-Digital Converter

SPI Setup

Reading the Temperature

Conclusions

References/Resources