Tag Archives: kakapo

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.

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.

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.

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.

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.

Kakapo status update

Hi all.

So it seems like there’s been a bit of interest in the Kakapo since I sent off the beta version to Nicegear. That’s really awesome. So I thought I’d post a quick update about where I’m up to with production.

Firstly, the beta testing has been valuable and libkakapo has been worked on by both myself, and hads at Nicegear. This is critical to get as many bugs out in the libraries you may be leaning on heavily to make those first steps to lower-level code.

The final production panels have already been ordered, and will soon be on their way to me here in NZ. I’ll post an update when they arrive. The parts needed to produce an initial run of 25 have also arrived, so we’re good to go on the parts front.

So hang tight, there is progress being made, and we’ll have them shipping real soon now!

libkakapo and Arduino

A long time ago when I started working on the Kakapo design, I had some specific goals in mind. Arduino is an excellent platform, but it has been accused of hiding too much from the user and doing so by burning cycles – on an already constrained platform.

I sort of get where people are coming from, digitalWrite() is very piggy, slow, and hides things which should be part of an understanding of state. But by the same token, I think people have to start somewhere.

That said, it doesn’t mean they have to stay there. So one of the major goals of Kakapo was an intermediate board with boilerplate drivers but very little in the way of wholesale abstraction. The intention is you learn more about avr-libc and embedded dev along the way. I also admit I have a bias against C++ in embedded at this scale, and prefer pure C.

So that’s where libkakapo comes in. It provide some drivers for hardware to get you started, but doesn’t expose quite everything. It doesn’t hide several details. For example, SPI timing is expressed as division of the peripheral clock and not a bitrate, because that’s how the hardware works and how the datasheets describe it.

I think it’s also hard to follow the Arduino stack, the IDE is quite complex and the way it builds things is interesting but also complex. The libraries have a lot of different hardware to support. libkakapo is focussed on just one board, and simple boilerplate. It’s heavily commended and I think easier to read.

Now that the first board is out for beta testing, I’m getting a lot of good feedback on what is needed from a basic library that isn’t going down the path of re-implementing digitalWrite(). This I think will really improve the usability out of the box when you want to jump further on from the Arduino IDE.