What to do if you are stranded on a deserted island with a pile of Attinys and your laptopÉ
This weeks assignment was to memorize this document (http://academy.cba.mit.edu/classes/embedded_programming/doc8183.pdf), and program the board I made two weeks ago (http://fab.cba.mit.edu/classes/4.140/section.Harvard/people/Vizner/Week4/ElectronicDesign.htm) to do something.
When I finished the design Rob told me the microphone would not work because it was not biasedÉ I thought to use this opportunity to start exploring serial communication because I may want to use it to implement my SOT-KIBO project.
Setting up toolchains, programmer, serial communication, and other things you need to program the chips.
In order to program the Attiny you first need to write a program. I used C because it is most similar to C++ which I have experience using, and the examples are in C. I used the QT environment to work on my code, because I had it. I was not using it to its fullest potential. (https://www.qt.io/)
Compiler & Toolchain
I think this is the AVRDude. This is a piece of software that allows you to write to the different memory registers of the Attiny. It uses the gcc compiler already in the OS to compile the C code into a hex file then allows you to push it on to the programmer which in turn sends a bunch of tiny pulses to the new chip you are trying to program in order to set its registries
The commands for compiling code and pushing them to the chip are as follows (assuming you are using the usbtiny):
make -f [Program Name].make
make -f [Program Name].make program-usbtiny
Make file (referenced above)
This is a file that has instructions for the compiler about chip type, speed, which programmer to use and other important info. (example bellow)
I used the usbtiny programmer that I made a few weeks ago. (http://fab.cba.mit.edu/classes/4.140/section.Harvard/people/Vizner/Week2/Programmer.htm) This takes the hex file made by the compiler and pulses the target chip to set the memory.
) to be able to communicate between my computer and the chip in real (in this case 115200 pulses per second) time. This required the following drivers (http://www.ftdichip.com/Drivers/VCP.htm). It also requires a serial communication terminal on the computer I used CoolTerm (http://freeware.the-meiers.org/) at RobŐs recommendation.
Physically connecting all the pieces
The target chip needs power to be programmed which it can get from FTDI, after it is programmed it will use this to communicate with the computer. The ISP headers of programmer and target board are connected with ribbon cable (make sure orientation is correct). Programmer is connected to computer.
Loading first program and using Oscilloscope
I started by loading NeilŐs hello world example. It worked (and even thanked me)!
The program sends a character out to the chip and then the chip sends it back to the computer.
Here I am talking to myselfÉ
Rob showed me how I could use the oscilloscope to visualize the serial communication and check the timing on the bits.
Here you can see an 8 bit message (some character) from the serial communication. We checked both serial coming out of the computer and coming out of the chip.
Here we use the measurement tool (the two vertical bars) to measure the time of one bit. 9.04 μs
My Program (Bricolage)
I wanted to use the serial communication aspect of the hello world example to control the LED on my board.
I opened NeilŐs RGB LED example from the outputs week as a place to start looking for how to control LEDs. In his program he references PORTB. I went back and checked the schematics from my board and found that I put my LED on A7. Then I looked at the hello world example more closely and found that PORTA was set to serial_port. For a moment I thought I was screwed because I thought that meant the entire A bank was set for serialÉ
ThatŐs when I went to talk to Joe.
He explained how DDR, PORT, and PIN registers work (I still have questions but I am closer to a full understanding.
DDRX: is a register that sets the direction of communication
PORTX: is a register that lets you set the pins to high or low
PINX: is a register that will tell you the status of the pins.
PX#: lets you set a particular pin.
In this program serial_port is actually a variable representing PORTA. Which is cleared and set by the get and put char commands for the echo function. PA7 is not used in this program so it is still free for me to control my LED.
The first goal was to get the light to turn on. This took some finagaling with the code.
I defined these two variables.
#define LED_pin_on (1 << PA7)
#define LED_pin_off (0 << PA7)
But it wouldnŐt work.
Joe realized we also needed to set the DDR for pin 7 so changed the initialization to
It worked but now wouldnŐt turn off.
Changed set(serial_port, LED_pin_off); To clear(serial_port, LED_pin_on); and it worked!
The blink would only happen when get_char was satisfied, which means it would blink once each time I pressed a character. I wanted to add a bit more logic so I looked up how to do a char compare, easy, use ==.
I made it so that it would only blink if I pressed the ÔaŐ button.
ThatŐs when Joe jokingly said you should make it do Morse code. 30 minutes later and a visit here (https://en.wikipedia.org/wiki/Morse_code) The attiny Morse code generator was complete!
It can only handle one character at a time, and there are two obligatory pre-programmed messages. 1: ŇSOSÓ, 2: ŇHi MomÓ
I was also curious how much of the memory this many functions and characters would take.
The answer is:
Program: 1822 bytes (44.5% Full)
(.text + .data + .bootloader)
Data: 17 bytes (6.6% Full)
(.data + .bss + .noinit)
Not to much, but also not an insignificant amount.
Video of SOS:
Video of Hi Mom:
Video of char @ a time: