Eagle To KiCad Made Easy

December 27, 2015 by Anool Mahidharia 19 Comments

One barrier for those wanting to switch over from Eagle to KiCad has been the lack of a way to convert existing projects from one to the other. An Eagle to KiCad ULP exists, but it only converts the schematic, albeit with errors and hence not too helpful. And for quite some time, KiCad has been able to open Eagle .brd layout files. But without a netlist to read and check for errors, that’s not too useful either.

[Lachlan] has written a comprehensive set of Eagle to KiCad ULP scripts to convert schematics, symbols and footprints. Board conversion is still done using KiCad’s built in converter, since it works quite well, and we were able to successfully convert two projects from Eagle. The entire process took only about 10 to 15 minutes of clean up after running the scripts.

The five scripts and one include file run sequentially once the first one is run. [Lachlan]’s scripts will convert Eagle multi sheet .sch to KiCad multi sheets, place global and local net labels for multi sheets, convert multi part symbols, build KiCad footprint modules and symbol libraries from Eagle libraries, create a project directory to store all the converted files, and perform basic error checking. The Eagle 6.xx PCB files can be directly imported to KiCad. The scripts also convert Via’s to Pads, which helps with KiCad’s flood fill, when Via’s have no connections — this part requires some manual intervention and post processing.

KiCad Utilities Generate Parts; Track Costs

December 5, 2015 by Anool Mahidharia 48 Comments

The popularity of KiCad keeps increasing, and not only are more people converting to it and using it for their projects, but there’s also a growing number of folks actively contributing to the project in the form of libraries, scripts and utilities to improve the work flow.

KiPart

[Dave Vandenbout] a.k.a [xesscorp] has written a couple of utilities for KiCad. When working with large multi pin parts such as micro-controllers, creating a schematic symbol from scratch using the traditional KiCad schematic library editor can be quite tedious. KiPart is a python script that uses a CSV table as its input to generate the KiCad schematic symbol and is able to create multi-part symbols too. Usage is quite simple. The csv file needs a part name on its first row. The next row contains the headers. ‘Pin’ number and Pin ‘Name’ are the minimum required. Additionally, you can add in ‘Unit’, ‘Side’, ‘Type’, and ‘Style’. Unit is used when defining multi-unit parts. Side decides the location of the pin, Type its function, and Style is its graphic representation. Running the KiPart python script then results in a nice KiCad schematic symbol. Besides, KiPart can specifically generate schematic symbols for the Xilinx 7-Series FPGAs and the Cypress PSoC5LP. There are a whole host of options to customize the final output, for example ordering pin placement based on pin number, or pin name or pin function. Source files can be obtained from the [xesscorp] Github repository.

KiCost

Another useful utility from [xesscorp] is KiCost. It is intended to be run as a script for generating part-cost spreadsheets for circuit boards developed with KiCad. The one piece of information you need to add to your schematic parts is a manufacturers part number. The KiCost Python script then processes the BOM XML file, reading the manufacturer part number, scraping the web sites of several popular distributors for price and inventory data, and creating a costing spreadsheet. You can grab the source files from the KiCost Github repository.

Check the two videos below where [Dave] walks through the two utilities.

Thanks to [RoGeorge] for sending in this tip by commenting on the Open Source FPGA Pi Hat built by [Dave] that we featured recently.

Continue reading “KiCad Utilities Generate Parts; Track Costs” →

KiCad 4.0 Is Released

November 30, 2015 by Elliot Williams 68 Comments

If you’re a KiCad user, as many of us here at Hackaday are, you’ll be elated to hear that KiCad 4.0 has just been released! If you’re not yet a KiCad user, or if you’ve given it a shot in the past, now’s probably a good time to give it a try. (Or maybe wait until the inevitable 4.0.1 bugfix version comes out.)

If you’ve been using the old “stable” version of KiCad (from May 2013!), you’ve got a lot of catching-up to do.

The official part footprint libraries changed their format sometime in 2014, and are all now hosted on GitHub in separate “.pretty” folders for modularity and ease of updating. Unfortunately, this means that you’ll need to be a little careful with your projects until you’ve switched all the parts over. The blow is softened by a “component rescue helper” but you’re still going to need to be careful if you’re still using old schematics with the new version.

The most interesting change, from a basic PCB-layout perspective, is the push-and-shove router. We’re looking for a new demo video online, but this one from earlier this year will have to do for now. We’ve been using various “unstable” builds of KiCad for the last two years just because of this feature, so it’s awesome to see it out in an actual release. The push-and-shove router still has some quirks, and doesn’t have all the functionality of the original routers, though, so we often find ourselves switching back and forth. But when you need the push-and-shove feature, it’s awesome.

If you’re doing a board where timing is critical, KiCad 4.0 has a bunch of differential trace and trace-length tuning options that are something far beyond the last release. The 3D board rendering has also greatly improved.

Indeed, there are so many improvements that have been made over the last two and a half years, that everybody we know has been using the nightly development builds of KiCad instead of the old stable version. If you’ve been doing the same, version 4.0 may not have all that much new for you. But if you’re new to KiCad, now’s a great time to jump in.

We’ve covered KiCad hacks before, and have another article on KiCad add-on utilities in the pipeline as we write this. For beginners, [Chris Gammell]’s tutorial video series is still relevant, and is a must-watch.

Thanks [LC] for the newsworthy tip!

Hackaday Links: November 22, 2015

November 22, 2015 by Brian Benchoff 9 Comments

There’s a new documentary series on Al Jazeera called Rebel Geeks that looks at the people who make the stuff everyone uses. The latest 25-minute part of the series is with [Massimo], chief of the arduino.cc camp. Upcoming episodes include Twitter co-creator [Evan Henshaw-Plath] and people in the Madrid government who are trying to build a direct democracy for the city on the Internet.

Despite being a WiFi device, the ESP8266 is surprisingly great at being an Internet of Thing. The only problem is the range. No worries; you can use the ESP as a WiFi repeater that will get you about 0.5km further for each additional repeater node. Power is of course required, but you can stuff everything inside a cell phone charger.

I’ve said it before and I’ll say it again: the most common use for the Raspberry Pi is a vintage console emulator. Now there’s a Kickstarter for a dedicated tabletop Raspi emulation case that actually looks good.

Pogo pins are the go-to solution for putting firmware on hundreds of boards. These tiny spring-loaded pins give you a programming rig that’s easy to attach and detach without any soldering whatsoever. [Tom] needed to program a few dozen boards in a short amount of time, didn’t have any pogo pins, and didn’t want to solder a header to each board. The solution? Pull the pins out of a female header. It works in a pinch, but you probably want a better solution for a more permanent setup.

Half of building a PCB is getting parts and pinouts right. [Josef] is working on a tool to at least semi-automate the importing of pinout tables from datasheets into KiCad. This is a very, very hard problem, and if it’s half right half the time, that’s a tremendous accomplishment.

Last summer, [Voja] wrote something for the blog on building enclosures from FR4. Over on Hackaday.io he’s working on a project, and it’s time for that project to get an enclosure. The results are amazing and leave us wondering why we don’t see this technique more often.

KiCad Script Hack For Better Mechanical CAD Export

November 8, 2015 by Anool Mahidharia 16 Comments

Open source EDA software KiCad has been gaining a lot of traction recently. CERN has been devoting resources to introduce many new advanced features such as differential pair tracks, push and shove routing and this plenty more scheduled in the pipeline. One important requirement of EDA packages is a seamless interface with mechanical CAD packages by exporting 3D models in industry common formats. This improves collaboration and allows further engineering designs such as enclosures and panels to be produced.

KiCad has had a 3D viewer available for quite a long time. But it uses the VRML mesh format (.wrl files) and there are compatibility issues which prevent it from rendering certain versions of VRML files. Moreover, the VRML mesh export is not particularly useful since it cannot be easily manipulated in mechanical CAD software. Recent versions of KiCad now offer IDFv3 format export – the Intermediate Data Format, a mechanical data exchange specification for the design and analysis of printed wiring assemblies. Taking advantage of this new feature, [Maurice] created KiCad StepUp – an export script that allows collaborative exchange between KiCad and FreeCAD.

A FreeCAD macro and a corresponding configuration file are added to the KiCad project folder. You start with .STEP files for all the components used in the KiCad design. The next step is to convert and save all .STEP files as .WRL format using FreeCAD. On the KiCad side, you use the .WRL files as usual. When you want to export the board, use the IDFv3 option in KiCad. When [Maurice]’s StepUp script is run (outside of KiCad) it replaces all instances of .WRL files with the equivalent .STEP versions and imports the board as well as the components in to FreeCAD as .STEP models. The result is a board and its populated components which can be manipulated as regular 3D objects.

Continue reading “KiCad Script Hack For Better Mechanical CAD Export” →

Developed On Hackaday – HaDge Is Back To The Drawing Board

October 30, 2015 by Anool Mahidharia 42 Comments

A couple of days back, we wrote about the HACK – a prototyping platform designed by [Michele Perla] based on the Atmel SAM R21 MCU. It’s one of the new breed of devices consisting of an ARM Cortex-M0 MCU + IEEE 802.15.4 Wireless radio bundled together. This was exciting since we could pack a lot of punch in the HaDge hardware. We planned to use the same design later to power the HaDge. Building HACK would have allowed us to get it in the hands of the software team, while the hardware folks worked on the real HaDge layout.

The HACK design was ready for review and we asked around to verify the antenna layout, which was the part we were not too sure about. We asked Atmel for help with verifying the layout. That’s when we had the facepalm moment. They asked us – “What about FCC certification?” Since we plan to build the badges in quantities of a few hundred at the very least, it’s obvious we cannot escape from FCC certification. A design based around the R21 is ruled out – the cost of obtaining approval is pretty high. This means we need to punt the R21 and instead use an off-the-shelf radio module which is already FCC certified. Sigh.

Now the good news. This is a setback in terms of time, and effort put in by [Michele]. But beyond that, we’re good to go back to the drawing board and start afresh. First off, we decided to revert back to the Atmel D21 as the main controller. It’s a fairly decent MCU, and there’s a fairly robust tool chain available that a lot of people are familiar with. For the Radio, we are looking at some of these available options :

The last one from Microchip looks quite promising. But we’re open for better and cheaper suggestions, so please chime in with your comments.

Developed On Hackaday – It’s A Badge. No, It’s The HaDge

October 26, 2015 by Anool Mahidharia 14 Comments

Sometime back, we announced start of a new project under the “Developed on Hackaday” series – a Badge for the Hackaday community. At its core, this badge is a single node in an Internet of Badges. At every event this badge is deployed at, a Hackaday Sub-Etha mesh network will be created, and each badge will be able to transmit and receive messages from other badge wearers. There are plans for an Sub-Etha to Internet gateway, so even if badge wearers are on the other side of the world, they’re still connected through the HaDge network.

Things have been moving along quickly, so I thought of doing a quick round-up and share progress with the community. First off, it has a name. HaDge, as in HackaDay Badge. Our objectives up until now were to set up a team, name the project, set up repositories and lock down on a working bill of materials. Within a few weeks, we’ve got all of that tied down. The HaDge group chat channel has been super active, and everyone’s been pitching in with ideas and suggestions. A spreadsheet seemed like a good idea – it let everyone add in their suggestions regarding candidate parts, create a feature list and then talk about it on the channel.

We realized early on that building the hardware is going to take some time. So in the interim, we need a dev kit platform to get in to the hands of the software developers so they can start working on the smarts that will power the HaDge. [Michele Perla] had already built JACK (Just another Cortex kit) – a development kit powered by the Atmel SAM D21. It’s pretty bare bone with just the bare minimum of parts to make it work while keeping an eye on reliability. The microcontroller+radio on the HaDge is the Atmel SAM R21 – a close relative of the D21, so it made sense to respin the JACK and create HACK (Hackaday Cortex kit) – a development kit powered by the Atmel SAM R21 that is going to be used as the core of the HaDge. [Michele] has worked hard single-handedly to complete the design and it is now ready to go for PCB fabrication soon. We are just awaiting some feedback and review of the Antenna part of the design. None of us on the hardware team have a strong RF-fu so we don’t want to make an avoidable mistake. If you’d like to review and help vet the HACK design, grab the design files from the github repo and let us know.

Once HACK board layout is cleared for fabrication, we’ll work on building kits that can be sent out to the software folks. We will also be working on porting the HACK design in to KiCad and this is something I have already stared work on. I started by using the neat Eagle2KiCad conversion tool by [LachlanA]. It’s not perfect, but it does reduce the work involved in porting over from Eagle to Kicad. Once that is done, hardware development for the actual HaDge will see some progress – keep a watch on the project page.