7. Electronics design¶
In this week, I learned (or rather I am struggling to learn) about PCB design and how to observe the operations of the board I designed.
- Use the test equipment in our lab to observe the operations of a microcontroller circuit board
- Redraw the echo hello-world board
- Add (at least) a button and LED (with current-limiting resistor)
- Check the design rules, make it, and test it
- Extra credit: simulate its operation
Antti, another of our local instructors, gave as a short introduction to PCB design and assisted with the tasks for the week.
One of the tasks for this week is to design a circuit board by re-engineering an existing board and adding at least two components to the board: an LED and a button. The design of the board was done in Eagle which I had already installed. Before beginning to design, the fab.lr library file needs to be downloaded and added to the Eagle libraries (as seen from the image below). This file holds most of the Fab Lab inventory’s components that are needed for the Fab Academy. The file does not need to be in the Eagle libraries folder, it can be in any folder as long as its path is added to Eagle. To change the path, from the main Eagle window you click on Options>Directories.
Part of designing the board includes adding the components and connecting them. Before starting, I created a new project in Eagle, File>New>Project. Any new project created will appear in the projects Folder in Eagle and the Schematic (.sch) and Board (.brd) designs will be saved into this same folder.
Under this new project, I created a new schematic and added the components to the schematics editor needed to create the board. This can be done from Eagle’s Schematic Editor where there is a Graphical Icons Toolbar from which the components and the connections between them can be made. There is also an option for the command line. I used the graphical toolbar. The main icons used for placing the components were Add part (highlighted in red), Net (highlighted in blue), Delete (highlighted in turquoise) Move and Rotate (highlighted in green) as shown below. These commands are also available when you right-click on the layout.
After placing all the needed components, I connected them using the Net tool and set their values by right-clicking on them, selecting Value from the dialog box. I then checked that everything was connected using the Electric Rule Check (ERC) command. If everything is connected, a board can be generated by clicking on the Generate/Switch to board icon.
The Generate/Switch to board command results in the figure below. On the board’s editor, the toolbar icons have different options for routing and ripping up routes between components (highlighted in red and blue), moving and rotating components (highlighted in purple), selection (highlighted in black), and Ratsnest which helps with arranging components so the routes between them flow smoothly (highlighted in yellow). The wider surface should be resized to almost the size of the board, but leaving enough space for milling when the board is ready,
The components should be moved around and routed until there aren’t any intersections between the routes. Unconnected components will lead to errors which have to be corrected. Multiple rounds of Autorouting and ripping the routes (ripup :), Ratsnest and manual routing helps.
Design rules check¶
When there are no errors (as shown in the Routing Variants Dialog box) after running Autoroute
with the DRC settings in the image below, the image files for milling can be created.
Exporting board design¶
Before converting the image, it is good to reverse the colours especially for the outline file. In Eagle, Options>User interface changes the background colour to white.
Next, I drew a line around the board with the Polygon tool from the toolbar. I named it GND and pressed Ratsnest to create GND all over the board’s surface to ensure there is no need for extra connections for GND.
With only the top layer selected in the layers dialog box, I exported the file as PNG. In Eagle, File>Export>Image and you define the settings shown in the image below. This creates the file for the traces.
Then I drew another rectangle around the board on the inside of the one above with the Line tool and used the Move tool to position it.
Traces file (second picture in image above)
For the outline, I gave the line drawn above a width of 40 mil which is slightly bigger (1.016 mm) than the 1 mm bit for milling the outlines. I changed the background colour to white and with only the milling layer selected (layer 46), I exported the image as a PNG using the same parameters as for the traces file.
Now, the images for milling the board are ready. These were converted to .rml files as outlined in the week for Electronics production.
As in Week 5, I collected all the needed components prior to soldering and soldered them onto the board.
- 1x ATtiny44 microcontroller
- 1x 2x3 Pin header
- 1x 1x6 Pin header
- 1x 1 uF Capacitor
- 1x 10 nF Capacitor
- 1x 20 MHz Resonator
- 1x 499 Ω Resistor
- 1x 10 kΩ Resistor
- 2x 49.9 Ω Resistors
- 1x Omron button
- 1x red LED
Below is an image of the soldered board.
Programming the hello world board¶
First, I ran the command to compile the code:
make -f hello.ftdi.44.echo.c.make
Then, I connected the programmer from Week 5 to the new board designed this week. Before connecting the two boards, I checked that the programmer was recognised by the computer when plugged into the USB port by running the command
ls /dev/tty* in Mac. This can also be checked in Mac through Utilities> System information> Hardware> USB. When connecting the two boards, it is important to check the orientation of the pins and that the GND of one pin is aligned to the GND of the other. I used an ISP cable to connect the two boards and a USB/FTDI cable to connect the new board to the computer’s USB port.
After this, I prepared the new board for programming by setting the fuses:
make -f hello.ftdi.44.echo.c.make program-usbtiny-fuses
Finally, I flashed the program to the microcontroller’s memory.
make -f hello.ftdi.44.echo.c.make program-usbtiny
The programmer can now be disconnected from the new board.
Testing the board¶
After programming the new board, I tested it to check that it was working.
I installed pyserial, a Python Serial Port Extension for different platforms and distributions, in the mkdocs virtual environment on my computer.
sudo python -m pip install pyserial
Then, I ran the python application connected to the serial port of the board with the following command:
python term.py /dev/tty.usbserial-FT9P2WH8 115200
To know the serial port number to reference, use the tab key after tty in the command above or before entering it, type ls /dev/tty* on the command line and connections to the USB port will be displayed.
After running the application, the python application window opened but it was mostly unresponsive and I had to restart (force quit) it multiple times.
The test did not work on my Mac, but tried it on Antti’s PC and it worked.
In order to test the signal, the ground clip of the oscilloscope has to be attached to the board (Ground). Then the probe (pointed) tip to the signal being tested (either VCC or input/output pins).
To observe the operations of the board, in Marjo’s computer from the PuTTY terminal, we typed the letters U,S, and B and viewed the signals in binary format as presented on the oscilloscope. The order of presentation is reversed starting with the least significant bit first - the bit that carries the least numerical value in a binary sequence.
Below are images for each of the letters as seen on the oscilloscope.
The Baud rate seen in the oscilloscope (11.49 kHz) was close to the one defined in the python application connected to the serial port above (115200).
This was another one of the challenging weeks.
Schematic design was pretty straight forward because we had Antti’s help. Still, I needed multiple tries to get it right. After this, it got a bit more complicated with routing the components on the generated board. Later, I realised that I should have done an ERC check on the schematic to ensure that all connections were correct before generating the board. After multiple tries, the DRC check on the board was eventually successful and producing the files to be milled was one of the easier tasks. As stated in the Electronics production week, it can be a problem reading from schematics and the board design as I haven’t yet grasped the notations for all components and their values. This was again an issue during soldering when I soldered two components the wrong way round. Luckily, it was not a major issue and with Antti’s help, this was fixed. Soldering was as difficult as in the previous related assignment and I have to quickly improve.
Despite all the issues with designing the board and soldering, the programming part of both electronics production and design have gone surprisingly well.