Category Archives: Electronics

My First Build: the Microgameboy

Let’s start with that I’ve never – ever – soldered anything before. Although we define this pcb-build as beyond Arduino, I felt hopeful I could pull this off because of the excellent equipment in the lab and the guidance of @Blok2009. In the end it took me about 2,5 hours to put together one Microgameboy v5– in comparison, it takes @Blok2009 about 10 minutes to achieve the same.

Starting with the mcu was a big hit for me – there is something special about holding computing power in your tweezers and melting it down into liquid metal. Being able to work under a microscope also was a huge benefit – although shifting field of vision from microscopic to normal every few seconds was a new experience for me. Blinking required.

I took a little break in the process as it was rapidly going from enjoyment to annoyance and I didn’t want to break my joy in creating this.

I had a bit of a scare once everything was melted on – the power source was connected and nothing happened…

What did I do wrong? Together with @Blok2009 we took of the battery clip again and looked at all my solder smearing . I noticed that there was one capacitor that I had actually only connected on one side, another capacitor’s head or ass was stuck in a bubble of solder – probably not connecting to the plate on the pcb (the surface tension of the orb holding the solder of the plate) other places had more solder on them than might be good for them. I corrected all these things and we added some kapton tape under the battery clip as it might be touching things it shouldn’t be touching. Now, I am not sure which one of these things actually mattered but – praise be onto Nuggan – now there were leds* blinking and the Microgameboy was ready to receive its game: BITMAN.

Adding some colour buttons and a fish (because fish) and my Microgameboy is ready to incite and amuse. I am so proud.

* – the three LEDs on the board are the only things I did not solder on myself.

!E Embedded Expo aka mcu! mcu!

Another day, another tech-tradeshow. This one is about anything containing a micro controller unit; The Embedded Expo. No way to register on-line beforehand so we just rocked up to the Convention & Exhibition Centre. There was a waiting line that definitely had our name on it. International visitors -check, VIP – but of course and Group too. Swapping business cards for badges, we are good to go.

There was much to see and question, every booth had someone who spoke English. Manufacturers of the worlds’ tiniest LED, china – the cup kind – with an interactive touch display, smart home set-ups and the like. We also took home a very interesting Journal of Electronics of which we can only read the titles, some of the references and the scematics. The Shenzhen DIY community, hackerspaces and makerplaces were also present.

Here we see a set-up for RENESAS new hardware accelerated operating system on the mcu. Both rows of tubes are keeping the orange balls in the middle by controlling airflow. When we up the measurement frequency the mcu without the new fancy system can no longer maintain control.

We also showed a few people the microgameboy, to kind of explain what TINRS does. They all seemed impressed, although some thought it was a bit too small. Explaining the idea of just making something because you can or building a prototype that you do not necessarily intend the mass produce is still tricky.


Huanqiangbei Shopping – day 2

Another day at the market looking for parts. Happy hunting with a long list of things to get. The ground floor of one of the buildings used to be a beautiful mosaic, but it got smashed and broken by the amount of commerce taking place on top of it.

Negotiating for some 7805 power regulators. We are not negotiating over prices – these already are REALLY low, as are the amounts we want. With a few exceptions we only spend a few euros at any one stall. Meanwhile, the sellers have to deal with our lack of Chinese and whip out parts from their massively stacked 2-square-meters or make them appear from the magical ‘somewhere else’. No need to haggle over a 10% discount. Each item was minutely checked before being handed over. Deal made!

Up and coming (we are seeing them more than last year) are all the Arduino and their lookalikes, RasperryPi’s and Banananaboards as well as the sensor- and building-kits that go with them. Up and down we go; the list isn’t finished yet.

After two days of Huanqiangbei, we have a lot of stuff:

Huaqiangbei Shopping – day 1

Huaqiangbei – to some of our group it already feels like smelling something from your childhood, to others it is a new shock to the circuit.

After much browsing in the overload of little stalls with parts, knick-knacks and anything that can possibly be connected, the first actual purchase was a bag of LEDs. The quantity we desired and the quantity in a standard bag did not match but luckily our pretty assistant for this transaction was willing to rip open the package and divide by weighing. Seemed weird to us at first but it makes perfect sense. Who is going to count out 500 LEDs? Besides, what’s one LED more or less between friends.

Here we have the tools we need to negotiate a bunch of CMOS logic gates – we still speak only three words of Chinese but thankfully numbers and serial lettering are the same. Pointing, sketching and the trusty calculator still gets us through. There was some waiting for components that magically appear from somewhere, meanwhile tea was served from a very small clay pot.

Around a corner somewhere we found walls of clamps, cutters, tweezers, holders and solders. The shiniest and sturdiest all seem to be Made in Japan – Asia rules. Happy browsing all round.

Yes, Stijn is talking into a microphone. After the initial overload some of the guys thought it would be a good idea to be able to reach each other. We don’t have Chinese SIMs so they bought a set of walkie-talkies. Huanqiangbei is a lot to get around. We will be back!

CITE China Information Technology Exhibition

DSC05577DSC05585 We were excited to see CITE and had ourselves an early start. We had some wonderful Chinese bread for breakfast – with the undetermined pork or fish sugary floss – and set out in the foggy morning. The big trade-show hall is within walking distance of our temporary home. When the Chinese build an Exhibition centre, they mean it and make the ones in our own country look puny.  There was so much to see!  A few of the highlights:

DSC05572 DSC05574Neuron; A full-body motion capture suit; a collection of sensors that you can easily strap on and lets you freely move around. There was a guy doing live demonstrations in front of a big screen, he seemed kind of uninspired so I did a little dance with him – to relieve boredom and to see if the sensors would also follow some more rigorous movement. I made him follow me and together we boogied down to the ground and twirled like ballet dancers. On screen all the moves (including his stumbling and hesitance) were really well followed.

DSC05590Pick and placers in all shapes and sizes, a CNC on magnetic rails, robotic paste dispensers and 2-component gluing robots which were unexpectedly cheap. Electric factory worker drills and screwdrivers – stopping on counterforce and hanging down from heaven (or the ceiling).

