[Quinn Dunki] keeps rolling with her 6502 based computer build. This time around she’s added some memory to store the programs, but needed a way to get that code into the device. Above is her solution, a bank of hex switches used to program the 8-bit command and 16-bit address for each line of machine code.

This is a continuation of her Veronica project. The last time we saw it she had hardwired the logic levels for the data bus, but that’s no fun since nothing can actually be computed. [Quinn] picked up an SRAM chip which will store the program. It’s compatible with the 6502′s memory bus, but needs a bit of extra circuitry for her to be able to hand program it with this switch bank. She used some tri-state buffers to switch between connections to the processor, and to the hex switches. This way, she disconnects the RAM from the processor using the buffers, uses the switches and push button to clock in the program, then patches the RAM back into the computer.

Seeing this process in the video after the break certainly gives you an appreciation for what an improvement the punch-card system was over this technique. Still, seeing this is a delight that we’d like to try!

The International Obfuscated C Code Contest is back. The stated goals of the IOCCC are to, “Write the most obscure C program, show the importance of programming style (by doing the opposite), stress the preprocessor to the breaking point, and illustrate some subtleties of the C language.” If you think you’re up to the task of abusing your compiler, check out the rules and guidelines for the contest.

There’s nothing quite like having the code for a flight simulator look like a plane, or calculating pi by measuring the area of C code. The submissions to the IOCCC are classic hacks; very clever things that shouldn’t work, but do despite themselves.

There hasn’t been an IOCCC competition since 2006, and no one knows if it will be around next year. We’ve already seen a few potential entries for this year, like piping chars into /dev/audio to generate a song and hyperlinks all the way down. If you’ve got something you’re working on, feel free to send it in.

via /.

“I can’t hear myself in the mix,” “yeah, man, I’ll be there at 8,” and “dude, we need like four more mics.” Each and every one of these words is documented in actuarial tables and doesn’t bode well for your sound tech’s risk of a stroke. Luckily, there’s an even better way to kill your sound guy and this time, it’s actually pretty clever.

[@dop3j0e] at the Stuttgart hackerspace Shackspace came up with the Noiseplug. It’s a very small build that could almost fit into a quarter-inch jack. It’s all SMD with a tiny (unknown) ATtiny9 microcontroller powered by a watch battery.

The music coming out of the Noiseplug is really interesting. All the code on the microcontroller is a one-liner written in C. Similar ‘algorithmic chiptune’ programs can be run on any PC: check out these three examples.

These potential entries to the International Obfuscated C Code Contest throw chars into an 8-bit PCM stream. Piping the output of these programs to /dev/audio would generate an actual song – written entirely in one line of C.

Of course, [@dop3j0e] could have made his Noiseplug a little less annoying, but sound techs are underappreciated for a reason, right?

Check out the Noiseplug in action after the break along with a few one-liner C songs.

All of those orange, cyan, and yellow dots represent digital ants fighting for supremacy. This is a match to see who’s AI code is better in the Google backed programming competition: The AI Challenge. Before you go on to the next story, take a hard look at giving this a try for yourself. It’s set up as a way to get more people interested in AI programming, and they claim you can be up and running in just five minutes.

Possibly the best part of the AI Challenge is the resources they provide. The starter kits offer example code as a jumping off point in 22 different programming languages. And a quick start tutorial will help to get you thinking about the main components involved with Artificial Intelligence coding.

The game consists of ant hills for each team, water as an obstacle, and food collection as a goal. The winner is determined by who destroyed more enemy ant hills, and gathered more resources. It provides some interesting challenges, like how to search for food and enemy ant hills, how to plot a path from one point to another, etc. But if you’re interested in video game programming or robotics, the skills you learn in the process will be of great help later in your hacking exploits.

[Chris] wrote us to share a neat technique he has been using to program the Arduinos he uses in his projects. He likes to build bare bones Arduino clones rather than sacrifice full dev boards, and instead of programming them via traditional means, he is using his computer’s sound card.

