Category Archives: Projects

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:

This 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!

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.

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!

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.

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!

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.

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.

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.

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!

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.