13. Output Devices¶

Introduction

Prior to my Fab experience, I have used output devices on almost every Arduino or c-based project that I have worked on, so the basic premise of using output devices was not foreign to me prior to this week. However, I had never added an output device to a custom board that I designed and fabricated, excluding the board that I designed for electronics design week, which technically featured an onboard LED as an output. As I wanted to take a deeper dive into outputs throughout this week, I decided to design my own board that I eventually programmed to interface with a small 5V DC motor.

Assignment

This week's individual assignment was to add an output device to a microcontroller board you've designed and program it to do something. The group assignment for this week was to measure the power consumption of an output device.

Week 13 Individual Assignment

For my individual project this week, I decided to design, mill, solder, and program a board that I used to interface with a small DC motor. As this week’s assignment required that I use an output device with a board that I have designed and the touchscreen LCD that I will use as an output on my final project will work via a Raspberry Pi, I decided to work with a DC motor as I felt that it would provide a challenge as well as useful insight into in the design process of mechanical devices. I began by opening my circuitry software of choice, EAGLE, and designing a simple schematic that would be used to interface with the DC motor.

pg1 pg1

As I only wanted to include an external output device on this board without any other onboard electronics, the design phase of this schematic was incredibly straightforward, especially relative to the process of designing my input board for RFID. The only two components that were necessary on this board were the ATTiny412 microcontroller that I would use to connect to the DC motor, and a 22pF capacitor that I placed between the VCC and GND pins that the motor connects to in order to aide in the smoothing of voltage. I included lots of header pins on this board in order to make uploading and interfacing with my output board and eventually other microcontrollers very straightforward. After postulating that the process of programming my input board was extended in large part due to the modicum of pins which necessitated repeatedly ditching FTDI, Arduino, and RFID connections from the board in order to attach a different component, I decided to include enough pins to mitigate the amount of time that I spent disconnecting and reconnecting devices to the board. The pins that I included duplicates of were VCC, GND, and UPDI (which is also pin 5 on the ATTiny412). I decided to include headers for each pin on the microcontroller, even though my DC motor only uses two of the headers. I included the extra headers for future expansions, particularly the RX and TX pins, of which I plan to use during networking and communications week to interface with my input board. After adding the microcontroller, capacitor, and header pins to my schematic, I was ready to begin routing the traces for my board in a .BRD file that I generated from my schematic.

After importing my schematic into EAGLE’s proprietary .BRD file editor, I routed the traces of the schematic in a sensible manner, successfully eliminating the need of any 0 ohm jumper resistors and thin, ‘rat’s-nest’ clumps of traces in any sectors of the design. After routing the traces in a compact formation that would ensure their durability, I decreased the size of the borders of the file to only include what I wanted to mill out. After deciding on the final size of my board, I exported the .BRD file to one of our lab’s Bantam Tools Milling Machines and prepared to mill the first iteration of my board.

pg1

After milling my board in our lab, I cleaned it with water and used tweezers and a microscope to remove some smaller debris that could potentially short my board later on. Removing extra copper shavings also makes the board generally look cleaner which is definitely a positive as well. After my board reached a semi-waterless state I was ready to begin soldering the few components that I needed to the board

I finished the physical portion of this week’s worth by soldering my headers, microcontroller, and 22 pF capacitor to their respective pads on my milled board. One problem with this board was that I forgot to widen the traces directly underneath the microcontroller pads, which made these traces incredibly thin, though I resolved this easily by extending the solder connection from the pins on the microcontroller to the widened sections of the afflicted pins’ traces and did not encounter any major problems with my board due to this small oversight that I made during the process of designing my output board. Also, please excuse the large solder clumps on the VCC, GND, and UPDI 3x1 header array. All of my other solder joints were made under a microscope with a quality soldering iron in our Fab Lab, while these last three joints were hastily added with poorer equipment than what I am generally used to. In no way does this reconcile my egregious actions, but I wanted to shed light on the origin of the abhorrent joints on my board.

pg1 pg1

The process of uploading my code to this board was identical to that of my endeavors during electrons design and embedded programming week, as I was using the same microcontroller which requires the same UPDI uploading protocol. My first uploads were successful, and the motor began spinning when I connected the GND and data pin to the motor. The code that I wrote for this week is included below and is included in this week’s zip download that is enclosed below.

const int motor = 6;
void setup() {
  pinMode(motor, OUTPUT);
  digitalWrite(motor, HIGH);
}

While this is likely the least complicated code I have written throughout the entirety of Fab Academy, it allowed me to verify that I am capable of using an output device with a board that I designed and satisfied the requirements for this week’s assignment. While this does satisfy this week’s requirements, I plan on taking my output device much further than this in my final project, which will use an interface that I am currently developing and a 7” touchscreen with a Raspberry Pi.

Conclusion

While the board that I designed for this week to control the motor did work as intended, there are several key flaws with my design that prevent the motor from functioning with maximum performance, primarily due to the limitations of the microcontroller that I used for this week. The ATTiny412 is an excellent microcontroller for smaller electronics that do not require significant amounts of current to operate at their maximum levels. However, my motor requires significantly more current than the 40 mA that the ATTiny412 is capable of supplying to its output pins. Several solutions that would have functioned better for controlling the motor that I used during my work for this week's assignment include the inclusion of a motor driver board or a MOSFET motor driver, which are capable of supplying significantly more power to the motor and allowing to take full control over its potential that was incredibly restricted when powered by the digital pins on the ATTiny412 that I used to power it.

Group Assignment

This week's group work was done entirely by Drew Griggs, and his contributions are described in extensive detail on this week's group site.

Download this week's files! (16.8 kB)

Important Links

Last update: July 4, 2021