BBPSU 3.0 on the way!

It’s been a few years since I did a major revision of the Breadboard PSU, but that time has come. Below is a render of the most recent revision about to enter manufacture:

bbpsu30This version includes better thermal performance for the 5V regulator, by switching to a D-PAK (TO-252) package. This has more surface area and a larger heat sink area on the board itself, and provides a more stable surface to install a small heatsink.

The other major change is that rather than driving the 3.3V regulator directly off the DC input, it is chained off the 5V regulator. This actually allows more current to be drawn from the 3.3V regulator, since it has a smaller voltage drop to regulate down to. This does mean the total output is limited by the 5V regulator, but it is a considerable improvement in what you can draw from the 3.3V rail.

The remaining changes are mostly cosmetic. This happens to be the first version I’ve used Kicad for, which is unexpected to me given I’ve used Kicad on a number of projects now!

These should be available soon from!


Kakapo net+sd shield

Those of you who have been following my personal twitter account will have seen endless pictures of the shiny new net+sd shield for the Kakapo.


There’s plenty of shields with ethernet and SD card support, but there’s a few different things about this one compared to others:

  • The latest WizNet W5500 hardware TCP/IP chip
    • 32kB SRAM, 8 sockets
    • Automatic circular buffer management
    • Compact 48-pin LQFP chip
    • SPI support up to 80MHz
    • Variable length transfers to reduce overhead
    • 10/100 Full and Half Duplex support
  • Built-in I2C MAC address EEPROM
  • MicroSD card socket
  • W5500 chip is automatically reset by Kakapo reset sources
  • W5500 and SD card MISO shield pin is buffered; does not drive pin at all when deselected
  • Four status LEDs: Link, Activity, 100M and Full Duplex
  • Jumpers for easy disable/enable features; no soldering to free shield pins from features not required!
    • Jumpers for W5500 !CS line and !INT lines
    • Jumper for SD card !CS line
    • Jumper for I2C 4.7k pull-up resistors
    • Opening !CS jumpers enforces part remains deselected
  • MAC address sticker for easy identification
  • All pins used explained on the bottom side of the shield
  • Same pins used as the common Arduino Ethernet shield

The shield is going through some final testing, and will be available soon!

API changes and new stuff coming

Kakapo API updates first. The SPI API was changed yet again to include providing the byte to send when stuffing the TX side with irrelevant data. The “txdummy” param to spi_conf() configures what the byte should be when stuffing.

This is mostly useful for dealing with SD cards over SPI, as to push them into SPI mode you need to issue >=74 SCK cycles with its data-in pin high. Stuffing the output with 0xff does the trick for this.

Since I’ve mentioned SD cards, the Net+SD shield is nearly complete and should see the first prototype ordered next week. This includes a WizNet W5500 TCP/IP chip and a microSD card socket.

The shield is roughly similar to the official Arduino Ethernet shields (using the same pins as that shield), but includes a MAC EEPROM on I2C and all used pins can be disabled with simple jumpers. This means you can use just the Ethernet or SD functions of the board. It also includes pull-up resistors on the I2C port, with a jumper to disable them if you already have pull-ups somewhere else.

To ensure the W5500 reset is consistent with the main Kakapo board, there is a buffered reset handler. The output pins of both the SD card and the W5500 are also buffered and controlled by the CS pin for each function to ensure no disturbance of header pins they are connected to.

The W5500 is an upgraded version of the W5100 featured on Arduino official shields. It includes 32k SRAM (up from 16), 8 sockets (up from 4), and allows variable length transfers (instead of fixed 1, 2 or 4 byte transfers). The latter means we can push larger blocks of data into or pull out of sockets with less overhead.

Since I know people will want to hit the ground running, a basic driver for the W5500 for TCP client and UDP in both directions has been pushed into libkakapo. There is a stub which still needs to be completed for TCP server support. The TCP code supports using standard IO functions with TCP connections, like the USART driver.

At this point, I’m still working on the SD card support, and it’s likely the board will be released before this support is completed in libkakapo. The W5500 driver also still uses fixed IP configuration, a DHCP client and other high-level protocols (like DNS) are still to come.

Breadboard PSU Feedback

The time has come to start considering design changes for one of my more commonly shipped projects: The Breadboard PSU. It’s had a few revisions in the time I’ve been making them, most recently moving towards panelisation and automation of more of the build.

Feedback is one of the things which helps me make better things. So the point of this post is to invite people who have bought, used, or seen the PSU to give feedback about it.

At the moment, I have a few changes in the back of my head for the next revision:

  • The 3.3V reg is fed directly from the input voltage. This means it really has trouble supplying much current at all (it’s very thermal limited, since it’s a linear regulator). This should be moved to be fed from the 5V side.
  • The 5V regulator is now going to handle the most load and therefore leak the most heat. The SOT-223 package is not the best for thermal performance, I’d like to re-arrange it for a D-PAK version instead.
  • D-PAK would also allow a more comfortable fit for a heatsink, probably a small 8x8mm one just to try to help improve thermal performance.
  • The MOSFET on the input side for reverse polarity is great for low loss, but is much less critical than I originally felt. It’s slightly less area than a diode. Given the other changes, I’ll probably switch this back to a diode.
  • The DC jack is large and annoying. Either needs to be SMD mount, or possibly take the plunge on JST and include a JST to DC jack cable.

Anyway, feedback is very welcome and I’m happy to answer any questions!

libkakapo recent changes

Hi all, a quick post about some recent changes in libkakapo.

Firstly, on the major API changes, there is a different SPI API than existed previously. It now accepts arbitrary length buffers for bytes to TX and fill with RX. As TX always happens before RX, you can supply the same pointer if you wish.

The API also allows either of these buffers to be provided as NULL, which means it will either generate 0’s on TX (which is how a read-only SPI transaction works), or discard RX bytes.

In the old API, you would do this to write a 128 byte stream:

uint8_t buf[128], n;

for (n = 0; n < 128; n++) {

On the surface, this doesn't seem like it's that bad, but this involves making 128 function calls to transmit each byte!

Instead, in the new API, you can do this:

uint8_t buf[128];


Since we're just writing, we can just toss the RX, and throw the SPI driver the whole buffer to churn through. This eventually will allow us to decide if we want to set up DMA for the transaction, which would speed up transfers a little more.

The other changes are more minor:

  • The ringbuffer utility code now uses lengths for buffers, instead of masks. Internally, we still use masks and enforce power-of-two lengths for the ringbuffer, but the API feels more natural.
  • Added a watchdog driver, since the avr-libc one is a little inconsistent with XMEGA hardware. This has not been completely tested (I still need to write a test case for it).
  • GCC was generating warnings for the hook functions in timer.c, these have been silenced properly. (H/T: hads)
  • timer.c also was not returning the same error codes consistent with other drivers, so these have been fixed up.
  • clock.c (the system/peripheral clock configuration API) now returns a unique error code for an oscillator not being ready.

So there we are, that's the last couple of weeks on the libkakapo front!

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.

Tech and Electronics