[Mark] had seen a few examples of algorithmic music generation that takes some simple code and produces complex-sounding results. Apparently it’s possible to pipe the output of code like this directly to audio devices on a Linux box, but [Mark] decided to go a different direction. His project lets you play simple algorithms as audio using AVR microcontrollers.

Now the code work for this is very simple, but he hardware implementation is where things get interesting. Ostensibly, [Mark] didn’t have the components available to build a filter to use PWM as an audio signal. Being that he’s a ham operator, he grabbed some radio equipment he had on hand and whipped up an alternative. He’s feeding the PWM from an Arduino into the voltage controlled oscillator on a board meant for high-altitude balloon telemetry. The signal broadcast by this board is then picked up by his radio receiver, and played on some speakers.

Rube-Goldberg contraptions aside, the effect is pretty interesting, as you can hear in the latter half of the video clip which we’ve embedded after the jump.

[Andrey Mikhalchuk] is trying to gather a base set of lab instruments. Specifically, he’s looking for hardware that will let him quickly filter solids out of a liquid. He first started by adding a cotton disk to a plastic funnel. It does the job, but when left to gravity it’s quite slow. He needed a way to speed up the flow even when the filter is heavily clogged with particulates.

There’s already a solution to this problem. It’s a glass container called a Büchner Flask. These feature a glass tube coming out from the neck. By hooking a vacuum pump up to this tube, reduced pressure inside the flask will pull the liquid through the filter in no time. Rather than purchase the specialty item, [Andrey] altered a rubber stopper to accept both the funnel, and a glass tube. This is a cheaper version because it uses a common conical flask but it works just as well. To create the vacuum, an altered bike pump was used. Check out videos of both hacks after the break.

In our hands-on review of the Digilent chipKIT Uno32, we posed the question of what the lasting appeal might be for a 32-bit Arduino work-alike. We felt it needed some novel applications exploiting its special features…not just the same old Arduino sketches with MOAR BITS. After the fractal demo, we’ve hit upon something unique and fun…

So just what are the chipKIT’s unique features over a stock Arduino? Until the expected Ethernet shield ships this summer, a few ideas are on hold. Let’s see then…there’s no shortage of MIPS, of course…but there’s also heaps of RAM and flash storage. And with the latter, sampled audio came to mind. There are Arduino shields for just this sort of thing — the Adafruit Wave Shield turns up in many projects, using an SD card for sound storage — but if one’s needs are modest, the chipKIT’s PIC32 is perfectly capable of storing brief audio samples in its own flash program space, no cards, adapters or added expense required. We estimate the Max32 can hold nearly a full minute of voice-quality audio.

Playing with the idea, we found we could do one better. Actually, several better. A limitation of SD card-based players like the Wave Shield is that they can only play one sound at a time. Dealing with the FAT filesystem and buffering audio data off the card takes nearly everything the Arduino’s little ATmega chip can muster…polyphonic sound requires kludges. But our flash-resident audio samples on the chipKIT are trivial to access. With the fast 32-bit CPU, many samples can be processed simultaneously…and then, with gobs of RAM, time-based effects such as reverb can be added. And before we knew it, there was a toy synthesizer sitting on the table:

Having previously dabbled with the PIC32 using Microchip’s tools, we were surprised by the simplicity with which this went together. A few early rough spots aside, the chipKIT and MPIDE environment show major promise for being every bit as simple as Arduino. In fact, the whole build was completed faster than the documentation phase. And then a second surprise, even to us: everything in the parts list, aside from the chipKIT board itself, is common stuff that could be found at RadioShack. No funky special ICs, components or mail-order shields. Most of the “magic” is in software, thanks to this fast microcontroller.

Here’s a demonstration of the finished mini-synth in action:

Please excuse the demonstrator’s tragic lack of rhythm and coordination. This is why professional musicians get paid millions while amateurs lead sad lives as technology bloggers. Be thankful that we spared you the blooper reel.

