Week 4Home

This week we learned how to design circuits.

Using KiCad

I decided to use KiCad for the design part of this week's project, as I like being comfortable with free, open-source tools so that I can continue to use them once I lose access to academic licenses. The documentation provided with KiCad was very thorough and helpful in learning to use the tools.

My plan was to make a version of the Hello_world tiny44 FTDI board that would have an extra button and LED for limited user interaction. First, I had to make a schematic showing the components and connections I wanted for my circuit. You may notice that I forgot to add a resistor in series with my LED.

Next I had to create a netlist and assign my component footprints. I used the fab component library for my components and footprints. The KiCad library, at least seems messy, with seeming duplicates and no documentation, so next time I'll try using a Digikey or built-in library, but it worked this time.

The hardest part was actually laying out the PCB. I opted to do this all manually so that I could get a feel for what goes in to trace routing. I used 0.25 mm traces, with 0.5 mm clearance (to give a bit of room beyond the minimum of 0.397 mm for our 1/64" endmill). I first routed everything without the extra button and LED and then used forward annotation from the schematic to add in these two extra components (notice anything missing still?). Here is the end result:

Fabricating the board

I then exported svg files for milling. The mods program I used to communicate with the milling machine (see week 2 for details) needed a PNG input, so I first tried converting the files using ImageMagick. My first mills, however were failures.

There were so many things wrong with the first boards that it was a bit hard to troubleshoot, but here are some things I figured out:

• On the first attempt, I noticed that the board was convex, so that the middle of the board curved up and was pressed down whenever the milling tool came down to cut. Furthermore, some of the cuts looked offset, as if the board had shifted partway. For the next try, I made sure the board wasn't warped, and then made sure to tape it down extra strongly.
• The first board also had some places at which the tool didn't cut all the way through the copper. This happened in spite of making sure the tool was firmly against the copper when tightening it. I set the cut depth to 0.05mm for future cuts.
• On the second attempt, I forgot to invert the PNG (KiCad exports with the traces black), so the resulting cut was the inverse of what I wanted. Next time, I made sure to invert it (though this turned out to be difficult).
• The lines still seemed to be crooked and at weird angles on this second attempt, even though the board had not shifted at all. After some troubleshooting, I realized that I was working with a really low dpi png file, and that mods really needed a higher dpi to work correctly. Using GIMP to convert my svg into a 1000 dpi PNG fixed this problem
• GIMP, however, unlike ImageMagick, left the background transparent in the resulting png. This led to problems, as mods doesn't know what to do with a transparent background when inverting. I therefore had to fill the background with white in GIMP before exporting the PNG.

Finally, I figured out how to make my board correctly! (see the good board on top of my two bad cuts)

Here is a picture of the mods workflow using the low dpi PNG. Notice the strange pattern in the machine path result that doesn't really follow the input pattern.

And here are the final PNG files that I used for the correct milling run:

I then soldered the components on. It was at this point that I realized I had forgotten the current-limiting resistor for my LED. Rather than start again, I decided to try some post-production modification by cutting a trace with a razor blade and soldering the necessary resistor over the gap. This seemed not to cause any short circuits, so I went ahead with testing.

Programming and Testing

For programming the board with the Hello World program, I used the files and rough instructions provided on the embedded programming part of the course website. These were meant for a linux/mac environment using Python 2.x, while I was attempting to do the programming on Windows 10 using python 3.7, so I had to adapt the instructions moderately.

First, I saved the various code and makefiles and compiled them as the first instruction specified:

• make -f hello.ftdi.44.echo.c.make

Next, I plugged my board into my computer using an FTDI to USB cable, plugged a fabTinyISP into my computer, and connected them via their ISP headers. I then programmed the board. Here, I used the described commands, but omitting the 'sudo' before the command.

• make -f hello.ftdi.44.echo.c.make program-usbtiny-fuses
• make -f hello.ftdi.44.echo.c.make program-usbtiny

In order to run the last command to interface with my new board, I had to find and save term.py, a piece of python code written by Neil that gives you a terminal-like interface to a serial connection. This code, however, was written for a Python 2.x environment, and I wanted to run it using my Python 3.7 environment. I therefore had to make a few changes in the code:

• Change "Tkinter" to "tkinter" (Python 3 uses lowercase for tkinter)
• Change "ser.write(key)" to "ser.write(key.encode())" (ser.write expects bytes, not a string).
• Add parenthesis around argument of "print" function. Python 2 allowed "print yourstringhere" while Python 3 requires "print(yourstringhere)"
• Manually fix inconsistent use of spaces and tabs in indentation (Python 3 is stricter about indents)

At this point, I had a working python script for the terminal, but it still wouldn't run, since I was missing the PySerial package required to interface with the serial port. I therefore used the built-in pip package installer to install this library.

• pip install pyserial

Now I was almost ready to run the terminal, but I couldn't just copy and paste the command from the linux/mac instructions because port naming is different in Windows. I therefore had to determine what port my device was plugged into. I did that as follows:

• Open devices and printers (Control Panel > Hardware and Sound > Devices and Printers).
• Find your device (something with TTY in the name; try unplugging and replugging to see which device changes).
• Double click on the device to open properties. Navigate to the hardware tab, and click on the entries until you find one that says something like "COM3" under 'location.' This "COMx" is your port name.
• Later update: PySerial actually has a built-in module for checking which ports are in use. Type in "python -m serial.tools.list_ports -v" and the port you are using should show up with the device information.
• Start your terminal communication interface with the following command:
• python term.py COMx 115200 (where x is the number of the com port you found)
• Later update: Pyserial also has a built-in command-line terminal, miniterm. To use this instead of term.py, type "python -m serial.tools.miniterm COMx 115200"
• Type in whatever you want and watch the board echo it back!

I tested how big of a memory the chip had available to store my messages by writing "Hello, World! HTM(a)A is great!" As you can see in the following image, the buffer starts overwriting itself from the beginning after 24 characters.

As a last step, I tried to use an oscilloscope to view the signal passing in and out of the TTY connector on the board. By turning off autoscroll on the oscilloscope, I was able to capture a view of the signal.

Files

• My KiCad project (zip)
• Python 3.x-compatible term.py