What’s Coming In KiCad Version 5

Way back in the day, at least five years ago, if you wanted to design a printed circuit board your best option was Eagle. Now, Eagle is an Autodesk property, the licensing model has changed (although there’s still a free version, people) and the Open Source EDA suite KiCad is getting better and better. New developers are contributing to the project, and by some measures, KiCad is now the most popular tool to develop Open Source hardware.

At FOSDEM last week, [Wayne Stambaugh], project lead of KiCad laid out what features are due in the upcoming release of version 5. KiCad just keeps improving, and these new features are really killer features that will make everyone (unjustly) annoyed with Eagle’s new licensing very happy.

Although recent versions of KiCad have made improvements to the way part and footprint libraries are handled, the big upcoming change is that footprint libraries will be installed locally. The Github plugin for library management — a good idea in theory — is no longer the default. Spice simulation is also coming to KiCad. The best demo of the upcoming Spice integration is this relatively old video demonstrating how KiCad turns a schematic into graphs of voltage and current.

The biggest news, however, is the new ability to import Eagle projects. [Wayne] demoed this live on stage, importing an Eagle board and schematic of an Arduino Mega and turning it into a KiCad board and schematic in a matter of seconds. It’s not quite perfect yet, but it’s close and very, very good.

There are, of course, other fancy features that make designing schematics and PCBs easier. Eeschema is getting a better configuration dialog, improved bus and wire dragging, and improved junction handling. Pcbnew is getting rounded rectangle and complex pad shape support, direct export to STEP files, and you’ll soon be able to update the board from the schematic without updating the netlist file. Read that last feature again, slowly. It’s the best news we’ve ever heard.

Additionally, this is one of the rare times you get to hear [Wayne] speak. This means the argument over the pronunciation of KiCad is over. It’s ‘Key-CAD‘ not ‘Kai-CAD‘. You can check out the entirety of [Wayne]’s State of the KiCad talk below.

Continue reading “What’s Coming In KiCad Version 5”

SPI On Embedded Linux

Are you already comfortable working with Serial Peripheral Interface (SPI) parts and looking for a challenge? We suspect many of you have cut your teeth on 8-bit through 32-bit microcontrollers but how much time have you spent playing with hardware interfaces on embedded Linux? Here a new quest, should you choose to accept it. [Matt Porter] spoke in detail about the Linux SPI Subsystem during his presentation at FOSDEM 2017. Why not grab an embedded Linux board and try your hand at connecting some extra hardware to one of the SPI buses?

The hardware side of this is exactly what you’d expect from any embedded SPI you’ve worked on: MOSI, MISO, a clock, and a slave select. [Matt] gives a succinct overview of SPI and reading datasheets. Our own [Elliot Williams] has done an excellent job of digging through the basics and most common gotchas if you need to get up to speed on all the SPI basics.

The fun details in the talk start at about 18:30 into the video when [Matt] jumps into the Linux side of SPI. You need a controller driver and a protocol driver. The controller driver is responsible for dealing with the pins (actual hardware) and the protocol driver handles the job of making sense of the SPI packets (messages containing any number of transfers) going in or out. In other words, the controller drive just want bits and pushes them in or out on hardware, the protocol driver makes those bits meaningful to the Linux system.

Adding SPI devices (think devices like LCDs and sensors) to your own embedded systems means telling the OS the particulars about that hardware, like max speed and SPI mode. There are three ways to handle this but the Device Tree is the preferred method for modern systems. This paves the way for the controller driver which implements an API set that the Linux SPI subsystem will use to work with your new hardware.

Protocol drivers follow the standard Linux driver model and are pretty straight forward. With these two drivers in place the new device is hooked into the OS and opens up common SPI API calls: spi_async(), spi_sync(), spi_write(), and spi_read(), and a few others.

Continue reading “SPI On Embedded Linux”