He builds a simple dead bug Arduino (which he calls an Audioino) using a handful of resistors, a pair of caps, an LED, a reset switch, and most importantly – an audio jack. After burning a special audio bootloader to the chip, he can connect the Arduino directly into his computer’s speaker port for programming.

Once the microcontroller is connected to his computer, he runs the IDE-generated hex file through a Java app he created, which converts the data into a WAV file. With the Arduino put into programming mode, he simply plays the WAV file with an audio player, and the code is uploaded.

He says that this method of programming comes in handy in certain cases where he builds things for friends, because they can easily update the software on their own without a lot of fuss.

If you are in the market for a PIC microcontroller programmer, you may want to consider a model with an In-Circuit Debugger (ICD). [Rajendra] put together a great tutorial on using an ICD when debugging PIC firmware, which makes a pretty convincing argument for owning one.

In his tutorial, he happens to be using a MikroElektronika PICflash2, but he says that there are plenty of other ICDs out there if you are not keen on this particular model. The PICflash2 not only acts as an ICD, but as the name suggests it works as an ICSP as well.

[Rajendra] walks us through a short debugging session using some simple code that reads data from an LM34DZ temperature sensor, displaying the results on an LCD screen. While he isn’t actually hunting for bugs, he does show how easy it is to step through the PIC’s code one statement at a time, evaluating variables and registers along the way.

[Rajendra] does point out that using an ICD does occupy a few I/O pins while running, limiting your resources just a bit. We think that being able to debug code as it runs is pretty reasonable tradeoff if you don’t necessarily need each and every pin available for use.

Microsoft just released the beta of the Kinect for Windows SDK. Although, “Microsoft does not condone the modification of its products” it appears Microsoft have changed their tune and released APIs for C++, C# and Visual Basic seven months after the Kinect was officially hacked.

We’ve seen libraries being developed since the launch of Kinect, culminating in the OpenKinect project. The Microsoft release covers the same ground as the OpenKinect project, and will hopefully improve on attempts to get audio out of the Kinect.

We’ve seen Kinect hacks run the gamut from telepresence, to robotics, to 3D modeling, so the Kinect seems like a great tool in the builder’s arsenal. The Kinect is a wonderful tool, and even though most of the functionality has already been replicated by the open-source community, it’s nice to know there’s official support for all the great projects we’ve seen.

In his line of work, Hackaday reader [Pedantite] often has to monitor the build status of several continuous integration servers throughout the day. One afternoon, he got the idea to install a set of stop lights in the office in order to monitor the status of the servers, but filed it away as a “wouldn’t it be cool if…” project.

After some time had passed, he was bitten by the idea bug again and decided he would build a physical device to display the status of his build processes. This time around, he brainstormed on a smaller scale and the result is the “Indictron” you see above.

He built a simple LED board made up of four rows of four LEDs to display the build processes. Different LEDs are lit depending on the project’s current build status as well as the results of the previous build. The board uses an ATmega88, and interfaces with a compiler watchdog application using a virtual USB package made specifically for AVR micro controllers.

The end result is a simple, yet useful status board that “just works”. He does not seem to have code or schematics posted on his site at the moment, but we’re pretty sure he would share them upon request.

