libkakapo is now LGPL

After a bit of discussion, I came to the realisation that while I am keen to make sure that libkakapo is open source, I only care about how others improve the library, rather than what they do with it.

Pragmatically, I don’t mind if libkakapo was to be used by a closed-source project, so long as if the project made some great improvements that those changes ended up in the main source.

I had chosen GPL for the library more or less by default. But using GPL for the library means that your projects must be under the GPL as well – the linking clause requires it. This makes no sense for a library where I’m only interested in the drivers, not your project source.

LGPL means that both open source projects can use these drivers (which is good, because they can’t use Atmel’s ASF), and closed source projects can as well. The only obligation closed source projects have is to ensure they distribute the library source with their firmware (or generally make the library source available), and that any modifications to it must be included as well.

I think this is a nicer balance and I know a few people have asked about how to use this library on closed-source projects they’re being paid to develop for customers. I’m actually very supportive of that, because it indirectly funds improvements to the library. And that’s definitely a good thing.

So there we are: libkakapo is now LGPL.

Kakapo roadmap

Now that the first batch of boards has been shipped off and are starting to make their way out to customers, I thought I’d post a bit of a roadmap on things that I plan to work on around Kakapo.

First up is to resolve some of the outstanding major tickets on libkakapo. The main one to sort out is the various problems with clock.c, namely that is takes control of hardware when it shouldn’t (breaking the philosophy that you should determine how it’s used, not the framework taking it away from you) and that RTC support needs to be broken out into it’s own code.

Less urgent is to expand the number of supported modules. I’d like to get watchdog, type 2, 4, and 5 timers, and a few other things with better support. Modules present on the XMEGA D4 will be highest priority, but given I use libkakapo myself on other projects, support for some of their modules is useful to me at least.

Anyway, if you’d like some idea what I think is on my to-do list for libkakapo, have a look over the issue tracking.

I also need to write up more tutorials which build on the examples provided in the libkakapo source. Those examples actually serve as test suites as well, since they provide a quick way to check the libkakapo driver works as I expect. But they should really have documentation associated with them here about what they’re doing and why they work.

On the hardware front, the next major addition to the family will be a W5500-based Ethernet+microSD shield. This is the latest revision of the Ethernet/IP chip commonly used on Arduino Ethernet shields. The first prototypes of the PCB go off to be made this weekend. You’ll see more updates on that soon, I hope!

Lastly, thanks to everyone who has expressed interest, committed code, and generally supported getting Kakapo out and about. I really appreciate the effort people have put in.

Open Source Hardware and Kickstarter et al

You’ve designed a great widget or board, and it’s time to get some backers to turn it into a shipping product. Up goes a page on Kickstarter, and the questions and money start rolling in.

At some point, you might be asked whether your thing is going to be open source. Or, your intention is to make it open source when it ships. Great, there’s a lot of community interest in open source hardware and your Kickstarter goes well.

Only you can’t actually open source it, because it has a binary blob to support a chip. Or an NDA for the datasheets. Or you thought a published API was all you had to do. In some cases, you can’t because you didn’t understand what open source meant, and what people expected is far from what you’ve offered.

Hardware projects on Kickstarter are great, but I see too many with intentions or vague statements about open source that are straying close to misleading. Some variation from the promises made is to be expected, but making a major claim about a product (like saying it is or will be open source) is quite different.

You probably aren’t actually trying to fleece people. But as someone who actually makes Open Source Hardware, I feel like you might be treading into the area without playing fair. So before you trumpet that your widget is open source, here’s some things to think about.

Do you understand what Open Source means?

A very important first step is to make sure you are using the same meanings as everyone else. Have you read the OSHW definition, and definitions of various licenses for your firmware? Do you understand the implications of linking a binary blob into an otherwise open source piece of code? Some licenses may not allow you to do this (so-called “linking clause”).

Are you prepared to release all your design files in their original source form? It’s not sufficient to release compiled or generated files (eg, PCB gerbers), you need to provide the source used to create and edit the design.

Do your due-diligence before mentioning open source

This is a really basic thing, you should already have a good understanding about the parts you are using and what restrictions are in place for those parts. For example, if you need to sign an NDA to get the datasheet, there is a low chance you could reasonably meet Open Source.

Are the parts well documented enough to be easily replaced by alternatives? Do you need special toolchains or libraries with licenses that are incompatible with open source?

Have you chosen a license?

