We know that measuring the speed of light with an Arduino is possible. It’s just that the implementation is hard.

Last month we saw [Udo]‘s blinkenlight shield that can be used as a line scan camera. It’s a neat piece of kit, but [Udo] really wants to submit something for the Buildlounge laser cutter giveaway, so he figured measuring the speed of light would be an easy project. If a kid and a chocolate bar can do it, surely it can’t be too hard.

[Udo] hit upon the idea of pulsing a laser pointer and measuring the time of the reflection. Because his blinkenlight shield can be used as a light sensor, all that’s needed is a mirror and a pretty long line of sight. There’s a few problems with the setup though: with the Arduino running at 16 MHz, a photon will travel 19 meters in one clock cycle.

Even with some very clever coding, we’re not really sure detecting an emitted photon is possible at such (relatively) slow clock speeds. We’re thinking [Udo] could source a few hundred meters of optic fiber so the entire experiment could fit on a desk, but feel free to drop a note in the comments if you’ve got a better idea. [Udo]‘s demo of his blinkenlight/laser mashup is after the break.

So you’re getting better at programming microcontrollers and now you want to do several things at once? You know better than that, microcontrollers are only capable of processing one thing at a time. But if you’re clever with your coding you can achieve something that behaves as if several things are going on at once. The most common way to do this is to set a flag using an interrupt, then use the main loop to check for that flag. [S1axter] posted a tutorial on this topic where he uses bit field structures to help simplify time sensitive events.

We think [S1axter] did a fantastic job of explaining this moderately difficult topic clearly and quickly. In the video after the break he begins by explaining what a bit field is and how it is defined. Basically you’re using a C structure to track a flag using just one bit of storage. This way the flag is either set or not. We suggest you pay careful attention to how he declares the structures as volatile, so you don’t have unexpected behavior when you try it yourself.

Chances are you have already heard of the passing of [Dennis Ritchie]. We admit, we’re among the throngs who knew little of his life, but [Cade Metz] has posted an excellent remembrance of his life which we think is well worth reading.

[Dennis] passed on October 12th at the age of 70. This image shows him receiving the National Medal of Technology awarded to him by [Bill Clinton] in 1998. His legacy lives on in the work that earned him this award as the creator of the C programming language; a side project which he developed to help him achieve the creation of a new system kernel called UNIX. This work, of course, was the precursor that led to universal software packages like OSX, iOS, Linux, and even Windows (which at one point was itself written using the C language).

