Category Archives: Opinion

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.

Conclusion

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 look: XYC X-26Y Mini PC

A quick jot of some notes about the XYC X-26Y from nicegear:

The good:

  • OpenELEC on it just works. And by works I mean everything works. Wifi card, HD video playback, even HD Audio over HDMI works. All I had to do was point audio at HDMI instead of analog out in XBMC.
  • XBMC UI doesn’t drag much at all. I’ve loaded it up with Aeon Nox (which is quite pretty, and therefore quite hungry) and it is just fine.
  • Price. Considering it includes a wifi card, 2GB of RAM, and a 32GB SSD, the price is really excellent.
  • Fanless. Yep, it’s completely silent with the SSD in it. It wouldn’t be if  you installed a spinner, but out of the box it’s indeed silent.
  • Build quality looks good. Feels solid. I haven’t opened it up but I’m not expecting it to be anything bad.
  • It’s quite wide/deep but moderately thin. So it’s pretty good for size overall.
  • GigE. Excellent!

The bad:

  • Fanless means this thing is not cool. It’s not just warm to the touch, it’s noticeably hot. Not so hot you can’t touch it at all, but it’s not comfortable after a pretty short amount of time. But that’s the trade-off, right?

The indifferent

  • USB ports are upside down. At least I’m not plugging stuff in often.
  • Box it came it bears no resemblance at all to contents, so don’t be alarmed by the ATOM and ION2 logos on the outside, this is an Ivy Bridge Celeron and QS77 chipset.
  • An IR window would be cool, but it’s not a big deal.
  • Wireless antenna placement is on one of the sides, which isn’t a big deal I guess. Would have been hard to cram it into the back as thin as it is.
  • No eSATA, which would be nice for expanding storage beyond the mSATA and 2.5″ internal drive bay.

All in all, I’m pretty happy with the box and how it has performed.

Invisible software

The recent decision by the government to flip-flop on the wording of changes to the Patents Bill has pushed the concept of “embedded” software back into the limelight. The whole concept that there is an obvious or well defined line between “software” and “embedded software” is nonsense, but we seem to be persisting with this idea.

If you’ve read this blog before, you’ll have noticed I am spending a bit of time writing code for a few projects that could be called “embedded”. Actually, I don’t personally see them that way at all, they are just code running on general purpose CPUs with some restricted hardware configuration. To me, they are no different in concept to a PC or any other general purpose CPU.

That is, after all, the definition of software: instructions executed by a general purpose machine. Hardware is not a set of discrete abstracted instructions with a concept of execution. The line is very sharp between those two realms.

The arguments seem to boil down to an idea that if the software is invisible enough (to whom is not defined) then it is “embedded”. For example, recently I spent some time with a large aircraft manufacturer discussing some aspects of their aircraft systems. One component was described as an “embedded” security appliance. It actually turned out to be a Linux machine – a general purpose, commonly used OS – on merely a slightly restricted and custom board.

Does a general purpose OS, running on special hardware, but otherwise no different to any other implementation of that OS, constitute “embedded” in any meaningful way?

Invisible to some is not enough to consider it to be some special class of software, because it’s still software. Another example is the fact that microcontrollers (general purpose CPUs in a very compact form) have reached a price point and size where they are suitable replacements for traditional logic designs. So, every headphone cable shipped with an iPhone or an iPod contains a CPU: it’s in the case with the control buttons in the cord. It’s “invisible”, so therefore it’s now a special class of software, even though it is just software?

Software should not be patentable. Period. How invisible it is, or whatever organisation structure is around how it’s written is irrelevant. Software is not different merely because it’s hidden from view.

Where this becomes complicated is inventions which depend on general purpose CPUs and code. The line should be explicitly stated in the bill: an invention may depend on such a thing but patent protection does not apply to any software involved in the invention, regardless of the form that takes.

Anything else is open to be gamed by industry to create effective patent controls on software, and “embedded” is fluid enough that you can regard all software as embedded in some way.

Just another dev board

Lately it seems like a bunch of vendors have been pushing out more dev boards in the wake of the success of the Arduino platform. Actually, this isn’t quite true, there have always been dev boards out there. The boards were mostly produced by the chip makers themselves, and were fairly expensive compared to the current wave of offerings, but there’s always been a steady supply of dev boards if you wanted to tinker.

The largest change has been to ease of use and a PR talking about how your board is an “Arduino killer”, but does this make any sense?

Latest cab off the rack has been Microsoft’s Gadgeteer platform, based on an ARM MCU and .NET development environment. I’m not picking on this board because it’s from Microsoft, I honestly don’t particularly care who provides the boards and the environment. I am picking on it because it misses the point. It misses it in the same way that NXP’s mbed dev board and (online only!) environment misses it.

Early users only care about how quickly they can get a blinky LED, and how quickly they can interface with some prebuilt modules. All of these offerings do that about as well as each other. If that’s all you’ll ever do – use other people’s prebuilt modules and other people’s libraries – then you’ll probably never run into any difficulties. There’s a lot which can be achieved with that exposure.

But at some point I think it’d be useful to be able to, for some users, take those experiences and go deeper into the rabbit hole of electronics. Not just use other people’s libraries and boards but make your own, dig into the internals of what’s really running on these boards, how they’ve been designed and built, to extend those platforms into a base to explore the whole realm of embedded software and electronics.

So how deep can you go on these Arduino killer platforms? Not that deep. In the Gadgeteer case there’s no PCB layouts or schematics for the mainboard. There’s a spec on how they want you to use the connectors on it, and how to build co-operative modules, but there’s a very clear limit placed on doing anything custom with the mainboard itself. It’s hard to tell from the source code provided, but I don’t see any sign of the any of the code actually running on the MCU. The same goes for NXP’s mbed, the hardware driver libraries are all closed and inaccessible. (NXP’s mbed does provide schematics and PCB layouts for their dev board, but only as PDF images and not in an editable form.)

Neither of these products can be a base for anything other than using the exact products they already have, exactly as they have presented them to you.

I hugely appreciate the fact that much of my own MCU and PCB work is based on looking into these details, and having access to source code running on the MCU, and the schematics and layout of the boards in a form I can edit. That in the end they’re based on what the Arduino project and other true open source hardware projects provide. I really doubt I would have gotten very far with my own boards if it wasn’t for that level of access that the Arduino provides.

And that’s the point. It’s not just about slick dev environments and an open surface to plug things into, and talking about “open hardware” like that means your have a PDF of what the pins on your board do. It’s about how deep into the rabbit hole you can go if you want to. Gadgeteer and mbed will let you get up to your ankles, and no further. They’ll do well and I have no doubt people will do so quite amazing things with them, but they’re no Arduino killer.