DSC05593 Thin film speakers and conductive textile printing – actually stretchy and no more of the crackling problems it had in the past. This seems like an interesting technique to build some creative and wearable applications. Make stuff work AND look good!

DSC05565 DSC05566

pcDuino: Lego-like blocks that you can program as components onto your pcb and build things on with Lego. Like many things nowadays it works with Scratch. Very nice educational tool, allows for mucking around. Disassemble and reassemble.


We walked in to the “e-health” hall, which mostly consisted of e-cigarettes and their many, many liquids. The air was sweet and fragrant and scantily clad ladies were walking about with promotion materials. One of them handed us a throwaway e-ciggarette which supposedly equals one packet of cigarettes.

DSC05571There were multiple versions of a step on electric transport device – sort of a Segway without the middle stick which most of us tried out for a couple of meters. You control it by moving your feet very slightly. Roman has the distance record between us and had the basic manoeuvring down in less than two minutes.

A rolling drone that can also bounce and flip. 3D printers with a delta-bot, SLS stratasys printers, room-sized 3D printers and liquid printers. OLEDs in panels of 10 by 5 cm and 8K screens by BOE. Many more things to gawk at and definitely to much to list here. Makeblock was also there, showing of their new stuff – more on that when we visit the studio.


Programming interface progress: SWD JTAG command sequences

by Stijn Kuipers

Since the last post I spent quite some time with my new tool to dump sequences from my commercial debugger. After comparing these dumps to various codebases I found online (libswd, cmsis-dap, mchck) and comparing them to the various manuals on the subject, I managed to extract the command sets for a set of essential functions:

1) Peek/Poke (universal to all ARM cores)
2) Halt/Continue (universal to all ARM cores)
3) Reset (Freescale specific)
4) Mass erase (Freescale specific)

With these command sets figured out, I was able to recreate them on a standard Arduino and trigger them with a simple serial remote control application. I also managed to figure out how, when and why all the various types of registers are available to read/write over the debug lines. In the case of the Freescale chips I’m targeting, some features are only available after setting certain bits somewhere else. Others only work when the system resetpin is activated. Joy.

Example: reading the identification register to see if the chip has powered up correctly. The magic value here is the 0x04770031 at the end.


Figuring all this out has brought me much further along the path – I am now almost ready to start executing flash commands on the target device. When the system can flash the MKL26 and MKL02 chips I am planning to move the codebase from the Arduino it lives on now to a set of dedicated small/cheap boards. One of these will be another USB-stick type PCB (plugs straight in to a USB port) with a simple row of programming pins meant to program microgameboys – possibly pogopin holder.

Still to be continued…

Reverse engineering SWD JTAG debugging/flashing protocol for Freescale chips

by Stijn Kuipers

One of the great breakthroughs of the Arduino has been that to get started, you only need the device itself and the software. The try/fail/try again cycle of development got reduced to altering your code and pressing run (again).

Most other platforms completely fail in this respect. Many chip-manufacturers have excellent and cheap try-out boards that are even pin compatible with the Arduino. However, while Arduino gets many things right – hardware choices and software choices are not two of them. The Atmel AVR series is easy but outdated. The Arduino “IDE” barely beats notepad.exe in functionality and project management.

Chip manufacturers almost invariably fail to recognize that having to struggle through ANYTHING between the compile button and the thing actually running your code is losing them enthusiasm, mindshare and ultimately customers. Because the manufacturers have no idea how to approach this part of the developer experience themselves, and apparently no inclination to get involved, they attempt to extend the Eclipse IDE (with endless pages of settings tabs) or try to become hardware compatible with Arduino.

So when I was recently asked if I would like to host a workshop programming games for the latest incarnation of the microgameboy, I had a problem! There is no real foolproof way to even talk to these chips! The official toolchain only supports a handful of programmer devices you have to attach separately using a tiny halfpitch connector that is not easy to find. This will not do for novices.

So part of my “this really should NOT be Rocket Science” quest has become this:

Make developing for a platform like the microgameboy EASY.

Stage one: creating a cheap tool to connect the microgameboy to your pc to update the program memory.

The chip I am using in the microgameboy is made by Freescale (the MKL02Z32 to be precise). This chip belongs to the ARM Cortex M0 family of devices. ARM is a big company that creates standard designs for chips. If you keep to the standard, software written for that standard will run on your device. Luckily, the Cortex standard includes a chapter on the debugging interface. The debugging interface allows anyone to inspect the inner state of the chip and poke around in its system memory. With some clever mangling (and the manual from Freescale – since this bit is outside the Cortex standard) you can trick the chip into updating/rewriting its own flash memory. This is what I’m going to do.

The first step of such an undertaking is (as usual): Homework.

Serial Wire Debug manual by ARM

“DAP Lite” manual by ARM

KL26 manual by Freescale
There are endless stacks of documents to be found that all refer to the debug interface in some way or other.. which always leads me to:

The second step of such an undertaking is (as usual): screw this shit..

I am not going to sit here reading 5000 pages of dense text. I’ll have a look at the actual data instead.

Last year I ordered a whole bunch of tools to deal with inspection of electrical signals. Amongst this set is an Open Workbench Logic Analyzer by GadgetFactory. It allows you to record a whole bunch of signals at the same time, at very high speeds. Using this device, I got this:

2015-02-02-0219 - Logic capture of the init sequence made by jlink

Saving this to a file and parsing the file for clock/data state transitions got me this huge array of bits:

data dump from jlink capture:

As you can see, the file contains some obvious patterns, creating diagonal lines in the data dump like 60’s wallpaper. By pressing enter at the diagonals, I separated the data dump into a more logical grouping of bits.

Spacing it better


Almost repetitive, I did not manage to create a straight line but again revealed a pattern in the data. I remembered reading about the packet layout somewhere on the first pages of the manuals. The packets should be 8bit – pause – 3bit – optional pause – 33 bit – optional pause. Let’s see how that fits the data:

Syncing it up

