I’m working on a little PCB for a robotics competition. It is used by the competition volunteers to time races between competing robots. Cool!
The design is based on an Arduino Nano to keep things easy…. in theory. In practice, I couldn’t get a modern (or even outdated) version of the Arduino IDE to program this thing. It’s a common theme in the forums. Anyway, as a service to my future self and any other future selves, here is how I got it working, despite Arduino’s lack of care or interest in supporting their products:
Abandon using the USB interface. I tried this on 3 operating systems & 3 versions of the Arduino IDE, I could not get it to work. According to legend, sometimes it may start working after a lot of wasted time. In these rare cases, nobody seems to know how they did it.
Use an ISP programmer. Hopefully yours is not the Olimex avr-isp-mk2. This is what I have, and it is effectively not supported by Arduino since version 1.5.x
I recommend using the legacy 1.8.x IDE from https://wiki-content.arduino.cc/en/software. Download that, extract the archive. Newer versions of the IDE seem to hang indefinitely on a vague loading screen.
Applies to Olimex programmer: Find the avrdude executable included in the arduino archive. Replace it with your new compiled one
find . -name ‘avrdude’
it should be at hardware/tools/avr/bin
use the ln command to link your compiled avrdude into this location. This replaces their older incompatible version with your newly patched binary
You can now run ./arduino from the Arduino legacy archive – this was enough to get it working on my end
In the Arduino IDE, upload the sketch by selecting your programmer from ‘Tools > Programmer’, and upload the sketch by using ‘Sketch > Upload using programmer’
Other things you may have to do on Linux systems: install a udev rule for the Olimex programmer, and add yourself to the appropriate group (probably dialout). See Olimex link below.
If you are on Windows with the Olimex interface – compiling will be different to some degree, but ultimately you still replace the avrdude executable to fix the issue.
Earlier this year, I decided to design a project to evaluate Seeed Studio’s Fusion PCBA service. I didn’t have any immediate need for a PCBA, and so I found myself in the classic hobbyist situation: a solution in search of a problem.
The project needed a low parts count, a small PCB, and it had to be fun to design. I settled on a programmable Gameboy cartridge to meet my hobbyist needs. So, with Seeed Studio’s fusion PCBA parts library in hand, I fired up KiCAD and began my design journey! I began with some handy footprints from Gekkio’s awesome Gameboy footprints library, available on their GitHub: https://github.com/Gekkio/gb-hardware
Unfortunately, I had chosen the wrong footprint for the selected Flash chip, but Seeed Studio caught the issue and was able to help me correct it easily. Overall, their service was very good! I happily received my PCBA’s in a number of weeks.
Silkscreens: never miss an opportunity for a good pun.
Upon receiving the boards, I soon discovered that I did not place the mounting holes in the standard locations for a Gameboy shell. No worries though – that’s where FreeCAD and a set of calipers come in handy. Exporting a 3d rendering of the PCB from KiCAD took any guessing out of the equation:
The final result looks pretty good – I will note that a Gameboy PCB should be 0.6mm, but in my excitement, I must have accidentally selected 1.6mm. Therefore, the cartridge shell is very thin at the back, but the PCB gives it rigidity.
My development cartridge – fits like a glove
Setting up a project in STM32 Cube IDE is trivial work, however – I discovered that I had used a slightly incompatible footprint for the MCU. One of the pins is no longer available for GPIO:
Oops!
I double-checked all of the library components and indeed found that it was my mistake. That’s the price you pay for feverish hobbyist development, I suppose! Fortunately, I have GPIO to spare (At the top of the PCB), so I can do a hardware patch without any issues.
In bringing the board up, however, I have found that I am unable to get the MCU running at the intended 84 MHz – anything above 48MHz triggers hard faults in the CPU. Luckily, STM32 Cube IDE makes it trivial to configure global clock settings. I am not yet sure if this will be fast enough to meet the timing requirements of the Gameboy – I was unsure about 84MHz being fast enough. But, we will soon enough find out.
Stay tuned for hardware patching and new revisions!
For 2019’s iteration of The Long Con, I volunteered to help wrangle up some brain teasers for their “capture the flag” contest – a tech convention standard wherein attendees compete to solve assorted technical puzzles. As my experience with “cool stuff” mostly lives in the realm of circuit board design, I opted to contribute a circuit-board based puzzle. I think it looks pretty sharp with the silkscreen logo!
Hardware Design
As this is a small local convention, there wasn’t much budget available to go off-the-wall with technical capability – so, my three design goals were: 1. it has to look cool, 2. it has to be cheap, and 3. it has to do something neat. With these design goals in mind, I began my digikey search for an inexpensive but capable microcontroller. I settled on the attiny84a based on it’s capacitive touch capability, as well as an internal temperature sensor. These on-board sensors meant I wouldn’t need to add external sensors, which would increase the unit cost. You can get more info about the attiny84a here.
Designing the circuit board was relatively easy, based on Atmel’s design guides for capacitive sense (this is via their QTouch library). The hardest part was designing the capacitive touch sensor – I opted for the simpler rotary sensor design due to its ease of entry into KiCAD. I tried a few different ways of importing their recommended design, but couldn’t quite get it to work.
Recommended Design
What I wound up using
I had intended to use svg2mod to import the auto-generated footprint, but the polygon approximation didn’t seem to work out to a workable resolution. I didn’t feel like going any further down this rabbit hole, so I opted for the simpler design that Atmel’s documentation suggested.
The rest of the design was reasonably boilerplate MCU work – I stuck to standard components that were available from Digikey, and preferred components that exist in their KiCAD libraries. I have uploaded the KiCAD project to github, check it out!
Schematic diagram for the CTF boardKiCAD/PCBNew view of the circuit board3D rendering of the PCB
Software Design
The software was very dependent on Atmel’s QTouch library – most of the challenge was actually in configuring their IDE to work correctly. I wrote up my experiences on their forums here. Based on this experience, I have resolved not to use Atmel components for a while… I got the feeling that Atmel Studio is a second class citizen since the Microchip buyout.
The actual software itself is not terribly complicated (or optimized) – Atmel’s QTouch library, for all of its installation issues, was easy to code with. I had wanted to configure the firmware to spend most of it’s time in a low-power sleep state, but after doing some quick calculations, the battery would last the duration of the conference on a coin cell without the low-power modes. And so, I spent no time optimizing this device for power consumption.
For this unit, I opted to use reflow solder techniques. I purchased a Whizoo upgrade kit to modify a toaster oven, but I did not get the parts in time. I ultimately used a thermocouple and manually rode the thermostat on my toaster oven to follow something like a soldering profile. It seemed to work reasonably well!
For flashing the firmware onto the attiny84a, I placed a contact pad that mated with a spring loaded 6-DIP connector on the back of the device. To make for an easy flashing process, I exported a 3d model from kicad and used it to make a 3d-printable jig. I had to manually line up the spring loaded connector and hot glue it in place, which was a little tedious, but worth it in the end.
3d printed programming jig, complete with “Pogo pins”
Demonstrating fit on the jig
Conclusions
The project was an overall success, and people enjoyed the challenge. Unfortunately, out of the 30 that I had tried to manufacture, only 6 worked to their fullest extent! I attribute this to my ambitious use of tiny resistor arrays – it appeared most of the failed units featured poor connections on these components, and my reflow repair skills were simply not up to the task. Luckily(?) only a couple teams got far enough in the CTF to get to the “PCB challenge”, so we were never short on units despite the poor yield.
Another conclusion – try a different MCU vendor next time, Atmel Studio/QTouch installation was a torturous experience!
Puzzle Spoiler
The general intention was for participants to look up the datasheet of the single IC to see what peripherals it had – QTouch and temperature sensing – and work from there.
Puzzle 1 – this conference takes place during the daylight savings time change. Users had to “turn back the clock” by using the capacitive rotory sensor on the clock face. 4 complete rotations would prompt the LEDs to display a byte pattern.
Puzzle 2 – the weather had just begun getting cold in Manitoba (where this conference took place). Users had to get the unit 15 degrees Celsius colder than when they plugged in the battery. This could easily be done by taking the unit outside. This was a fun puzzle to figure out from a software point of view – the calibration on the sensors was not great out of the factory, and I didn’t intend on taking multiple calibration points for each board. So, it simply looks at the temperature delta since the unit turned on instead of comparing against an absolute temperature.
