[Eagle vs KiCad part 4]
In the last post in my Eagle vs KiCad series I’d got as far as using Eagle to place all the components for the HexMonitor project in a schematic. Now it’s time to join them together.
Even before I begin, something tells me that perhaps this is too ambitious a project for my very first PCB. But hey, nothing ventured, nothing gained.
Making sense of it all
There are quite a few connections to make. There are the incoming data and address bus lines – 24 in total – that connect to the three 74HC165N shift registers. There are the connections between the shift registers and the ATMEGA328P microcontroller – and also a few between the shift registers themselves. The are connections from the microcontroller to the 74HC595N shift register that controls the display. And finally there are connections from both the microcontroller and the shift register to the 4-digit 7-segment LED display. Phew!
Did I miss any out? Oh yes, a couple. There’s a line from the connector to the ATMEGA328P that controls whether the data bus or the address bus will be read. This will need to be pulled high via a 10K resistor to default to the address bus. Pulling the line low switches to the data bus. And I threw in serial connections because … reasons.
To keep track of all this stuff I used one of my worksheets. This shows the connections to the microcontroller. (You can click on any of these images to see a bigger version.)
Some of the text refers to the variables or macros I’m using in the code – for example, the ATMEGA328P pin I’m using to send data to the 74HC595N shift register is defined in the code thus:
#define OUT_DATA PB3
I made a table to show the links between the 74HC595N and the LED display:
|74HC595N||4-digit 7-seg display|
All of this was carefully cross-referenced between my working code and working breadboard prototype. None of this information will mean much to you, but I thought I’d show it as an example of the process I’m going through. I figured the only way of having a fighting chance of ending up with a circuit – and a circuit board – that actually works is to plan carefully.
Casting your nets
One of the classic newbie mistakes with Eagle is to start joining items with the ‘wire’ tool. It seems obvious, but it isn’t. In the schematic, we’re dealing with an abstraction of the circuit, not the physical connections themselves. And the thing that joins two points of a schematic is a ‘net’.
I’m fairly sure Eagle has improved since the last time I tried to use it. When the net tool is selected, a small circle appears when the cursor is at the right point to make a connection to a pin. Even so, when connecting to a pin, it’s easy to go a little too far and drop the net without actually connecting. If you haven’t made a connection you’ll soon know because Eagle will continue to draw the net as you move the mouse pointer around – a clear sign that you’ve fouled up.
Often it’s a good idea to delete a net that you think you might have messed up and start again.
Taking the bus
A bus, in Eagle terms, is any group of nets that you want to run along the same path. Buses are very useful for keeping things tidy and I like the way that Eagle allows you to define what signals they carry just by setting the name – it’s a lot like creating an associative array (or dictionary) in code.
But I do have one big issue with buses. You can spend a lot of time attaching something to a bus with a bunch of nets. But if you have the temerity to move the bus, the nets don’t go with it. They are left dangling in mid-air. I saw complaints about this online, dating back several years, and it seems a weird oversight. You can get around it by grouping the bus and all the associated nets before moving anything, but that seems a clumsy solution.
I suspect that the trick with buses is to route them where you think they need to be but leave connecting them with nets until the very end, when you’re fairly sure they won’t need to move.
Shifting things around
I tried my best to guess the best position for each component when I first placed it in the schematic. In the end, though, I wound up moving everything – with some items I moved them several times.
Eagle has a clumsy way of moving groups of items – select the group with click and drag, select the move tool then right-click to find the Move:Group option. Like everything else with Eagle, it seems to take more clicks and more mode shifts that it should.
When you’re done, Eagle has a useful sanity check. The Electrical Rules Check (ERC) button attempts to assess whether everything that should be connected is connected and that there aren’t any obvious foul-ups.
This kicked up a fuss about a number of things. Happily, if you highlight a fault in the list, Eagle points to the part of the schematic it believes is an issue.
This threw up a number of unexpected issues. For instance, when I modified the connector part, I’d mistakenly specified a number of the pins as power pins, rather than I/O. I’ll fix that in the library but I’ll live with it for now in this project as none of those pins is used.
I also used ‘+5V’ for the supply connections but the ICs have ‘VCC’ for their power pins and Eagle warned about that mismatch. In fact, other than moving a couple of things so they don’t overlap, the ERC didn’t turn up anything that was actually a problem and I was able to click ‘Approve’ for all of them to get rid of the warnings.
So this is the schematic I ended up with.
I’m not saying it’s good. I’m definitely not saying it’s going to work. And I know that laying out the traces on a 100 x 80mm board (the maximum size the free version of Eagle allows) is going to be a nightmare. But hey, I did it!
So, joining stuff together together isn’t difficult, but it takes patience.
And that’s as far as I’m going to take things with Eagle for now. The next step is to go through the same process with KiCad. And once I’ve got schematics in both programs I’ll go on to the next step of layout out the boards.
Wish me luck…