10100101 100 11101110001010001000001111010000 0
10100101 100 11101110001010001000001111010000 0
10000001 100 11011110000000000000000000000000 0
10010101 100 11000000000000000000000000000010 1
10110001 100 00000010000000000000000000001111 1
10001101 100 11000011110000000000000000000000 0
11111001 100 00000000000000000000000000000000 0
11101101 100 10001100000000001110111000100000 0
10111101 100 11000000000001000000000000001111 1
10001101 100 11000000000000000000000000000000 0
11000101 100 11010010000000000000000000110001 0
11010001 100 11000000000000010000000000000011 1
11111001 100 00000000000000000000000000000000 0
11110101 100 11000000000001111111111111111111 1
11010001 100 11000011111111000000000000000011 1
11111001 100 00000000000000000000000000000000 0
11111001 100 10110000000000000000000000000000 1
11111001 100 00001001000000000000000000000000 0
11111001 100 10100000000000000000000000000000 0
11110101 100 10001101000000000000000000000000 0
11010001 100 11001000000000010000000000000011 1
11111001 100 00000000000000000000000000000000 0
11110101 100 11000000000011111111111111111111 0
11010001 100 11000011111111100000000000000011 1
11111001 100 00000000000000000000000000000000 0
11111001 100 10110000000000000000000000000000 1
11111001 100 00001001000000000000000000000000 0
11111001 100 10100000000000000000000000000000 0
11110101 100 10001101000000000000000000000000 0
11010001 100 11000100000000010000000000000011 1
11111001 100 00000000000000000000000000000000 0
11110101 100 11000000000010111111000000001111 1

Way better again. Especially the centre column of 100s is looking good! This is the ACK-message of the SWD-standard.

Parsing it

To parse it I had to look at the manual again *sigh*. There are some bits in the protocol that allow the chip to do sanity-checking on the signal. Start bit, stop bit, park bit, parity bit – checking for these bits allowed me to sync the signal even better. More manual readings gave me the names of the various registers and bits. Read bit, write bit, debug bit, ACK, error and all that jazz.

Behold the interpreted bit stream of a commercial programming box talking to a Freescale-chip:

needle (0x0BC11477) in LSB first format: 11101110001010001000001111010000
found needle!

skipped: 11111111111111111111111111111111111111111111111111111111011110011110011111111111111111111111111111111111111111111111111111111
AP R ?????? skipped: 11111111111111111111111111111
DP R ID DP R ID 0x0000001E 10000001 100 01111000000000000000000000000000 0
DP W CTRLSTAT -> 0x50000000 10010101 100 00000000000000000000000000001010 1
DP R CTRLSTAT 0x000000F0 10001101 100 00001111000000000000000000000000 0
AP R DATAREAD AP R ?????? DP R RDBUFF 0x00000000 10001101 100 00000000000000000000000000000000 0
AP W CSW -> 0x23000012 11000101 100 01001000000000000000000011000100 0
AP W TARGET -> 0xF0002000 11010001 100 00000000000001000000000000001111 1
AP R DATAREAD AP R TARGET 0xF0000FF0 11010001 100 00001111111100000000000000001111 1

Download the code/program/dumps HERE.

Coding it

Now that I had captured a real bit of setup-code that actually performed the thing I needed to do on the chip, I could rewrite it! With some tweaking, head-banging and by using the logic analyser again to check if my own output matched the official output – I managed to get something working. Now I have a way to dump the contents of the memory of any Cortex M0 device with an enabled SWD subsystem:

uint32_t Peek2(uint32_t address)
Write(false, DP_W_ABORT,0x1e);
Write(false, DP_W_SELECT,0);
Write(true, AP_TAR, address);
Write(true, AP_CSW ,0x23000012 ) ; // , SIZE_32 | AUTOINC_SINGLE |( (uint32_t)1<< (uint32_t)24) | ( (uint32_t)1<< (uint32_t)25) | ( (uint32_t)1<< (uint32_t)29));
Read(true, AP_DRW);
return Read(false, DP_R_RDBUFF );

Now gives the following output on my MKL02Z32 test device:

SWD-DP id: 0x0BC11477
Cortex M0 identified!
D0342900 22002301 4288B410 2401D32C
42A10724 4281D204 0109D202 E7F8011B
42A100E4 4281D204 0049D202 E7F8005B

Up next: writing hex-files to the built-in flash memory. To be continued..

STM32F030F4P6 “AVR programmer” board

by Krzysztof Foltman

After the initial success with LPC810, I was ready to work on something with more memory and more I/O. Searching the Farnell catalogue for simple, low-cost and hobbyist-friendly MCUs, I found the tiny STM32F030F4P6 microcontroller made by ST Microelectronics.

The microcontroller

The chip is based on an ARM Cortex M0 core, has a 48 MHz clock, 16 KB ROM and 4 KB RAM and is available in a 20-pin 0.65mm TSSOP package.
Unlike the LPC chip, it provides plenty of I/O pins and a wider selection of peripherals, including SPI and timers. It is still an entry level chip. It has none of the advanced interfaces like USB or I2S present in its larger counterparts, but that gets reflected in price – it costs about 1.50 euro in single units.
The low price is particularly important for people without experience with soldering of relatively fine-pitch SMD packages – with some basic magnification they are not prohibitively difficult to solder, but getting a number of spares makes the whole learning process less stressful.

Several options are available to make sure that I would be able to use the new microcontroller. One of them involves using an SMD breakout board and a breadboard. However, I was skeptical of the ability to get the Serial Wire Debug programmer/debugger working with the breadboard – it usually requires fairly short wires and it is sensitive to signal quality issues. There is also the “dead bug” approach of gluing the IC upside down and soldering wires to it. This I rejected because of the soldering skills required. My easiest option involved using the first version of a 10x10cm matrix protoboard that arrived from China some time earlier.

Getting it working

After soldering the chip to the PCB, I needed a way to verify that it was working. The easiest way to achieve this was adding a decoupling capacitor and the SWD port, and using an STLink v2 programmer I got from Stijn to communicate with the chip. These programmers are easily available from eBay or Aliexpress, and work fine most of the time – the issues are usually resolved by holding the chip in reset manually. The example eBay link to get one of those programmers is Here

