[Samimy's] latest project is a little strange, but one man’s weird is another man’s wonderful so we’re not about to start criticizing his work. Nope, we’re here to praise the fact that his rotary phone turned reading light and audio amp is very well constructed.

He started by removing the phone housing. Those old enough to have used one of these devices will remember their bulk, and there’s a lot of unused space in both the handset and body housing. [Samimy] started by removing the speaker and microphone from the handset, and drilling a ring of holes to receive white LEDs. The circuit was wired so that lifting the handset turns on the lights.

But he didn’t stop there. A set of speakers and the audio amplifier circuitry from an old tape deck are also hiding inside the base of the phone. If you look closely in the image above you can see that he’s connected his cellphone and is listening to some tunes through the antique hardware. Take a gander at the video after the break to see construction and use of the project.

The team over at the Louisville Hackerspace LVL1 is not going to be outdone when it comes to collecting environmental data. They put together this Frankenstein of sensor boards that lets you collect a heap of data showing what is going on around it.

At the center-left a small Arduino clone is responsible for collecting the data. Data storage is not talked about on their write-up, but if that’s an ATmega328 chip you should be able to work out an easy way to store data on the 1k of internal EEPROM. If that’s not enough, there is an I2C bus included on the board making it easy to add a compatible EEPROM.

The sensor on the bottom left should look familiar. It’s a DHT11 temperature and humidity sensor we’ve seen popping up in projects lately. But wait, there’s also a TMP102 temperature sensor; but that’s not the end of it. A BMP085 pressure sensor also includes a third temperature sensing option. Want to see when the lights go on in the room? There’s a CdS sensor and a TSL230R Lux sensor for that. An op-amp circuit can measure the sound level in the room via one of the Arduino’s ADC pins. And finally, an RTC board is used for time stamping the data.

Obviously this is overkill, and we’re sure it’s meant as a test platform for various sensors. All of them have been mounted on the protoboard and wired up using the point-to-point soldering method.

Like many people, [yardleydobon] had a hard time locating his ceiling fan’s pull chain at night when his room is completely dark. Rather than continue to flail around blindly grasping for the chain, he decided to find a way to illuminate it instead.

He started off by disassembling a solar garden light, retaining the solar cell, photoresistor, and batteries. After paring down the electronics to the bare essentials, he mounted them inside a plastic battery storage case which he attached to the outside of the fan’s lamp. [yardleydobon] then ran a pair of wires from the electronics box down to end of the chain, where he added an LED and a translucent pull to diffuse the light.

He admits that it’s not the nicest looking modification around, but it does the job in a pinch. He has some ideas that he may put into play if he has the time to revise the design, and we bet that many of you do as well. If so, be sure to share them in the comments.

[Brainiac27] isn’t going to let the absence of sun prevent him from biking. He has no trouble lighting his path with this 1300 Lumen bike light he built.

The light source is a 3-up star by Cree. It puts off a lot of light, but also generates quite a bit of heat which is the reason for that large heat sink. It is meant to be used with a CPU but works well for this purpose thanks to the adhesive thermal paste used to unite the two parts.

The mounting bracket is a custom job, bent from 1″ by 1/8″ aluminum bar. [Brainiac27] had some issues with length the first time he tried making it. For his second attempt he started with an overly long piece, made the bends from the center out, and only made cuts once the bends were all completed. The bracket makes it easy to mount to his bike, with the battery stored in a bike bottle and a remote switch (with attaches to the jack you can see on the project box above) hidden underneath one of the brake hoods.

The intensity of this light nearly doubles one of our other favorites.

It turns out that as the days get shorter, chickens lay fewer eggs. But you can trick them into keep up production using artificial light. [Jpitz31] decided to build his own timed coop light to bridge the gap until the days of plentiful sunlight return.

He already had an LED camping light to use, but needed to find a way to power it and to switch it on and off on a schedule. He chose an ATmega328 for the latter, as he had a bunch of extras sitting around. As for power, there isn’t AC available where the coop is, so he opted for a 12V lead-acid battery with hopes of adding solar charging features in the future.

Switching is handled by a relay, with accurate time kept by a DS1307 real-time clock (it’s the red PCB seen above). Everything fits nicely on the board, and we have a couple of feature suggestions for future improvements. The linear regulators will eat up some extra power so moving to a switching regulator will help save juice. Also, it would be very easy to add a light sensor so that the light will only be on when the ambient light drops to a preset level. This way he won’t need to mess with the schedule as the length of the days change.

Here’s the latest project from [Niklas Roy's] workshop. Lumenoise is an audio synthesizer controlled by drawing with a light-sensitive pen on a CRT television.

The pen is a self-contained module which connects to the TV via audio and composite video RCA plugs. Inside the clear pen housing you’ll find a microcontroller which generates the audio and video. The business end of the pen contains a phototransistor which lets the ATmega8 take a reading from the video screen. Since the chip is generating that video signal, it’s possible to calculate the pen tip’s position on the screen and modulate the sound output based on that data. You can watch a recording of the results in the video after the break.

This is a very simple circuit to build, and [Niklas] makes the point that most of us have a CRT hanging around in a dark corner somewhere. We think this would be a fantastic soldering project to do with the kids, and that this would be right at home as a children’s museum piece because of the wow factor involved in playing around with it.

We can really tell from this and some of his past projects that [Niklas] just loves the 8-bit audio.

We, like the rest of the world, have watched in horror as footage of the recent earthquake-caused disaster has been reported from northern Japan. It’s easy to watch video and see nothing but distruction, however, life goes on and [Akiba] is looking for a way to help the recovery efforts. He mentions that one of the big needs in the disaster area right now is for light, as the power infrastructure has been heavily damaged. The mason jar seen above is a Kimono Lantern that was meant to accent a garden at night. It has a solar cell – one NiMH rechargeable battery – and one bright LED along with a charging circuit. It was designed in the Tokyo Hackerspace and they released the build files in hopes that a large number can be donated to those in need. With a reasonable amount of daylight, the single cell battery can be charged enough to provide 10 hours of light from the little device.

How can our hacks help others? That question has been on our minds for the last few days. Light is a great first step. But we’ve also wondered about information networks to help coordinate rescue and cleanup workers. There are hacks that bring WiFi using wind power or solar power. What other hacks do you think would be useful to aid in the recovery process?

ePaper displays are easy on the eyes because there’s no flickering backlight to put strain on them. This is great until you’re trying to read in a dim environment. Of course Amazon will sell you a backlight that’s powered from the reader itself if you’re willing to pay. [Txoof] thought the price was a bit too high so he built his own version.

There are two pockets in the top of the Kindle reader for hooks to grab onto. Each has an electrical contact in it and together they provide about 4V of power. To patch into that source [Txoof] cut his own hooks from brass stock and mounted them onto a piece of basswood. He then cut and bent a hood from more of the brass stock to house the LEDs. A series of three of the white diodes draw their power from the hooks and shine onto to the display. As you can see this works just fine, but could benefit from just the right diffuser.

Sometimes projects are vast, complicated, and complex. Other times projects are a bit more on the simple. Today we thought we would share a couple projects with something in common that may be familiar sounding to the more experienced crowd, but may inspire a few readers new to the world of microcontrollers.

First off, a cool decor tip looking to snazz up a college residence or bar is a guide for lighting up a shelf of liquor bottles using an Arduino to control a few RGB LEDs. This guide includes easy to follow schematics, source code, and a good explanation of using transistors to drive higher current to the LEDs than the Arduino could provide.

This six finger drum machine uses a Drum Kit – Kit AI to take in values from piezo sensors and convert those values into MIDI information to be used by either a hardware MIDI controller or PC. We like the CNC cut hand, and the design considerations put into it (like vibration buffering)

When moving beyond the buttons and LEDs in every starter kit out there, PIR motion sensors are usually a good next step. [LemonSlice] even goes so far as to add a a pair of XBees for making this motion sensor a little more autonomous.

[Don't stop the clock] is doing some work with a projector, a camera, and the Kinect. What he’s accomplished is quite impressive, combining the three to manipulate light with your body. The image above is a safer rendition of the Hadouken from the Street Fighter video games, throwing light across the room instead of fire. This comes at the end of the video after the break, but first he’ll show off the core features of the system. You can hold up your hand and wave it to turn it into a light source. In other words, the projector will shine light on your hand, moving it, and manipulating the intensity based on hand location in 3D space. Since the Kinect is sending fairly precise data back to the computer the projected image is trimmed to match your hand and arm without overflowing onto the rest of the room until you touch your hand to a surface you want illuminated or throw the light source with a flick or the wrist. It may seem trivial at first glance, but we find the alignment of the projector and the speed at which the image updates to be quite impressive.

[Thanks Vasili]

Quadcopters stand aside, here’s a three-rotor helicopter we think you’re going to love. The body is made out of plywood and carbon fiber rods, keeping it light enough to be easily lifted by just 3 motors while making sure the force doesn’t tear the aircraft apart. Three gyroscopes, two accelerometers, three magnetometers, and a GPS module are all used in conjunction for an autopilot system. There’s a lot of great pictures and videos but our favorite, embedded after the break, shows the tricopter writing messages in the sky using light and camera exposure tricks similar to this ground-based trike.

[Thanks Hernandi]

• Expand the sample code, adding features to our simple program while I challenge you to write the code yourself.
• Discuss AVR fuse bits, how to use them, and what to watch out for
• Touch on some of the peripherals you’ll come across in these chips

As a grand flourish to the series, I’ve used the example hardware from this final part to build a bicycle tail light. Hopefully this will inspire you to create something much more clever.

Series roadmap:

• AVR Programming 01: Introduction
• AVR Programming 02: The Hardware
• AVR Programming 03: Reading and compiling code
• AVR Programming 04: Writing code

Adding to the Example Hardware

The example code that I’ve been working with on the last two parts of this tutorial is a bit boring. It makes one LED blink on and off at a rate of about 1 Hz. That LED was connected to the pin for PD0, so let’s start out by adding an LED and resistor to the rest of the PORT D pins for a total of 8 LEDs. We should also talk about inputs, so let’s add a switch on PC0. Here’s a schematic showing our changes:

I moved the original LED over to some open space on the right side of the breadboard. I’m connecting the cathode to the ground rail on the bottom, jumping the trench with a resistor, and connecting a jumper from that resistor to the Port D pins on the microcontroller. I organized the LEDs in ascending order from right to left making it easy to address them when writing code:

If you know your resistor color codes you’ll notice that the Brown-Green-Red resistors I’m using are 1.5 kOhms, strangling the current to a tiny trickle for LEDs. Well, I’m using super bright LEDs, and these resistors were the first that I pulled out. They work just fine for prototyping but should be replaced with a correctly calculated value on a finished product.

Next I hooked up a button. Digital inputs on microcontrollers need to have a value of 0V or VCC (input voltage which is 5V in our case). If they don’t have a clear value they are said to be “floating” which can lead to false button readings and other unhappy occurences. We need to set up hardware that will force a value of 0V or 5V at all times. This turns out to be quite simple. By connect the switch from the pin to ground and a resistor from the pin to VCC (called a pull-up resistor) there will always be a very small 5V current trickling into the pin, except when an unrestricted path to ground is created by pressing the button. We don’t even need our own resistor as there’s one inside the microcontroller that we’ll take advantage of. Here’s a schematic showing what this connection, along with the internal pull-up resistor, looks like:

That description is a mouthful but all we’re really doing is placing a button between PC0 and Ground. Pin 23 is PC0 on the ATmega168 and the pin right next to that (pin 22) is GND. I’ve connected a switch accordingly. In the following image please note that Pin 22 is connected with a jumper wire to the ground rail above it, but is obscured by the black wire from the push button:

And finally, I want to make connections to the chip for In-System Programming. I like to do this using a patch board that I created. This lets me use a 10-pin IDC cable for easy connection to my programmer:

That’s it. I plan to use this hardware with several different firmware examples so double-check your wiring and then start writing code.

Writing Code

Time to practice writing your own code. I have come up with four firmware examples ranging in difficulty from “Hello World” to “Damn That’s Slick”. I’ll discuss each of them briefly but along the way you should try to write your own code, using my examples as… examples. The best way to learn to code is to write a small portion of code, let the compiler yell at you for messing up, and then figure out how to fix it.

Blinking all 8 (8led_1hz)

First thing’s first, can you make the example code from Part 2 blink all 8 LEDs instead of just one?

There’s really only two things that you need to change from the original to make this happen. First, when setting up the input/output, make all of the pins on Port D outputs, then turn them all on. Second, when toggling the bits in the Interrupt Service Routine use a bitmask that affects all eight bits.

The source package for this part of the series includes this alteration. Grab a copy of it and look at the 8led_1hz code. In it you’ll find these changes:

  DDRD |= 0xFF;			//Set PortD pins as an outputs
  PORTD |= 0xFF;		//Set PortD pins high to turn on LEDs

  PORTD ^= 0xFF;		//Use xor to toggle the LEDs

As you can see, both portions of code use 0xFF as a bit mask. This is a byte containing all ones, which will manipulate every pin on the registers to which we apply it. Before I had shifted a bit using this:

'1<<0'

It resulted in a bit mask of 0×01, protected the upper seven bits from being changed during register manipulation.

Make the LEDs do something interesting (m168_led_effects)

Now I’m going to take a big step forward in C code difficulty. But I challenge you to develop three different types of LED effects by yourself:

• A binary counter which counts up at 1 bit per second
• A flasher that alternates lighting every other LED
• Larson scanner (a simple one, doesn’t need to use PWM)

You’ll find my example code in the m168_led_effects directory. Here’s some of the new things I’m using in my code:

Definitions: I’m using definitions for common settings and for I/O pins, ports, and direction registers. These are constants that the compiler will replace with appropriate values but they make your job much easier. If you get most of the way into a project and realize you need to change some of the hardware this will make it simple to do. Need to change from Port D to Port C? No problem, change the #define and the rest of the code will still work

Delay: AVR libc has a nice delay utility called delay.h. You can see that I’ve included it at the top of the source file and also written a function called delay_ms(). This is a moderately accurate way to mark the passage of time. The drawback to using this is that you are literally wasting time when the processor could be doing other things. Still, it’s simple and if you’re new to microcontrollers you’ll probably find yourself using this frequently at first.

Also notable in this version of the code is my use of functions to take the complexity out of MAIN. I like to do this when I can to make program flow more readable. If you use descriptive function names it will be easy for others to see how the firmware works just by looking at main. This is also why I comment my code quite a lot. Not just for others, but so I can read it quickly if I come back to it later and don’t remember what I originally wrote the program to do.

Before we move on here’s a quick synopsis of how I solved the three goals:

• When displaying a binary counter at 1Hz I simply start Timer 2 the same way I did for the blinking LED in Part 2 of the tutorial. Each time it fires I don’t toggle the pins, but set the entire port to an 8-bit variable value while incrementing it at the same time. The ++binary_counter increments that value just before it sets Port D. It is crucial that this value be a global variable using the keyword ‘volatile’ because it is changed by both the ISR and in the main loop. If you don’t make it volatile the compiler might optimize the code in a way that disturbs or disrupts the intended functionality.
• Creating an alternating flasher is much the same as toggling a single LED. I set up for the effect by instantiating a variable with every-other bit as 1. When using an exclusive OR operator (XOR) on this value, all of the bits will flip. I could have set up an interrupt with a shorter delay than the 1 Hz interrupt to take care of this but for learning purposes I used a delay instead.
• The Larson scanner is a classic bit of blinky goodness. The core function is to illuminate one LED and sweep it back and forth. To do this I just created a loop to shift the bits, waiting after each change. Once the LED on the end is lit the program leaves the loop and enters another one to shift bits the other way. The same could have been accomplished with a variable that keeps track of which direction the LED is moving, testing during each iteration.

When you’ve read and understood how this code works it is time to get the button up and running.

Make the button do something (m168_led_button)

We brought a button to the party, let’s alter our LED effects so that the button is used to change between the three possibilities. If you’ve never written code for a button input before there’s little chance you’ll be able to pull this off yourself, so open up the code in the m168_led_button folder and lets walk through it.

Debounce: Buttons often register more than one press if not handled correctly, a process called debouncing. There is a hardware fix for this, but you can learn about that on your own time. Recently, I gathered a post full of different debounce code, but the one I almost always use is based on code by [Peter Dannegger]. It relies on several parts:

• Code to start a timer with an overflow interrupt
• An ISR to service the timer overflow, resetting the timer for 10ms interrupts and polling the button pin.
• A bit mask and pin definitions that identify how the buttons are hooked up
• A function used to check if a button press has been registered
• Code to check that function and act when a button has been pressed.

The magic is in the ISR debounce code. It flips bits in a binary counter to register four successive button press readings totalling 40ms. That signals a legitimate button press and when the get_key_press function is called it will return a populated key mask. To help understand how this debounce code works, I have included a code example called button_debounce. This has been slimmed down to include only the code used to debounce. Pressing the button will toggle the LEDs.

During the hardware setup I talked about using the internal pull-up resistors. I have to remember to set those up at the beginning of the program or the input pin will be floating. The datasheet talks about this on page 71. When a pin is set to input using the Data Direction Register, writing a high value to the Port bit for that pin will enable the pull-up resistor. From there the current status of the pin can be grabbed from the appropriate Pin register. Notice the ISR used for debouncing reads KEY_PIN, which is defined as the PINC register at the top of the source code. You don’t have to read the Pin register because the ISR is doing it for you.

My implementation of button debouncing in the m168_led_button code is just fine, but my use of the button is a hack. I should have used a state machine and gotten rid of the delay functions in the code. For simplicity I just littered calls to get_key_press throughout the code whenever I was trapping the program in a loop. I used the detection of a key press to return to main from the function the program is stuck in.

Pick this apart, writing simple code that you understand and slowly you will build the knowledge base necessary to understand this code as a whole.

Creating something useful (m168_bike_light)

I wanted to finish the code writing section with a useful application for our test hardware. Behold, a bicycle tail light. It has a button to scroll through several different red light patterns, and it uses sleep mode to shut off the LEDs and conserve battery power.

I’ve changed the program flow to use a state machine. This is a bit of a juggling act. I use an interrupt to set a flag called ‘timer’. The main loop constantly polls that flag, as well as the button, and acts accordingly. Whenever that flag is set the next step of the LED effect is performed.

Sleep mode is also used in this example. One thing to note: when in sleep mode the chip uses almost no current, conserving batteries. But the linear power regulator still burns away like crazy. For this to be useful the code should be ported to a chip that operates at low voltages. For instance, you could use a tiny13 and two AA batteries without a regulator. Adjustments would need to be made for less pins and corrected LED resistor values, but these are not difficult changes to make. Have a look at the code in the m168_bike_light folder. The comments and your hard-earned AVR knowledge will help you understand how this works. Good luck!

Now I’ll move on to the discuss one of the most important parts of theses microcontrollers:

AVR Fuse Bits

The fuse bits are a set of registers that control some core features of the AVR line of chips. You can think of them as another type of memory, programmed separately from the code that you want to execute.

Read the datasheet

Fuse bits for the ATmega168 are covered starting on page 285 of the datasheet. You should make yourself thoroughly familiar with this information. Incorrectly programming these registers could render your chip useless unless you have a programmer capable of High Voltage Programming (HVP).

There are three fuse bit registers on our chip, the Extended fuse byte, the High fuse byte and the Low fuse byte. All of them use inverse logic, meaning that a ’1′ means the corresponding feature is NOT selected. I start every project with these registers set to the factory default, information I keep in a text file with the factory fuse defaults for all the chips I work with. At the beginning of every project I try to talk to the chip using the ‘-v’ option of AVRdude to make sure the programmer and chip are both working correctly to save time on later debugging. Here are the ATmega168 defaults:

• efuse: 0b11111111 (0xFF)
• hfuse: 0b11011111 (0xDF)
• lfuse: 0b01100010 (0×62)

I’ll touch on most of these features in the next section. But of particular concern are the bits that select the clock source, and the reset disable bit. If you disable the reset pin, by accident or in order to use it as an I/O pin, you will need to use HVP or debugWire to use ISP programming again. If the clock pins are changed you will need the appropriate external clock signal, or HVP for the same reason.

You can program the fuse bits using AVRdude. In fact, there’s an example in the documentation. This command will reset the fuses to the factory settings:

avrdude -c dragon_isp -P usb -p m168 -U efuse:w:0xff:m -U hfuse:w:0xdf:m -U lfuse:w:0x62:m

AVR Peripherals (A Whirlwind Tour)

Take a whirlwind tour of the features available to you on this chip. This is gonna be quick, but you already have the core skills you need. Just read the datasheet and using the Internet to connect the rest of the dots.

EEPROM memory

Most (if not all) of the AVR chips come with Electronically Erasable Programmable Read Only Memory. This is persistent memory that stores data between resets and when there is no power to the chip. This is where data loggers store information and often contains things like text strings, font data, etc. AVR-GCC will generate an .EEP file at compile time with any EEPROM data that you use in your programs. This needs to be programmed to the chip separately from flash data.

Timers (Regular and Watchdog)

Timers are where it’s at in terms of functionality. They go far beyond simply measuring time, and can be used to wake the chip up from sleep mode, to generate pulse width modulation frequencies, and much more. Some chips have asyncronous timers, like Timer/Counter 2 on the ATmega168, that can use an external clock signal separate from the other timers.

Also not to be missed is the Watchdog timer. These timers can save money, and even lives. They are a hardware timer enabled through the fuse bits that will reset the microcontroller if not handled in software. Why would you want to do that? Because nobody writes perfect code. When using a Watchdog timer you frequently reset its counter during successful code execution. That way if your code ever hangs or gets caught in a loop the Watchdog timer will automatically reset the device, getting you out of a software-caused bind. See what [Jack Ganssle] has to say about them.

Real time counter

I mentioned above that Timer/Counter 2 can be run asynchronously from the rest of the timer/counters. Why is that valuable? One of the uses is as a Real Time Counter (RTC). This works in conjunction with a clock crystal to keep track of the time and date.

Hardware PWM

Continuing with the theme of timer/counter based featured, these chips have hardware-based pulse width modulation. PWM generates a signal between 0V and VCC by turning a pin output on and off frequently. The frequency used, and the duty cycle (ratio of high versus low over one period) are set in the registers and you don’t have to think about it again until you want to change them. This is useful for a slew of things, like dimming an LED, driving a servo motor, or generating sound on a piezo.

ADC

If you want to measure an analog value you need an Analog-to-Digital Converter. Most AVR chips have several of these with varying degrees of precision. This enables you to do things like measure light levels using a photoresistor and reading the value of a potentiometer (using it like a settings knob).

USART

The ATmega168 has a Universal Synchronous and Asynchronous serial Receiver and Transmitter which allows it to communicate in many different ways. This includes serial communications like USB (by taking advantage of the V-USB stack), as well as chip-to-chip communication standards like SPI, I2C, and TWI.

SPI

The AVR family often incorporates Serial Peripheral Interface bus communications protocols into its hardware. The USART on the ATmega168 offers master SPI functionality, used to control other chips that also use the protocol via three connections; two for data one for clock.

I2C/TWI

The USART also offers hardware I2C and Two Wire Interface features. Like SPI these are common chip-to-chip protocols but they use just two wires; one for data and the other for a clock signal.

Analog comparator

The analog comparator uses two input pins to compare analog signals. Based on their relation, the chip can be set to fire interrupts if one changes value compared to the other. The two inputs can be mapped to any of the ADC pins, but only two values can be compared at one time. I’ve never used this feature and I’m basing this description purely on what I’ve read in the datasheet. Sorry!

Lock bits

Any code you write to these chips can be read back and stored (albeit what comes back out is machine code, the C code we’ve been writing can never be reproduced perfectly from what you get off the chip). That can then be used to program other identical chips. But there is a feature called lock bits that can protect that code. Once set, the chip cannot be read, and depending on which bits are set it may not be able to be reprogrammed. That is, until the chip has been erased, which resets these lock bits.

JTAG, debugWire, and High Voltage Programming

In this tutorial we’ve been using In System Programming, but there are a few other ways to program AVR chips. JTAG is a standard hardware debugging (and programming) interface that some chips have, but the ATmega168 does not. Many of these chips can use the debugWire protocol to program and debug with just one wire communicating on the reset pin. Both JTAG and debugWire protocols are configured using the fuse bits.

High Voltage Programming is used to rescue chips that cannot be reached using other programming methods. There are two kinds, High Voltage Parallel Programming, like the ATmega168 uses, or High Voltage Serial Programming which chips with a low-pin count use. If you disable the Reset pin or enable debugWire, or set the clock source incorrectly in the fuse settings, HVPP or HVSP should be able to reset the fuses and rescue the “bricked” chip.

Power and Sleep

Microcontrollers operate so quickly there is often just wasted time as they scroll the infinite loop waiting for an interrupt to happen. If you are operating under battery power this just wastes juice. By using the power saving and sleep modes batteries can last longer. This is accomplished by turning off power hungry peripherals like the ADC, and shutting down the processor when not needed by putting it to sleep. They’re a bit tricky to understand, but often worth your while

Conclusion

That’s it really. I’ve had a great time writing about this. Fiddling with microcontrollers is my favorite hobby and I hope it has become yours as well. These are really very simple concepts that grow in complexity as you pile them atop each other. Just compare the original Part 2 source code with the bicycle tail light code. But that’s the fun of it. This is the inventor’s equivalent of a choose your own adventure novel. So come up with a challenge and see where it takes you!

Follow Me

@szczys

Resources

Part 4 Firmware package: Github repository

Atmel AVR ATmega168 Datasheet (PDF)

AVR Libc manual

[Jay Collett] was having trouble seeing his keyboard when the room was dim. But throwing a light under the desk just didn’t seem cool enough. Instead he built an RGB light board that is controlled by his desktop. The board is based around an ATmega328 with the Arduino booloader. He etched a single-sided PCB to connect it to a group of five RGB LEDs, with a programming header for an FTDI cable. The board communicates with a PC via serial connection, with a C# control application that [Jay] coded to control the color. We’ve embedded a couple of videos after the break but check his page for a package of code and hi-res pictures.

If you want something cool that’s a little bit less work to build check out the EL-wire keyboard from this links post.

[Alan] acquired a stereo microscope from eBay, and decided to save some more money by designing, machining, and assembling his own arc reactor ring light to go along. After finding an LED driver board sitting around as well as ordering some surface mount LEDs, he set about using a lathe to cut away a block of lexan, making sure to include slots for the lights as well as the microscope mount point. Follow the link to see the detailed build photos, as well as some comparison shots with and without the ring light.

A month or two earlier though, and [Alan] would have had a fantastic start to an Iron Man costume.

[Malikaii] is exercising the hacker spirit inside by building light stands out of junk. He’s using them as an alternative to purchasing off-camera flash units. He made this one using a lot of salvaged parts; two crutches make up the frame, a discarded reflector for one of those highway-work floodlights will house the flash, and an old pillow case diffuses the light. The version above can easily be moved around by an assistant, or if you’re shooting solo [Malikaii] also found that the base from an oscillating fan was easy to adapt for use with the crutch frame.

If you’re not able to scavenge these parts perhaps a folding light tripod is what you need.