Neil gives a lecture which I'm pretty sure is 80% acronyms, a mere 20% of which I recognize
So I decide - I'm going to make something amazing! I want to make a Magic 8 ball that uses an accelerometer and outputs randomly selected 'fortunes' on an LCD screen. I even find a guy online who did a similar project so I have something to work from.
I think "this is a great approach" because I can make tweaks to a pretty high level script! With help from a labmate with microcontroller experience, I start making new Eagle schematics and order some components I'll need.
I'm having trouble understanding the C code so I go to Matt's office hours. He asks "do you have experience programming in C?"
So he says "this project might be too ambitious for you".
Spoiler Alert: he was right
I think "I can do anything!!" (but I do change from accelerometer to a button input...) I start the Lynda C tutorials (highly recommend!) so I can understand what the code is doing, so I know how to tweak it.
But slowly I begin to wonder (while my components are in the mail)... what if I write something amazing but can't get it onto the board? That would be pretty bad...
I try to get my development environment working on my PC (Windows 7 64 bit). I install arduino with this tutorial and need some new drivers for my FabISP to get the bootloader working. But judging by my frustrations and the flurry of emails about getting the development environment set up, I think "this seems like a terrible endless rabbit hole".
So I decide to use a lab computer, and follow this tutorial. IT TOTALLY WORKS THE FIRST TIME!
But I want to practice writing my own code. I decide I want to learn how to use the button input, and make the RGB LED switch between its colors. I successfully change the blink program for my own board. Then Nadya shows me Neil's scripts for the input and output device weeks.
I combined two programs (one for an RGB LED and one for a button) so that when the button is not pressed, the LED blends between colors, and pressing the button makes the colors switch (but not blend). I also made a new board, since I broke my first one plugging in the FTDI cable.
Hooray!
How to program your ATTiny44
Step One: Use an Ubuntu computer. You're worth it.
Step Two: Make a program in C. Don't know how to program in C? Try learning from Lynda (MIT Certificates required). I recommend starting with something already made. I took pieces from...
Step Three: Make the makefile! For the most part, the makefiles look the same. Just change it depending on the clock you're using, and the IC. And, of course, the file name for your c file
Step Four: Now run your commands!
make -f [makefile name]
This command says, with the make program, run your make file. This compiles your c file (which is referenced in your makefile) for the device that you specify in your make file. It'll give you all kinds of fun errors when you do things wrong.
sudo make -f [makefile name] program-usbtiny-fuses
This says "run the program-usbtiny-fuses line in the make file" which physically makes the fuses for running the internal clock. This line needs to be run only once for your board. There isn't harm done if you run it again, it just isn't necessary. But once you run this on a board, you can't change out the timer or the board won't work.
sudo make -f [makefile name] program-usbtiny
This line puts your code (which has been compiled) onto the board (which has its fuses made). After you run this, your board should have its new behavior.
Step Five: GIF PARTY!
Lindy, what did you learn?
Well, kids, lower your standards to raise your satisfaction with your work. Haha, just kidding (sort of).
Lesson One: Hardware and Software are entangled I like to think this is not true, but a lot of my coding would have been easier if I'd had the datasheet next to me when making my circuit. Namely, I would have had all input devices on one port, and output devices on the other. Now that I've finished this, I need to redo my magic 8 ball (the dream is still alive, I'll do it another week) diagram so that all my buttons (or accelerometers) are on one port while the many leads going to an LCD are on another. This will make my coding much simpler.
Lesson Two: Have you thought of something? Someone else has probably already done it I don't mean to make you feel bad, but you should take advantage of someone else's learning. I have found programs where people use while loops, where they use interrupts. Pins are usually declared the same way, but some people define them as they go, and others define everything in the beginning. As long are you are producing new work, it's not bad to see how other people have solve the same/similar problem.
I'm looking forward to making more things using embedded programming, and I do eventually want to set up a development toolchain on my PC for my own work. But it's hard to justify when Linux machines are so readily available.