I’ve finally gotten around to using Git instead of Mercurial on a project. So far it has been uneventful. I still prefer Mercurial because it treats all OSes as first class citizens and because I think the CLI is cleaner. My workflow doesn’t require a lot of branching, but Git fans seem to think it really shines there. My main motivation for going Git on this project is to get some experience with what will likely become the defacto standard DVCS.
I am mostly using
git-cola git gui as a GUI frontend. Ironically, git-cola—like Mercurial but unlike Git itself—is Python powered.
The best resource I’ve found so far for working with Git if you already know DVCS fundamentals is Spherical’s “Git for the lazy.” Entp’s “Version Control for Designers” is pretty good too.
Update: Turns out SVG might be a better base than PostScript for this. See PDF output from KiCad in Linux from SVG.
I’ve tried to get decent PDF output from KiCad‘s Eeschema a few different ways, but what I’ve found to work most reliably is to first export to PostScript (File > Plot > Plot PostScript) and then use the
ps2pdf command from ghostscript to convert to PDF. (The Arch wiki has a good writeup on
The biggest problems with this are:
- It’s a lot of typing to get the conversion to happen (the minutia of which you won’t have memorized).
- It leaves you with both a PostScript and a PDF of the document(s), one of which is likely to get out of sync with the other, which may or may not be in sync with the actual schematic, etc.
To help with this, I use the script below. I drop a copy of it into the root of my KiCad projects and edit the OPTIONS as needed for the project. Then whenever I want PDFs of my schematics, I export PostScript from Eeschema and then click on this script in my file manager. Note that running this script will destroy any
*.ps files in the directory—that’s by design.
# DESTRUCTIVELY convert all postscript files
# in working directory to PDF.
# Requires ghostscript.
# Mithat Konar 2013 [http://mithatkonar.com]
FILES=$(ls -1 *.ps)
for file in $FILES
ps2pdf $OPTIONS $file && rm $file
I’ve not tried the script on any PostScript files other than those produced by Eeschema, but I’ve got no reason to think it won’t work on other PS files as well.
I added a tutorial on C++ pointer basics to my wiki. It needs some work but might be useful in its present state.
I just noticed that my Mercurial repository of some KiCad modules I made never made it to the Web. Took care of that just now. You can access the repository at https://bitbucket.org/mithat/kicad-modules-mfk/.
Last week I finished delivery of a custom 6-channel DAC for mastering engineer Greg Reierson at Rare Form Mastering. It uses three stereo DAC cards I designed previously for Audio by Van Alstine, Inc. (currently used in their production DACs) and six custom dual-differential gain/filter cards. I designed the gain/filter cards to use an absolute minimum of active stages—something I have consistently found to help subjective performance.
Greg reports that the new DAC is dead silent and delivers noticeably better LF control than his previous setup. We hope to do some gain-stage device (that’s opaque-speak for “opamp”) comparisons down the road to see if things can be improved further. He will be using the new DAC for general monitoring and also to drive his newly acquired Neumann VMS 70 cutting lathe.
Note: This is a 2011 repost from the now mostly defunct Biro Technology blog. I’m reposting it because it’s good information that belongs here. (P.S. Added it to the wiki.)
I’ve been working a bit with KiCad lately and have run into a problem in PCBnew with “stitching” (i.e., adding vias between) filled zones on top and bottom layers. This is something you typically do if you have flooded the unused spaces on both top and bottom of your board with copper and have connected the floods to ground or some other reference.
The KiCad FAQ outlines a process for doing this, and it works fine until you refill (i.e., re-pour) the zones–or the DRC refills them for you. When the zones are refilled, the vias you added for stitching become isolated from the zones and end up as little pads floating in space.
The problem and a workaround was discussed in a recent thread on the kicad-users mailing list. I wanted to summarize here the workaround in a slightly less terse way:
- Route the board and define your zones as you always have.
- Fill the zones as you always have.
- Select “Add tracks and vias” from the toolbar on the right.
- Click on an existing pad that’s connected to the zone’s net, drag the pointer a little bit to create a short track, then either (a) right-click and select “Place Via” or (b) type the ‘V’ shortcut.
- To add more stitching vias, continue to drag the pointer and type ‘V’ where you want to drop vias (or right-click and select “Place Via”).
- When you are done placing vias, hit the ‘End’ key on your keyboard (or right click and select “End Track”).
You can repeat this as many times as you want to create different clusters of stitches. When you refill zones, the vias will retain the connectivity information and work as expected.
Since Olimex’s PCB prototype service is currently offline, I decided to try another provider for a project I’m working on. The one I settled on is OSH Park, and I have to say the online ordering process worked far more smoothly than I expected. I uploaded a *.zip file full of Gerbers exported directly from KiCad, and the system recognized everything perfectly. Here’s hoping the boards turn out equally fine.
One bit of advice: As near as I can tell, KiCad’s layer alignment targets only add extra square inches to your design for which you will be charged, so you may as well leave them off.
I’ve been using Mercurial along with Bitbucket for project hosting for quite a while now. I’ve also grown quite fond of EasyMercurial to help manage my repositories. However, I have started to wonder if I should consider using Git as my defacto standard VCS.
I was originally attracted to Mercurial over Git because I got the sense that Git was an almost hackish amalgam of various scripts written in a variety of languages—and because it encapsulated a lot more “power” (read: “complexity”) than I saw myself needing. And while Linux was (and is) my main OS, Windows support for Git was sorta grimmish. Bitbucket’s hosting policies at the time seemed better than the closest Git-equivalent: GitHub (still do—BB’s unlimited private repos in particular), and Redmine offered an easy self-hosted project management solution including repository, wiki, issue reporting, etc. as well. Gitourious was available at the time but was (and is) feature incomplete compared to Redmine. I can’t remember if Trac supported either at this point.
So why consider changing? I’ve recently noticed what appears to be a mad rush to use Git in general and GitHub in particular–so much so that I’m wondering if Git is going to become the defacto industry standard soon. Changing to Git may not be as huge a deal as it might seem at first because Bitbucket, RhodeCode and Trac now let you use Git repositories in addition to Mercurial, and it seems Git’s support for Windows has improved. There are also a number of GUI Git clients available for all major platforms—though none of them seem as sweetly usable as EasyMercurial.
I may just try managing my next project with Git as a test-case. Worst case: convert the Git repo to Mercurial.