It took some trial-and-error to get adequate signal quality: long cables or having signal wires too close makes the communication unreliable at speeds that STLink is using. I found the correct configuration file to use with OpenOCD (32f0308discovery.cfg – it is included with OpenOCD).

Some time later, I had a working SWD set-up. On my system, and OpenOCD installed in /usr/local/, the example command to erase the flash and program an .elf file is:

sudo openocd -f /usr/local/share/openocd/scripts/board/32f0308discovery.cfg -c 'init' -c "program file.elf verify reset"

The next step involved writing a small program that blinks a LED, in order to make sure that the basics work. For this, I decided to use the code and the linker script for the LPC as a starting point. The memory addresses and the entire initialization code had to be changed to reflect the differences between platforms. And no more I2C or port expanders – this chip had enough I/O to do something that I could use in practice.

The project

At the time, I was trying to make a camera rail controller for a friend. It was meant to be a simple radio-operated stepper motor controller. That in itself could be a good opportunity to try a new microcontroller, if it wasn’t for the size constraints on the device. The 10x10cm prototyping board was too large to fit in the carriage of the device, and the smaller prototyping board was through-hole only. Also, the project didn’t really require a lot of processing power, an ATmega chip would work equally well.

A project based on ATmega is probably easiest to prototype using Arduino environment. But it’s not like it’s easy to buy an ATmega with bootloader burned in, at least in Ireland – it might involve a few days of waiting or paying a good chunk of money for an original Arduino from Maplin just to source the chip. So, what if I built a device to do exactly that – to take a blank ATmega and burn the Arduino bootloader into it. Sounds like a nice learning project to use the STM32 for!

The STM32 definitely had enough I/O pins and memory, and an SPI peripheral that could be used for communicating with the AVR In-Circuit Serial Programming port. The board had enough space to host a 28-pin ZIF socket, so I added that and some user interface elements – two LEDs (green and red) with suitable resistors and a reset button. The SPI-based ICSP code was easy enough to write based on Atmel’s documentation: IMG_20140911_224839 (1)the datasheet and the AVR910 application note about using the programming interfaces. Finding the correct version of the Arduino bootloader was slightly harder than I expected, but I had it all working after a single afternoon of coding. The slightly cleaned up version of the code and very rough documentation is available here

The remaining parts are:

  • the clock crystal and the load capacitors for the ATmega – but not for the STM32 as it runs off its own internal RC clock
  • the beeper – not strictly required but a nice addition. I didn’t dare to power the beeper directly from the microcontroller, so I used an 2N3904 transistor in common emitter mode as a switch.

The programmer code checks the device ID and uploads the bootloader, sets the correct fuses and then uploads a blinky example.

Now, any time I want to make a simple device based on an ATmega microcontrolller, I don’t need to buy a pre-programmed chip – I can get a blank one and pre-program it by simply inserting the chip into the board’s ZIF socket and press a button. After a while, I get a long “beep” and a green light, announcing the fact that the chip is functional and ready to use. Even better, this board provides a simple way to check an Atmega chip that I suspect to be damaged during one of my failed experiments: a series of beeps and a red light will remove any doubt.


This Is Not Rocket Science at all.

The tricky parts is soldering and SWD signal quality, and the initialization and the linker script. One needs to remember to enable all the clocks during start-up and to take care of the interrupts. Otherwise, there may be unexpected crashes when SysTick gets triggered and there is no ISR to call. Overall, this chip is easy to obtain (Farnell), inexpensive, relatively easy to use and less limited than the 8-pin LPC chip.

There are some comparable options from other manufacturers in the same market segment: LPC811 and LPC812 from NXP (the latter is also available in a 20-pin SOIC package with 1.27mm pin pitch, making it easier to solder). My preferred option was an STMicro part because of my prior experience with their Discovery boards and the fact that most of skills learned when working with a specific microcontroller are usable across their entire chip lines. Most of the time they use the same peripheral, so parts of the code can often be ported -with minimal changes- to their 180 MHz parts. NXP parts have several other advantages, the most important being the clear documentation they provide and their very flexible pin assignment matrix.

LPC810 board

by Krzysztof Foltman

This is my first successful attempt to do something with a 32-bit microprocessor in a circuit of my own making, instead of relying on commercially-available development boards. After some prior unsuccessful tries using STM32F051 and TQFP64 to DIP breakout boards, I decided to start over with something easier. Something that would not require SMD soldering skills, a custom board or any special tools. With all those requirements, I picked the only 32-bit microprocessor that is easily available in a hobbyist-friendly package: the NXP LPC810.

The microcontroller

This chip is an ARM Cortex M0+ core. The basic specs are rather modest:

  • up to 30 MHz clock (built in, no crystal or external oscillator required)
  • only 4KB of flash,
  • 1 KB of SRAM,
  • 6 pins of I/O.

It’s available in an 8-pin DIP package, which every electronics hobbyist should be familiar with – the same package is shared by many popular chips, operational amplifiers, headphone amplifiers, switching-mode power supply controllers and many others. It can even be used with a breadboard. Can’t get any easier!

The datasheet and the user manual, as well as some application notes and errata sheets are available at: See here

Programming the chip

For programming I used a simple USB-to-TTL-serial dongle – no special hardware is required to flash the device. Well… not all that special. The programming mode is activated by holding the PIO0_1 pin down during reset. In order to keep the ability to use that pin for other purposes during normal operation, I used a 2N3904 transistor to pull it down on the RTS signal from the serial dongle. So, depending on the state of the RTS line, pulsing DTR low would either run my program or enable program upload mode. The RTS and DTR can be controlled from the PC in software, so all the required modes – normal operation, normal reset and reset to programming mode – can be triggered. As an alternative, LPC810 also supports the Serial Wire Debug mode, which I haven’t tried yet with this particular chip.

The programming protocol is well documented and there is an existing example of using LPC810 with open tools, including a short programmer program and the linker script: See here

I/O expansion

The limited amount of I/O may be insufficient for any complex designs. Out of 8 pins, two pins are used for power, and three more have to be sacrificed for programming interface and the reset. So, in the end, only 3 GPIO pins are left. Even with the unusual ability to freely reassign some functions to any of the pins, there’s not much that can be done using so few pins.

One of the solutions involves adding a port expander, which I did. I decided to use Microchip’s MCP32008, an 8-bit expander using an I2C bus. This way, 2 data pins are used to provide up to 8 pins of general-purpose I/O, and the direction can be set for individual pins. If that’s not sufficient, more expanders can share the same bus. It is also possible to use MCP32016 – a 16-bit expander – for even more I/O on a single bus address. There are few more alternatives from other manufacturers, too: NXP’s PCF8574 is another popular choice.

In order to build the test device, I used one of the 5x5cm This Is Not Rocket Science matrix protoboards, which provide just enough space to fit the LPC810 and the MCP32008. It requires a bit of careful planning to fit all the components, but no special skills are required.

The hardest part of adding an I2C port expander was the electrical interface: open drain outputs with appropriate pull-ups for the bus. For clock it is possible to use the built in pull-up, but for data I had to add an external resistor. The software – both initialization part and the actual I2C transactions – is not particularly complicated. The documentation contains very detailed, step-by-step instructions to get each peripheral working, and related registers are often cross-references in the right places. This is very different from my experiences with STM32 series chips, where critical information is scattered between the reference manual, data sheet and possibly application notes and other documents. In STM32’s defense, those chips are also much more complex and powerful than LPC810, so a comparable level of detail would make the reference manual run into many more thousands of pages.


Overall, using both the LPC810 and the port expander is Not Rocket Science at all. Soldering is easy because of the DIP package, and it’s possible to use a socket to further reduce any thermal risks. The programming interface is a simple serial port + 2 control pins. Both chips are easy to get and inexpensive and documentation (link above) is clear, detailed and helpful.

This is as stress-free as it gets for building the first circuit based on an ARM Cortex M chip.

However, due to small memory, lack of DMA or analog inputs and very little I/O, the chip is of limited use.  It would probably do decent enough job for things like controlling relays or a character LCD from USB, at least when combined with a USB-to-serial dongle – but if I only needed that, in most cases a better choice would be an 8-bit AVR chip in an 8-pin package, like ATtiny85.
However, if I had to use a 32-bit microcontroller for such a task, I would probably pick this one.

The yellow-panel microgameboy in action

I’ve had some great fun with the microgameboy from the Yellow Panel.

See here:

Adding levels with a custom level editor:

And.. because you sortof have to… I made a small midi-file converter and attached a piezo beeper to a leftover GPIO pin…

Initially I had some trouble getting the screen to power up on 3.3v… Turns out my init-code was sending too early. After I added 200msec delay to wait for power stabilization, the init code ran as expected and turned on the internal chargepump. Hurrah! 0.49″ OLED screens are cute!

Panel merging tool progress

It has been quite a while since I had a chance to work on the tool – I have been too busy validating the output and playing with the microgameboy, but finally I’ve had the time to incorporate some bugfixes.

The biggest one on the list has been the import of gerber files generated by Diptrace..

See here:

UPDATE – Whoops, forgot that some boards still use holes! Not everything is SMT yet 😉

Fixed the diptrace drill exports too:

ld bug 6


The yellow panel – prototyping utilities.

The recent paneling experiment resulted in a nice new addition to our prototyping toolbox:

the yellow panel.

And the yellow panel..  Dirty dirty DIRTY soldermask (check topleft)And the other side.

The yellow panel contains:

  • Wolfsom SMT microphone breakout with small amplifier
  • QFN24-to-dip adapter
  • Freescale K20 TFT backpack (enhanced Teensy3.1 without the bootloaderchip)
  • Freescale KL02Z DIP breakout with microphone
  • USB-testpoint board in USBstick form
  • 0.49″ I2C OLED breakout board
  • 3.3v MIDI IO board
  • KL02Z micro-gameboy with 0.49″ OLED, microphone, switches and battery.
  • A keychain

The general theme for this board is “controlling stuff with audio while having sufficient visual feedback” I will be soldering a few of these over the next few weeks to test out various ways to get light/motion things synced up to music.

The microgameboy (screens have not arrived yet – they will get their own post once the hardware is complete):

IMG_1566 IMG_1565

Code upload works! Blinky fizzbuzz LEDs!


USB testpoint thing soldered in 2 configurations:

IMG_1564 IMG_1563

If you’d like to try these as well – get some at and ask us for schematics/bom/help on twitter!

Creating breakable PCB panels for

DirtyPCB seems to be the first small-prototyping-service that allows you to build panels with breaktabs. I had to try this! Soon after this thought I stumbled upon the great question of “how” – here I had all these folders full of gerberfiles for boards.. but the tools to panelize them were all very primitive, expensive, unhandy, unartistic etc… time to fix this!

Down here you can see the progress I’ve made from initial concept to usable tool.

The tool shall be released in (bin + source) full after I’ve gotten the second round of panels back from DirtyPCBs (I am not going to give away a tool that will create unproducable gerbers – I need to doublecheck everything)

Dealing with PCB artwork: procedural vector art tooling for Eagle

I like decorating PCBs. After I’ve spent ages designing and routing a schematic, I want it to look nice.

Sadly – this is very badly supported by most CAD software dealing with circuit boards. Some vector art import tools exist, but they are all very far removed from an ideal art workflow. The artist can’t really get direct visual feedback on the endresult.

To fix this, I’ve started writing some tools.
The first tool is a C# module that mimics the HTML5 Canvas2D vectorographics API but outputs scripts for Eagle CAD. Eagle can only deal with cutout-polygons on copper layers! This means that polygons with holes (like the letter O) will not have their insides emptied out if they are on the silk layer. Therefore, all polygons are converted to holeless triangle meshes. This allows the tool to import complex shapes. The first usage of this system is the text function. Any font file you have can safely be converted to a holeless polygon soup.

The second tool is a full Eagle board file importer, rasterizer and interpreter so you can extract relevant curves and use them to dynamically create graphics.

The third tool will integrate the first and the second tool with a code-editor window and a Lua backend. This should allow very fast “live coded” procedural board-art graphics. I am still working this.

Screenshots of the progress in chronological order:

The Eagle script generator starts to work:
Generating Vector Art for Eagle

