Keeping the electronics up!

Note: All the files here

Contents

Designing the board

For the board design I will be using Kicad, the main reason being the program being Open Source, free and quite easy to learn from scracth. I have already used it for the a Electronics production assignment. Therefore, let’s jump to it!

For the PCB design, I have mainly kept the original hello-board, including a RESET button connected to the PA2 pin of the ATtiny44, and two LEDS: one RED LED as a power indicator and one GREEN LED connected to the PA7 pin. The LED resistors are calculated with an online calculator with the following parameters:

These parameters will just lead to the minimum resistor for the LED not to explode, so I put both with 1kΩ for convenience.

In Kicad, the main screen looks something like this. I will be mainly interacting with the first 4 big horizontal buttons, which allow us to create the schematic, PCB and import libraries into Kicad.


The workflow goes like:

  • Import libraries into Kicad (only to be done once)
  • Create the schematics with Eeschema
  • Create a Netlist
  • Import the Netlist into the PCBnew editor
  • Create the PCB layout
  • Export into SVG
  • Edit the file into a vector editing program (Inkscape or similar)
  • Machine it
  • Solder it

Schematics design

First, we have to include the fab library, specifically for Kicad. For this purpose, we will click on the Schematic Library Editor icon (second icon) and then on Preferences > Component libraries > Add…. There, we select the fab.lib library we have just downloaded. Now, we have to launch the Eeschema - Electronic schematic editor and comence with the schematics design. In order to add components, we will click on the Place component icon and selecting the elements needed from either the fab library we have included or other custom libraries of our own. Once we have included all the components, listed below, schematic looks like this:


  • ATTINI44-SSU for the microcontroller
  • RESONATOR for the XTAL
  • AVRSPISMD for the ISP
  • 6MM_SWITCH6mm_SWITCH for the reset button
  • LED for both LEDs
  • FTDI-SMD-HEADER for the FTDI
  • CAP-UNPOLARIZED for the capacitor
  • RES-US1206FAB for the resistors
  • and GND and VCC for both ground and VCC sources

