A week dedicated to learning more about circuits and programming our personal boards
We began this week by in our lab by experimenting with a variety of boards available to us in our lab. We grabbed random boards and looked up their details online, in hopes to run blink code on the boards. We also created a Micro-Controller Google Sheet to document the specifics of multiple boards, which allowed us to get the process of coding done far easier and quicker.
The first board that I grabbed was an AdaFruit Trinket 5V, which took a while to get working. I needed to check AdaFruit's documentation and look over GitHub for drivers and necessary installations for blink to work on the board.
The next board that was passed to me was an Arduino Uno, which took significantly less time to get working. This board, unlike the AdaFruit, seemed to be directly supported by Arduino (unsurprisingly), which made the setup and coding process far easier.
The next step of this week was to get our boards that we had machined weeks earlier programmed and working, which turned out to be a difficult task. When I had completed the board, I was able to upload and run a simple hello1616.ino file that printed the user input from the serial monitor back out in the serial monitor. However, this week I was unable to get this code (or any other code) to work with my board.
Professor Goodman guided us all through a tour of KiCad, the software that he suggested we learn and use for this week’s project. We went to the GitLab for FabAcademy’s KiCad library and downloaded the file, uploading it into the schematics and footprints of the software. This process took me longer than expected since I had (before meeting) downloaded an outdated version of the FabAcademy library, so I had to do a lot of on-the-fly adjustments and downloading.
The KiCad software proved to be a little tricky to master at first, especially with such finicky zooming. I decided to plug in a mouse when using this software so that I could use the mouse wheel rather than spending time zooming in and out, and over and over again until I get a better view of my design.
The first view that I used to design my circuit was the Eeschema/schematic view. I was able to add symbols for components into my design and rotate/move them freely. The hardest part of the schematic view for me was remembering the controls and finding the correct components. However, I really enjoyed the task of connecting the components with wires, and it brought back fond memories of me using Logisim, a similar tool used to create logical gates and circuits.
My hope for this design was to create a board that had two buttons and three LEDs to create a simple coordination game. My plan is to code this board to have each player press one button each at the same time. If the buttons were pressed in a number of milliseconds within eachother, the green LED would light up. If one person pressed their button after the other with a delay longer than that, the LED closest to their button.
The next step of the process was to create the tool paths for the traces on the copper surface. To accomplish this, I used the PCB view, and began connecting components with 0.5mm copper trails. This process was surprisingly fun. It was like a complex puzzle (and reminded me of the mobile app/game: Flow Free) that kept me thinking even while I was away from my computer. I created the design above while trying to optimize the size of the design, and thus had to redesign. Although this design had a very small footprint, I was hoping to create a circuit that was symmetrical in its button and LED placement, and found later I did not include two pull-down resistors.
My next iteration took far more time to put together, as there were now more components and thus far more constraints on the design. After tedious randitions of getting to the lasts components and it being impossible to connect then with a trail of copper that wouldn't create a short circuit, I rejoiced when I created the above design. Although reminiscent of a concerned skeleton, I am extremely proud of this design and am incredibly happy with how it turned out.
The next step was to fabricate the design with the roland mill. I uploaded the design as an SVG to illustrator, double checked the nodes and connections to see if there were any errors/issues, re-traced some copper paths, reuploaded to illustrator, and sent the file into Mods.
After zeroing the mill and performing a series of air cuts, I first cut the trace of the design. During this cut, it was evident that I did not correctly zero the mill as it was barely scraping the top of the copper, and thus had to abort the cut, re-zero the mill, and then start the cut again. This cut went much better.
I then changed out my bit to a 1/32" carbide end mill and repeated the same steps. I went to illustrator, double checked the design, uploaded to mods, performed an obsessive amount of air-cuts, and then mustered the guts to cut into the material. I first cut out the holes for the connectors and keychain hole, and then the outside cut.
These came out beautifully. I then went to sleep in order to not be as shaky for soldering the next day. After week 4, I felt much more confident in my ability to create a circuit board and (in comparison) flew through the soldering process. I was using a heatgun for all solders except for the pins, for which I used a solder iron. The hardest part of the soldering process was keeping my hands steady and soldering the areas of the design that had copper going under components. I had to make use of Neil's strategy of "heating up a component while holding onto it with tweezers until the board came loose and fell" a few times since I was getting more connections in areas than I was planning. In addition, an area of my board (above pin 1 of the ATiny1616) was connected by copper in a way that it should not have been. I tested this area with a multimeter and it had continuity with less-than desirable parts of the board, so I had to chip away at the extra copper that was creating the bridge, and after testing the continuity again, found I had fixed the problem and probably saved me a lot of time if I had plugged it in and something short circuited or blew up.
After I had finished soldering and had tested my board with a multimeter a few more times, I moved on to programming the board.
I downloaded Arduino and got to work with connecting my board to my computer. I copied over Neil's Echo Hello code and after changing the code from 1614 to 1616-compatible, I clicked "upload using programmer" to upload the code onto the board. After this, and a bit more trouble shooting and switching the Tools->Chip to the correct 1616 chip, I then reconnected my board with the FTDI pins in order to have the board and the computer communicate with eachother. The next crucial step was to cross my fingers. After quadruple checking the connections to make sure I had connected all pins correctly, I tried over and over again by opening the serial monitor to create communication between the board and the computer. After asking for help from fellow classmates, we realised a common problem among our boards and found that by adding a line "Serial.swap();" under the void setup() funciton, this allowed the communication to occur and fixed the code.
I crossed my fingers again and was thrilled when my board said "hello" back!!!!! It worked! I felt so accomplished.
This week was an incredibly challenging week, and I am extremely proud of what I have accomplished. The process of going from design to fabrication to electronics is tedious, long, and full of hurdles, but it is also so rewarding.
After taking a small break, I came back and got back to perfecting the code. AND I GOT IT WORKING! The game is a simple version of a reflex game, where both players hold one finger over a button. They attempt to press the button at the same time and if one person presses slower, than a red led blinks, signifying they were not fast enough (or rather that they both were not coordinated enough). I was so glad that it worked and instantly started playing it with my roommate.