To start this week's assignment, I decided to spend some time reading tutorials and looking at the work done by other students in the previous years since I have no prior experience with Eagle or any other circuit design software. I asked feedback from my colleague who works on complex 3D printed circuits and he said that while he was not working with Eagle, this was the main software of choice. His work was done with Circuit Maker from Altium and was mostly similar to Eagle. Thus I also had a look at it, but was severly disappointed. The registration process made it look like it was running in the Cloud similarly to Onshape, and raised lots of expectation by requiring designs to be shared using LGPL licensing, but eventually ended up being just a trap to have the user base registered online and get their projects published for free. The real application only runs on Windows and seemingly is far from getting any Linux / Mac support. Thus, I am staying with Eagle and may have a look at KiCAD.
I looked at the previous work of several people including Tiffany Cheng, Cody Glen, Julia Grotto, Kevin Kwok, and Ron Rosenberg, as well as the suggested tutorial linking to Schaad's work. The main elements I got back include several tours and external tutorials to look at as well as tips to get the design work done. I eventually also found a few posts that were useful during circuit verification which I include in the list below:
Working with Eagle was not without a learning curve and some frustrations. The first issue I encounted in the schematics drawing was to disambiguate some of the components. The fab.lbr library includes multiple variants of some of these and it is not always clear which one is intended. I actually suspect that multiple are possible in some cases, notably I saw that some people used polarized capacitors in their schemas, which seems to not matter in terms of footprint, but I don't think we have access to anything else but unpolarized capacitors, which as I understand are better anyway since they work in both direction whereas polarized ones are seemingly direction-dependent. For the resonator, I was suprised to see a crystal component which I thought would be the one of interest, but turned out to not be. Finally, the pin headers have multiple variants: the generic pinhd-2x3-smd and the specific avrispsmd, which I chose instead. Both look exactly the same. The components I ended up with include the ATTiny44-SSU, the FTDI pin headers, two resistors (10k and 1k ohms), the resonator, the unpolarized capacitor (1uF), the AVR ISP pins (similar to 2x3 generic pins) and the two extra components - the default LED, and a 6mm switch from Omron. I was suprised to not be able to find the similar switch in the default library of Eagle. For more diversity, it seems important to install extra libraries of components. An interesting one is the Common Parts Library from Octopart.
The main trick to schematics seems to use labeling of the wires (and use "nets" instead of the line tool of course). The labeling allows to completely avoid having to care about the routing, which is not the point of the schematics anyway.
The first part is basically a lookup of each of the components and spreading them on the schematics. I added two many ics as I was not sure of which one at the beginning, but deletion is trivial.
Then, I separated each component and labeled all the wires I needed, and created the connections of interest.
For the LED and the switch, there are a few possible pins available. I initially used the same ordering that I had seen other people use without thinking too much about it. Unfortunately, I changed this last one to have the button on pins 10 and/or 11 of the uC afterwards and this led to a nightmare for routing when designing the board. The trick here was to look at a nice board without the two extra components such as provided on the fab academy website and realize where the the ground was and just draw directly where it was available from a free pin of the ATTiny44 towards the ground line in the periphery. This seemed harder with pins 10 and 11 (PA2 and PA3, on the right, see figure below), and much easier with pins 5 and 6 (PB2 and PA7, bottom left).
Having done the schematics, I first had an issue to generate the board because I had created a board file before which had nothing in it, and then created the current schematics, but these two were not linked together, which led to Eagle complaining that the board design could not be linked correctly and it could not generate anything. The solution was to delete that bad initial board, and press on the icon to switch to board design, which then prompts for creating the initial board design anew, and this ends up in a correct state.
Initially, I tried to move the components on the board and then to use auto-routing. This took several attempts and they basically all failed with different degrees of evilness. Note that I don't like to work with pure black and bright red/green colors, so I decided to switch the background to white and add the dotted grid for alignments.
The first attempt ended up generating a via to route the ground above some cross wires. A posteriori, most of my problems of routing were due to the ground pins first, and then due to the VCC part. It might have been much better to just put ground for everything at the boundary using a polygon as I remember one of the TAs mentioned at some point. Unfortunately I did not think about that at that point. Will do next time! The second issue was that multiple wires would go in between the legs of the microcontroller. While this is fine for a few in the long direction, there is not enough space between neighboring legs to do that.
By rotating and trying to move some sets of components, I started to realize that I would need to go through the microcontroller via the main direction, and then pack the components together. I found a way to avoid the via, but the auto-routing ended up creating very tightly packed wires below the uC, which probably would not be machineable or be very easily short-circuited.
At that point, I decided to arrange the components similarly to the basic board design mentioned before. I would then manually arrange the wires to follow the same path and change the schematics back to have the led and switch on pints 5 and 6 of the ATTiny44 which had an easy spot in the lower-left section of the board with lots of space and an outside "ground" that was needed for both. After removing the routes and using auto-routing, I ended up with a new design that was already much better but still had some issues because VCC was in the inside at the top of the board instead of being outside as in the basic design.
This design would have been fine, but I decided to try to be similar to the original board and rerouted the ground and VCC after rotating the top resistors and capacitors so as to match the reference board. The main issue with that last board was the VCC on the right that had to be routed to the VCC on the top-left pin of the micro-controller, which was not doable without going in between some of its tiny legs, which I wanted to avoid as much as possible (I don't know if it would be machinable in fact!). Finally, I used manual routing to finish the wires and follow the same directions as the original board, ending up with a similar design that does not need to go between any legs of the microcontroller. I also added my initial to the design in vector fonts (required by the design rules in the fab.dru file) to stamp it.
And finally generated the trace and outline by exporting at 1000 dpi for the SRM20, and then inverting the color in gimp, and finally creating the outline as a simple rectangle (with some cut corners) from Gimp in a separate layer.
I used the Roland SRM20 to trace and cut my PCB.
Everything went well, even the small traces below the IC got separated correctly.
(Update).
I initially didn't look carefully enough, but the traces were quite wrong!
Indeed, the left connection from VCC on the IC pins had completely been merged with the nearby legs.
For some reason, I didn't realize this initially and was pondering for a while what was wrong beyond the potential short,
and after desoldering the IC, I finally realized that the short was not coming from the solder, but the lack of a correct cut
resulting in the VCC being connected to all main pins of the IC without even soldering!
Population went well as well as soldering. I used the LED reference from the previous ATTinyUSB board to orient mine correctly towards ground. I realized that the orientation of the arrow was actually different with Eagle, so I assume that either the components were different or the original schema came from a different software. What really matters for LEDs (and diodes) is the orientation of the triangle, not the external arrow (not in diodes). The resistance labels (physically printed on top of the component) were kind of obscure, but given this new board I realized something interesting. 10k ohms is denoted as 1002 where I guess the last 2 corresponds to having 2 extra 0, which would explain why 1k ohms is denoted as 1001 and not 1000 (from the previous board).
Removing the IC was non-trivial. I asked my lab colleague to give me a hand and it went much easier than I thought. He initially tried to remove the extra solder mixed between legs (which I had eventually created while trying to unsolder the whole IC). For that, he used his own flux that was more of a "paste" and did not create bubble, but created a lot of smoke, so it was better with a ventilation system next to it. Using flux and the braid led to the bridges being removed, but the whole thing was still shorting with VCC. That's when he showed me how to best remove the IC in a quick manner: using the heat gun towards the IC, and a tweezer to pull the IC (or hang it and the board until it detaches). That's when I finally realized the tracing issue: the VCC trace had not been separated from the left legs of the IC!
Instead of recutting, I just used a cutter to remove the traces except for the middle VCC leg and then checked for shorts. Everything was now back to normal! My friend showed me that given the solder in place, using the heat gun would allow an instantaneous way to resolder the whole IC directly. This was very quick! The flux heating did burn a bit the board unfortunately.
The programming went without any problem using my own ATTinyUSB created two weeks before. The generated code seemed to be slightly different with a different size (760 bytes of program and 64 bytes of data) than that in the tutorial (786 and 33 in the tutorial). The output seemed however to be all correct, so I trusted it. The tricky part was that although it had been programmed, I could not talk with the board using serial communication.
$ make -f hello.ftdi.44.echo.c.make
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: 760 bytes (18.6% Full)
(.text + .data + .bootloader)
Data: 64 bytes (25.0% Full)
(.data + .bss + .noinit)
$ 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=attiny44 --format=avr hello.ftdi.44.echo.out
AVR Memory Usage
----------------
Device: attiny44
Program: 760 bytes (18.6% 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.00s
avrdude: Device signature = 0x1e9207
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 (H:FF, E:DF, L:5E)
avrdude done. Thank you.
$ 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=attiny44 --format=avr hello.ftdi.44.echo.out
AVR Memory Usage
----------------
Device: attiny44
Program: 760 bytes (18.6% Full)
(.text + .data + .bootloader)
Data: 64 bytes (25.0% Full)
(.data + .bss + .noinit)
avrdude -p t44 -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.00s
avrdude: Device signature = 0x1e9207
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 (760 bytes):
Writing | ################################################## | 100% 1.12s
avrdude: 760 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 760 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 1.43s
avrdude: verifying ...
avrdude: 760 bytes of flash verified
avrdude: safemode: Fuses OK (H:FF, E:DF, L:5E)
avrdude done. Thank you.
For testing the echo board, I initially used the python script provided there. To use it, I had to install PySerial. Unfortunately, I first installed "serial" using pip, which ended up not working but not in a way that would explain well why it did not work. After realizing the difference in the two modules, I removed serial and installed the correct PySerial. The script would work, but the TK interface would freeze after entering the loop and I would never be able to input anything and thus not see any echo back. This happened to other people so I am suspecting that there's either a bug, a version problem or some access problem.
I then decided to try different solutions and first using bash directly to talk to the serial block, which was not successful. I finally chose to try the Node.js way with the serialport npm module, with its serialport-term binary using the following command:
serialport-term -p /dev/usb/tty.usbserial-XXXXXXX -b 115200
This worked like a charm (note that the XXXXXXX part seems to change randomly on my MAC when you plug / unplug / replug)! The only issue being that the initial interaction with the shell created some empty inputs that would trigger a few echo lines. But beyond this minor bug, the echo board is working!
$ /usr/local/bin/serialport-term -p /dev/tty.usbserial-FT9KZ1SE -b 115200
hello.ftdi.44.echo.c: you typed ""
hello.ftdi.44.echo.c: you typed ""
hello.ftdi.44.echo.c: you typed ""
hello.ftdi.44.echo.c: you typed ""
hello.ftdi.44.echo.c: you typed ""
hello.ftdi.44.echo.c: you typed ""
hello.ftdi.44.echo.c: you typed ""
hello.ftdi.44.echo.c: you typed ""
hello.ftdi.44.echo.c: you typed ""
hello.ftdi.44.echo.c: you typed ""
hello.ftdi.44.echo.c: you typed ""
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 "asdfa"
hello.ftdi.44.echo.c: you typed "asdfas"
hello.ftdi.44.echo.c: you typed "asdfasd"
hello.ftdi.44.echo.c: you typed "asdfasdfa"
hello.ftdi.44.echo.c: you typed "asdfasdfa"
hello.ftdi.44.echo.c: you typed "asdfasdfas"
hello.ftdi.44.echo.c: you typed "asdfasdfasd"
hello.ftdi.44.echo.c: you typed "asdfasdfasdf"
hello.ftdi.44.echo.c: you typed "asdfasdfasdfallsasdfasdf"
hello.ftdi.44.echo.c: you typed "asdfasdfasdfaslsasdfasdf"
hello.ftdi.44.echo.c: you typed "asdfasdfasdfasdsasdfasdf"
hello.ftdi.44.echo.c: you typed "asdfasdfasdfasdfasdfasdf"
After looking around, I found out multiple native ways to do serial communication on Linux there including (my favorite although partially buggy) simply using screen /dev/ttyUSB0 115200.
Although I love screen and use it all the time, it does not automatically return to line after each command is received.
Maybe there is a trick to force this behaviour...
This means that the alignment you see above is all messed up in screen.