It can be hard to judge if you have given much thought to what open source means if you haven’t selected a license already.  You will need to consider a license for both the hardware design and the firmware or software involved in it.

License terms could exclude it from being considered as open source. For example, if you do not allow derivative works this does not meet the OSHW definition.


I really want to see more OSHW designs, and sites like Kickstarter are really good at getting them started. But don’t just hop on the open source bandwagon without thinking about it carefully. That just makes it harder for those of us following the rules to appear honest, and you’ll have disappointed customers too.

Quick shipping update

The first 16 Kakapo boards available to buy have been shipped to nicegear today. I still need to take proper product photos, but that doesn’t stop them working so it’s been down my priority list.

The next thing to work on is cleaning up libkakapo documentation inside the source and writing up more documentation here. I also need to submit a patch to avrdude to allow the avr109 programmer type to perform automatic reset. It’s not a huge patch, but I’m not sure when it’ll be merged.


First shipping batch almost complete!

A bit of a production update on the Kakapo. The first production batch of 16 boards has been completed, and are ready to pack and ship off to nicegear. There is also now a product page up so you can register to buy one before they arrive.

The next task is the final boxing. I had originally planned to use a set of black boxes with a sleeve, but they are quite large. They fit the boards plus the USB cable just fine, but I have been thinking about a more compact box.

BqsWn4YCEAAqwx1Playing around in Inkscape with a flat-box design and cutting from 160gsm card stock, I think I’ve come up with a nice compact box which is large enough for the board (in a bubble anti-static bag) and USB cable.

Now the question is, figuring out how to get lots of them made cheaply and easily. Hand-cut is fine for a prototype but it definitely won’t scale.

The pricing of things

The part about making electronics for people to buy that I really don’t do well is the price. Designing something, while it has some challenges, doesn’t stump me as hard as picking a price for the result.

Covering the obvious costs (ie, the components) is usually pretty easy. Covering my time is harder, since even for assembly time I don’t have a useful value for it. Not one I could reasonably apply.

There’s also some complexity in the cost of the components. I’m not making thousands or millions of these, so the prices for components are volatile and sensitive to quantity.

This then means the price for initial runs has to be just high enough to cover the big costs and a little more to help fund the next run, but not so high it won’t sell at all.

While I’d like to think I’m inventing new things, I am not and the market already has a price for many of these things. The heuristic of “cost times three” breaks down – I don’t have the same production capacity or immediate demand to make that viable against the market price.

A lot of the future is about getting better pricing on the parts I am using, and improving build processes so that it takes less time to do each build.

Funnily enough, I am working through the pricing for the Kakapo dev board, which is what prompted this post. Should be an announcement soon on what that looks like!

Kakapo production boards


The Kakapo production boards have arrived! These are a 2×2 panel (so a total of 4 boards within each panel) and the new silk has turned out fantastically well. Hackvana has supplied these boards and they have delivered very high quality PCBs again.

The new Kakapo logo was redone for this run, mostly to make it look better in white rather than the black I had originally planned. The drawing was redone in Inkscape, with cut-out lines for adding detail to the solid area. I think it’s turned out great, the picture doesn’t do justice to how fine the detail lines actually are.

I expect to start production on these at the weekend, starting with shipping the final configuration to Nicegear for feedback and then ramping up making the first run.

It’s also about time I worked out the pricing, I’m aiming for around the same as an Arduino Uno, at least as close as I can make it. It will depend on how much small runs (as it currently is being made) adds to the costs.

Kicad Nightly

Since the excellent CERN push and shove router has been pulled into mainline, I’ve been playing around with the KiCad nightlies. This is a bit bleeding edge, but given the rate of development (and, so far, mostly minor crashes) it’s been okay.

The push and shove router is just awesome. At the moment it still only exists as a special rendering mode, so it’s a bit cumbersome to switch between it and the rest of the functionality. I can’t wait for the OpenGL rendering CERN have added to be the default.

There’s a few really powerful changes straight off in the OpenGL mode. The first is the layer you’re working on is brought to the top, so you can much more easily see the related traces for the layer. This seems simple, but it makes a world of difference for running traces.

The push and shove router has some great features. Apart from being able to more intelligently follow where you are pushing the cursor, it will adjust tracks around the path you’re taking to meet design rules. This means tracks are gently pushed away to fit the new track, but only enough distance to ensure you are within DRC.

