How to Make [almost] Anything

Nathan Melenbrink

Input Devices

The assignment for this week was to "add a sensor to a microcontroller board that you've designed and read it". I came to the realization that I had a lot of sensors and switches to program in preparation for my final project. I expected I would need an accelerometer to determine verticality, a camera to send images back to a host computer, and stepper motors with limit switches, also (hopefully wirelessly) transmitting data back to the host computer. I feel like my work is cut out for me for the next few weeks, but for a number of reasons, I was most eager to get the stepper motors driven via Arduino, and made this a priority. Additionally, I tried to design and program a Fabduino with an accelerometer attached.

  • Tools: Roland Modelo mill, surface mount soldering tools
  • Materials: Electronics components
  • Software: Eagle
  • Year: 2014

Project 01b
I picked up where I had left off two weeks ago, by trying to find a suitable toolchain for using the Arduino IDE. I had previously successfully programmed the LED blink.c with the make file provided. I just wanted to also set up Arduino IDE as an option, just to have a more comfortable programming environment to more quickly try things out. I'd followed David Mellis' tutorial , but I kept getting errors in the verification phase along the lines of:

avrdude: verification error, first mismatch at byte 0x0040
0x01 != 0x02
avrdude: verification error; content mismatch
The error varies (in terms of byte location) when I edit the boards.txt file. The ATtiny44 segment looks something like:

attiny44-20.upload.tool=arduino:arduinoisp (external 20 MHz clock)

I found in the data sheet that the Stack Pointer Register should be set to 0x3E (0x5E), though I'm not quite sure what the parentheses mean. In the .make file with which the board was originally programmed (Neil's file) the low fuses were set to 0X5E, though I seem to recall there was some discussion about this in class. In the boards.txt file, if I change 0xfe to either 0x5e or 0x3e, I get content mismatch errors at different bytes. But I don't understand why the bootloader is still of any consequence, as my understanding was that it was used to set the fuses once and that was it. As far as I can tell, everything agrees at 20 MHz. I never exactly figured this out. I had problems burning the bootloader (couldn't find .tool files), and after wiping and re-following David's tutorial again with the same issues, I realized the only difference was that he's using the 1.0.4 IDE and I was using the most recent release. So I wiped that and installed 1.0.4, and then everything seemed to work (bootloading as well). Seems silly to have to downgrade...I assume the discrepancy has something to do with the directory structure in the 1.5 IDE installing to the Program Files directory, while 1.0 doesn't...? Anyway, I'm more than happy using 1.0.4 for now just to be able to get some results this week.
Project 01b
After getting things to work by downgrading Arduino IDE, next on my to-do list was to establish serial communictions with my host computer. I went back and forth between a few sample codes trying to understand why my chip was having issues with the "Serial" command. This is because the ATtiny44 microprocessor is not formatting for serial communication the way that Arduino IDE is expecting it to be. I therefore need to add these lines of code, which specifices the SofwareSerial.h file and tells the IDE which pins should be used for receiving and transmitting (in the case of ATtiny44, pins 0 and 1 respectively):

#include SoftwareSerial.h
const int rx = 0;
const int tx = 1;
SoftwareSerial mySerial(rx,tx);
And then afterwards call any Serial commands using the variable definition "mySerial" instead of just "Serial". For example, Serial.Begin(9600) becomes mySerial.Begin(9600).
Project 01b
On to the part where we're supposed to design and mill a board with a sensor. I had an hunch that I would need an accelerometer for my final project, and later would need some kind of camera. However, it seems that working with cameras can be quite complex (spanning between various data protocols), and I didn't find many helpful references. So I decided to modify a Fabduino design to include an embedded accelerometer. I figured it would allow me to complete this week's assignment while leaving me enough pins free to add a camera later. I started with Anna's Fabduino Design which pulls out all of the pins for the ATmega328p and added an accelerometer component taken from the in-class example.
Project 01b
Milled and stuffed board, including the accelerometer in the top right.
Project 01b
The next step was plugging it into the serial port and programming through the FabISP. Unfortunately, as soon as I plugged it in, it started overheating, which suggested there was a short between GND and VCC somewhere.
Project 01b
Furthermore, the COM port failed to recognize the device. I made sure I had the correct FTDI drivers and tried to think of anything else that might have gone wrong. I finally decided it was due to the botched solder job on the ATmega328p. Probably a lost cause...I'll need to do it all again, this time more carefully...
Project 01b
This week I also tried to get ahead and start with output devices, specifically stepper motors. This will be the critical output device for me final project and something I felt I needed to get working as soon as possible. I milled and stuffed the bipolar hello stepper motor driver from the course site. That was pretty straightforward, except for the H-bridge components which I had to research a bit to understand. I needed a power source, so I hacked a 9V wall plug to a 2x2 header (probably not the ideal method, but I didn't know what else to do). After setting the fuses and programming the board with the hello stepper .c file (it took a few tries), it finally seemed everything was communicating. However, when everything was powered the motor wouldn't rotate (as it was instructed to in the .c code) but it did firmly hold its position and could not be rotated by hand (it's easily rotated when it's not powered). I had paired black and green wires and red and blue wires, so I figuerd switching the order from Green-Black-Blue-Red to Black-Green-Blue-Red might give me the proper polarities. However, the same problem persisted. I then started thinking maybe I was mistaken, and it was actually a uniploar motor...we'll see in class.