[Eagle vs KiCad part 8]
So, as I mentioned in the previous post, I’ve decided to change direction slightly. Rather than continuing with the HexMonitor project to a completed and fabbed board, I’m going with a slightly simpler project.
The reasons are two-fold: first, the HexMonitor board is sufficiently complex that I figured it had no chance of working, this being my first PCB design; and second, I need the new board more that I need the HexMonitor one.
The new project is a parallel interface breakout. I have an Epson dot matrix printer (currently undergoing restoration) that I’ve owned since 1983. I want to be able to print to it from a Raspberry Pi. And yes, I already own a USB-to-parallel cable, although I’ve never got the drivers to work. And besides, I want to be able to print my way – and learn something along the way.
I’m approaching this in two stages in order to optimise the chances of it working.
Stage 1: The breakout board that we’re looking at here. This consists of a DB25 female socket with right-angle solder pins for board mounting, a 74HC595 shift register to drive the eight data lines but using only three GPIOs on the RPi, and a TXB0108 to shift the 5V logic levels that the parallel interface uses down to the 3.3V that the Raspberry Pi needs for its GPIOs. I’m also breaking out all the signal lines at the 5V level should I want to connect, say, a microcontroller. To provide the 3V3 power for the TXB0108, I’m using an LM1117 voltage regulator. There are also some bypass capacitors and pull-up resistors.
Most of the components are surface-mount because it’s time I got to grips with that (I have a hot air rework station on the way). As well as something to play with, this board (assuming it works) will allow me to prototype stage 2.
Stage 2: I’ll replace the shift register with an Atmel ATMEGA328P microcontroller – probably a surface-mount version. I’ll provide programming headers so it can be programmed on the board. The Raspberry Pi (or anything else, actually) will then communicate with the board via TTL serial.
I first put together the schematic in KiCad. This went fairly fast now that I’ve become accustomed to some of the program’s many quirks. I’d already created my own part for the 74HC595. I had to do the same for the TXB0108 and the LM1117 (although in the latter case I can’t remember whether I had to or just wanted to). This experience confirmed for me how easy it is to make new parts in KiCad. Here’s the schematic.
I’ve used a bus here, in part because of the way the DB25 connector is, to my way of thinking, upside-down. The eight data lines run top to bottom on the 74HC595 but bottom to top on the DB25. (Yes, I could have reversed the order on the shift register and allowed for this in software, but, you know.) I’m tempted to draw my own DB25 part.
I then went right ahead and did the board design, but I’ll cover that in more detail in the next post.
Then I had to do the same in Eagle. It’s actually a little while now since I last used Eagle, and some of its idiosyncrasies came back to bite me – such as the way that, in move mode, you have to get the cursor very accurately on to the little cross-hair in the component (which isn’t always very visible). On the other hand, all the components I needed were already in Eagle’s libraries.
I managed to knock up this schematic in Eagle in about half an hour. And I know what you’re thinking: “Yeah, I can tell.”
I’ll admit it’s not pretty but it was fast. I could have done some tidying up, but I wanted to get on to the board design, which will be the subject of part 9 of this series (crikey!).
What I gained from this experience are the following observations:
I still find Eagle’s modal interface annoying, especially when you’ve deleted a component and then move to another not remembering you’re still in delete mode.
It’s possible to speed up Eagle’s interface considerably via Options -> Assign… where you can program hot keys for various modes. You can’t just use M to enter ‘move’ mode, though – alpha and number keys have to be used with a modifier (Cmd, Ctrl and/or Alt). But at least the interface is programmable and I think Eagle will be far more usable if you spend some time configuring it.
Overall, I found KiCad easier to use for creating the schematic. While I much prefer Eagle’s approach to bus connections, I think in future I would employ KiCad’s global label feature for buses.
So far, I’ve found Eagle’s libraries to be more comprehensive, and there are very useful third-party libraries (SparkFun, Adafruit and more). It just seems better supported in this way. Plus, using libraries is so much easier than KiCad’s cock-eyed approach.
That said, creating parts in KiCad isn’t difficult and gives you the opportunity to make them the way that suits you best.
So, now to create some boards.