Output Devices
Add an output device to a microcontroller board you've designed and program it to do something
- Demonstrate workflows used in circuit board design and fabrication
- Implement and interpret programming protocols
Concrete Evidence:
- Described your design and fabrication process using words/images/screenshots.
- Explained the programming process/es you used and how the microcontroller datasheet helped you.
- Outlined problems and how you fixed them
- Included original design files and code
The outputs week homework was delayed due to travel and will be updated soon. Enjoy the Flickr album below before I have time to write up this week's work more formally.
Creating an output device was delayed because of travel to Costa Rica. Upon return, I was able to design an LED array that could accommodate 6 5mm LEDs, charlieplexed to run on three pins of an ATtiny45. The first attempt at building the board I designed was unsuccessful because I had included a voltage regulator that I did not actually have in stock in the lab. Instead, I redesigned the board, not including the regulator, and built that version.
Designing the board
The original design was to make an LED array that could accept a range of voltages for powering the board. This would include an onboard regulator, to keep the voltages at 3.3v. In that design, LEDs and resistors could be paired to keep their current draw around the optimum recommended 20mA. Although the ATtiny45 itself can handle a range of voltages, having a known voltage may help the LEDs function regularly.
To implement this concept, I included a screw terminal part and the voltage regulator on the board. The idea being that I could screw in wires and the regulator would handle it from there. I also included a hole in the board, so that I could thread the wires through it for a bit of strain relief for the terminal, or solder joints (if I alternatively soldered in wires where the JST connector belonged). For some reason, Eagle did not want to autoroute one of the final connections on the board between the terminal and regulator. To work around this issue, I manually drew traces that ended close to one another and connected them together in the post- processing in MS Paint. [NOTE: later on in the course I figured out how to deal with this problem more directly in Eagle.] Within Paint, I connected those traces, generated a separate file to identify all holes that would need cut through the board, and gave the board ‘Dimension’ lines from Eagle a white infill, so that fabmodules.org would have an easier time recognizing the outline. This post-processing in MS Paint goes quickly and nicely provides all of the modification needed to make the outputs from Eagle work well with fabmodules.org. One of the most useful parts of this is being able to draw out the location of all of the holes that need drilled in the board, and knowing they can be turned into toolpaths that will accommodate the small number of through-hole parts for the board. However, the need for this post-processing makes me feel as though I should look at learning Kokopelli for designing circuits when I have more time.
Redesign for Networking Week
Eventually, I redesigned the LED array board to solve the problems outlined above and to accommodate serial communication. This required that I base the circuit on an ATtiny44 and include a serial transmit and receive pin. I also chose not to include the voltage regulator and instead included a second 2X3 header that will be both the serial and power connections. This latest version of the redesign is certainly an output. However, this version of the board could also count for a node in the networking and communication week. It also will be able to serve as a set of indicator lights in my final project.
Writing the Code
The code for the first version of this output was quite simple – probably too simple. All that I needed to do was remove the unused pins from the routines in the example ‘C’ code and alter the makefile to compile for an ATtiny44 processor. This was really so little editing that it felt like cheating, so I decided to try to use the time to figure out how the registers work, and how the macros included at the beginning of these programs relate to one another and the processors. Trying to understand the macros in the example programs requires knowing about how the Atmel chips interact with their pins via three independent 8-bit registers. This three-register system is explained nicely HERE and is simply expanded to multiple three-register sets when there are more than 8 I/O pins on a chip. Independent pin register sets are denoted by the capital letter at the end of the register names: DDRA, PINA, PORTA, DDRB, PINB, PORTB, DDRC, etc… In order to further explore the interrelationship between these three registers I was inspired by a classmate's work to develop my own spreadsheet to simulate possible combinations of values in pin registers of the common ATtiny45 and ATtiny44. That spreadsheet is available HERE and may be of use to future students in exploring the relationship between these register values. I also started to redefine some of the macros in Neil's example programs to language that felt more readable to me personally. The changes that I made prioritized my familiarity with Arduino over what may be conventional on the AVRfreaks message board. I also edited and added to the comments assigned to these macros.
Serial integration to the output
The redesigned board that included serial communication was a significantly more difficult coding challenge. I started by trying to integrate the ‘hello.bus.44.c’ code with the code I describe above for the carliplexed LEDs. While the original code for serial communication involved an ability to handle long strings of characters sent in and out along the serial bus. I wanted something much simpler. All that was required was a function to listen for incoming char codes and use those to turn LEDs in the array on or off. In order to make this work, I also needed to add a few functions that would constantly cycle through the LEDs and an array of Booleans that control if individual LEDs are turned on or off faster than persistence of vision would be able to discern.
Upload and Troubleshooting
Uploading the code to a device is a pain. For some reason, I have struggled to get the AVR-libc toolchain from Atmel to install properly on my Windows laptop. The windows machine will generate an ‘out’ file, but not a ‘hex’ file. Instead, I always need to use a separate Ubuntu machine that is at least a decade old and barely functions. It can get the job done, but not quickly. This inconvenience means that I check for compile errors on my Windows laptop and then use the Ubuntu machine to generate the ‘hex’ file and upload through the programmer.
======================= UPDATE ===============================
For the final project I have designed the following outputs, each of which were networked as well: Stepper motor, DC motor, 20X4 LCD display.
You can see all images (used and unused) from this week's work HERE.