This week was a whirlwind tour back into the world of embedded programming. At one point I did this for a living, but it's been more than 5 years since I've had to touch a complier so things are a little hazy for me.

I had already set up the AVR toolchain on my laptop in the week we built the FabISPs. I also went ahead and bought my own FTDI cable so that I could do the programming and communication at home.

I figured I would start with my board with one button. Here you can see the light flashing every time it detects either the button being pushed or released.

I started with the base code located in the hello.ftdi.44.echo.c example.

There are a few important concepts for this week. Each individual pin on the microcontroller is associated with a port which also has an associated data direction register. We need to set the direction of an individual pin, and then we can either read values in or output values. As an example to configure my LED on PA7 to be an output and initially off:

If I want to set an pin as input, I need to follow a similar process. The following is for a switch on PB2 that requires a pull up resistor. To turn on the pull-up resistor you simply have to write a logical 1 to the button_pin on button_port.

Once a button is set as an input you can test the the proper pins register (PINB) variable for the current status of the pin of interest.

I wanted to refresh myself on the use of interrupts incase I had any time sensitive code I needed to run. Again there is the hello.ftdi.44.echo.interrupt.c code to start with.

There are some important flags that establish your interrupt environment. Each pin is associated with one of two interrupt vectors. PA0 to PA7 correspond to PCINT0 to PCINT7 that are handled by the PCINT0_vect ISR. PB0 to PB3 correspond to PCINT8 to PCINT10 and are handled by the PCINT_vect. PCMSK0 and PCMSK1 contain the enable flags for the previously mentioned interupts, and both a specific pin and it's corresponding PCIE0 or PCIE1 bit in the GIMSK register must be enabled for an interrupt to be able to be triggered. As an example, if I wanted to trigger an interrupt on a button chaning state:

At this point it is important to note that the demo interrupt code has an undocumented feature that preventus you from extending the code until you make a slight edit.

In short:

When the serial input pin changes state, a flag is set that tells the processor to run the Interrupt Service Routine (ISR) at the next available opportunity. The ISR as written will then read in a character, and echo it back to you.

While an ISR can't be interrupted by another ISR, that flag can be set while an interrupt is running. In this case the action of receiving a character on the serial input pin will set the flag again (as the state is changing while the character is being received), and the processor will immediately launch into the ISR again after it finishes. Unfortunately this second time there is no character to receive, so the program will hang in the ISR waiting for another character to be transmitted, and this process will repeat itself so nothing will execute but that interrupt after the first time it is called.

To fix it add:

at the end of the ISR. It clears the flag associated with that interrupt so it will behave as expected in this case and you will not return to the ISR until the next time you are receiving a character.

This is not the appropriate fix in all cases, especially if you have other interrupts that you are trying to capture on PA0-PA7, but is a good place to start.

As interrupts are a poor design choice for testing buttons I went back to a main loop implementation (still running an interrupt for the serial communication) to handle the buttons on my two button board from the circuit design assignment.

hello.ftdi.44.twobutton.interrupt.c
hello.ftdi.44.twobutton.interrupt.c.make

To give bus networking a try I built the hello.bus.45 bridge and two nodes.

Here you can see me telling node 0, node 1, and node 2 to do the thing where they flash twice. If the boards were behaving better I might have considered having them do something cool, but it was a good proof of concept to have under my belt.

To figure out what the heck an arduino was and why people have been so excited about them I decided to give the hello.arduino.328p board located on the embedded programing lecture page a try. This board is nice as it uses a slightly more poweful atmega328 chip with more ram and more pins.

After making and programming the board successfully with the example code on the website I spent way to much time figuring out how to run an arduino at 20 MHz. The easy way to use this board is to simply use the internal 8MHz clock when playing with the arduino programming environment and be happy with that. For some historical reasons the arduino bootloader is only designed to run at 16MHz. If you run at 20MHz nothing particularly breaks but some of timing functions will have a little error. It is possible to manually edit the code to fix some of the error, and some of them may now be fixed in the source.

I had a further issue, in that the arduino is built to run on the atmega328p processor, and it seems that the arch shop only has the atmega328. This would make for some fun trickery down the line.

This is a bad idea. Just get a 16MHz resonator and a atmega328p.

Really

Ok... fine... I'll tell you

First you need to download the latest version of the arduino software. After doing that download the latest build of the optiboot bootloader (a snazzy bootloader that replaces the default) and replace the version of optiboot that came with the arduino software.

You can use optiboot to compile new bootloaders for the arduino. The following can be added to the optiboot makefile to add a profile for a 20MHz atmega328 device.

Unfortuniately optiboot is only written to work with a select family of microcontrolers. The atmega328 is not one of them. Fortuniately the 328 is the same at the 328p except for the pico-power addons (for the most part) so you can modify the source of optiboot to work with atmega328's. Open the pin_defs.h file and any time you find a line like:

add the 328

Then from a terminal (assuming you have the avr toolpath installed already) you can build the new bootloader with:

You should now have a optiboot_fabduino_atmega328.hex file in your optiboot folder. Now that we have the bootloader that we want to use, we have to tell the arduino software how to use it. Figure out where the boards.txt file is on your OS and add a board profile for the 20MHz board on a 328 (the format has changed slightly since the file that is on the MAS.816 website)

and while you're at it add a profile for the 20MHz board on a 328p

The reason for the two profiles is because for some as of yet unexplaied reason, while buring the bootloader the chip is properly detected as a atmega328, but when trying to use the arduino software to upload a sketch over ftdi the device signature is that of a atmega328p. I suspect that this has to do with the internals of optiboot. To install the sketch ensure the fabduino20 board is selected and the proper ISP, and select tools -> burn bootloader. After buring the bootloader change to the fabduino20p board profile and you can upload sketches as normal. As I mentioned - the timing functions will be ever so slightly off, so this is not an ideal setup for time sensitive operations.

While we are at it we might as well make a profile for a 8MHz atmega328 device (using the internal oscillator). This will have proper timing. The addition tot he makefile for optiboot:

Then from a terminal (assuming you have the avr toolpath installed already) you can build the new bootloader with:

You should now have a optiboot_fabduino8_atmega328.hex file in your optiboot folder. Now that we have the bootloader that we want to use, we have to tell the arduino software how to use it. Figure out where the boards.txt file is on your OS and add a board profile for the 8MHz board on a 328.

The same strangeness with the bootloader exists, while buring the bootloader the chip is properly detected as a atmega328, but when trying to use the arduino software to upload a sketch over ftdi the device signature is that of a atmega328p. Install and burn the boards the same ways.

For the lazy: