Week note — 29/17

This is the first of the week notes. The purpose is two-fold; 1) document trials and tribulations and 2) motivate myself in to getting stuff done because I know I’ll have to write about it. They will be mostly centred around the product I am designing/prototyping/making. Hopefully an interesting mix of product design, electronics, programming and branding.

The week started with building a custom microcontroller-on-a-board. It had a few key goals; to prove I could make a custom board using the exact part number I’ve chosen to base the product on (an EFM32LG332, I know you are wondering) and to have something to prototype properly with. The starter kit, although the same family of microcontroller, uses a different larger IC. I’d rather use the actual part number I plan to use. It’s mostly because I am nervous about choosing pins and ports. It’s not quite as straight forward as Arduino world where you can say for certain what a pin does and it’s already done for you. You have to do that configuration yourself, and things can clash if you‘re not careful or experienced. Typically you have to write tens of lines of code to configure peripherals. So being able to connect stuff to exact ports and pins mitigates the risk of a silly mistake. I expect this will be something to look back on with a learned smile.

The board went together with relative ease. There are not many components, though it’s the first time I’ve used tiny 06 packages in my designs. In the end, there’s little practical difference to their bigger 12 sized brothers I’ve been using for the DIY kits. The main downside is that you can’t see what values they are easily.

The board is programmed from the starter kit. Just jump a few wires from a 20-pin header to the custom board and configure the IDE to point at an external MCU not the one on the starter kit. I followed an article in the knowledge base and had a hello world LED lit up straight away. I was surprised and should probably trust myself to do such simple things now.

Later in the week, a few prototype boards arrived for the various elements of the product. Instead of breadboarding everything I’ve decided to modularise the design and make PCBs. This feels like it’ll be a bit more robust. The whole thing would probably go over ten breadboards, and there are a lot of repeating components. I’ve been drawing up and uploading the different modules over a few weeks, so they’re now trickling in from the PCB prototype place I use. Boards usually take about two weeks to arrive from upload, which isn’t too bad considering they come from the USA.

The first board built is the primary “display” element. It consists of eight RGB LEDs driven from three 8-bit shift registers. Each shift register controls a different colour and also has PWM control over brightness. It’s simple and it works. The shift registers are controlled over a serial interface called SPI, which I had already got working on the starter kit. I wrote the display driver code and added in some colour correction for when colours mix. Each element of the RGB LED (red, green and blue) has different electrical and luminosity characteristics, so you need to compensate for that. There is a single byte for each colour and it just compares those bytes to decide if the same LED is lit up and adjusts the PWM. Obviously, this doesn’t work for multiple LEDs but I’m not doing that anyway, yet.

To test the display code I started to write the sequencer code. This was fairly straight forward as I’ve written code for a sequencer before. As everything is in C and not C++ I have had to learn how to use structs instead of classes. Fairly easy, just a bit messier. I got fairly carried away and have implemented nearly everything needed for the sequencer to run. It’ll be a different matter when it has live controls rather than a virtual clock and presets in code, and I have to catch all the edge cases that make it break.

typedef struct sequencer {
 int currStep;
} sequencer;
sequencer seq1 = {0};
void clock(sequencer* seq) {

As per every week, I went though a crisis of scope-creep and worry about various aspects of the product. It’s usually the paradoxical “is it too big?” and “should I add x, y or z”. This week was mostly discussing quantising with Alex. I’ve come to the conclusion that it needs one, whether or not it should be built in or as an expansion board is still up for grabs. Most certainly it should have a jumper on the back to at least set it to do chromatic quantising. The main outcome is that I’ve sketched out how it will work and it’s totally doable either way. I also sent off to fab the design for one expansion module that has always been on the cards — which for sure will be an expansion module and not built-in as it’s really quite large.

Something to compliment the electronics and code is the fun of branding. Last week I got a custom rubber stamp and this week I’ve been finding things to stamp. And buying too many ink pads. I realise that it doesn’t say the brand name — but I’ve decided I’m going straight for the well-established form of branding and skipping the bit where people have to actually learn what your logo refers to. Maybe I need another stamp for the name?

Next week I plan to build up the next prototype board, I already have it but am missing an IC for it. Other prototype boards will also arrive. Plus I need to draw up the main controls prototype board and quantiser board and send those off to fab.

Feedback on these notes is very welcome. Is it too techy? More explanations needed? And if you want some kind of stamped goods, just let me know.