Development Kits 101: What Makes A Good Dev Kit

Development Kits 101: What Makes A Good Dev Kit

Since I was about ten years old, I have been building and playing with electronic development kits. Over that time there have been good ones and bad ones.

Nowadays, I get to review Dev Kits, so I get to look at them from an outsiders view point, not one where I’m clouded by the excitement of opening the box and getting started with it. So in this blog, I want to pass on to you, and the makers of these Dev Kits, what makes one work!

I guess we have to first have to consider why someone wants a Dev Kit before deciding if it’s good or bad. What people or engineers expect from the experience is key. There are two main flavours of Dev Kits, in my view, which are as follows. First, you have the kits where they supply you with the key device or component that you’re interested in. This first type of kit comes with worked examples and has been designed to be configurable. It’s also flexible enough that you can get at the part and interface with it in order to access its full potential. This is a kit that, once you are bored with the shipped demos, you can actually use as part of a development platform. These I class as true Dev Kits.

The other type I will class as Show Case Dev Kits. These are the ones that turn up preprogrammed with a flashy demo, blue LED’s flashing or sexy graphics displays attached. These are one-trick ponies in my view that, while they may demonstrate how well a device works, leave you with very limited access to it, no configuration, and, well, are really nothing more than marketing toys.

So the first key fact about a dev kit is that first word – it’s called ‘Development’ for a reason, and that’s so people can use it to develop with. A one-trick pony ends up in a draw never to be seen again.

So, having discounted these show-off kits, there is still lots more to consider. I’ve had Dev Kits that are designed for development but fail really, really badly at doing it. Even adding a blue blinky LED would have made it a lot better. No, a Dev Kit needs to not only be developable (if that’s even a word!?) but be a tool that’s easy to understand and use.

So lets open the box on what a good Dev Kit is. First off, it has to be packed well. Kits with broken connectors or components that have broken off in transport suggest the manufacturer has little respect for it. Once out the box, you should find all the additional tools you may need. That means don’t skimp on a USB cable if your product needs one. There should also be a quick start guide and CDs or DVDs included, as well.

On the CDs or DVDs, you should be able to find data sheets, application notes, drivers, sample code, and everything (and I do mean everything!) you would need to get developing. You have to assume the user doesn’t have access to the internet so don’t make them spend hours wandering round web sites to find tools and stuff they need to download. I don’t care that they may not be the latest, engineers are not silly and understand this so will, if needed, follow links (also supplied) so that they can get the latest tools etc.

CDs and DVDs don’t, in my view, have to be specially printed for the job. I’ve come across Dev Kits that have CD-R with the company logo on it. These are great as they contain much more up to date information. The very best I came across was a supplied USB flash drive that not only gave me 1.5G of free space but partitioned off space that mounts as a CDROM with all the tools on it.

Once it’s all unpacked it’s time to get started and time is critical. Like anything, if it’s not interesting from the start, you will quickly lose any excitement you have. I set a 30-minute rule: that is, I should be able to power the Dev Kit up, download a “hello world” demo, and get playing all within this time. This should be a completely pain-free progress. Tools should install and drivers should just work. Hardware will be easy to understand from the start, well-labeled, and, with the assistance of the quick-start guide, make connections or whatever to get that first “COOL” from the engineer.

The quick start guide is not just about the first-time connection. It should guide you as to where to get started when installing software, where data sheets are on the supplied CDs, etc., and give web links for extra reading as well as point to support pages. This should not be a book but enough to point an engineer in the right direction.

Lots of Dev Kits cover micro-controllers these days, and manufactures like supplying sample code. This is all very good, but the sample code must be of good quality. The code should have lots of clear comments within it and even a supporting document, if needed, to help new engineers through how the code works. It should be written so interface code (for example to a SPI device) can be reused. I once got a single file supplied as a 5,000+ line assembly file with no comments and no support documentation. What’s worse is the chip had C compilers available but the code supplied made it almost impossible to work with: I may as well have designed the whole thing from scratch!

If you’re looking for a new Dev Kit, find a review to see what people think.  It will actually help your development progress. And when manufacturers get it wrong – tell them! Hopefully a few of them out there will have read this and maybe all Dev Kits will reach a good standard.

What horror stories do you have with Dev Kits? Tell us what you have found or maybe about one that was very well put together. I’d love to hear your views.


What irritates me is electronic devkits which are brilliantly designed pieces of hardware, but which are let down by their supporting firmware and/or software. Even worse is if the software is good but either single-platform, closed-source or comes with licensing restrictions which mean it cannot be used in a real product.

Much as I like Digilent’s products, they do fail in this regard. Their software is poorly-designed, closed-source, and licensed so you may only run it on Digilent hardware. So you only find out you’ve got a Show Case Dev Kit after you’ve invested time and effort using it.

For this reason I made FPGALink[1], a cross-platform open-source library, firmware and VHDL reference design for Digilent’s Nexys2 and Atlys boards (and any others using the Cypress FX2LP for USB communication). You can JTAG-program the FPGA and then communicate with it, all over USB.


Windows-only code is a no-go for me.

All the code that comes with a development kit should be open source and well documented.

Actually, I prefer not using cutting-edge parts that need custom development kits. Far better for me to use technology that has been around long enough to be thoroughly tested and with lots of development help already available. But if you need the latest stuff, you’re stuck with whatever crap the manufacturer throws together to make deadline.

My post isn’t about Dev KITS so much as as similar past experience with a micro-controller. In one of my classes, my professor switched from the Pic to MSP430. I found the MSP430, despite being developed by TI and having an endless amount of sample codes available online, had poor documentation. For many first time programmers, orienting yourself is impossible.

I think you hit the nail on the head in terms of what needs to be in a kit, and I would like to add that documentation that is concise and obvious (don’t leave anything to assumption) to even a first time Dev Kit user. Thanks for sharing!

Comments are closed.