But you can also drag traces like never before. Hitting G on a trace allows you to just drag the trace section, so it adjusts how it connects to the other stationary parts, and adjusts other traces to suit how you are trying to push the segment around.


For example, in the screenshot above, I’ve just pulled the LED lines so they are spaced close, and clear of the mounting hole. It’s easy to just grab the angle section and pull it towards the capacitor to the left, and then pull the other lines to bring them together.

Similarly, I ran the USB D+/D- lines first, but then needed access to the two pins beside them. It’s easy to start a trace, and drop a via, with the lines being gently pushed out to suit.

KiCad was already allowing me a lot less instances of having to rip-up traces, but with the new router I’m doing so even less, and it’s much easier to get a really tight design done.


Support all the things

I started out libkakapo as a basic set of drivers for one specific board, with the intention that there would be little abstraction of the real hardware configuration. The point behind doing this is to allow users to step away from a heavily-abstracted framework like Arduino into something which exposes a bit more of how things work.

The drivers in libkakapo are intended to be boilerplate, rather than abstracting. But the early implementation of it was too focused on one specific board with one specific MCU. This resulted in using a simple integer for what instance of a specific digital interface we wanted (eg, the “first” USART was 0.. whatever “first” meant).

I wasn’t very happy with this, esp given “first” was unclear, as was second and so forth. It made no sense when I was not trying to hide many other details to hide the hardware names, but a solution to make it friendly while fast wasn’t forth coming quickly.

The fast thing is important. If you look at many abstracted interfaces, they boil down to mapping between a friendly name or identifier and the actual resource. digitalWrite() in Arduino hides the real port and pin names, so it needs mappings to deal with this.

If a mapping is inefficient, that’s fine in setup but a real problem on regularly called code, especially in interrupts. Mapping from a number to a port is easy, but mapping a port to a number is harder. It seemed to boil down to an expensive series of if statements or an excessive number of defines or something.

I had kicked the idea of fixing that to touch, and got on with other drivers. But recently during beta testing with Nicegear, it’s become a bit more obvious the simple integer doesn’t work. I’ve built a beta board for them with a different MCU from the expected production run, using a 128A4U instead of a 64D4. The board physically supports it, so it was an easy thing to do.

But now libkakapo is stuck, do I fork it for diferent MCUs or support many, and then there’s this problem with that simple integer.

In the end, the best choice was to go back to what decisions I was making about abstraction. Exposing the hardware names was the right thing, I just needed a way to map it efficiently in both directions.

The solution was to use an enum type which listed all the hardware names (actually a similar name, so it wouldn’t overlap with avr-libc defines), and use this as an index into an array. The whole explanation is in this github ticket.

The upshot is we get to use hardware names, and the ISRs which depend on it can select the right port handler immediately, instead of a long series of if statements. Now it looks a lot better and an annoying bit of abstraction is removed. And it’s much easier to support almost any XMEGA MCU now.


Things are never done

I don’t think I’ve designed a single electronics project that I really consider to be “done”.  At times, I think the constant re-working of designs is unhelpful, esp when there are a few people who are very keen to see a finished product.

The thing is, every time I go back to looking at how the design of something is, I find another iteration that improves the capabilities, makes it easier to build, or makes it less expensive.

Take for example the BBPSU. It’s now on revision 3 or 4 (I forget actually, “2.0″ is not technically true) and there are still likely to be more revisions. It’s not that it’s a bad product, but it can be improved on.

For example, I’ve used PTH DC jacks with large round holes to solder them to for a long time. DC jacks have slots, but slots can be difficult depending on the board house and a load of other factors. The fallback for them is large holes. They’re a pain to solder.

Similarly, using a P-Channel FET for the reverse polarity protection is a neat idea, but as the footprint I chose is a little tight it can cause production problems. A diode isn’t as compact but it’s got a lot more tolerance in it and at the current ranges of the BBPSU, it’s not that bad.

The regs were SOT-223 for compactness, but it’s become more obvious that it’s not the best package for the 5V regulator – which leaks a lot of heat. More recent boards have used a D-PAK version of the same regulator, which sinks heat much better.

As I said, there’s nothing actually wrong with the BBPSU, it works and does what it says on the tin. As you can see from the rambling above, it also doesn’t mean it’s beyond being improved.

The challenge I now find myself in is picking the right time to call it “done enough” and produce some devices for people to use, before going for another iteration. That’s still something I’m working on.

Tech and Electronics