Ana Cabral

Week 8

Embedded Programming

back to main page

The assignment

This week’s assignment was to read the microcontroller data sheet, in this case the ATtiny44A and program our board from week 6, to do something, with as many different programming languages and programming environments as possible.



Reading the microcontroller data sheet

I started by having a look at the index and underdstang what I could expect to find in this datasheet.

I took a closer look at Input/Output ports, since it was what we will make most use this week. That enabled me to start understand a little bit more the code from other students.



Bits & bytes, binary, decimal and hexadecimal systems

Look here.



Programming the board

I decided to start by programming my board using C. It was hard to find “spot-on” tutorials… They were either paid (some had a 10 days free trial, but you’d still need to enter your credit card details) or too long (like 7 hours intro…). So, after all, I decided to look into previous FabAcademy students documentation. I studied Linda's, Charlie's and Marco's solutions. They all had different programming styles and they all wanted to do something more complicated with their board than making 1 LED blink when a button was pushed.

So, I compared their codes and followed the one that was more appealing to me, Linda’s. Linda had a board with 3 LEDs. The middle one would be on when the board was powered. The other two would alternate, one would blink when the button was pressed.

Based on Linda’s code, I tried to write a simple version, where when the button was pressed, the one and only LED I had on the board would blink.

I ran the makefile, by typing “$make -f hello.ftdi.44.echo.led.c.make” just to check if there was any problems with the c file. This is what took me most time… troubleshooting…! All the syntax, and how carefully/precise one needs to write. It helped doing it in Brackets, where it shows how parenthesis are connected.

Before running the makefile in Terminal, you need to make a new makefile (if you have a new c file), where on the first line, you insert the new c file name, and it helps to save with a correspondent name. So, f.x., for hello.ftdi.44.echo.c you have hello.ftdi.44.echo.c.make and for hello.ftdi.44.echo.led.c you have hello.ftdi.44.echo.led.c.make.

When, after a couple of iterations a makefile ran without problems, I connected the programmer (usbtiny) and the board to the computer and typed “sudo $make -f hello.ftdi.44.echo.led.c.make program-usbtiny”, to write the program on the microcontroller.

I experienced a problem here, my computer could not find the usbtiny. I had it connected to the computer through a usb 2.0 extension. My instructor (Bas) suggested to use a usb hub to connect the usbtiny to the computer - apparently, it has happen before, some conflicts when connecting usbtiny to Macs… usb hubs have proved to be a good way around it. And indeed, by having the usbtiny connected through a usb hub, the problem was solved.

So, I loaded the program in the microcontroller, disconnected the micro controller from the programmer but kept the board powered by the computer. Tested by pressing the button but nothing happened. Based on Charlie’s webpage, I thought that maybe my LED was not soldered in the correct direction, so Bas showed me how to use the multimeter to verify that. With the multimeter, I checked that there was voltage (5V) going across the button and across the LED while the LED was off. So it was soldered in the wrong direction. I re-soldered the LED, in the right direction. Still, it didn’t work.

I looked into my code, and identified another possible problem… on line 53 pin_test I had written pin-direction and pin-value (DDRA, (1>>PA7)). Since this is an input (and all ports in a microcontroller will be read as an input unless told otherwise), it makes more sense to specify pin-port and pin-value (PINA, (1>>PA7)).

I corrected the C file, saved, loaded it in the microcontroller, and YES!!! IT WORKED!! Or something worked. So, I thought I had programmed the board to turn on the LED when the button was pushed. Instead, the LED was on as long as the board was powered and the button was NOT pushed.



Main learnings from this week

I feel I’m building up important foundations for the next weeks in programming. It has been really interesting to look into bits & bytes, binary, decimal and hexadecimal systems and understand a bunch of things that surrounds us everyday but we don’t question… Like our internet speed, what does it exactly mean, or an IP address or the size of an usb. It takes some time for all the information to sink, but documenting makes me synthesise the learnings of the week.

I would like to get back to this board and use it to practise the foundations of programming in C. The next iterations would be to make the LED blink when the button is pressed, add a delay to the blinking and add readability to the code.



Files

All files can be found here. To download the files, right click with the mouse and chose “save link as”.

LED_C_1, LED_MAKEFILE_1