Week 6: Electronics Design
Download this week's code
Little things
I switched to Brackets for HTML editing. It auto-completes tags, auto-closes tags, and auto-completes linked files for you. Very nice.
Designing the board in Eagle
I have used Fritzing, I have always hated Eagle's interface. But, I am determined to learn how to use Eagle because it appears to be a standard tool, and it's integrated with Fusion 360, which is now my standard CAD tool.
Neil provided several images for the hello echo board. I used this image to create the schematic, because it provides the components, their connection names, and the connections for the schematic. I was able to add the components in Eagle's schematic designer, and connect them using nets. The components I added were a phototransistor connected to PA2 with a 10K resistor connected to ground to create a voltage divider, a tact switch connected to PA3 with a 10K pullup resistor, and an LED connected to PA7 with a current-limiting resistor.
I did: added components in Eagle using the Add tool. Moved them around to where I thought I was going to connect them with the Move tool, because Eagöe needs a separate tool for every possible function. Here you can see a screenshot of the schematic beginning to come together, and the final schematic.
The label tool allows you to create nice graphical labels to make routing less visually messy. Why don't the labels stay connected to the traces when I drag them around? I learned that I should move the traces and not the labels. Because, that makes a lot of sense.
Emma insisted that I check the proper value for the current-limiting resistor for the LED. The LED part number is 160-1167-1-ND. I found its datasheet in Octopart. I had some trouble differentiating between maximum and nominal conditions, but the LED had the "standard" red characteristics of Forward current 20mA and forward voltage 1.8V. I used the internet's most popular current-limiting-resistor calculator and got the value 180Ohms for a 5V source voltage. The closest resistor value we had was 499Ohm.
I placed the components in the PCB view. The Jeremy Blum tutorial said that he preferred to route everything manually. I thought that I should do that instead of using the autorouter, just to learn how to route traces in the Layout view.
I changed the 6-pin programming pin to a part from the FAB library so the pins were named properly. As a result, I had to redo some of the PCB stuff, and I could not just delete the old traces, I had to use the Ripup tool.
I had trouble ingetrating the phototransistor. How do I make it work? Yay! I routed something under the resistor. This is like solving a puzzle. You can see it here under R4.
Design Rules
I used DRC to check design requirements. I set .4mm clearance for everything. I ran the DRC, moved things to fixed clearance, ran it again. I did the repeatedly until Eagle told me No Errors.
Exporting and etching
I followed this document for PNG export from Eagle. Select layer 1, export as image. Set it 500 DPI and MONOCHROME. Then add 20 pixels horizontally and vertically in a programme like Gimp. This becomes the edge of the board. Fill in the traces and invert to create the outline file.
Emma checked my images and found that the cutting file should have been inverted. In Gimp, the INVERT command was greyed out. What to do? I instead filled the whole image as white, and when I selected IMAGE - FLATTEN it created a black border. Ta da.
There were also weird letters in the image. From the photoresistor, EMITTER and COLLECTOR were in the image, even though they are not part of the layers that I had selected. I simply filled them in in Gimp. But checking in mods showed the mods would have milled around these letters, ruining the traces.
After etching the board, some of the traces were coming off the board. Too thin. Emma suggested that they should be .4mm, so I found some advice here about a script that will change the thickness of all the traces. Eagle has a scripting language called User Language Programs (ULP), and there is a standard script called cmd-change-brd-width.ulp to change wire widths. You access the ULP by typing, surprise, ULP in the Eagle console.
Etching again
Emma thinks that .3mm traces are probably fine, but maybe don't hold up to re-milling if there's a problem. She also suggested (hi, Emma!) to do the z-calibration from the middle of the milling area. She also thinks that the sacrificial layer needs to be replaced and that might be affecting the depth. She encouraged me to remill using the default settings and see what happens.
It wouldn't cut the outline. Emma suggested that I did the Z calibration with the tool too low so the machine couldn't cut through. Redid the calibration. Recut the outline. That fixed the problem. Yay!
I cleaned up the traces with a knife. There were a few hair-thin pieces of coppes that could has caused a problem.
Soldering
Looked at the datasheet of the phototransistor in octopart to determine orientation. The package has a notch in one of the corners. Emma found someone else's project, and found that the notch does not go to ground.
The IC pins were very hard to solder! I used a continuity check with the multimeter to ensure that the legs had connections to all the traces. I also checked for continuity between VCC and GND. The button's housing was also touching the VCC line, but it didn't seem to touch any other parts of the circuit, so I think everything's fine.
Programming and Testing
Testing using this documentation from Neil. The board was connected to the programmer with a 6-pin ribbon cable, with the programmer plugged into the USB port of a computer (Emma says it's OK!), like this:
All the commands took longer than I expected to compile.
egon:helloSource david$ make -f hello.ftdi.44.echo.c.make
avr-gcc -mmcu=attiny44 -Wall -Os -DF_CPU=20000000 -I./ -o hello.ftdi.44.echo.out hello.ftdi.44.echo.c
avr-objcopy -O ihex hello.ftdi.44.echo.out hello.ftdi.44.echo.c.hex;\
avr-size --mcu=attiny44 --format=avr hello.ftdi.44.echo.out
AVR Memory Usage
----------------
Device: attiny44
Program: 758 bytes (18.5% Full)
(.text + .data + .bootloader)
Data: 64 bytes (25.0% Full)
(.data + .bss + .noinit)
Then I get an error!
egon:helloSource david$ sudo make -f hello.ftdi.44.echo.c.make program-usbtiny-fuses
Password:
avr-objcopy -O ihex hello.ftdi.44.echo.out hello.ftdi.44.echo.c.hex;\
avr-size --mcu=attiny44 --format=avr hello.ftdi.44.echo.out
AVR Memory Usage
----------------
Device: attiny44
Program: 758 bytes (18.5% Full)
(.text + .data + .bootloader)
Data: 64 bytes (25.0% Full)
(.data + .bss + .noinit)
avrdude -p t44 -P usb -c usbtiny -U lfuse:w:0x5E:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e930c (probably t84)
avrdude: Expected signature for ATtiny44 is 1E 92 07
Double check chip, or use -F to override this check.
avrdude done. Thank you.
make: *** [program-usbtiny-fuses] Error 1
Is it because it's the Attiny84 and not the Attiny44? I'll change the command. I edit hello.ftdi.44.echo.c.make, and change MMCU=attiny44 to MMCU=attiny84. And try again. The same error. I edit the file again and replace all instances of t44 with t84. Success!
egon:helloSource david$ sudo make -f hello.ftdi.44.echo.c.make program-usbtiny-fuses
avr-objcopy -O ihex hello.ftdi.44.echo.out hello.ftdi.44.echo.c.hex;\
avr-size --mcu=attiny84 --format=avr hello.ftdi.44.echo.out
AVR Memory Usage
----------------
Device: attiny84
Program: 758 bytes (9.3% Full)
(.text + .data + .bootloader)
Data: 64 bytes (12.5% Full)
(.data + .bss + .noinit)
avrdude -p t84 -P usb -c usbtiny -U lfuse:w:0x5E:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e930c (probably t84)
avrdude: reading input file "0x5E"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x5E:
avrdude: load data lfuse data from input file 0x5E:
avrdude: input file 0x5E contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: safemode: Fuses OK (E:FF, H:DF, L:5E)
avrdude done. Thank you.
And success again!
egon:helloSource david$ sudo make -f hello.ftdi.44.echo.c.make program-usbtiny
avr-objcopy -O ihex hello.ftdi.44.echo.out hello.ftdi.44.echo.c.hex;\
avr-size --mcu=attiny84 --format=avr hello.ftdi.44.echo.out
AVR Memory Usage
----------------
Device: attiny84
Program: 758 bytes (9.3% Full)
(.text + .data + .bootloader)
Data: 64 bytes (12.5% Full)
(.data + .bss + .noinit)
avrdude -p t84 -P usb -c usbtiny -U flash:w:hello.ftdi.44.echo.c.hex
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e930c (probably t84)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "hello.ftdi.44.echo.c.hex"
avrdude: input file hello.ftdi.44.echo.c.hex auto detected as Intel Hex
avrdude: writing flash (758 bytes):
Writing | ################################################## | 100% 1.72s
avrdude: 758 bytes of flash written
avrdude: verifying flash memory against hello.ftdi.44.echo.c.hex:
avrdude: load data flash data from input file hello.ftdi.44.echo.c.hex:
avrdude: input file hello.ftdi.44.echo.c.hex auto detected as Intel Hex
avrdude: input file hello.ftdi.44.echo.c.hex contains 758 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 2.89s
avrdude: verifying ...
avrdude: 758 bytes of flash verified
avrdude: safemode: Fuses OK (E:FF, H:DF, L:5E)
avrdude done. Thank you.
A FTDI cable was plugged into the single-inline 6-pin header on the Hello Echo board, and connected to a USB port on my laptop. I downloaded Neil's term.py. Then installed py-serial in macports to resolve some dependencies in term-py. Then I decided to skip that when I had more dependency issues and just installed a serial terminal for OS X, hoping it would just make things easier… Success? I'm getting something back; I suspect that the serial settings are mismatched. Oh I just resized and now it all works.
hello.ftdi.44.echo.c: you typed "55555aeiqjaldkjf4444444"
hello.ftdi.44.echo.c: you typed "55555aaiqjaldkjf4444444"
[Disconnected]
[Connected]
hello.ftdi.44.echo.c: you typed "a"
hello.ftdi.44.echo.c: you typed "as"
hello.ftdi.44.echo.c: you typed "asd"
hello.ftdi.44.echo.c: you typed "asdf"
hello.ftdi.44.echo.c: you typed "asdff"
hello.ftdi.44.echo.c: you typed "asdffg"
hello.ftdi.44.echo.c: you typed "asdffgh"
hello.ftdi.44.echo.c: you typed "asdffghj"
hello.ftdi.44.echo.c: you typed "asdffghjk"
hello.ftdi.44.echo.c: you typed "asdffghjkl"
hello.ftdi.44.echo.c: you typed "asdffghjkl"
" hello.ftdi.44.echo.c: you typed "asdffghjkl
"hello.ftdi.44.echo.c: you typed "asdffghjkl
"hello.ftdi.44.echo.c: you typed "asdffghjkl
"hello.ftdi.44.echo.c: you typed "asdffghjklHooray!