If you’re interested in a bit more of [Pedantite's] work, check out his “Good Times” parental timer we featured last week.

[Pyra] was looking for a way to reprogram some ATtiny13 microcontrollers in a SOIC package. He’s re-engineering some consumer electronics so adding an ISP header to the design isn’t an option. He had been soldering wires to the legs of every chip but this is quite tedious. What he needs is an adapter that can make physical contact with the legs just long enough to program new firmware. After looking around he discovered that a PCI socket can be used as a progamming clip (translated). It shares the same pitch as a standard SOIC package but is not wide enough for the chip. He cut out 4 rows of the socket and the section of motherboard it was soldered to. Then he made a cut down the middle of the plastic and bent the two sections apart. The image above illustrates this, but not shown are the eight wires that he later added to connect to the device.

We wonder if this can be adapted to program SOIC parts without removing them from a circuit board. That would be a handy tool for finishing up the LED lightbulb hack.

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

You may be able to write the most eloquent code in the history of embedded systems but without a way to run it on the hardware it will be worthless. In this installment of the tutorial series we will:

• Look at some of the available AVR programmer options
• Place the microcontroller on a breadboard and connect it to a power supply and a programmer.
• Use programming software to send some example code to the microcontroller

If you missed Part 1 take a few minutes to review that portion of the tutorial and then join us 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

Programmers

As I said before, if you want to get it on the chip you’ve got to have a programmer. There are a huge number of options, but I’ll cover a few of the easiest and least expensive. We are focusing on In-System Programming (ISP) which means that you can program the chip without removing it from the circuit.

DAPA Cable

A Direct AVR Parallel Access, or DAPA cable, is an incredibly simple and cheap programming method. You can build one very quickly for a few bucks worth of parts, but the convenience comes with a few gotchas. The first is that you must have a parallel port on your computer; something that modern laptop and some modern desktops don’t have. But if you’ve got an old PC around that has one this will get you up and programming in no time.

In fact, the first AVR prototyping I did was with one of these cables. That is, until I discovered another gotcha. This will only program low-speed chips. If you try to run the chip’s clock at full speed (by changing fuse settings… more in Part 3) you won’t be able to use a DAPA cable to talk to it any longer. There’s also the possibility of damaging your parallel port or worse if you do something wrong. But if you want to go for it anyway, here’s how I built mine.

It connects to a computer using a DB25 connector. As you can see in the schematic, I’ve used 1 kilo Ohm resistors on the Reset, SCK, MISO, and MOSI pins for current protection. I did not use a resistor on the ground pin. I used a piece of ribbon cable, soldering one end to each of the five signal lines shown in the schematic. On the other end of the ribbon cable I used a connector housing with six slots, filling one of them with a blank so that I could keep track of the signals. This is easy to plug into a pin header or connect to jumper wires as shown above. In retrospect it may have been a better choice to use a 2×3 IDC connector and route the signals using the AVR ISP standard (from AVR: In-System Programming PDF). If you go this route chances are you’ll upgrade before long so don’t agonize of the design details.

Arduino

I would be remiss to skip over using an Arduino as a programmer. They’re ubiquitous with the embedded systems crowd and if you don’t already own one, you can try to find someone to lend you theirs for a little while. All that is required is to write an AVR programmer sketch to the Arduino and make the programming connections. We’ll take a look at this method later in the post.

USBtinyISP

The USBtinyISP is an In-System-Programmer based around an ATtiny2313 that uses a USB connection (see where the name comes from?). It isn’t a bad choice for your first programmer. If you are confident in your skills you can build the circuit circuit yourself and use a DAPA cable to get the programming firmware onto the chip. Or you can just buy it from Adafruit Industries. But if you think you’re going to be serious about AVR development, you should consider shelling out the extra bucks for a professional programmer.

Professional programmers

The Ateml programmers are the gold standard. They offer something that none of the other hardware we’ve covered has, the ability to recover a chip that you’ve messed up. If you want to use the reset pin as I/O, you will need to use High Voltage Parallel Programming to talk to your chip. Even if you don’t decide to do that, at some point you’re going to screw up and you’ll need to recover a process, which helps offset the extra cost of a professional programmer. It is possible to use an Arduino for High Voltage Parallel Programming to recover your AVR, but that’s another hack in itself.

We use an AVR Dragon for pretty much everything. But the STK500 is a very popular board even though you need a serial port to use it. It has chip sockets, buttons, and LEDs for on-board prototyping. The Dragon leaves options open with unpopulated socket footprints, and it uses a USB connection.

If you’re in this for the long haul there’s no substitute for one of these choices.

We should at least mention the MKII, a programmer that offers ISP in the same way that the USBtinyISP does, but also provides JTAG, debug wire, and few others. We have no experience with this unit so you’ll have to do your own research if you’d like to know more. As for the other programmers out there, use Google or check the comments to this post as people usually don’t like to keep their preferred programmer choice a secret.

Bootloader

A bootloader is not really a programmer, but a way to get around using one. A bootloader is a set of code already on your microprocessor. It handles basic input and output neccessary to write your code into the chip’s memory. The bad news is that they do take up programming space, but you won’t have to buy a hardware programmer.

Programming a chip with a bootloader on it is beyond the scope of this tutorial. But it’s not hard to learn to do. In fact, this is how it is possible to program an Arduino without a separate hardware programmer.

Setting up our test circuit

Enough talk, let’s build something! We need four things: A microcontroller, something to power it, some way to program it, and something to show us it’s working.

Hardware:

• Solderless breadboard
• Jumper wires
• ATmega168 microcontroller
• 78L05 voltage regulator
• 100uf electrolytic capacitor
• 10uf electrolytic capacitor
• LED
• 180 Ohm resistor (any resistor between 180 and 330 Ohms will work fine)
• A programmer (we’ll show both a DAPA and an Arduino)

What we’re doing

In a  nutshell, we’re going to blink an LED as our first embedded program.  This takes a few components: a power supply, the microcontroller itself, and the LED and its current limiting resistor.

The power supply consists of a voltage regulator which will take an input voltage above 7v and output a constant voltage of 5V. In order to work correctly, this circuit requires two filtering capacitors. The capacitors act like storage tanks, absorbing small fluctuations on the power rail to provide a steady source of electricity to keep our microcontroller safe and happy.

As an output we are going to use an LED. We must include a resistor to limit the amount of current that will flow when the software lights it up. Without this current limiting resistor, current would flow at levels that are unsafe for the LED, the microcontroller, or both.

The circuit schematic

Above is the circuit we are using as an example. The a simple 5v regulator circuit using an LM7805 linear regulator and two filtering capacitors is on the left, separated from the rest by a dotted box. If you already have some type of regulated 5v supply save yourself some time and use that.

You may also notice that the chip in the schematic is labelled AVR-MEGA8. The ATmega168 that we’re using is pin-compatible with at ATmega8. That means that you can swap one for the other and all 28 pins will be where they’re supposed to be, so this will cause no issue.

It is a good practice to add a few components not seen here. There should be two 0.1 uF capacitors for decoupling; they filter out fluctuations on the power rails called noise. One between VCC and GND, the other between AVCC and AGND (as close as possible to the pins). There should also be a pull-up resistor on the reset pin with lets an incredibly small amount of current trickle into the pin at a 5V level. This the chip from resetting by accident when it’s floating (not connected so there’s no clear 0 or 5V value). I’ve omitted these parts for simplicity and it shouldn’t be an issue with this simple project. But as your projects get more complicated, neglecting these considerations will come back to bite you.

The circuit built on a breadboard

I started building the circuit by adding the voltage regulator to the breadboard. Then connect the ground leg to the ground rail on top of your breadboard, and the output leg to the voltage rail of your breadboard. I have also added two wires that I will eventually connect to the positive and negative terminals of a 9V battery.

It is important to read the datasheet for your voltage regulator (example: LM7805) to figure out which lead is input, ground, and output. Your regulator may look different from mine as they do come in different packages. In the image above, the input lead is on the left, the ground is in the middle, and the output lead is to the right.

Now I’ve completed the power supply by adding the 100 uF capacitor between the input leg and ground leg of the regulator, and the 10 uF capacitor between the output leg and ground leg. Pay careful attention to these capacitors, one lead should be marked as negative (a band with a minus sign) on the case of each capacitor. Before adding the microcontroller it would be a good idea to check the voltage output using a multimeter. Too much juice can destroy your new chip.

After checking to make sure I had a steady 5V source, then disconnecting the battery, I added the ATmega168 microcontroller to the board. Note that the dimple is pointing to the left. This is important, as the standard orientation and lead numbering of a DIP package shows that pin 1 is now on the lower left, letting us easily find the other pins that we need.

Power and ground have been connected to the chip as well. Pin 7 (VCC) and Pin 20 (AVCC) have been connected to 5V. Pin 8 (GND) and Pin 22 (AGND) have both been connected to ground.

The final step is to connect the LED to output 0 on Port D. Our schematic tell us that we want to connect the positive lead of the LED to Pin 2 on the ATmega168, and the negative lead should go to an unoccupied row on the breadboard (make sure you don’t attach it to Pin 1). LEDs usually have a small notch flattened on one side of the plastic case to denote the negative leg of the device. The final piece of the puzzle is to connect the negative side of the LED to ground by using our resistor.

In the image above I’ve hooked up a 9V battery , but nothing happened. That’s because there’s no firmware on the chip to make the LED blink yet. We’ll need to fix that in the next step.

Programming our test circuit

Check all of your connections one more time and let’s get ready to program the microcontroller.

Connecting to a programmer

You only need to make six connections in order to program our chip:

• Voltage
• Ground
• Master In Slave Out (MISO)
• Master Out Slave In (MOSI)
• Reset (RST)
• Slave Clock (SCK)

This is true for any programmer that is using In-System Programming. There’s even a standardized 6-pin header that I design into most of my circuits so that you can easily reconnect your programmer to a circuit board and update the firmware down the line. But for this example we’ll just use some jumper wires to make the connections. One thing to keep in the back of your mind is to only use one voltage source when programming. You should either disconnect the power to your circuit while programming, or do not make a connection to the voltage line on your programmer.

Connecting an Arduino as a programmer

Using your Arduino as a programmer is super easy. The first thing you’ll want to do is open up the Arduino IDE, and then open the example software: ArduinoISP.pde (in the examples/ArduinoISP folder). Flash it to your Arduino in the normal fashion. Now follow the directions for targeting an AVR on a breadboard (bottom of that page). Important: Choose one power source. That is to say, either connect the voltage on the Arduino board to your breadboard, OR connect the battery to the power supply we wired up. Doing both has the potential to damage your hardware.

Here’s how mine looked once I had it hooked up.

Now that everything is ready to go, jump to the next section: Flashing firmware with AVRdude.

Connecting using a DAPA cable

Depending on how you constructed your DAPA cable, it should be pretty easy to make the five connections we need. Notice that the DAPA cable doesn’t have a Voltage connection. The target processor must have its own power source (like the power supply we built on the breadboard) during programming. Here is what my DAPA cable looks like once connected.

If you’re unsure of the connection that need to be made, go back and compare the DAPA cable design to the circuit schematic. Match up our five connections: MISO, MOSI, RST, SCK, and GND.

Flashing firmware with AVRdude

If you did your homework from Part 1 of this series you should already have the cross compiler tools installed. First, download the firmware package and navigate to that directory in a shell, or at the command prompt. The following commands can be used on Linux and OSX systems to program the chip.

Arduino as the programmer:

avrdude -P usb -b 19200 -c avrisp -p m168 -U flash:w:main.hex

DAPA as the programmer:

avrdude -P /dev/parport0 -c dapa -p m168 -U flash:w:main.hex

AVR Dragon as the programmer:

avrdude -P usb -c dragon_isp -p m168 -U flash:w:main.hex

USBtinyISP as the programmer:

avrdude -P usb -c usbtiny -p m168 -U flash:w:main.hex

You can get help from the AVRdude program by running:

avrdude -h

That will print out a list of available commands, or you can read the online documentation. Windows users will need to change the /dev/* portion of the command to match your connection. You should find the Windows page of the online manual particularly helpful for this. Standard Windows port names include com0, com1, etc. for serial ports and lpt0, lpt1, etc. for parallel ports.

As for the other flags used in the programming commands above:

When using the Arduino as an ISP programmer you must specify the speed, using ‘-b’. That value is set in the Arduino sketch and should be 19200 by default.

You will always need to specify what kind of chip is connected to the programmer. Here I’ve used ‘-p m168′ for our ATmega168. Get a list of all compatible microprocessors by typing

avrdude -p ?

The same is true for specifying a programmer. You can change the ‘-p’ to ‘-c’ in the command above to get a list of programmers.

The final option in the commands we used tells the programmer to write (that’s the ‘w’) the file ‘main.hex’ to flash memory. Part of the command is used for many things, including changing the fuse bits on the chip. I’ll talk about this in Part 3 of the series.

Debugging

Your LED should be flashing away quite happily at this point. What’s that? It’s not? Time to start the real learning. Here’s a list to get you started:

• Did you successfully program the chip? You should get the message: “258 bytes of flash verified” and “avrdude done. Thank you.”
• If you had an error during programming, check first to make sure there is power going to your chip.
• Try the programming command again using ‘-v’ in place of ‘flash:w:main.hex’. This will just attempt to talk to the chip instead of writing to it, and is very handy when working out programming bugs
• Recheck your programming connections to ensure you’ve got the correct signals connected to the right pins
• Make sure you have the correct port on the computer and that you have permission to use that port. Linux users may try talking to the chip with the -v flag as ROOT to discover if there is a permission problem. If this works you need to add your user to the group that has permission to access the port the programmer is connected to
• If you did successfully program the chip you should recheck your hardware. Is the LED installed backwards, preventing it from lighting up?
• Take a trip to Google and start searching… this usually plays a roll in the development process so don’t feel bad. A lot of folks have already experienced the trouble you’re having and they made it through okay in the end.

Conclusion

You’ve done it, your first embedded circuit is alive! For now it will just flash to let you know everything is working. But next time we’ll talk about how this was accomplished, what we can do to make it behave differently, and how to use the compiler to translate our code changes into a file that the microcontroller can run. Thanks for reading and we’ll see you back here for the next installment.

Follow Me

@szczys

Resources

Firmware package: Package download or Github page

Atmel AVR ATmega168 Datasheet (PDF)

AVR dude online documentation

AVR In-System Programming Application Note (PDF)

AVR ISP Programming Header:

We love looking at hardcore electronics projects with a beefy microcontroller and hundreds, if not thousands, of lines of code at its center. But everyone needs to get there somehow.

This tutorial series aims to make you comfortable programming the Atmel AVR line of microcontrollers. Whether you’ve never touched a microcontroller before, or you’ve cut your teeth with dozens of Arduino projects, this will help you get right down to the hardware and give you the confidence to build anything.

Series roadmap:

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

Prerequisite knowledge

Here’s the good news: I’ve set the bar quite low. You need basic knowledge of installing programs on your computer and using them. You should have some idea of how a solderless breadboard works and it is advisable that you have a multimeter and know how to measure voltage with it. And you shouldn’t be afraid of using Google to research questions that aren’t explicitly answered here.

What does a microcontroller actually do?

This is a loaded question. For the sake of understanding I’ll take this down to the most simple explanation:

1. A microcontroller takes some type of input
2. It makes a decision based on the software you have written
3. The outputs are changed based on the decision in step 2.

A microcontroller does what you program it to do. It does so quickly, and reliably.

How does it work?

For this tutorial series I will be discussing digital logic. That is to say that all input and output pins will be judged based on a voltage of zero, or 5V. This produces our digital 1′s and 0′s, with 5 volts as a one, and zero volts as a zero.

So if you want to light up an LED just wire up the circuit to a pin, make that pin an output, and set it to a logic high (5 volts). If you want to add a button, connect it to a pin that is set as an input and program the chip to measure the voltage level of that pin. It really is that easy, once you learn how to write the correct commands so that the chip understands your wishes.

A look at he chip itself

I’ve decided to use an ATmega168 microcontroller. It’s a powerful chip but it’s no harder to start using than its younger brethren. It will leave plenty of room for you to grow into your projects, while remaining affordable (less than $4.50). Here’s a diagram of it:

This is often called the pinout as it shows what each of the 28 pins on the chip actually does. All of these pins have multiple functions and that’s why there’s long lines of text next to each, except for five which only have one name. These are the pins having do with voltage and ground (VCC, GND, AVCC, AREF, AGND), an important issue with microcontrollers.

Integrated circuits need a steady voltage source. This means as part of our project we’ll need to build a voltage regulator. This is an easy thing to do on a breadboard, and you should be able to get your hands on the parts locally. It is also worth noting that there is a semi-circular dimple on the top of the chip. This is something you’ll find in the plastic case of these dual-inline-package chips an it’s used to make sure you don’t plug it in backwards.

Take a look at the pinout once again and look for the pins whose names start with PD. You should see eight of them total, labeled PD0 through PD 7. This is a fantastic example of the 8-bit nature of these chips. PD stands for Port D, one of the input and output register. Everything in these chips centers around 8-bits. That’s a sequence of eight 1′s or zeros in different combination. If you want to turn on or off specific features, you change one or more bits in a 8-bit register. Every time you want to change one pin you must address all eight in the register. We’ll learn much more about this but not until the third part of the series.

Programming

The ATmega168 is a programmable microcontroller. But better yet, it’s reprogrammable. In fact, when you’re working on a project you’ll most likely reprogram it several times an hour.

This chip has a size limit of 16 kilobytes of programming space. In these modern times of 64 gigabyte iPods 16 kilobytes might sound minuscule. But in reality that’s 16 kilobytes of machine code. You can do a lot with that… trust me.

You do need some type of hardware to get the code onto these chips. Usually this comes in the form of an AVR programmer. In the second part of this tutorial we’ll look at several different programming options, then build and program a test circuit.

Do Your Homework

To get ready for the rest of this tutorial series I need you to gather some tools. You must have some type of computer, be it a Linux box, Mac, or Windows PC. This will run software that takes our code, compiles it into something the microcontroller can use, and then tells a programmer how to write it to our chip.

The compiler

We’re eventually going to be writing our own code for the AVR, which uses the RISC architecture. But we’re doing this on a computer with x86 architecture. The tool necessary to accomplish this is called a cross-compiler. This is quite possibly the best reason to choose AVR for development, there’s an excellent tool chain available that can easily be installed on multiple platforms.

• Mac users: Install CrossPack
• Windows users: Install WinAVR
• Linux users: Debian and Ubuntu users should install the GCC-AVR package which includes the entire toolchain. Others may want to look at the AVR-libc toolchain page for help compiling the packages.

This is not the only option. Many Windows users swear by Atmel’s free AVR Studio software. This is the only time I’ll reference it as I don’t have a Windows machine and have never tried that package.

Programming software

Our software-of-choice to run the hardware programmer is called AVRdude. If you installed one of the toolchains above you should already have this program. Go to a terminal window or the command prompt and type the following to make sure:

avrdude -h

This will show the help screen. If you get an error, you should check to make sure you properly installed the toolchain in the previous step, or go download AVRdude yourself.

What the future holds

That wraps up the introductory installment of this series.

Part 2: In the next installment of this series we’ll take a look at several pieces of hardware that you can use to program an AVR microcontroller. I’ve written a hello world program and will walk you through building the circuit on a breadboard, connecting the chip to a programmer, and using AVRdude to write this simple firmware to the device. I don’t want to get you too excited, but this does involve a flashing LED.

Part 3: A pre-compiled HEX file was used to program the AVR microcontroller in Part 2 of the series. In this portion we’ll look at the C language source code that made up that firmware. I’ll also talk in-depth about the peripherals available on the chip and detail how to use them. We’ll finish up by adding functionality to the original program, recompile it, and reprogram the chip with the upgraded version.

Part 4: Now that you’ve acquired AVR programming skills I’ll show you how to start building cool stuff with them.

Follow me:

@szczys

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!

Have you heard the latest track by gzip? Maybe it’ll end up on a “Greatest Hits” album alongside Philip Glass.

Visualization techniques such as animated algorithms can help programmers better grasp the abstract theories that make software work. Could auralization, the sound equivalent of visualization, provide similar insights? Postgrad student (and J. S. Bach fan) [Cessu] developed a program to do just that. By carefully mapping registers to notes, and slowing the tempo to a human timescale, the result is a cacophonous machine that offers a glimpse into the operation of various programs. You might find the resulting minimalist “music” insightful, entertaining…or maybe just incredibly grating.

[thanks Shadikka]