There has been some Internet fodder regarding media coverage of [Steve Jobs'] death and not of [Dennis'] passing. It’s harder for those lacking experience with programming to comprehend [Dennis'] contributions. We’re glad to have an opportunity to pass on the story of his life and to take a moment to appreciate his accomplishments.

[Thanks Dave]

[Photo Source]

[Mike] sent in a project he’s been working on – a port of a BASIC interpreter that fits on an Arduino. The code is meant to be a faithful port of Tiny BASIC for the 68000, and true to Tiny BASIC form, it fits in the very limited RAM of the Arduino.

True to Tiny BASIC’s assembler roots, [Mike]‘s C port makes extensive use of the “infinitely-abusable” goto statement. Kernighan and Ritchie said themselves, “code involving a goto can alway be written without one” but [Mike] found that using goto left a lot more room available for BASIC code. The BASIC interpreter eats up around 600 bytes in the Arduino RAM, leaving about 1.4 kB for BASIC code. Not much, but more than the lowest-end BASIC Stamp.

[Mike] says he started this project to see how ‘old bearded ones’ conjured up so many impressive programs with a few kB of RAM. Tiny BASIC was originally conceived for the Altair 8800 that shipped with 256 bytes of RAM stock, so it seemed like a perfect fit. Right now, all we know is we’ll be spending the weekend digging through our copies of Dr. Dobb’s Journal.

Microsoft has thrown its hat into the open source hardware hobby market. Their offering is called the Gadgeteer. We’d love to tell you all about it, but the big M didn’t make it very easy to find out about the device and it’s addons. When we set out to find what processor is running on the board we were happy to see that they do call it an Open Source Hardware project, but no schematic is posted. When we did finally navigate to the hardware documentation it’s a file that must be downloaded and you’ve got to agree to their licensing before grabbing it. So that’s as far as we went, and now we’ll go back to using more open tools.

For those of you who aren’t scared off by the lack of openness, the first thing you’ll notice about this board is that it’s full of connector headers. Instead of the small rows that Arduino uses, the Gadgeteer is meant to use ribbon cables to connect to various breakout boards. You can program for the platform in C# using the .NET framework. This means using Microsoft Visual Studio for those that are already acquainted with the platform. But regular readers will note that we’re always looking for Linux support in our IDEs and you won’t find that here.

[Thanks Hrasdt (and several others) via Slashdot]

[Bob Alexander] admits that he over-engineered his clock, giving it eight control buttons, eight twelve-segment alpha-numeric display digits, a GPS module as a time source, and a beefy microcontroller to boot. But he’s found a way to get more for his money out of the device by adding RSS and weather features to it.

Since he’s using the PIC 18F4550 it’s a snap to add USB connectivity. From there he wrote a fantastic PC-side application for communicating with the display. Now he has the option of displaying time, RSS feeds, or weather by scrolling through the options with one of the buttons. Perhaps the best feature is the option to launch a browser on the PC and view the current story just by pressing a button on the display. Check out the two demos after the break; one shows the clock features and the other demonstrates the C# software.

Clock  features

Software features

[Luigi Rizzo] has been working on some hacks for his 3rd generation Kindle. There is already a Python based terminal emulator called AjaxTerm but he wanted a lightweight standalone so he reimplemented the program in C. The 100k binary monitors the keyboard, launching the terminal emulator when it detects a Shift-T sequence. It also uses alternative key mapping to fill in for some of the keys the Kindle’s keyboard is missing.

We haven’t seen a whole lot of Kindle hacking since it was hacked to run Ubuntu. Seems like this terminal emulator is a useful and unobtrusive hack to try out on the beloved reader.

[Oliver Kreylos] is using an Xbox Kinect to render 3D environments from real-time video. In other words, he takes the video feed from the Kinect and runs it through some C++ software he wrote to index the pixels in a 3D space that can be manipulated as it plays back. The image above is the result of the Kinect recording video by looking at [Oliver] from his right side. He’s moved the viewer’s playback perspective to be above and in front of him. Part of his body is missing and there is a black shadow because the camera cannot see these areas from its perspective. This is very similar to the real-time 3D scanning we’ve seen in the past, but the hardware and software combination make this a snap to reproduce. Get the source code from his page linked at the top and don’t miss his demo video after the break.

[Thanks Peter]

We live in a world where everything must be portable, ranging from mobile applications to making an application able to run on Linux, Windows and OS X.  Making a C# application to be completely portable across all windows computers is a problem that Microsoft knows about and willingly admits they will not fix. [Mike] from Geek Republic has taken it upon himself to show us how to hack up some code to make your programs portable.  This code is a good push forward for people loving the portability of modern applications. He will admit that bugs may exist so be on the lookout and he would probably appreciate the feedback.  Looking forward to a fully working provider so that .NET applications can be carried wherever people go!

[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.

In the last installment of our tutorial series we built a simple circuit on a breadboard and programmed an ATmega168 to make it run. That proves that you know how to follow directions, but the eureka moments of doing everything yourself are on the way. This time around you will get down and dirty with the datasheet, learning where each line of the sample code came from, and give your recently installed compiler a test drive. We will:

• Talk about bitwise operators and how they work when coding for microcontrollers
• Discuss C code shorthand
• Review the sample code from Part 2 and talk about what each line of code does
• Learn to compile code

If this is the first you’ve heard about our AVR Programming series, head back to Part 1 and start from the beginning. Otherwise, take a deep breath and we’ll being after the break.

Series roadmap:

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

Prerequisites

• You must know something about C code. The ability to read it is probably good enough, Google can help you with the rest as you learn.
• It helps if you have a text editor that includes syntax highlighting. I’m purely a Linux user and I like to use both Kate and Gedit depending on my mood. But I also use nano from the shell quite frequently. This is a tool and your choice is purely personal preference.
• Grab the sample code from part 2 of the series. I’ve embedded it below but you may want it in a separate windows for reference.
• Datasheets; the instruction manual for hardware. Grab the datasheet for the ATmega168 as I’ll be referencing specific pages as examples. Knowing how to look up information in the datasheet and turn it into code will make it easy for you to use any chip in the AVR family.

Bitwise Operators

Even though we’ll be writing code in the C language, we’re quite close to the hardware when programming microcontrollers. Because of this you must understand bitwise operators. Not just kind of, not intuitively, you should know them well enough to teach them to someone else without looking it up.

Hands down the best explanation I’ve ever come across is by [Eric Weddington], who also co-authored the makefile that came with my example code. It is also known as Programming 101. Read it, know it, love it. But I’ll try to give a quick crash course for those to lazy to read his whole lesson.

The list above shows all of the code symbols and their logic operation.

• OR – true if either or both bits being compared are 1
• AND – true only if both bits being compared are 1
• NOT – results in the opposite of a value (~1 = 0, ~0 = 1)
• XOR – exclusive OR… true if one bit being compared is 1 but false if neither or both of them are
• Shift Left – moves bits left within a binary number. (1<<0 = 0b0001, 1<<4 = 0b1000)
• Shift Right – moves bits to the right a desired amount (0b1000>>2 = 0b0010)

We’re going to use Shift Left all the time in our code because it’s a quick way to build a binary number. We’re always working in binary numbers made up of eight bits. Those bits are numbered 0-7 because counting always starts with 0 when it comes to microcontrollers. So if you want to set the fifth bit to a logic high (’1′) you would shift ’1′ left by 5:

1<<5

This will result in the binary number 0b00100000. If this is child’s play, move to the next section. If not, read [Eric's] tutorial.

C Code Shorthand

I tend to use shorthand in my code as my hands often hurt from too much typing (as they do now). This saves a bit on the old ibuprofen expenditure for the month by allowing me to type less characters to accomplish the same simple assignments. Here’s a quick table of examples:

So basically, if I am setting a variable by using that same variable as the first operand I can just place the operator before the equals sign and put the second operand after the equals sign to accomplish the same task without typing the variable name twice. If you understood that sentence you’re doing quite well!

Jump into the sample code

Psuedocode

A good practice when developing code is to write psuedocode. Something that clearly states what you want to do in plain language. This is an outline of the structure that your program will take and it shouldn’t include any specific code, but will be replaced by that code later:

//Setup the clock
  //prepare an interrupt every 1 second

//Setup the I/O for the LED

//toggle the LED during each interrupt

This program is so simple that the psuedocode seems unnecessary, but it will keep you focused and help stave off errors on larger projects.

The Actual Code

The main.c from the Part 2 sample code is embedded below. Take a minute to match up the parts of the psuedocode above with actual code blocks below.

/*
* Hackaday.com AVR Tutorial firmware
* written by: Mike Szczys (@szczys)
* 10/24/2010
*
* ATmega168
* Blinks one LED conneced to PD0
*
* http://hackaday.com/2010/10/25/avr-programming-02-the-hardware/
*/

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

int main(void)
{

  //Setup the clock
  cli();			//Disable global interrupts
  TCCR1B |= 1<<CS11 | 1<<CS10;	//Divide by 64
  OCR1A = 15624;		//Count 15624 cycles for 1 second interrupt
  TCCR1B |= 1<<WGM12;		//Put Timer/Counter1 in CTC mode
  TIMSK1 |= 1<<OCIE1A;		//enable timer compare interrupt
  sei();			//Enable global interrupts

  //Setup the I/O for the LED

  DDRD |= (1<<0);		//Set PortD Pin0 as an output
  PORTD |= (1<<0);		//Set PortD Pin0 high to turn on LED

  while(1) { }			//Loop forever, interrupts do the rest
}

ISR(TIMER1_COMPA_vect)		//Interrupt Service Routine
{
  PORTD ^= (1<<0);		//Use xor to toggle the LED
}

The first few lines are comments for the benefit of human eyes and will not be used by the microcontroller. Comments in C are prefaced by two slashes (//) for single line comments or encased in slash-star (/*) and star-slash (*/) pairs for multiline comments. It’s a good idea to write comments that detail the program, what it does, what hardware it runs on, and any other helpful information. I find that I often reuse code from past projects and a bit of information at the top of the file helps locate what I’m looking for quickly.

The Includes

The next thing you see are the includes:

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

Includes tell the compiler that we’re going to be using things from other files. In this case, two files from AVR Libc that came with the cross-compiling toolchain we installed in Part 1. These are C files that allow us to use human-readable (and rememberable!) code when working with the hardware on the chip. The io.h file rolls header files for all of the supported AVR chips into one. We define what processor we’re using in our makefile, and the appropriate header file is automatically chosen from io.h when we compile our code later in this tutorial.

In our example code I’ve used names like DDRD, PORTD, TCCR1B, OCR1A, TIMSK1, etc. All of these have addresses that are pointed to using the io.h file. This allows us to call pins on the chip by the names like PORTD which are the same across all AVR variants instead of register addresses like 0x0B which has different functions on different chips. Most likely you’ll need to include io.h in every AVR program you use, and doing so makes your code more portable. The interrupt.h file is only needed if you are using interrupts, something we’ll talk about as we look at the next code block

Setting up the clock for use with interrupts

Processors need a clock signal in order to work. AVR chips can use external clocks like a crystal oscillator or a ceramic resonator, but they come from the factory configured to use the internal RC oscillator as the system clock (read more on page 28 of the datasheet). The internal RC oscillator of the ATmega168 runs at approximately 8.0 MHz depending on voltage stability and temperature. It also ships with the DIV8 fuse enabled which divides the clock signal down to 1.0 MHz. For the sample program I wanted an LED to blink between on and off, changing about once a second. Here’s the code block that sets that functionality up:

  //Setup the clock
  cli();			//Disable global interrupts
  TCCR1B |= 1<<CS11 | 1<<CS10;	//Divide by 64
  OCR1A = 15624;		//Count 15624 cycles for 1 second interrupt
  TCCR1B |= 1<<WGM12;		//Put Timer/Counter1 in CTC mode
  TIMSK1 |= 1<<OCIE1A;		//enable timer compare interrupt
  sei();			//Enable global interrupts

The very first line has something to do with interrupts. An interrupt is a great feature of microprocessors. Basically you tell the chips to watch for a certain condition. When it matches that condition it will stop what it is doing no matter where it is, and run a different set of code called an Interrupt Service Routine (ISR). Because we are about to change some settings having to do with interrupts, we don’t want anything (like an interrupt) to stop us in the middle of this process. I’ve used a command that is available to us because we included interrupt.h at the beginning of our file. The command is cli(); which disables all interrupts. Once we are done with our settings we must remember to enable them again, using the sei(); command. You can see I’ve done that at the bottom of this code block

Now we want to watch for the passage of 1 second worth of time. The four lines in between these two commands are used to setup a counter to do just that. Because the internal oscillator is running at 1 MHz, or 1 Million cycles per second, we must trigger an interrupt every 1 million cycles. The biggest timer this chip has is 16-bits which can only count from 0 to 65,535. In other words, we don’t have a timer that can count high enough to measure such a large number of cycles.

Fortunately, we have the option to use a divider with our timer, called a prescaler. To do so we look in the datasheet on page 134 to see a chart outlining the clock select. It shows prescaler options which divide the system clock by 1, 8, 64, 256, and 1024. Knowing that we want to count 1,000,000 cycles we can use a bit of math to choose the best prescaler:

1,000,000 / 1 = 1,000,000
1,000,000 / 8 = 125,000
1,000,000 / 64 = 15,625
1,000,000 / 256 = 3,906.25
1,000,000 / 1024 = 976.5625

The math only leaves us with one choice. That’s because using a prescaler of 1 or 8 results in a number of cycles that is larger than 65,536 so our 16-bit timer can’t count high enough. Prescalers of 256 and 1024 give results that are not a whole number. If we don’t use a whole number we introduce an inaccuracy in our timing because we can’t measure a fraction of a cycle. A prescaler of 64 meets both our needs, being a whole number that is smaller than the limits of our 16-bit counter.

How can we set up this prescaler? The datasheet tells all. Looking at “Timer/Counter1 Control Register B” (TCCR1B) which spans pages 133 and 134 we can find the answer. Diagram 15-5 shows a clock settings table. In our case we need to set CS10 and CS11 to ’1′ on the TCCR1B register. To do this we use an OR operator and Left Shift a ’1′ to the location of the CS10 and CS11 bits:

  TCCR1B |= 1<<CS11 | 1<<CS10;

Because this is our first real bitwise math let’s look at it in depth. First off, we’re only setting two bits on the register so we do not want to use just an equals sign. If I had done that, this command would force all other bits to zero. Instead, I use shorthand code to use the OR operator to compare TCCR1B with a bitmask containing a ’1′ at the correct location for the CS10 and CS11 bits. Any other bits on the  TCCR1B register that are set to ’1′ will remain so.

I’ve created a bitmask to the right of the |= operator. As I talked about in the includes section, CS10 and CS11 are defined in io.h. But looking at the TCCR1B register we can see that CS10 is on bit 0 and CS11 is on bit 1. If you solved your math problem longhand it would look like this:

1<<CS11 | 1<<CS10;
1<<1 | 1<<0;
0b00000010 | 0b00000001;
0b00000011;

This is the method that you use for setting any bit for any purpose. It really is that simple. Build a bitmask and apply it to a register or variable. Just remember to be careful about preserving data that might already be stored on a register or in a value but using the OR operator during assignment.

Now that we have a divided clock source for the counter, and a target number of 15,625 cycles to watch for thanks to the math above. We can use one of the modes of Timer1, the Clear Timer on Compare Match (CTC), to trigger an interrupt at that exact cycle count. Take a look at page 121 of the datasheet and you will see we need to set OCR1A to our target value. We’ll set it to 15,624, one less than our cycle count because microcontroller timers start counting with the number zero, not one. This time we will use an equal sign because there are no other values stored in this register:

  OCR1A = 15624;

I also need to set the timer mode I want to use. Table 15-4 on page 133 has a lot of information on this. As discussed before, I want to use CTC mode so that narrows my choices on this table down to just two. I can choose between those because I know I’m using the value of OCR1A as the largest number the timer should count to, or TOP. The chart tells me to set the WGM12 bit on the TCCR1B register to 1.:

  TCCR1B |= 1<<WGM12;

This could have been done at the same time as the timer prescaler because they’re set on the same register. But it’s fine to do it in two steps because I’ve used the OR operator, making sure I’m not changing any of the other bits on this register.

The next step can be a “gotcha” for new developers. Everything is now setup correctly for our timer to trigger an interrupt at the appropriate interval. But if we don’t set the “interrupt enable” flag for that particular event, the interrupt will never happen. Page 136 of the datasheet cryptically discusses the use of the Timer/Counter Output Compare A Match Interrupt Enable. Setting this bit to 1 will enable the CTC interrupt we are planning to use:

   TIMSK1 |= 1<<OCIE1A;

Simple right? Do it a few times and it will be. There’s a lot of functionality with the timers on these chips and wading through the register settings is the price you pay for that power. But now we’re ready to go with 1-second interrupts.

Initializing the Input/Output pins

When an AVR chip resets, the pins are all placed in tri-state mode. At the beginning of the program any input and output pins need to be setup for their desired function. Starting on page 73 of the datasheet you can read about using pins as general input and output. There are three registers for each pin that we will generally be concerned with: Data Direction Register (DDR), Port register (PORT) and Pin register (PIN). Each of these will be suffixed with a letter corresponding to which set of pins we are working with. I’ve connected the LED to Port D so I need to work with DDRD, PORTD, and if I was using inputs, PIND.

  //Setup the I/O for the LED

  DDRD |= (1<<0);		//Set PortD Pin0 as an output
  PORTD |= (1<<0);		//Set PortD Pin0 high to turn on LED

The code above is used to set up an LED. Setting a bit on DDRD to 1 will make the corresponding pin an output. Setting it to zero would make it an input. Here I’ve set up an output because we are driving an LED. Outputs can be turned on or off by setting a 1 or a 0 to the PORT register respectively. So above I’ve used PORTD to turn on bit 0 which corresponds to pin connected to the LED.

If we were using a pin as an input the PORT register would be used to enable or disable an internal pull-up resistor and the PIN register would be used to measure the logic value currently present on that pin. Table 13-1 on page 74 shows the various states of I/O pins, but I’ll cover it more in part 4 of this series.

The Loop

Embedded programs must have an infinite loop that prevents the program from getting to the end and exiting. That’s because if our program exits the chip will just sit there and do nothing (after all, there’d be no program running). In this case I don’t need the loop to do anything since I’ve already set up the hardware and I’m using an interrupt to blink the LED:

  while(1) { }			//Loop forever, interrupts do the rest

I’ll add functionality to the loop in Part 4 or the series, but for now the ‘while(1)’ loop just traps the program and does nothing else.

Handling the interrupt

Everything is now setup and ready to go, but nothing will happen unless we write code that does something after the interrupt happens. This is called an Interrupt Service Routine (ISR). The rest of the code is halted and this routine is run. It is best to keep this as short as possible, which is easy here because we just need to toggle the LED:

ISR(TIMER1_COMPA_vect)		//Interrupt Service Routine
{
  PORTD ^= (1<<0);		//Use xor to toggle the LED
}

If you look at page 62 of the datasheet you can see that the interrupt source for Timer/Counter1 Compare A match is called “TIMER1 COMPA”. We take this and use it as the input variable for the ISR, replacing spaces with underscores and adding a lower case “vect” at the end. This is how the compiler knows which ISR belongs to different interrupt sources. As for the LED itself, I’ve used the XOR operator and a bitmask. The bitmask ensures that only bit 0 will be changed.

Compiling Code

Before we leave this segment of the tutorial series you should give your compiler a test-drive.

The compiler takes our C code and turns it into a file that can be written to the microcontroller. The ins and outs of a compiler get a bit hairy and this isn’t the time to explain those details. But as you learn to write embedded code you should make an effort to also learn how this code will be interpreted by the compiler. Doing so will prevent a lot of headaches caused by optimization (the compiler trying to streamline your bloated C code) and it will allow you to make the most of your hardware both in terms of programming space, and functionality.

But for now there’s a make file included in the example source from Part 2. If you haven’t already, unzip that package and navigate to the ‘src’ directory. There are two files in that directory, main.c and makefile. A makefile is a way to automate the compiling process. This one compiles, links, and programs a C code source file. If you look at the makefile you’ll notice that there are several user settings near the top. You need to setup the microprocessor for which you’ve written code, the name of the source file you’ve written (TARGET = main), the programmer you’re using (from the AVRdude list discussed in Part 2), and the port path for the programmer.

If you type ‘make’ you should be able to compile the example program. Unless you have an AVR Dragon programmer and you’re running Linux you’ll get an error when it tries to program the chip, but it should compile the code and output several extra files:

$  ls -la
total 84
drwxr-xr-x 2 mike mike  4096 2010-11-04 14:20 .
drwxr-xr-x 3 mike mike  4096 2010-11-01 14:55 ..
-rw-r--r-- 1 mike mike   894 2010-10-24 12:34 main.c
-rw-r--r-- 1 mike mike    23 2010-11-04 14:20 main.d
-rw-r--r-- 1 mike mike    13 2010-11-04 14:20 main.eep
-rwxr-xr-x 1 mike mike  7121 2010-11-04 14:20 main.elf
-rw-r--r-- 1 mike mike   750 2010-11-04 14:20 main.hex
-rw-r--r-- 1 mike mike  5224 2010-11-04 14:20 main.lss
-rw-r--r-- 1 mike mike  5171 2010-11-04 14:20 main.lst
-rw-r--r-- 1 mike mike 14464 2010-11-04 14:20 main.map
-rw-r--r-- 1 mike mike  3972 2010-11-04 14:20 main.o
-rw-r--r-- 1 mike mike  1454 2010-11-04 14:20 main.sym
-rw-r--r-- 1 mike mike 10235 2010-10-24 10:44 makefile

‘main.hex’ is the file that you can program onto the microcontroller. This makefile is extremely versatile. You can also see that it output ‘main.eep’ which can be used to program the EEPROM on the chip if your code includes default data stored in the EEPROM. It can also be altered to output an assembler file, or binaries in different formats.

If you’re compiler didn’t spit out this information, there’s something wrong with your toolchain. Use your friend Google to search for any error messages and see if you can’t get things fixed up. Another great exercise would be to modify this file to work with your programmer. If you managed to get AVRdude working in Part 2 of this series, this alteration is as simple as changing the makefile to use those same settings.

Conclusion

That’s it for now. In the next installment of this series I’ll be talking about fuse bits, writing our own code, and I’ll try to touch on many of the different peripheral features of this chip. I’m plan to augment the original circuit with a few more LEDs (so make sure you have at least 8 of them and their matching resistors) along with adding a button for input. Thanks for reading!

Follow Me

@szczys

Resources

Atmel AVR ATmega168 Datasheet (PDF)

AVR Libc manual

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]

In this tutorial we are going to get up close with the Visual Studio 2010 environment. We will learn how to make a console application as well as a form to display our hello world applications.  This will give us an opportunity to view 2 types of solutions of the many available in Visual Studio.  We will start making the console application first then progress to the forms application.

First we must  understand the development environment we are going to use.  On the far left side is the toolbox panel.  This panel gives us access to a lot of controls  that can be used by the Windows Forms.  Next is the Solution Explorer that will allow us to navigate the projects and files we are going to create in this Solution.  The Properties panel is directly under my Solution Explorer and will allow us to change properties of controls and of the form we will create later on.  If any of these are not being displayed they can be retrieved from the View menu at the top under Other Windows.  For more information on the Visual Studio IDE visit MSDN and search for the specific questions you are having.

Then we need to start the Visual Studio environment and create a new project.  To do this we will go to File then navigate to New Project and click it.  A dialog box will appear and ask you which project you would like to include in your solution that will be automatically created for your project.  We need to use the Console Application.  Next we need to replace the box at the bottom where it says ConsoleApplication1 with HelloWorldConsole and then after the project and solution is created press CTRL-S to change the name of the solution file to HelloWorld in the box under the project name box and press OK.  This will create a project inside a Solution file. The solution file acts like the glue that binds all projects included in the solution file together.  Later on we will discover how this is beneficial for creating projects and making class files that reference DLL’s that we will code.

Once the project is created we are going to edit the program.cs file.  After you have open the program.cs we are going to add the text necessary to have the program output “Hello World” to the console.  To do this we will need to add the line Console.Out.WriteLine(“Hello World!”); inside the static void main curly brackets.  After this is complete we can now build and attempt to build our solution.  To build the solution we need to press CTRL + SHIFT + B and the build process will being.  After the build is a success we can now run the Console Application by pressing CTRL + F5. This will display a command prompt with “Hello World!”.

Here is the source code for program.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace HelloWorldConsole
{
class Program
{
static void Main(string[] args)
{
Console.Out.WriteLine("Hello World!");
}
}
}

We can now move on to the windows forms application of Hello World.  To do this, we need to go to the solution and Right Click, then go to Add then click New Project.  For the project we will name it HelloWorldForms.  After the project is created we are going to delete the Form1.cs and we are going to create a new form by Right Clicking the HelloWorldForms Project, Navigating to Add then to New Item,  and when the dialog box appears we are going to pick Windows Form.

The name we are going to use is main.cs and press Add.  We now edit the program.cs to change the Form1 that can be found in the file to main.  After the Windows Form is created we can start adding in Controls from the Toolbox.
We are going to drag a label and a button onto the form portrayed in the middle of the program.  We are going to edit the properties here to make the text inside the label blank and the name of the label lbHelloWorld instead of label1.  After this is done we are going to want to edit the button we dropped onto the form earlier.  We will change the name of the button to btnHelloWorld and the Text of the button to Click Me!.  After this is done we are going to want to use an event handler to tie the button and the label together, so when the button is clicked “Hello World!” will appear in the label.

To make an event handler for the button we are going to go to the Properties panel and click the button on the top that looks like a lightning bolt.  This will take us to all o the event handlers that this button can handle.  We want the Click event handler, this will create the code required to handle a click event in the main.cs.  Now that the wrapper is there we can code the output to the label when the button is clicked.  Inside the curly brackets of “private void btnHelloWorld_Click” in main.cs input the following line of code to link the two Controls:

lbHelloWorld.Text = “Hello World!”;

This will make the main.cs look like this:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace HelloWorldForms
{
 public partial class main : Form
 {
 public main()
 {
 InitializeComponent();
 }

 private void btnHelloWorld_Click(object sender, EventArgs e)
 {
 lbHelloWorld.Text = "Hello World!";
 }
 }
}

The program.cs should look like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;

namespace HelloWorldForms
{
 static class Program
 {
 /// <summary>
 /// The main entry point for the application.
 /// </summary>
 [STAThread]
 static void Main()
 {
 Application.EnableVisualStyles();
 Application.SetCompatibleTextRenderingDefault(false);
 Application.Run(new main());
 }
 }
}

After all of this is completed we need to run the program by pressing CTRL + F5 again. The screen that should appear should be something like this:

The screen after the button has been pressed should look like this:

Now that we have completed the next tutorial you should be able to move through the Visual Studio IDE to make multiple projects under one solution, delete files within a project and create new forms and classes, and modify source code within event handlers.  The next tutorial will go more in depth with the Visual Studio Toolbox and make a form with controls on it with minimal backbone code, as well as review some of the common files created and what is automatically included for you.  For more information on Toolbox Controls you can check out Microsoft MSDN article on Toolbox Controls. If you are having any trouble with this project feel free to comment and I will help to try and resolve the issue.  Until next tutorial, Happy Hacking!

[StaticChanger] built a scoreboard to display his kill statistics from Halo for the PC. Yes, we’ve seen kill counters before, but we like the way that he gathers the data. This project is reading the score directly from an address in memory.

Using a program called Cheat Engine, the memory used by a program can be sniffed. After a few passes, the program will help you find a static memory address for your desired data. Once you have that it’s just a matter of using a pointer to that address in your desired programming language. In this case, a C# program polls the value and instructs an Arduino to display the value on a couple of 7-segment displays. Voila, the number appears next to your screen as you see in the image above.