Input is via five piezoelectric transducers (RadioShack #273-0073, $2.19 each) attached to analog inputs A0 through A4. We could have just used pushbuttons, sure, but we wanted something that could sense the pressure of each hit, and these were cheaper than force-sensitive resistors. Piezo sensors have a specific polarity, and the positive side (red wires) should connect to the analog inputs, and black to ground. There’s also a 2000 Ohm resistor added across each element:

Input for the reverb effect is straightforward. Two 10K potentiometers on analog inputs A6 and A7 (these are on the second row of analog inputs on the chipKIT Uno32, not present on Arduino). One controls the amplitude, the other controls the delay:

Finally, sound output uses high-speed PWM output on digital pin 3, passed through a simple low-pass filter to a headphone jack:

On our breadboard we’re using a handy little headphone breakout board from SparkFun, but one could just solder the appropriate wire leads onto a bare jack from “The Shack” (ugh). You may want to optionally add a 1 Meg pot just before the headphone jack. The circuit worked fine as-is with headphones or an amplified iPod speaker, but totally saturated our camera’s microphone input when fed directly.

This demo uses 16 KHz sound samples. As per Nyquist theory, the low-pass filter is then designed for an 8 KHz (-ish) cutoff frequency. For purely voice applications, half those rates should be sufficient (saving flash space and allowing longer samples), and the two resistor values should then be doubled.

And that’s it for parts. Can you believe it? On to the code…

To begin, we need something that can convert sound files into a format the C compiler can use. An ugly little UNIX command-line utility converts WAV files from a very specific format (8-bit mono, uncompressed) into C header files that can be #included by the MPIDE project. Arduino normally would use the PROGMEM directive to put these tables into the code flash space, but that’s not required here. Surprisingly, the much-loved Audacity program wouldn’t export 8-bit WAVs, but we found it possible to batch convert sounds using iTunes.

const signed char sample_drum[] = {
        0x02,0x03,0x01,0x00,0x00,0x00,0x00,0x01,
        0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x00,
        ...HUNDREDS OF LINES OF STUFF...
        0xff,0xff,0xff,0xfd,0xfd,0xff,0x00,0x00,
        0x00,0x00,0x00,0x00,0x02,0x00 };

We’ll spare you the horror of looking at that code or doing the conversion. You can download the complete set of project files here, and then adapt it to your own needs. The remainder of this article deals only with the MPIDE code.

But first, one fix is required: in our prior article, we encountered an issue with the chipKIT’s analog read speed, and a fix was discussed in the comments. This involves scrounging among the MPIDE source files for “wiring_analog.c” and changing a few lines. The old code resembles:

delayMicroseconds(99);
while ( ! mAD1GetIntFlag() ) { }
analogValue = ReadADC10(0);
mAD1ClearIntFlag();

This should be changed to:

delayMicroseconds(2);
mAD1ClearIntFlag();
while ( ! mAD1GetIntFlag() ) { }
analogValue = ReadADC10(0);

We’re told this change will be incorporated into later releases of the toolkit and this won’t be necessary for much longer. If you’re just ripping out the digital audio code from this project and ignoring this drum pad stuff, you can skip the change altogether.

And then there’s our sketch code:

// Mini sampling synthesizer for chipKIT Uno32.

#include "sounds.h"       // N_SAMPLES and data are here
#define PWM_PIN         3 // OC1 PWM output - don't change
#define SAMPLE_RATE 16000 // All samples fixed at 16 KHz
#define MAX_SOUNDS     10 // Polyphonic limit
#define MAX_ECHO     4000 // 1/4 sec fits in Uno32 RAM

short
  echo_data[MAX_ECHO]; // Circular buffer for echo

int
  echo_delay = 0, // Duration of echo effect
  echo_vol   = 0, // Echo effect volume (0-1023)
  echo_pos   = 0; // Current position in echo buffer
volatile int      // May change during interrupt:
  n_sounds   = 0; // Number of sounds currently playing

struct soundStruct {
  int sample; // Index of corresponding audio sample
  int pos;    // Current position within sample
  int vol;    // Playback volume, 0-1023
} sound[MAX_SOUNDS];

#define N_PADS N_SAMPLES // One pad for each sample

struct padStruct {
  short max;       // Max pressure during press (0-1023)
  short count;     // Timer for filtering out noise
  byte  triggered; // If set, currently reading a press
  short add;       // If >0, begin sound at next interrupt
} pad[N_PADS];

void setup()
{
  memset(pad, 0, sizeof(pad));    // Clear drum pad data
  memset(echo_data, 0, sizeof(echo_data)); // Clear echo
  pinMode(PWM_PIN, OUTPUT);     // Enable PWM output pin

  // Open Timer2, 1:1 w/256 tick interval (for 8-bit PWM)
  OpenTimer2(T2_ON | T2_PS_1_1,256);
  OpenOC1(OC_ON | OC_TIMER2_SRC | OC_PWM_FAULT_PIN_DISABLE,
    0,0);

  // Open Timer1 with interrupt for sample mixer (16 KHz)
  ConfigIntTimer1(T1_INT_ON | T1_INT_PRIOR_3);
  OpenTimer1(T1_ON | T1_PS_1_1, F_CPU / SAMPLE_RATE);

  delay(1);  // Slight delay avoids false trigger at start.
}

// Piezo transducers as input pads are fussy.
// To avoid false positives, a bit of hysteresis is used:
#define PRESS_MIN     20 // Must read at least this force
#define PRESS_COUNT    3 // for this many samples, then...
#define RELEASE_MAX    8 // Must read less than this force
#define RELEASE_COUNT 15 // for this many samples.
// Still imperfect; there are occasional double-triggerings
// and false triggers on adjacent pads.  Could be addressed
// with better mounting and isolation of pads and/or with
// improved input filtering in code or in hardware.

// The loop() function just reads pad and dial inputs; all
// audio work is done in the subsequent interrupt function.

void loop()
{
  int i, a;

  for(i = 0; i < N_PADS; i++) {  // Sample each pad...
    a = analogRead(i);

    if(pad[i].triggered) {    // Previously pressed?
      if(a <= RELEASE_MAX) {  // Yes, released now?
        if(++pad[i].count >= RELEASE_COUNT) {  // Really?
          // Sounds aren't added to play list here, just
          // flagged; they're added to the mix in the
          // interrupt.  This avoids a race condition
          // where this code may be trying to add a sound
          // while the interrupt is removing one.
          pad[i].add       = pad[i].max;
          pad[i].triggered = 0;
          pad[i].count     = 0;
        }
      } else {  // Still pressed...watch for new max
        if(a > pad[i].max) pad[i].max = a;
        pad[i].count = 0;  // Reset release counter
      }
    } else if(a >= PRESS_MIN) {  // Untriggered; new press?
      if(++pad[i].count >= PRESS_COUNT) {  // Really?
        pad[i].triggered = 1; // Flag to watch for release
        pad[i].count     = 0;
        pad[i].max       = a;
      }
    } else {  // Untriggered and below press threshold
      pad[i].count = 0;  // Clear press counter
    }
  }

  // Echo parameters come from potentiometers on A6 and A7
  echo_vol   = analogRead(6);
  echo_delay = map(analogRead(7), 0, 1023, 0, MAX_ECHO);
}

// This is the mixing/sample-playing interrupt,
// invoked at 16 KHz to match the audio sample rate.
// With guidance from Mark Sproul's PIC32 port of
// Brett Hagman's Tone library for Arduino.
extern "C"
{

void __ISR(_TIMER_1_VECTOR,ipl3) playSample(void)
{
  int i = 0, sum = 0;

  mT1ClearIntFlag();  // Clear interrupt flag

  while(i < n_sounds) {  // For each sound playing...
    // Waveform is cumulative, NOT averaged
    sum += (int)sample[sound[i].sample].data[sound[i].pos] *
      sound[i].vol;
    sound[i].pos++;  // Advance counter.  If end hit...
    if(sound[i].pos >= sample[sound[i].sample].size) {
      n_sounds--;  // Decrement number of sounds playing:
      // Move sound at end of list to the slot currently
      // occupied by the vacating sound (unless the same)
      if(i < n_sounds) {
        memcpy(&sound[i], &sound[n_sounds],
          sizeof(soundStruct));
        continue;  // Sound moved; dont advance index
      }
    }
    i++;
  }
  sum /= 1024;

  // Add in echo effect (if enabled) from circular buffer.
  // This takes place before audio level clipping so that
  // any clipping distortion won't be repeated in echo.
  if((echo_delay > 0) && (echo_vol > 0)) {
    sum += echo_data[echo_pos] * (echo_vol + 1) / 1024;
    echo_data[echo_pos] = sum;
    if(++echo_pos >= echo_delay) echo_pos = 0;
  }

  // Clip audio to 8-bit range.  This may cause distortion
  // when multiple sounds or echo exceed the 8-bit range.
  // Invoking the "quick & dirty" alibi again.
  if(sum < -128)     sum = -128;
  else if(sum > 127) sum =  127;

  SetDCOC1PWM(sum + 128);  // Set PWM output value 0-255

  // Check for any new sounds flagged by loop().
  // Done last because sounds finished above will
  // free up polyphonic slots.
  for(i = 0; i < N_PADS; i++) {
    if(pad[i].add) {
      if(n_sounds < MAX_SOUNDS) {
        sound[n_sounds].sample = i;
        sound[n_sounds].pos    = 0;
        sound[n_sounds].vol    = pad[i].add + 1;
        n_sounds++;
      }
      pad[i].add = 0;  // Clear flag even if not added
    }
  }
}

} // end extern "C"

Explanation:

The setup() function initializes two timers:

• Timer 2 and Output Compare 1 (hardware features of the PIC32 chip) are used for pulse width modulation (PWM). In conjunction with the filter previously described, this positions the speaker for each audio sample (Google for “PWM DAC” for explanations and examples). The PWM input clock is set to the chip’s full speed of 80 MHz, with an interval of 256 “ticks” (for 8-bit resolution), yielding a PWM waveform at 312,500 Hz. For this sort of DAC filtering it’s recommended that the PWM frequency be at least ten times the sample rate, so this is more than adequate for our needs. This is also why the code bypasses the native Arduino analogWrite() function for PWM, which operates on a much slower clock. Lastly, using Output Compare 1 dictates that we must use digital pin 3 for the audio output; this is one of the five native hardware PWM lines on this chip.
• Timer 1 operates at our audio sample frequency (16 KHz) and has an interrupt function attached. This function mixes audio samples and changes the PWM duty cycle of Timer2/OC1. The rates on both of these timers are set up once and never need to change, just the one duty cycle is varied.

This section of the code (and one line in the interrupt function) is admittedly not very Arduino-like, directly accessing hardware features in a non-portable manner. A more formal implementation would abstract these details into a library to which the novice programmer could just pass data. But for the sake of a simple, single-file demo, there it is, warts and all. In many ways, this is just a starting point to work from.

The loop() function reads the state of the piezo sensors and marks sounds to be played (received by the interrupt, later). There’s some crude debouncing of the piezo inputs…this really could use some more sophisticated filtering (which the PIC32 could easily handle), but it was skipped for brevity. The code generally detects varying pressure, but there’s still a fair bit of false triggering going on. In this function the reverb controls are also read: just two analogRead() calls, with the second one then mapped to the full length of the reverb buffer.

The interrupt handler is where all the fun stuff happens, and it’s surprisingly simple.

The extern “C” declaration makes the C++ compiler happy with the interrupt function declaration.

The program is designed for up to ten concurrent sounds, the details of which are held in the “sound” structure array (there’s more than enough CPU performance for greater polyphony, but it’s mostly just a matter that the input pads aren’t terribly practical for this). When a pad hit is sensed, a new item is added to this array (up to the maximum). Structure elements indicate which audio sample is used for this sound, the current playback position within the sample, and the volume level.

Audio samples are stored as signed values (rather than unsigned) because this makes them easier to mix (just add together) and easier to adjust gains (just multiply). Every opportunity is taken to use fixed-point math. From the prior fractal demo, we saw what a massive performance difference this can make — sometimes orders of magnitude. Most of our analog readings (returned as 10 bit integers from 0 to 1023) correspond to a gain (relative volume) value of 0.0 to 1.0 (or 0% to 100%). To perform this scaling in fixed-point units, add 1 to the reading, perform the multiplication (one instruction on the PIC32), then divide by 1024 (a simple shift operation, also one instruction). There’s no loss in accuracy vs. converting to floating-point; the source and destination values are going to be quantized anyway.

// Floating-point, slow:
// scale = float 0.0 to 1.0
out = (int)((float)in * scale);

// Fixed-point, crazy fast:
// scale = integer 0 to 1023
out = in * (scale + 1) / 1024;

Along these lines, note that where the audio samples are summed, this division is skipped until the end. This saves some cycles and the result works out the same. Algebraically speaking, (A/X)+(B/X)=(A+B)/X, and so forth. The interim 32-bit sum isn’t likely to overflow.

Fixed-point math happens again when applying reverb. The echo volume, in the integer variable echo_vol (10 bit again, from one of the analog knobs) is in the range 0 to 1023, corresponding to 0% (no reverb) to 100% (echo is as loud as the original sound). Reverb (in echo_data[] array) is a circular buffer — as sounds are played, the contents here (scaled by echo_vol) are first added to the output, then the result is placed back in the same position in the array and the position counter is incremented by one. When the end of the array is reached (or a shorter limit indicated by echo_delay) we “wrap around” back to the beginning.

The final resulting audio value is clipped to an 8-bit range. This may introduce clipping distortion when many loud sounds are used simultaneously. For brevity again, bells and whistles have been omitted, but courageous programmers could opt to add “soft clipping” here to limit such distortion. There’s ample CPU muscle.

The final 8-bit signed value is then transposed into the unsigned range and fed into the OC1 duty cycle for PWM output.

Lastly, the interrupt checks for any sounds that the loop() function flagged as being “hit,” and adds these to the concurrent play list. This flag-and-add behavior, rather than adding items directly in loop(), avoids a potentially nasty race condition whereby loop() could be in the midst of adding a sound just as the interrupt is removing others, throwing off the counter.

And that’s all there is to it. This demo only uses about one fourth of the storage on the Uno32, which itself has one fourth the capacity of the Max32…and we’ve yet to exploit any sort of compression. There could be some fun applications here, maybe adding better Super Mario sounds to toilets or voice prompts to other chipKIT projects (“Your door is ajar”). What other ideas could you see happening here?

So your house looks like a dumping ground for useless junk? Yeah, we know it’s the hacker’s curse… you just can’t stop salvaging stuff. But follow [Pontazy69's] lead by building something useful out of that junk. He took an old polystyrene box and made it into this fishtank. You can see that the sides and back of the box has gone unaltered, but the front wall is missing. [Pontazy69] marked and cut straight lines while leaving a lip around the edge. Silicone was used to glue some acrylic (or perhaps glass?) to the inside of this lip. Once dried he added another bead around the outside to ensure it doesn’t leak. Few fish would be happy here without some type of filter so he built one of those out of an old plastic bottle and some other pieces. See videos that show you how to build both the tank and the filter after the break.

We love aquarium hacks almost as much as clock hacks. So check out the water exchange system, and a couple of different lighting systems. Then document your own aquarium projects and let us know about them.

Fish tank made from polystyrene

Plastic bottle fish tank filter

[Thanks Greg]

[nickinoki] Made a light show using some amplifiers and an arduino. First he created a microphone circuit based around a LM386 Audio Amplifier. After amplifying the output of the microphone a second time, he uses three bandpass filters to block all but a few desired frequencies from reaching the arduino.  By only letting a few frequencies through the arduino is able to determine if the song is louder at higher or lower frequencies.  Then using the three analogue inputs he created a scheme for generating the light show on an arduino. While he was unable to achieve the exact target frequencies with his bandpass filters they worked well enough to allow him to successfully generate the light show.

As with many of the projects covered on hackaday, [bongodrummer]‘s Dust Sniper came about because of a lack of effective commercial solutions, in this case to the problem of quiet dust extraction.

Workshops are generally full of dust and noise, both of which take their toll on the human body. This is why safety regulations exist for noisy and dusty workplaces and–as [bongodrummer] rightly points out–we have to take precautions in our own home and community workshops. Hearing protectors, dust masks and safety goggles are integral, but reducing the amount of dust and noise in the fist place is paramount.

Using mostly scavenged materials [bongodrummer] did a quality job building the Dust Sniper–and all for a bill of materials totaling £20. It has an integrated work surface, automatic switches on 2 vacuum lines to sync up with power tools, a cyclonic air filter that prevents clogging the HEPA filter and reducing suction power, inlet and outlet soundproofing, and a plain old power outlet for good measure.

Whether or not you’re interested in building an integrated workbench/extractor system like this one, we recommend you check out the details of the cyclone filter and the sound reducing components. Not only are they an interesting read, but they could be useful to apply in other projects, for example a soldering station with fume hood.

We think it would be really neat to include more cyclones in our projects. Stick around after the break to see [bongodrummer]‘s prototype cyclone filter in action.

[ProfHankD] came up with a pretty easy way to take 3D photos using a single lens. He’s making Anaglyph images which use color filtering glasses to produce stereoscopic 3D effects. We’ve seen stereoscopic imaging hacks that use two cameras or a clever combination of mirrors, but this one uses a special filter and post-processing. [ProfHankD] drew up a template that can be used to properly align two colored filters, like those in the lens cap seen above. Once installed, just snap all the pictures you want and then hit them with your favorite photo editing software. This involves separating the color channels of the photograph and offsetting them to increase the depth of focus.

It’s a nice little process, and his writeup is easy to understand even if you’re not a hardcore photography guru.

[Thanks Paul]

[Daniel Reetz] has caught the Kinect hacking fever. But he needs one important tool for his work; a camera that can see infrared light. This shouldn’t be hard to accomplish, as the sensors in digital cameras are more than capable of this task, but it requires the removal of an infrared filter. In [Daniel's] case he disassembled a Canon Powershot to get at that filter. There’s a lot packed into those point-and-shoot camera bodies and his teardown images tell that tale. He also ended up with extra parts after putting it back together but that didn’t seem to do any harm.

After the break you can see video that shows the Kinect’s speckled IR grid, which is why he needed IR sensing in the first place. But there’s also some interesting photos at the bottom of his post showing the effect achieved in outdoor photography by removing the filter.

The flash never made it back in the camera. That’d be a perfect place for an IR light source. You’d end up with a night-vision camera that way.

If you’ve ever designed an embedded system with at least one button you’ve had to deal with button debouncing. This is also know as contact bounce, a phenomenon where a button press can be registered as multiple button presses if not handled correctly. One way to take care of this is with a hardware filter built from a resistor-capacitor setup, or by using a couple of NAND gates. We find that [Jack Ganssle] put together the most comprehensive and approachable look at contact bounce which you should read through if you want to learn more.

We’re interested in software solutions for debouncing buttons. This seems to be one of the most common forum questions but it can be hard to find answers in the form of reliable code examples. Do you have debounce code that you depend on in every application? Are you willing to share it with the world? We’d like to gather as many examples as possible and publish them in one-post-to-rule-them-all.

Send your debounce code to: debounce@hackaday.com

Here’s some guidelines to follow:

• Please only include debounce code. Get rid of other unrelated functions/etc.
• You should send C code. If you want to also send an assembly code version that’s fine, but it must be supplementary to the C code.
• Please comment your code. This will help others understand and use it. You may be tempted to explain the code in your email but this info is best placed in the code comments
• Cite your sources. If you adapted this code from someone else’s please include a note about that in the code comments.

As an example we’ve included one of our favorite sets of debounce code after the break. Please note how it follows the guidelines listed above.

/*--------------------------------------------------------------------------
10/13/2010: Button debounce code by Mike Szczys

based on "danni debounce" code by Peter Dannegger:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=189356#189356

This code detects and debounces button presses. It is tailored for use with
AVR microcontrollers but I've adapted it for other architectures easily and
successfully. It can be modified to use all eight bits on the same port
for up to eight buttons.

The interrupt service routine (ISR) at the bottom uses binary counter
variables (ct0 and ct1) to check the buttons once every 10ms until 40ms has
passed. If the button registeres the first and last times it reads it as
a keypress. There is no functionality in this code for detecting a held
button.
--------------------------------------------------------------------------*/

// F_CPU used by debounce to calculate 10ms interrupts
#define F_CPU 1200000

#include <avr/io.h>
#include <avr/interrupt.h>

//define pins used by buttons
#define KEY_DDR		DDRB
#define KEY_PORT	PORTB
#define KEY_PIN		PINB
#define KEY0		1	//Button on PB1
#define KEY1		2	//Button on PB2

//Debounce variables
unsigned char debounce_cnt = 0;
volatile unsigned char key_press;
unsigned char key_state;

/*--------------------------------------------------------------------------
  Prototypes
--------------------------------------------------------------------------*/
unsigned char get_key_press( unsigned char key_mask );
void init_timers(void);
void init_io(void);

/*--------------------------------------------------------------------------
  FUNC: 10/13/10 - Used to read debounced button presses
  PARAMS: A keymask corresponding to the pin for the button you with to poll
  RETURNS: A keymask where any high bits represent a button press
--------------------------------------------------------------------------*/
unsigned char get_key_press( unsigned char key_mask )
{
  cli();			// read and clear atomic !
  key_mask &= key_press;	// read key(s)
  key_press ^= key_mask;	// clear key(s)
  sei();			// enable interrupts
  return key_mask;
}

/*--------------------------------------------------------------------------
  FUNC: 10/13/10 - Sets and starts a system timer
  PARAMS: NONE
  RETURNS: NONE
--------------------------------------------------------------------------*/
void init_timers(void)
{
  cli();			// read and clear atomic !
  //Timer0 for buttons
  TCCR0B |= 1<<CS02 | 1<<CS00;	//Divide by 1024
  TIMSK0 |= 1<<TOIE0;		//enable timer overflow interrupt
  sei();			// enable interrupts
}

/*--------------------------------------------------------------------------
  FUNC: 10/13/10 - Initialize input and output registers
  PARAMS: NONE
  RETURNS: NONE
--------------------------------------------------------------------------*/
void init_io(void)
{
  //Setup Buttons
  KEY_DDR &= ~((1<<KEY0) | (1<<KEY1));	//Set pins as input
  KEY_PORT |= (1<<KEY0) | (1<<KEY1);	//enable pull-up resistors
}

/*--------------------------------------------------------------------------
  FUNC: 10/13/10 - Main
--------------------------------------------------------------------------*/
int main(void)
{
  init_timers();	//start the timer
  init_io();		//setup the buttons

  for (;;) //loop forever
  {
    if( get_key_press( 1<<KEY0 ))
    {
      //KEY0 press detected. Do something here
    }

    if (get_key_press( 1<<KEY1 ))
    {
      //KEY1 press detected. Do something here
    }
  }
}

//--------------------------------------------------------------------------
ISR(TIM0_OVF_vect)           // interrupt every 10ms
{
  static unsigned char ct0, ct1;
  unsigned char i;

  //TCNT0 is where TIMER0 starts counting. This calculates a value based on
  //the system clock speed that will cause the timer to reach an overflow
  //after exactly 10ms
  TCNT0 = (unsigned char)(signed short)-(((F_CPU / 1024) * .01) + 0.5);   // preload for 10ms interrupts

  i = key_state ^ ~KEY_PIN;    // key changed ?
  ct0 = ~( ct0 & i );          // reset or count ct0
  ct1 = ct0 ^ (ct1 & i);       // reset or count ct1
  i &= ct0 & ct1;              // count until roll over ?
  key_state ^= i;              // then toggle debounced state
  key_press |= key_state & i;  // 0->1: key press detect
}

[Photo credit: Jack Ganssle]

[Okie] designed this audio effect shield for Maple. You’ll remember that Maple is a prototyping system built around an ARM processor, so there’s plenty of power and speed under the hood. First and foremost, the shield provides input and output filters to keep noise out of the system. From there a set of potentiometers let you change the effect, with the manipulation like echo, distortion, and ring modulation happening in the firmware.

[Thomas] and a buddy were sucking down a few brews when they decided to hack their 2001 Chevy Cavalier for a bit better performance. If they could find a way to bring cooler air to the engine they speculated that they’d see an increase in efficiency. Instead of routing the air intake to a hood scoop, they took off the factory air filter and mounted a cold air filter in its place. PVC pipes were then used to create a delivery path from the front of the vehicle with the output in close proximity to the new filter. They tested their work and discovered a drop in intake temperature from 101 to 48 degrees Fahrenheit at 60 mph, and from 109 to 54 degrees Fahrenheit at 45 mph. Now the sedan runs better and generates more horsepower, all for around $35 in parts.

The dispenser is made of a Tupperware tub, a fish tank water filter, a float switch, and a water solenoid valve. It works essentially the same way as any toilet: the solenoid valve lets water into the filter where it is dispensed to the Tupperware container. The float switch is activated when the water in the container reaches a certain level. When the water level drops due to evaporation or thirsty pets, the float switch goes down and triggers the solenoid to let in more water. The whole works are powered by a GFI outlet for safety since this project involved water, electricity and pets.