Holes correctly converted to Eagle polygons (triangle soup):
Generating Vector Art for Eagle - 2

Importing Eagle board XML files starts to work (this is the PCB for the first LED badge):
Eagle Board Rendering In C#

More complex boards start to work (Goldfish R3 and Protoboard v2):
Eagle Board Rendering In C# - 2

01 - SMD Pad Rotation Correct!

Added the Eagle “ArcTo” curves -> automatically converted in to seperate line segments. (See the round corners – this is the Goldfish R3 connector board)
02 - Better layer abstractions and linewidths

And finally:  first glimpse of the combined board-reader-and-script-executing tool:
03 - Some random vectorart test

I am currently still perfecting the board-import/rendering function. After the integration of all the tools has been completed I will upload the code to our Github page.

Goldfish 4 UI board pictures

After some major drama in the workshop (leakages, iron dust cloud, broken floor, rainwater coming in, etc) I finally have some time to share a few progress pictures.

First and foremost: IT WORKS! The Goldfish R4 UI board can be used as a stand alone USB-MIDI controller! I had to do some workarounds, but it all seems to work now and I’ve used it together with a few DAWs. The current version has two modes: “control” mode and “xy” mode. In control mode you can use the encoders to control 6 MIDI-CC values at the same time, and press the encoders to select midichannels or different sets of CCs. The Goldfish keeps 36 controllers in memory, so you can see their value on the LED rings as soon as you switch between pages of CCs.
In xy mode you can control two MIDI-CC values at the same time by using the touchscreen. The left and rightmost encoders control which midi-CC is being sent by X or Y. This mode will get some “auto-LFO” options to spice things up.  

Here it is, showing the LED rings lighting up for the first time:
Ui in the dark

To save some board space, I’ve added mounting holes to re-use the Connector board from the Goldfish R3. This board provides MIDI plugs and stereo jacks. (the red PCB):
Backside fits a midiboard from fish R3


Development is easy: a standard Arduino-serial module plugs in to the board at the back:
Easy to program

Historic moment: First Fish! The hello-world of Goldfish development!
FIrst Fish

Lacking the time to lasercut a nice enclosure (see “major trouble” earlier 🙁 ) I just took 1 of the leftover PCBs and sandwiched the thing with some hex-standoffs to protect the insides:
Stacked with a second fish board - still needs a plexi casing
Up next – an extra Arpeggiator mode, one more revision of the PCB and some fluo-yellow lasercutting work for the casing!

To be continued!

LED Badges

Festival season is here!

And since we like glowsticks, but don’t like their nonrecyclable nature – we decided to go all out on a bunch of LED toys!


Each smiley features 20 LEDs in a Charlieplexed setup running on an Atmel Attiny85.

The smiley PCBs were done by They arrived VERY fast compared to the usual Chinese boardhouses. One week after ordering – with DHL shipping. The quality is exactly as advertised: Dirty, but good enough where it matters. The silkscreen drifted a bit here and there and the soldermask is not very strong (the copper shines through after some soldering) – BUT – they managed to do 150dpi bitmap silkscreen with no errors.

DirtyPCB smileys Smileys and Dirtystickers and Badge 1

Original design for comparison:

Smiley Design

Eagle Board and Schematic files, together with the code for the firmware will be uploaded shortly!



Exotic PCB production colours

The UI board for the Goldfish v4 is almost ready for production (post will follow soon) – so the search for fancy factories has begun!

I was quite charmed by the colours of this fish:


(found here:

Which led me to search for circuitboards with white soldermasks and red silkscreening. (or maybe a cheaper inverted option – red soldermask almost 100% covered by white silkscreen)

I found some (not so spectacular) samples:

and so far I found as a factory that seems to support this special option in small quantities.

Kezboards, umlauts and USB


While searching for some easy-to-add USB options for the new Goldfish development, I revisisted the V-USB package. This package allows you to add USB to any small microcontroller that can add an interrupt to a pinchange. Link:

While digging through earlier projects using this library, I found this amazing piece of “lets just fix this”ism:


This particular German got so upset about the lack of umlauts across the border that he made his own personal umlaut-device. A great reminder that while technology would be nowhere without imagination, it would not even exist without frustration.

Goldfish V4 UI panel – Encoder Rings

The FPGA-based Goldfish is still in constant flux. I decided it needed more encoders on the frontpanel, AND some visual feedback for the value of each of the encoders. Each encoder now has 16 LEDs around it to show the current value/meaning.

Apparently there are some suppliers that build complete rings (like Top-Up ), but I want to build my own rings first.

fishv4 - encoder setup


To build these rings, I wrote a small .NET tool to generate the scripts for Eagle. (If somebody has use for this or something like it, let us know on Twitter – I think it is too small/dirty to warrant its own github project – and it has been done before by others too)

The final puzzle to solve before the board can be routed and fabricated is the various ways I want the chips to talk to each other.

The interface board can be used as a standalone Arduino Mega (with TFT, touch and encoders) – using serial + reset to use the Arduino bootloader

The Freescale Kinetis K20 chip can upload new firmwares using this bootloader
The K20 usb-dfu bootloader is already in place and can be extended to allow passthrough to the FPGA and the Atmega

Now.. the UI board needs to talk to either the fpga or the mk20 based on the final firmware.. and the K20 might need to send commands to the video interface on the FPGA.. or on the UI board.. and the FPGA could send stuff to the audio codec… but the current goldfish code runs fine on the K20… so an optional bridge between the audio codec and the K20 might be handy to have as well… CHOICES!! if I can cleanly upgrade the K20 to a K22, the extra FPU performance will definately warrant codec-connection to that chip…

I’ll be back in the basement trying to decide what will happen. Building an open experimentation platform is all about enabling possibilities. But at some point I shall have to make concessions even before the first experiment.

To be continued!

Drafting the new Goldfish v4 boards

After playing with the FPGA boards for a while, I decided to completely overhaul the Goldfish board.

Spending a bit more time and money will make this box much more useful for the coming years of audiovisual experiments!

The current preliminary hardware feature set:

Spartan 6 LX9 FPGA
Freescale MK20 (or MK22) ARM Cortex M4 MCU
2 small 320×240 tft screens with AVR for touch handling (1 screen for the FPGA, 1 for the MK20)
4 to 6 encoders (no more buttons, the encoders also have a button if I need something pressed down 🙂 )
2 microsd slots (again one for each)
Wolfson audio codec with headphone, lineout and linein connected
VGA and HDMI output for the FPGA
MIDI ports
USB Host port
USB Client port

This all shall fit nicely sandwiched between 2 15x10cm PCBs

Progress so far:

goldfish 4 rough draft

Notes on FPGA board design

The happy Australian is at it again!

This time, he talks about designing boards with FPGAs and explains various things about using tiny BGA (ball grid array) chips. These 3x3mm FPGAs have 36 connector-balls underneath, spaced only 0.4mm apart. Making circuit boards for these chips is still a bit too intricate for most cheap factories, but when you consider how much smaller the final boards can be – maybe using a more expensive factory evens out after all!

New PCB order – small DIP protoboards

Krzysztof Foltman writes: “Another PCB sent to manufacturing. This time, it’s a universal 5x5cm protoboard. If you’re a beginner at electronics and want to try making a simple electronic circuit using standard through-the-hole components, it’s probably going to save you a lot of time. It’s compatible with DIL chips but also supports double-row pin headers quite nicely – something I missed in the cheap protoboards from ebay!”

fsm 5x5 protoboard

Download GERBER files.

Fun with FPGA chips: VHDL for VGA and WS2812b RGB LEDs

In the past few weeks, Stijn and Krzysztof have been playing with FPGA chips.

Progress has been made!

Stijn has created a servicable text-mode VGA setup:


Eventually, a component like this will be used for quick debugging of FPGA internals and/or GUI’s for the upcoming FPGA-hosting Goldfish device. For now it provides some fancy glitch visuals by twiddling with some on-board switches.

Krzysztof has added support for the WS2812b RGB LEDs to the FPGA code repository:
FSM-fpga ws2812b - less bright FSM-fpga ws2812b


WS2812b RGB LEDs are extremely convenient to add some colour to your projects. Each LED comes with a built in controller and you can chain any number of them together.

You can find the WS2812b VHDL code at the github repo here. The VGA code will be added once it is a bit more complete.

Progress on new protoboards

After using our V1 prototyping boards for a while we decided to design some improved versions to make future experiments easier.

This new board is focussed on mostly analog setups:

It features a switchable supply between USB and external power and an area for SOIC MCU’s and CODECs.

This board is an upgrade from the v1 protoboard:


– The connector placement has been improved.
– There is a new hole pattern and connector which makes it fit the Goldfish platform (giving instant access to graphical user interfaces to control experiments – or an FPGA daughterboard with HDMI for heavy lifting)
– There is dedicated space for an Atmel Attiny85 beside the TQFP area which can give a quick and dirty USB interface to whatever TQFP is on the protoboard. (using the VUSB library). It can also be used to generate reference signals or bootloader portknocking.

As soon as the new Goldfish mainboard + extension header has been finalized we will add these protoboards to the next batch to be sent to the PCB factory.

China the Difficult #3 Bazaar communication

China is usually perceived as difficult by Europeans: communication is impossible, constant daily hassle, unyielding culture and far too many people. We are here to experience the truth of it. If there is any prejudice in particular you would like us to check out – let us know.

 Communication on the Huaqiangbei Bazaar has not been too bad! There was one interaction where we were trying to purchase some buttons where all communication broke down (see the picture of our attempt to explain the concept of prototyping) but for the most part we have been doing fine.

Most of the people we meet speak some electronics related English, few of them speak enough English to have a small conversation while At a desk Connectoran equally small amount speak no English at all and simply ignore you. We have met no fluent English speakers on the Bazaar. However, on the Bazaar the language barrier is hardly a problem as the interaction you have is structured  – thank heavens – with numbers we can all understand. It’s basically a conversation via calculator. What you want is simple and expected. Point at a thing and then indicate how many of that you (might) want with pen/paper, a mobile device or on the calculator that everybody has behind their counter.

One such exchange with a very helpful Chinese woman who spoke no English at all, ended in a pack of jelly beans (FETs, power regulators, opamps, logic ICs etc > about 12 different kinds, 25-50 pieces of each) and the spontaneous exchanging of gifts. I got her pocket magnifier with LED and gave her a small Delfts blue kissing statue.

The communication in numbers mostly refers to one of two things: quantity or price. You can haggle over the price if you want but the margin for haggling is not of Arabian width and everything is really cheap already. We tried to get a lower price a few times just to test the concept – just typing in another number as a counter offer works fine. The biggest problem we had was that sometimes the quantities we asked for were too low – 50 pcs instead of 5000 pcs – and people simply would not sell to us. No worries, thank them and move on. There are many stalls that carry the same things and another one might have a small amount available. To us this was another reason not to haggle as selling smaller amounts seemed to be more of a hassle.

Roman visiting SepiCN and MakeBlock

blog written by Roman Buehler

Yesterday I temporarily separated from my beloved TINRS-friends and went to Zhuhai, where I met my other lovely friend John Wang. I and my brother met him for the first time in our China Trip 2011, when we crisscrossed China on a different kind of business adventure trip in only 12 days. Which was very stupid. And very stressful. And totally overkill. And the best holiday I have ever had. Except that now this China trip may even surpass my last one.
John drove me through a wonderful landscape of Chinese hills and seascapes as we went to see his new LED factory, SepiCN. He has some new products, one of them seems to be based on an idea that we discussed three years ago: a single 50x50cm, 40watts LED material, that illuminates not from a single point, but a wide area; it is not rim mounted LED’s which reflect upon a refractive glass, but the actual material illuminates, creating a diffuse light. AWESOMENESS!
We went on to discuss a few possibilities of what could be done with such lighting, and we’ll see what happens in the next few years.

Shenzhen 2 121Today TINRS had an appointment with the awesome people of Makeblock – WOOOHOOO! We visited their office and warehouse, where they showed us around and revealed the new parts they have in development. Shenzhen 2 142We even got to give them some input on a few specific things, some new parts that we thought could be very interesting to have.

Things that hopefully benefit Makeblock and everyone else that builds things with their products! We spent almost the entire morning there and did a small on-site shopping tour, where Stijn and Krzysztof selected quite a few parts that they were kind of missing in their arsenal of Makeblock materials.

After giving some gifts from the Netherlands and Switzerland, we went on to do the first fitting at our tailor Jeri C in Luohu Shopping Mall. The suits fit perfectly and are very comfortable.

We’ll have another busy day tomorrow, and we are going to visit the Seeed Studio people to see their awesome stuff live and in Technicolor!

Maker Faire Shenzhen – Palette

One of the things we saw on the Faire was Palette – a system of connectable blocks. Each block contains an interaction element – a knob, a slider, a button, a LED or a tiny screen. You can connect the blocks together using side connectors to build a customized control surface for your favourite software. They were showing if off Traktor, so we guess they are aiming at DJs). The software behind the blocks is aware of the layout you build with it. The Palette will show you this layout on screen so you can assign functions to all the blocks you have attached.