Once we have them all linked and in display, we can double click on the component in order to edit it’s properties. There we can modify the component Reference (title, for example R1, C1, …), it’s value (1000Ω, 1uF) and it’s footprint. The latest, we can change it by clicking on Assign Footprint and choosing it from the fab library. Normally, if any doubt, I have always selected the 1206 for resistors, capacitors and so on. In the case of the microcontroller, I chose the SOIC14, as included in the (vendor’s website](https://www.digikey.com/product-detail/en/ATTINY44A-SSU/ATTINY44A-SSU-ND/1914708).


Some quick tricks for Kicad: hover over the component and click on:

  • R to rotate the component
  • C to copy it
  • M to move it
  • Delete to delete it

Also, one has to be careful of what we click on, since the values, titles or the component themselves are different entities. Finally, a very convenient tool in Kicad is the Place global label, marking lines or ports with labels, in order to make the schematics clearer.

Once we have finished with the schematics design, having assigned all the names, values and footprints to the components, we should click on Generate Netlist, which is a list of components and references which serves as a link between the schema and the PCB layout editor:


This will create a .net file that we will be import later into the Pcbnew editor.

PCB-design

We can now close the Eeschema editor and open PCBnew. First thing is to load the Netlist by clicking on Read netlist. I have kept normal settings and clicked on Read Current Netlist. One should carefully read the Messages area in case of any error (normally in red) and review the schematic in Eeschema in case of errors. One of my mistakes was not setting properly the names to the components (repeated names) or not assigning the footprints properly.


Now it’s time to do the routing. At the begining, all the components are disconected (only with white lines) and all on a pile. With the help of the M key we can arrange them quickly and comence with the routing. I tried to use my intuition at first in order to place the components by my self, but I am not that smart, so I cheated by looking at the original example and re-routing it afterwards with the extra components.

Before starting drawing traces, we set the Design rules by clicking on Design rules > Design rules. The set of rules I used are shown below, which comply with the tools we’ll be using for the traces (1/64”).


The resulting PCB is shown below. Brief coments on it are: all the traces are done by connecting pins on the F.Cu layer and the cuts are done in the Edge.Cuts layer, using the Add graphic line or polygon tool.


Once we have it routed, we save it and click on File > Export SVG with the following configuration:


From experience, it’s interesting to save all of the layers into the same file, because we will be editing the SVG in a vector program such as Inkscape.

Traces file creation

Now, in a program where we can edit vectors, such as Illustrator or Inkscape, we will generate the PNG file that will go into fabmodules or mods. I will be using Inkscape for this purpose. My method (after only two PCBs) is as follows:

  • Import the SVG file
  • Arrange the layers into Traces and Cut


  • Redo the cut layer with a single area that covers the whole export:


  • Save the layers independently as PNGs, taking care of the position of the export (X0, Y0 and X1, Y1 or width / height) to match the actual size


Finally, the exports, ready to download:



Fabricating the board

Machining the board

With these, we can now use the fab.modules or mods in order to generate the traces for the machining. I will be using the Modela MDX-20 with the following settings in fab.modules, using this tutorial as reference.

  • Machine: MDX-20
  • Origin: X0, Y0 and Z0 are set to 0mm, in order to keep the same origin as the locally defined in the machine
  • ZJog is set to 2mm, meaning that the machine will lift the tool 2mm while not cutting
  • Xhome, Yhome, Zhome are set to 0mm, 0mm and 5mm.
  • Cut depth: 0.1mm
  • Offset: 4.
  • Offset-overlap: 50%, relative to the tools diameter (1/64” in this case)


And the traces:


The settings selected for the PCB outline (only detailing the ones that are different):

  • Cut Depth: 0.5mm
  • Stock thickness: 1.5mm
  • Number of offsets: 1

The final result, after the machining process is shown below:


Everything went smoothly with this software, although I had to make sure that:

  • The images where in PNG with background in white (not transparent), for which I edited the image in GIMP.
  • If something goes wrong with the Modela (for example, you break the tool as I did), you have to kill the process with the terminal line (thanks Xavi for the help and Marc for the documentation), since the process can’t be finished through FabModules or even restarting the machine. Since FabModules runs on Python, we can list the open processes that have python in it:
ps -A | grep python
6139 pts/1 00:00:00 python

With the process 6139 we know which one to kill:

kill -0 6139

We also have to kill cat processes with the following, because the machine will still be working:

ps -A | grep cat
6160 pts/1 00:00:00 cat
kill -0 6160

Soldering the board

Not much to say about the soldering, apart from highlighting that the cathode side is marked with GREEN in the LEDs!:


Testing the board

Via hardware with a multimeter (+Group Assignment)

This test is done in order to verify continuity and lack of shortcuts, and I will take the opportunity to explain the use of a multimeter before plugging the board to the computer. The multimeter has two probes (red + black) and they have different ends, like alligators, tweezers and so on. These probes are to be connected into the multimeter in either one of the three holes it has: the black probe always goes to COM and the red probe goes to either one of the other two, depending on what we are measuring.

It also has different modes, normally selected with a central knob and that have different purposes: measure resistance, check for continuity, measure voltage, currents and so on.


Image Credit: Sparkfun

It can measure AC or DC currents, and in more complex versions the display can come with an oscilloscope in order to check more complex signaling. So, in order to measure, for instance, resistance, we will set the multimeter in Ω mode and set both ends probes on each side of the target resistance to be measured. If the multimeter has different modes for the same purpose, like in the image above, for measuring resistance, the range can be changed into the knob (normally 200Ω, 2kΩ, 20kΩ…) meaning that the maximum resistance will be measured with the selected number. The result will appear in the screen normally in a weird fashion for example 0.918 kΩ, which relates to 918Ω. Other checks can be done similarly onto other magnitudes by changing the knob to the corresponding area (V~ for AC, V- for DC…).

It can also be used to check continuity or the diode anode/cathode position. For the continuity, there is a mode where we can check if two lines are connected and the multimeter will beep in this case. In order to check a diode, we can check whether or not current flows through the diode from anode to cathode, by checking if the diode lights up while connecting the red connector to the anode and the black connector to the cathode. This will help us to determine how the LED is to be oriented in the circuit.

So, a basic check is to set the multimeter in continuity mode (either marked with a diode, a sound pressure icon or Ω), and verify if:

  • there is connection between Vcc and GND (top and bottom lines of the MiniUSB)
  • the diodes are lighting up when checking continuity from anode to cathode and not viceversa
  • all GND are connected: crystal, USB, ISP, ATtiny44…; same with Vcc
  • there continuity between traces before each component

Via software

Once the hardware check has been done, the first thing in order to test the board is to download the FTDI drivers from the FTDI chip website. I have used this tutorial in Sparkfun in order to define my FTDI driver version, which happened to be the 2.4.2. The computer needs to be restarted in order for it to finish installation (in my case it did, in Mac).

Once the drivers are installed, one should see the board connected through the FTDI cable when doing:

➜ ls /dev/cu*
/dev/cu.Bluetooth-Incoming-Port /dev/cu.usbserial-FTHBQ1K0

Test with Arduino IDE

Now, it’s time to program the board. For the first time, I will use the Arduino IDE for safety and ease of use. I have followed the tutorial in order to set up the necessary libraries. Mainly, to extract from it:

  • Open the Preferences in Arduino
  • Find additional boards manager
  • Add the following URL: (https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json)
  • In Tools > Board manager… menu, download the attiny
  • Now under Tools > Boards, we should see:


Now, in order to test the configuration, still in Arduino I uploaded the following code:

#define LED 7
#define BUTTON 2

void setup() {
  pinMode(LED, OUTPUT);
  pinMode(BUTTON, INPUT);
}

void loop() {
  if (digitalRead(BUTTON) == HIGH) { // IF the button is NOT pressed
      digitalWrite(LED, HIGH);   // turn the LED on
  } else {
      digitalWrite(LED, LOW);   // turn the LED off
  }              
}

Making reference to the pinout from the ATtiny44, where both PINS are marked as 2 and 7 in the Arduino Framework (brown):


In the code we are checking if the BUTTON is pressed when it’s set to LOW (set to ground) or not, and therefore changing the LED accordingly. Note we are using the Arduino Libraries functionality in the background, while we compile and link the sketch.

Test with PlatformIO

PlatformIO is an open source ecosystem for IoT development. Cross-platform IDE and unified debugger. Remote unit testing and firmware updates.

From my very little experience in programming and following advice on the topic from other much more experts than I am (or might ever be), PlatformIO is a very convenient environment for embedded programming. It support a great variety of chips, which are carefully implemented in several Platforms, taking care of all the compiling / linking / upload needed. I will be using PlatformIO for the rest of the assignments, so I will try to set up the bases for its setup here.

First, to download platformio, it is best to follow it’s own guide. Since it’s based on Python, we ca use pip (Pip Installs Python or PIP Installs Packages):

➜ pip install -U platformio

Once installed, we can go to the folder where we want to save our project and initialise a PlatformIO project:

➜  Blink Code cd Platformio
➜  pio init

Note that pio is an alias for platformio. The pio init command initialises a folder structure that contains the following:

- Project
 | - src
 | - lib
 | - platformio.ini

Now, we will be putting the code into src and the direct dependencies (libraries) into lib. The platformio.ini file describes the instructions needed for the compiler to understand the target, as well as the desired method for reprogramming it. In our case, having read the Atmel AVR documentation on the PlatformIO website, the file looks like:

; PlatformIO Project Configuration File

[env:myenv]
platform = atmelavr
framework = arduino
upload_protocol = usbtiny
board = attiny44

Now, in the src folder, we put the code, taking care of adding the necessary #include at the beginning:

#include <Arduino.h> // This is important

#define LED 7
#define BUTTON 2

void setup() {
  pinMode(LED, OUTPUT);
  pinMode(BUTTON, INPUT);
}

void loop() {
  if (digitalRead(BUTTON) == HIGH) {
      digitalWrite(LED, HIGH);   // turn the LED on (HIGH is the voltage level)
  } else {
      digitalWrite(LED, LOW);   // turn the LED on (HIGH is the voltage level)
  }       
}

Now, we can compile with pio run. Note that the first time it will download the necessary framework for AVR:

➜  pio run
[Mon Mar  5 19:43:04 2018] Processing myenv (upload_protocol: usbtiny; platform: atmelavr; board: attiny44; framework: arduino)
-----------------------------------------------------------------------------------------------------------
PackageManager: Installing framework-arduinoavr @ ~1.10620.2
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
Verbose mode can be enabled via `-v, --verbose` option
Collected 24 compatible libraries
Looking for dependencies...
Project does not have dependencies
Compiling .pioenvs/myenv/src/blink.o
Compiling .pioenvs/myenv/FrameworkArduino/HardwareSerial1.o
...
^
Compiling .pioenvs/myenv/FrameworkArduino/WInterrupts.o
...
^
Compiling .pioenvs/myenv/FrameworkArduino/new.o
Compiling .pioenvs/myenv/FrameworkArduino/wiring.o
Archiving .pioenvs/myenv/libFrameworkArduino.a
Indexing .pioenvs/myenv/libFrameworkArduino.a
Linking .pioenvs/myenv/firmware.elf
Calculating size .pioenvs/myenv/firmware.elf
AVR Memory Usage
----------------
Device: attiny44

Program:     674 bytes (16.5% Full)
(.text + .data + .bootloader)

Data:          9 bytes (3.5% Full)
(.data + .bss + .noinit)

Building .pioenvs/myenv/firmware.hex
=============================== [SUCCESS] Took 1.95 seconds ===============================

This is the same process as making make. Finally, we can program the board by:

➜  Platformio pio run -t program
[Mon Mar  5 19:43:55 2018] Processing myenv (upload_protocol: usbtiny; platform: atmelavr; board: attiny44; framework: arduino)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PackageManager: Installing tool-avrdude @ ~1.60300.0
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
Verbose mode can be enabled via `-v, --verbose` option
...
Linking .pioenvs/myenv/firmware.elf
Checking program size
text	   data	    bss	    dec	    hex	filename
674	      0	      9	    683	    2ab	.pioenvs/myenv/firmware.elf
Building .pioenvs/myenv/firmware.hex
Looking for upload port...
Programming .pioenvs/myenv/firmware.hex
...

avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

avrdude done.  Thank you.

============================================================================ [SUCCESS] Took 3.99 seconds ============================================================================

Which is exactly the same we do when we call the make the following with the make file:

avrdude -p t44 -P usb -c usbtiny -U flash:w:$(PROJECT).c.hex

Both methods, either with Arduino IDE or PlatformIO should make the LED turn off/on while pressing the button:


Yay!