Category Archives: Projects

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.

Kakapo production boards

20140610_181047

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.

bbpsu-2.0-running

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.

IMG_20140508_193252

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-feature

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.

kakapo-beta-box

Kakapo beta testing

Well, I’ve finally shipped off the first beta test unit of the Kakapo dev board to nicegear. This is mostly to shake out what I haven’t resolved yet, get valuable feedback on the design and packaging, and a bit of time to prepare some tutorials and documentation.

Over the next few weeks, I hope to fill out that last part a lot more. My intention was always to make this a stepping stone away from the Arduino by focussing on boilerplate drivers and a heavy emphasis on the way the datasheets and avr-libc are written.

kakapo-pogopins

It’s also been a chance to develop some new ideas on production processes. The example to the left is a pogo-pins programming header that uses normal fixed pin headers to keep it in place. Frees up the hands, and allows me to program a board easily. But it’s also used to align the headers when soldering them down, and it’s a protoshield for end users!

Kicad Redux

It’s been a few months now since I did the big switch from Eagle to Kicad, so I thought I’d post a few updates on how the process of switching has gone.

I’ve had to go back a few times to dig old designs out of Eagle, and I can’t say that I really miss any features of Eagle. I’ve gotten very used to all the little graphical glitches of Kicad so these don’t bother me as much any more. The designs have definitely gotten a lot better since switching as well.

I commented on the first post about switching I felt Eagle had a better connection between the board and the schematic, but I have to withdraw some of that. There’s a few features of Kicad which make a lot more sense now and the connection between the two isn’t as bad as I first thought.

kicad-dual-head

For example, it’s very easy in Kicad to have both the PCB and schematic up in separate windows on different displays (something I do rather constantly), and this helps make the two feel connected. Highlighting a component on the PCB side will actually cause the schematic to leap and centre that component, so you can see the context both in the board and the schematic very quickly.

Schematic hierarchies also work really well for breaking a design up into managable chunks. In the image below, I’ve buried the USB and power sections in their own schematic pages, so it’s easy to work on just the relevant parts of the board.

kicad-heirachy

 

During early PCB layout, the “get footprint” tool is fantastically useful. Hit “T” and enter a reference, and it grabs that part for moving. This makes it far easier to do the initial rough layout with parts in the right order to do things, and makes it easier to find related parts.

The workflow I’ve gotten very used to now. It’s an ingrained routine of change things in schemtic, generate netlist (when annotation usually pops up), adjust the footprints needed in the footprint assignment, and then reload the netlist in the PCB view. It’s not quite as fluid as the live connection Eagle has, but it’s close enough I’m much more comfortable with it now.

I’m very pleased with the native image to PCB import feature, although it could do with part scaling as currently this really depends on some external tools to get right. But being able to nicely import artwork into the silk as an explicit module is a big improvement over those capabilities in Eagle.

There are still things I’m not happy with about Kicad, but these are more general problems and not enough of a reason to switch back, I genuinely can’t see myself switching back to Eagle at all really.

Things that could be better:

  • You can’t just drop GND vias or even just vias in a spot, at least if you can I haven’t found how
  • The graphical glitches sometimes can be a bit misleading, is that an extra trace or just noise?
  • If you redraw a section of track, it will remove the old section only about 50% of the time. It’s not clear to me why it does or doesn’t at any given moment.
  • In a schematic, if a pin is not on the grid, you can’t connect to it. It would be nice if the wires could “snap” to the pin even if it’s off-grid
  • BOM generation is a bit of a hack and there doesn’t seem to be an easy way to generate a consolidated BOM (ie, qty 4 of part X with references R1, R2, R3, R4).
  • Refilling zones doesn’t appear to have a hot-key. Which means you are forever switching back to the zone tool to refill, and then back again. Grrrr.

All in all, I’m very happy with Kicad and have pushed out about 4 boards now using it, all of which have been just great, and significantly better than previous efforts.

w5500-beakout-instagram(another board designed in Kicad)

 

BBPSU 2.0 available now!

A quick note to report version 2.0 of the Breadboard PSU is now available from Nicegear.

They come fully assembled, so you can rip it out of the package and drop it straight into your solderless breadboard to get started.

This version, despite being significantly smaller is actually just as capable as the old version, and still supports custom voltages if you need them. They can also be sourced without any connectors or pins installed, if you are using them for a permanent install. Best to contact Nicegear if you’d like those options.

And for those of you looking for a way to power your Arduino from a higher voltage source, check out our Wide DC Supply Shield Kit which makes it easy and safe to use a DC input between 9 and 37V DC. No excessive heat or exploding capacitors on your Arduino!

More new PCBs

With a new job looming (actually, already started), it is the best time to start working on electronics projects again. No, I don’t know how that works either.

NTP Server 1.5 board has been made and now awaits testing. It’s pictured below:

The changes are documented on the history page. The two major changes are using a switch-mode power supply instead of a linear one, and removing some external flash that is no longer required now I have a working XBoot setup.

The other board to arrive is the first cut at an Arduino clone based on an XMEGA 64-pin chip. There are a few XMEGA based clones floating around, this one is mostly focussed on trying to support a wide range of 64-pin XMEGA chips and provide some extra hardware to get you started. This board is pictured below:

These are the first boards I’ve had made by the people at Hackvana. The build quality is good, with very clear silk and all drills have been correct. (I’ve had boards from other places with incorrect drills). In particular, despite the very small silk text for component labels (which, I should really have made a lower weight), they’re all clear enough to be read. Tented vias also came through just fine, and Hackvana will accept two drill files for plated and unplated holes, if you prefer to not plate mounting holes.

We’ll see how the boards perform when I get around to completing an assembly, but they look pretty good so far!

A busy few weeks

Rather unexpectedly, it’s been a busy few weeks on the electronics front. The result has been two new projects show up, and actual real honest progress on two other projects!

The two new designs are shields for an Arduino-based project that the great people at Nicegear are working on. One is a isolated driver and input shield, that allows switching higher voltages than the little Arduino can normally drive at much higher currents; the other is a compact switch-mode supply shield to allow you to run an Arduino off higher voltages without generating large amounts of heat.

The driver shield has been already built and tested by Nicegear, and works mostly as expected. There has been a revision to it already to include more voltage input options for the Arduino on the same shield as the drivers and input isolation. The original revision was limited to 12V for powering the Arduino.

The switch-mode supply shield hasn’t been built or tested just yet, but I’ve breadboarded the design so I am reasonably certain it’s going to work okay.

On the existing projects front, both the XMEGA-based Arduino clone and my long term NTP Server project have new boards ordered and on the way. The XMEGA board turned out pretty well I think, I’m hopeful with upcoming multiarch support in the Arduino IDE to see better support for such boards. On aspect about this board is rather than overloading the shield header with a bunch of useful but in-the-way peripherals, all additional hardware is conflict-free and allows full use of all the shield pins.

For example, the board includes pads for an 8-pin SOIC SPI flash or SRAM chip. While the SPI interface is wired to the usual Arduino pins for this (10-13), the CS line for the chip is on a discrete pin not shared with any of the shield pins. The same is true of extra LEDs, 32.768kHz watch crystal for the RTC, etc.

The NTP server had a minor polish up from the last post on it, but otherwise it’s down to just getting the board made and see if I’ve nailed down the last remaining issues. The software side of this is looking almost complete enough to start field testing!