Shenzhen 071

In the Novena

At the Shenzhen Maker Faire  we spotted Bunnie and had ourselves a little chat. We explained the concept behind TINRS and he fully agreed with showing the world that stuff can be done. When he asked if we had a sticker we offered a choice selection of our cut outs and – to our surprise – he pulled out a new Novena and stuck us inside.

IMG_20140406_135555 IMG_20140406_135554

Check out the Novena laptop on Crowdsupply. All the design files for the Novena laptop are freely available (hardware and firmware!). This, combined with the fact that it features a powerful built-in FPGA chip for advanced interfacing makes it poised to be the new ultimate hacker/maker laptop. We can’t wait for this project get in to the hands of the hackercommunity to see what amazing reverse engineering tools they come up with. Read Bunnies blog here about the idea behind the laptop, the design decisions and its proces.

Cheers Bunnie for leading the way (and sticking us inside) – enjoy the stroopwafels.

Maker Faire Shenzhen – first impressions

We were already spotted on the platform of the metrostation “Are you coming for Maker Faire?” – “yes” – “Follow me, I show you”. It must be our geek-sjiek attitude..

Just out of the station there were many of the Maker-red-robots, drones in the air and a rather large Bumblebee (Transformers – yellow one). People were waiting for us with maps and kindness – everything has been really well marked and easy to find.

 MF Krzysztof grinning map MF guiding floor stickers

The Faire itself is bigger than we expected and outside (huh?). We were impressed by the guys from 3rd Ear, a threedimensional music experience. Also, a guy from Music Thing Modular – who builds modular synthesizer eurorack modules- gave us the PCBs for two of their modules: a spring reverb and a random sequencer. With a bit of luck we can find all the components we need for these on the markets later this week.

Other interesting things:
– Quitbit
– Bicycle lighting/tracking by Helios
– A bendable sailboat for cleaning the ocean
– Modular controller blocks

Will upload photo’s / video’s and more details later


FPGA repository started on GitHub

2100838-40Krzysztof Foltman has posted his FPGA efforts so far on GitHub!

Currently the codebase contains modules to deal with:

– key-matrix input
– LED output with brightness control
– Serial port input and output
– SPI flash
– Quad-SPI flash (4 times as fast as regular SPI)

No doubt this will grow fast.

See here:

The code has been tested on a Cyclone IV FPGA.


HDMI research for the Goldfish FPGA stack



HDMI video out should be well within reach of a Spartan 6 FPGA. I am still in the process of readin up and figuring out. Here are some of the more interesting reads I’ve found. Some are interesting in-depth, technical details, some are stories of people that did this before.


The Hackaday link opens up different other sources and has an interesting discussion. Hamsterworks is a more in-depth technincal commentary. Xilinx, the Spartan-manufacterer, has some helpful things to say – especially on how they intended the HDMI-protocol to be implemented on their chip:

1 HDMI port?
2 HDMI ports?
2 HDMI outputs and an HDMI input?
HDMI audio?
Maybe an extra FPGA of a different type/brand?

Two outputs would be more than enough to convert the Goldfishies into full music production battlestations.


Goldfish v4 – Board design progress

The Goldfish platform is slowly growing in scope and complexity.

The first three Goldfish designs focussed on getting components to work at all – microcontroller, audio codec, TFT screen and MIDI. The designs I’m working on right now will provide the processing power to do something more interesting than polyphonic ringtones.

The current plan is to move from the Freescale Kinetis K20 to the ST STM32F407VGT6 microcontroller and have an expansion header to host a whole number of other experiments. Most notably – a Spartan 6-with-HDMI board and version two of the prototyping board. This header and the new expansion boards will allow the main Goldfish PCB to become a central JTAG/Debugging environment for the next few months of audio and robotics experiments.

The main Goldfish PCB so far

Goldfish-STM32 with expander

The MCU board has a few extra features compared to Goldfish version 3 -> there is an extra microSD slot and a big row of expansion pins. USB and reset/program button have been moved to the other side to accomodate the different microcontroller pinout and give a decent place for the pin header. The routing is just a quick autorouter test to see if it would still be possible at all to route it. This design is nowhere near final.

The Spartan 6 FPGA board so far

Goldfish-FPGA stack

This is my first FPGA board. I started with the Papilio Pro schematic as a known-to-be-working configuration to start from. Power and IO have been moved around a bit, and the FTDIchip-JTAG setup might be replaced by just a JTAG header. The connected Goldfish microcontroller board should be capable of uploading data to the SPI flash later on anyway, replacing the need for the FTDIchip.

As soon as I can get my hands on a few PCB-mounted HDMI connectors I will add two or three to the board. I’ve been reading up on HDMI-FPGA combinations, and the Spartan-6 FPGA should easily be capable of hosting a few videostreams – even 1080i is within range! (there will be some separate posts on this subject)

Currently I’m putting further development of these boards on hold until I’ve been to the Shenzhen markets. I have no doubt I will find more interesting screens/buttons/leds/plugs to use there – so it makes little sense in finalizing the layouts before going to China.