##Why'd you do that Carl? Why'd you run away to do FabAcademy?
This week's assignment was probably the most exciting thing for me. I'd been looking forward to it for about a year since I first heard about the course. Coming off the back of Electronics Design Week I learned about the tools used to develop a custom board to suit specific requirements.
I've worked on a few wearabables now, and a lot of compact electronics, so the size and shape of a circuit is critical and being able to prototype them quickly is an incredible advantage.
Technically I'm qualified in a variety of electronics but I haven't truly felt I could live up to my qualifications until I was actually able to prototype electronic circuits.
Fab Academy to me, is the best excuse to throw myself at something 150%, wholeheartedly and unreserved for 20 weeks. I left three perfectly well paying jobs in the prototyping and startup industries. My family, friends, romance, beer and my car.
I ran away because I needed to commit myself to the mastery my work was missing. I was pretty good at designing things, but I was missing the spark of well-rounded, intensely iterative general solutions to specific problems that the content of the Fab Academy course advocates.
But I can also understand there are very few students on the course that share my luxury. Many still maintain their jobs and family, or other studies at the same time. I wonder how they can make the most of this experience in a condensed timeframe.
Others simply have different motivations for taking the course. Perhaps they wish to master a particular skill more specifically, and the remainder of the 18-or-so weeks are just the padding to a vehicle of their specialisation.
You can see that some students insist on doing the bare minimum, or only pick projects within their field and to them I worry. Francisco Sanchez said to me in my first weeks that "people who want to succeed in Fab Academy, will. Those who want to be challenged and to learn, are completely separate from them."
So to that I believe the solution isn't more rules, or more specific assignment criteria. That only breeds line-followers and develops a converging cohort skill level around the lowest common denominator.
My intention over the next few weeks as I travel around Europe to different Fab Labs is to find out how we can find the "What brings people to Fab Academy", and use it. Like young jedi drawn to the lightsabre, I hope the Academy is able to appeal to the new generation of makers - non-engineers, non-academics, non-specialised, ___problem solvers___ .
This brings me to my next thought; There are so many ways to build anything, and I've been learning a lot of them for many years now. My fascination however is less about the actual product and more with designer mindset and how the designer chooses to make decisions.
When I see my fellow design padawans figuring out how best to approach a problem it really brings out their true colours - who they are, what they value and where they come from. That aspect of the designer makes me really excited!
If you were tasked to design a product for somebody, how would you start? For example, if you had to design the first ever plastic takeaway fork (yeah, you might have guessed I'm eating takeaway at the moment), there's a couple ways you might think about designing it.
Perhaps you might measure the maximum volume the fork could foreseeably hold, and multiply it by the density of the densest food item (just taking a stab, but probably icecream)... Another way may involve testing the loads on an existing fork as you used it in everyday eating to determine what makes a fork "usable as a fork".
The brilliance about multiple approaches is that things that may seem wrong to do aren't necessarily wrong. And contra-positively, things that seem like the best most natural design ever could be completely unsuitable.
The notion that there are no wrong answers in design is such a wild thing to think about. I didn't hope to do it justice here today, but I wanted to point out one of the things that makes me excited about the Fab- ethos.
##This week's assignment
Read a microcontroller datasheet
Program your board to do something
Load a program into your little processor
And lastly, the bonus points assignment as per the schedule:
"compare the performance and development workflows for other architectures"
My previous experience in microcontrollers has been pretty stock-standard. In fact, I was told off in my first week for mentioning Arduino, which is the proverbial Voldemort within the Fab-circles (you can't even mention the name. No kidding, find some other creative way to refer to it, but don't say the _actual_ word.)
I've taught classes to children 6-16 yrs old about the aformentioned microcontroller and programming suite, so I have a pretty good grip on what the system does and how to check that it does it, but I'd never thought to design my own board or program direct to the chip.
As I mentioned in this week's preamble, I was pretty excited about this part of the Fab Academy course. Being able to manufacture my own boards and select my own firepower was very appealing, and so I went out of my way to do a good job this week.
Since my experience was limited to them _blue boards who can not be named_ , I took excessive notes during the Professor Gershenfeld's lecture so I could explore the definitions later. I'd heard the term __bootloader__ thrown around quite a bit but not really known what it was. It's basically a program you load onto the chip that specifies how the chip behaves to new programs you load onto it. Simple concept but I never took the time to look into it until now.
Also, I encountered __avrdude__ in second year engineering and just thought he was a pretty cool guy, but turns out that it actually avrdude stands for AVR - __D__ ownloader, __U__ ploa __DE__ r. Nice to have closure on that one, and I think I will take more time to get to know the guy from now on 😎
In order to really master this week's activities I decided to try three different boards on three different ECAD softwares. Each board would have a different chip and I'd work my way up to some more advanced techniques in the process.
Wendy and some of the other Fab crew refer to this as "Spiral Development", a technique I learned from building racecars as an iterative method for building and improving prototypes where at each stage you have a functioning part you can fall back on if you run out of time (every time).
###Program your board to do ___something___
Since basically all freshly born microcontrollers have blink pre-loaded on them it's tricky, or at least misleading to tell by uploading blink if everything is working as it should.
I have a fascination for emergency vehicles and so I always quickly modify the blink template to do a triple flash, and this also helps to visually check the timing on the circuit.
Sometimes, as I found with the ATtiny85 in Week 6's hackathon project the timing can be entirely out and it's useful to know this before you go any further with a circuit.
Since I had every intention of advancing in little steps, I decided to settle with uploading the program in the Arduino IDE. There were no issues for me, but some of the class had trouble burning burning the bootloader but were still able to program the board anyway..
That's mighty confusing, so if you're reading this and you know why that happens please let me know!
###Build the FabFTDI with KiCAD
For those of you following along at home, you'll notice I ran out of time in Week 7's activities where I was planning to just stick it out with KiCad one more board. I was reminded when Neil mentioned it in the lecture so I used the advice from the Centre for Bits and Atoms write-up and that same write-up but edited at a different time for crosscheck.
My last experience with KiCad was pretty frustrating and Wendy in fact has a recording of me declaring "this will be my last board in KiCad" but I found that this is perhaps just the way it is and things (mainly Eagle, if you read on) could be worse.
To do this I took the time to read about the ATtiny45 chip and figure out what I could get away with. For this design I used the micro-USB port which was a huge mistake, since the pins are stuuupidly close together meaning I had to machine that section with the 0.01 inch tool.
I didn't have the time to figure out how to only machine a specific section of the board with such a fine mill bit but if you read on I ended up having to do it for the ATmega328p and ATmega16u4 chips. So for this board I just milled the whole thing in 0.01" with three passes.
When I plugged this all in I felt a melty sensation in my hand and immediately dis-plugged the USB cable. I checked using my built-in organic temperature probe (index finger) for the hotspot on the board and found nothing. Next I used my thermal camera to pinpoint the source and found it was actually the cable itself heating up (see picture).
Something must have been pulling some hard current.
Using the tutorials above, the guy says to make sure the zeners are the right way around but he in fact means to make sure they are the __wrong__ way around. Zeners are of course backwards so they don't go "pointy end down" like other diodes. Check my picture closeup if you are worried. The bar on the SMD package points to ground.
At 25 years of age I still check my left and right by making an "L" with one of my hands, and the polarity of diodes are the other thing I really never properly committed to memory and have to check every time.
Thankfully that was the only issue, and all that was left was to upload firmware to the ATtiny45. The following commands (lifted from the tutorials above) helped me out, but I had to fix a typo from the original instructions:
avrdude -p t45 -c usbtiny -P usb -U flash:w:cdctiny45.hex:i
avrdude -p t45 -c usbtiny -U lfuse:w:0xF1:m // Note the 'lfuse' not '1fuse', and the 'F1' not 'Fl'
avrdude -p t45 -c usbtiny -U hfuse:w:0xCE:m
avrdude -p t45 -c usbtiny -U efuse:w:0xFF:m // The original tutorial had a typo that meant to say efuse instead of euse
###Fab328P, or Carlduino.. call it whatever
Next on my quest I moved to an ATmega328P, the same chip used on the Arduino UNO unit. I've had a fascination with these for a long time knowing that you could make entire circuits on an extremely tiny board, but never took the time to visit the data sheet until now.
I used the the FabIO and the Gersh-duino from Neil for reference with my design, which were provided as examples in the lecture notes.
I also added a 3.3V regulator to my board and some LED's because I found that during the hackathon week that would have been quite useful. Especially for using ESP8266 and ESP32 boards, and I looked ahead at using the ATmega16u4 and figured I was going to need it for then as well.
Neil's Gershen-board was useful to refer to, I ended up reverse engineering his PCB image to a schematic and adding my changes since there's minimal extra hardware and really had room for expansion depending on what you plan to use it for.
This was the first design I used Eagle for, and towards the end of it I got so sick of Eagle I just rushed the final routing and didn't bother breaking out all of the I/O I had intended. Instead I settled with tiny circle pads for franken-hacking some very fine wire to if I need it.
####Major differences between KiCad and Eagle
I didn't want to admit it, but I really HATED Eagle. I wanted to like it, since our lab SOLDER in Perth actually has the Autodesk Ultimate Package, and everyone rants and raves about how good Eagle is..
The truth is, it has all the best intentions but doesn't live up to the usability and speed you need when you're at full throttle.
KiCad has some great intuitive keyboard shortcuts (more akin to Fusion 360's shortcuts) and even though visually not as flashy, it's clear and understandable what each element does.
I bet things will be different as board complexity goes up, but I can't say I recommend Eagle for any real reason.
With the KiCad workflow, it can be frustrating that you have to make changes to a schematic in order to update the PCB layout, but it's secretly a blessing compared to Eagle.
In Eagle the idea is that the schematic and PCB layout are synchronous, so changes in one should update the other. It's all great in theory, however it absolutely kills your flow to lose annototating consistency between the two files.
It took me a few hours to get back to a workable state from this problem in Eagle. I'm sure there are some beest practices for avoiding these situations but it's an experience heavy enough for me to stop using it entirely.
KiCad on the other hand forces precedence of the schematic over the PCB layout. It may be a harsh thing - to force the operator's workflow - but if I'm honest at least it's clear and works every time.
When you hit full speed you just NEED that in a software package.
####Machining with the 0.01" bit
You can see in the first stage of PCB machining that the pins for the ATmega328P are suuuuper close together. I needed to use the 0.01" end mill again, but I didn't want to mill the whole board with that tool (it would be a waste an wear it out. Not to mention it would take forEVER to machine and by this point it was 4am and I needed my board NOW!)
At first I tried it on my own, but realised that if I made the background black the toolpath generation in Fab Modules would interpret the ends of the traces as cut lines. This would be solvable by bridging every cut trace on the board but I resolved that there would HAVE to be a legitemate way to do this.
So I did a quick scan of the archive (with the boolean searching power of Google) and found an example of someone machining only a small section of their board in one tool, then finishing the board with another tool.
I actually can't find the link now but I'll post it when I get back to it. In summary you have to make the background white (duh!🤦) leaving only black areas to be machined in the specific area you need it. [Update: The student who posted it wrote about it here.]
You can find my three files in my design files folder labelled "detail", "traces" and "outline" to see what I mean. After running the detail section in 0.01" I used the 1/64" tool to clear the rest of the board.
####Franken-hacking a rushed board design
While soldering I found out that the Fab library for Eagle didn't have the right footprint for the LM3480 regualtor we had on hand so it was actually the much larger footprint. To fix this I just soldered to two of the pads (Pin 1 is V_out, Pin 2 is V_in) and bridged the GND with some of the leftover un-machined copper.
Another crazy thing that happened was that after soldering the FTDI headers I wasn't happy about the angle they were placed. So forgetting that they weren't through-hole I tried to mechanically convince the pins to rest horizontally straight but ended up lifting haLF THE TRACES OFF THE BOARD ?>!
I was pretty over it by this time of the morning so I wasn't going to machine another board, I decided I only *really* needed the VCC and GND pins for FTDI to prove that it works, and to patch one of the VCC traces that had been ripped up.
You can see in the close-up where I franken-fixed the VCC rail.
Programming this chip with the FabISP (Ol' Reliable) was a breeze given the Fab-structions in the tutorial. With no hiccups at all I was able to change the LED pin and upload my triple-flash sketch (written in 'Arduino C') using avrdude.
###Trying the FabLeo 16, (Carleonardo16) in Altium Designer
Lastly, and most excitingly, I built an evaluation board for the ATmega16u4 chip using Altium. There are a few reference designs from previous students using ATmega32u4 chips, which is a drop-in pin map for the 16u4.
However, the 16u4 isn't supported by the Arduino environment, and I couldn't find any good examples of anyone using this chip. But as far as I understand it has built-in HID USB support so it would be a very useful chip to understand.
So I decided to go out on a limb and build an evaluation board, based on the 32u4, just to check if I can establish some kind of useful programming on the chip and then use it in further projects. If all else failed, I could just machine the boards and wait for a 32u4 to arrive, but for now we only had the 16u4 in stock.
####Altium Desginer is comforting like sitting in a lake from a shampoo ad
I'd been really intent on using Altium since it is the most applicable EDA software I encounter in my career. Also, incidentally, Altium came out of Australia (Tasmania). So it would be totally uncool to not investigate it.
Altium Designer was like an intravenous injection of serotonin after my headches with Eagle. The user interfaces and viewport are AMAZING, and placing parts and figuring out functions is really intuitive coming from KiCad.
I would highly recommend for anyone starting out that they start from KiCad and then go into Altium. They are both quite consistent with each other and very fast design environments.
One suuuuper stand-out feature that Altium has over the rest is the ability to push traces out of the way when routing. This on it's own may justify the $8000 AUD pricetag that comes with each licence.
It does some other cool things too, like integrated 3D circuit display and some kick-ass simulation tools. But mostly I loved the visual layout, ease of routing and easy to understand errors that mean I don't really have to think too hard when I'm clicking around.
####Designing the evaluation board for the ATmega16u4
For the design I used the datasheet, the reference schematic for the Teensy 2.0 and Ardunio Micro, a bunch of previous students' work (Palash Nandy, Guillaume Teyssie, Luiz H H Bueno, Andrew Mao) and some forum posts by Arduino moderator 'Crossroads' (Post 1 and Post 2) to become confident in understanding the bare-bones pinout I would need.
One of the issues with Altium is that it's not simple to export to PNG for FabModules, like KiCad or Eagle. How I did it was by creating Gerber files for the board, then exporting the board to PDF. From there, I brought the PDF into Inkscape and then manipulated it.
I was a bit worried about the possibility of the scale being lost after printing to PDF but it turned out perfectly fine.
Another problem I had was that since Altium isn't common around Fab-circles, I couldn't find any libraries for some of the things we used. For now, in consideration of time, I drew some rectangles and guessed the rough spacing for the footprints of the USB and ISP pads.
I got it pretty close and was able to clip the legs of the SMD ISP headers to get them to fit.
Lastly, a classic regulator problem again. This time, the footprint was the right size (I made a point to check it!) but the pins were reversed (because no default library was here to keep me out of trouble).
I didn't know exactly where the bug was at first when I plugged in my board, since the whole backside of the board was hot. It could have been the crystal or the chip, since they were so close together on the board but by using my trusty thermal camera again I was able to find the incorrect component.
To fix this I pulled the little guy off and soldered him back on backwards (face-down). This configuration with the legs up in the air I've heard referred to as "sky soldering" and is an easy way to flip the pins on an incorrect transistor layout.
I was able to upload hex to the board with avrdude confirming success, but I'm still yet to figure out how to compile my own programs into hex.
Here's how far I got with my config, if anyone happens to be an expert and can tell me what else I needed to do feel free
From the following research:
###A bit about the 328P and 16u4 Datasheets
The datasheets show you a lot of information and as you grow into them eventually progress lower and lower into the document, understanding how it all fits together as your experience builds up. In the early stages, you look at the stuff near the top, namely pinouts and ADC/IO functions.
I'm only an initiate but coupled with some of my experiences in analog electronics I've been able to make awesome use of these chips with only the first few pages. The datasheet for the ATmega328P is here, and for the ATmega16u4 (and also 32u4) is here.
####IO, ADC, PWM and XTAL understood
The ADC pins are used for measuring analog signals, and the PWM pins are used for digital output. **Almost** all of them are labelled as digital IO pins as well, meaning they (the ones that are labelled as such) can be used for example for measuring a button press, or turning on an LED.
This was something I didn't already know, and can be useful in some weird ways. In Arduino you would usually use the A0-A5 pins as analog inputs, but they can also be used as digital outputs if you run out of pins, you just have to enable them as OUTPUT so they don't float.
Conversely, the Arduino environment gives the impression the pins 0-13 can only be used for output, however they can be configured to read when a button is pressed.
A caveat I learned in Output Devices Week about the ADC6 and ADC7 was that they can only be used as analog inputs. As such they aren't labelled as IO pins. This would be the only case I've found where it is important to read the description of the IO pins specifically, in every other regard the IO pins are generic digital functions. These two ADC pins are only available on the 32-pin TQFP chip.
Another thing that became useful was that when I ran out of Arduino outputs I could actually make use of the XTAL as IO. However, I would need to use straight-C to access these pins, as the Arduino environment does not let you access them trivially.
I have not yet discovered how to do this. If you are only comfortable with the Arduino IDE then don't plan on using the XTAL pins.
####Other things to watch out for:
There are things like VCC, GND, AVCC, AREF and such that are important to know about. AREF and AVCC in all the applications I've used should be wired to VCC. They have a different function to VCC, for example they don't power the MCU, but they should be connected.
Another thing to note is the operating voltage: I didn't realise you can run an Arduino from as low as 1.8V, and that all the ATmega16u4 notes I've seen runs them at 3.3V maximum, but they can handle 2.7-5.5V . Maximum voltages are an easy thing to forget to check!
Once you get more adventurous you could start to look at how the ADC, Serial and Timer architecture can be used in your project. I haven't yet advanced to that level, but I'm sure that after seeing some examples of other students' projects I will become inspired to learn and make use of them.
###Tips with Gimp:
So if you're like me and depend on Gimp, you might also share the frustrations of it taking a whole millenia to load. I looked deeply into the issue and found it is the 'system fonts' that it loads that contributes most to slow start up times.
I Google'd the issue and found it was a simple fix of removing the system fonts line from the startup script, however I found out the long way that you can't modify system text/config files just by opening them.
For this activity I had to edit boards.txt which was permissions protected, but I found out you can open Notepad as an administrator then open, modify and save your file that way.
When I realised that that worked I returned to Gimp, knowing exactly what needed doing but previously not having the means to do it. Scanning over the culprit config file like a pigeon looming over bread I found and destroyed that particular section of the script and now Gimp opens up in a matter of seconds!
##About the Design Files
There's a bit going on in the files for this week.
+ Blink - There's a blink program I've used and reused many times, originally for the t85, then repurposed for the t44 for this week. I also happened to use the same file to test my 328P by simply changing the ouptut pins.
This code uses both PWM for fade and delay for flashing. You can see it in action on the first video at the top of this page.
+ kHz-pwm-w_Gabriel - this code was used this week but documented and updated in Output Devices Week for my voltage booster circuit.
##Things I gave up on this week (for now):
Nothing! I managed to get through everything I had planned for once 👏