Validation and PCB Editor errors

[thanpolas]

Hey folks,

I am trying to create my first PCB and thought I’d start with a simple enough design, a pair of PISO Shift Registers that can be daisy chained so as to accept multiple inputs using just a few pins for arduino.

There are two set of issues I am having: Electrical Rule errors and PCB editor breaks…

Electrical Rule errors

• “Error: pins of type Output and Output are connected” This is a bus output pin of the PISO Shift Register pin that needs to be connected amongst all the daisy-chained ICs… From what I’ve read on this forum that’s a known issue but without an established solution… so do I simply chose to ignore it?
• “Warning: Net xxx is graphically connected to … but is not a member of that bus” … This error puzzles me, using the connector tool, I can clearly see the connections are correct and connecting where they should… not sure how to deal with this error

A screenshot of the errors:

A showcase of the whole design with the connector tool, in this case “1-7” is highlighted:

PCB Editor Errors

I have added footprints to all my components (hope I chose the right ones), so next I tried to enter into the PCB editor, however, I am getting the following error:

OSError: [Errno 34] Result too large: '/private/var/folders/vq/py19w61x4n93m2q9wpfv6gjm0000gn/T/AppTranslocation/E6811F1A-BB0F-4639-B174-2DD998CB4E16/d'

At:
<frozen importlib._bootstrap_external>(1487): _fill_cache
<frozen importlib._bootstrap_external>(1443): find_spec
<frozen importlib._bootstrap_external>(1314): _get_spec
<frozen importlib._bootstrap_external>(1342): find_spec
<frozen importlib._bootstrap>(914): _find_spec
<frozen importlib._bootstrap>(971): _find_and_load_unlocked
<frozen importlib._bootstrap>(991): _find_and_load

I have uploaded the project as a zip file:
shift-registers-export.zip (21.5 KB)

---

Please help!

[retiredfeline]

Post KiCad version information please.

[paulvdh]

About the bus…
When you put a label on a bus like that it is called a vector bus, and the names of the attached wires should have the same names as the bus members. Right click on the bus and then select Unfold from Bus to see the names of the members:

Alternatively, you can also rename the be bus label itself. I created the 1-2 with the “foldout” function.

---

And why are you connection the ~{Q7} pins together? It looks like real outputs and then this is a real pin conflict. I have not looked very carefully at the datasheet though.

You have specified 10p for the decoupling capacitors C1 and C2, and these are very small capacitors. Traditionally 100n is used. The exact value is not critical, but it’s a difference of 10000x

Ans as you’ve seen, putting an tilde does not change the text. This has changed some time ago in KiCad (probably with V6.0). To see the overbar you also have to use curly braces. You can see an overview of the supported “modifiers” with Schematic Editor / Place / Add Text / Syntax Help

[thanpolas]

hey @paulvdh, thankyou, yes, that eliminated all the warnings from the enumerated pins (PISO1[0..7])!

I am still getting the same warnings for all the other pins now on the “not named bus”:

Application: KiCad Schematic Editor

@retiredfeline

Post KiCad version information please.

Here it is:

Version: (6.0.9-0), release build

Libraries:
wxWidgets 3.1.5
libcurl/7.79.1 SecureTransport (LibreSSL/3.3.6) zlib/1.2.11 nghttp2/1.45.1

Platform: macOS Version 12.5.1 (Build 21G83), 64 bit, Little endian, wxMac

Build Info:
Date: Oct 29 2022 19:31:49
wxWidgets: 3.1.5 (wchar_t,wx containers)
Boost: 1.80.0
OCC: 7.6.3
Curl: 7.64.1
ngspice: 37
Compiler: Clang 12.0.0 with C++ ABI 1002

Build settings:
KICAD_USE_OCC=ON
KICAD_SPICE=ON

[thanpolas]

I’ve upgraded to the latest version and I still get the same error…

---

Application: KiCad Schematic Editor

Version: (6.0.11-0), release build

Libraries:
wxWidgets 3.1.5
libcurl/7.79.1 SecureTransport (LibreSSL/3.3.6) zlib/1.2.11 nghttp2/1.45.1

Platform: macOS Version 10.16 (Build 21G83), 64 bit, Little endian, wxMac

Build Info:
Date: Jan 26 2023 15:47:00
wxWidgets: 3.1.5 (wchar_t,wx containers)
Boost: 1.81.0
OCC: 7.6.3
Curl: 7.64.1
ngspice: 38
Compiler: Clang 12.0.0 with C++ ABI 1002

Build settings:
KICAD_USE_OCC=ON
KICAD_SPICE=ON

[teletypeguy]

hc165 does not have tri-state out – you can’t parallel those outputs but may be able to OR them if you manage the chips. What you probably meant was to feed the output of one into the shift input (pin 10) of the second one – iirc correctly it is the Q-not output (not Q) that feeds to the next chip.

I would put some resistors in series with those cmos inputs that you are running to terminal blocks and off-board to who-knows-where. There are basic diodes-to-rails on the hc inputs and with a series resistor of 10k or so you get some esd protection.

[paulvdh]

You have to name a bus for KiCad to be able to know which signals in buses are connected.

In the screenshot below I gave the bus a name, and I added the bus members to: Schematic Editor / Tools / Bus Definitions

The use of these "Bus Definitons** is explained in the manual, wich is very likely already in Schematic Editor / Help / Help but also on Schematic Editor | 6.0 | English | Documentation | KiCad
Now ERC only complains about IN-DS because it’s not connected anywhere else.

There is a bit of an (annoying?) overlap between local labels (which connect together on the same sheet just by referencing their name) and labels used for a bus (which maybe should not be local labels anymore ???)

---

Some more general notes:
Get rid of the squares around schematic sections. They add nothing useful, they clutter the schematic, and they also make maintenance and changing the schematic much more difficult.

Adding texts to identify schematic sections is a good thing. These are usually the first thing to look for in a schematic. Make these texts bigger, and maybe also bold to have them stand out from the rest of the schematic. The “big text” also indicates the text is related to a “section” instead of a “single symbol”.

Also, make more use of wires, and don’t just throw everything in a bus. The way how serial inputs and outputs are connected together (from the connector to the IC’s, and inbetween the IC’s, etc) is much clearer when you draw a wire instead of just labeling them.

[paulvdh]

I’m doing a bit of cleanup and want to throw in another screenshot:

Schematics are easier to read if you keep to the convention of Higher voltages on top, lower voltages on the bottom and signal flow from left to right.

Also, what is a value of “R1000”?

The Capital R is regularly used as a placeholder of a value multiplier of 1, and this would make it a 0.1 Ohm resistor, while it’s probably meant to be an 1k resistor.

After a bit more cleanup, I put all the power stuff together:

I usually just group the decoupling capacitors, and assume the person who does the PCB layout (me) is smart enough to know why these capacitors exist and how to use them. Putting the power stuff together, also reminded me to add a bigger buffer cap in addition to the decoupling capacitors for the IC’s.
I also put the PWR_FLAG symbols near to the power input connector as an indication that is where the power comes from.

I also just put the connectors directly on the shift registers. I would probably not have named the wires at all, but that is mostly a personal thing. I left the ~{Q} outputs open.

For the control signals, I just used local labels instead of a bus. Using a bus for them may have a slight advantage.

Sometimes the complexity of buses is needed to draw a schematic, but if it can be avoided then that is usually a better option.

The serial data now goes from right to left, which is contradictory to common convention, but for these shift registers the all the inputs weigh in more heavily, and I prefer to have these on the left side of the symbol.

Last, by mirroring one of the power connectors, pin 1 is now on the top of both and by putting them close to each other it’s easier to see they are a straight through connection, except for the data.

2023-02-06_shift-registers-export.zip (12.9 KB)

[teletypeguy]

Yeah, that’s how it’s done Paul!

Though I am pretty sure the Q7-not (pin-7) of the first chip feeds to the shift-reg-in (pin-10) of the second chip.

I used these years ago, in conjunction with hc595 for the opposite ser-to-par direction. It was four of each, which became a nice serial loop providing 32-bits in and 32-bits out from a three-wire interface that can be bit-banged or connect to an spi port. Write the driver for any number of num-bytes your gizmo provides (one 165 and one 595 for a one-byte loop, two of each for a two-byte loop…).

[paulvdh]

@teletypeguy

Though I am pretty sure the Q7-not (pin-7) of the first chip feeds to the shift-reg-in (pin-10) of the second chip.

Could be.
I mostly concentrated on style. I did not look carefully at the 74165 datasheet and I have not used this chip myself, nor did I check the correctness of the schematic.

[teletypeguy]

Hmm, in looking closer at the datasheet I see an extra inversion on the ser-in, so I may have had that backwards and it needs to go to Q. In any event, this is a perfect project to breadboard before doing a pcb as they are available in dip for a quick test.

[ML9104]

@paulvdh

I usually just group the decoupling capacitors, and assume the person who does the PCB layout (me) is smart enough to know why these capacitors exist and how to use them.

I do the same, but add a text label above each cap to show where it belongs (eg, U1, U2, U3…).

[ML9104]

@teletypeguy

Though I am pretty sure the Q7-not (pin-7) of the first chip feeds to the shift-reg-in (pin-10) of the second chip.

No. The signal flow in '165 and '595 (and other) registers is straightforward. No inversions.

[retiredfeline]

When chaining the 595 (a SIPO), the next shift register is driven by ~QH, not QH. I don’t know about the 165.

Edit: Ah ok, it’s QH’ and the ’ is not inversion. I thought that was strange, but didn’t look deeper.

Actually it makes perfect sense when I think of it. The chaining has to be from the register before the latch, so that the serial data can propagate even without latching. Then a single strobe signal to all the chips will cause the latched outputs to change in unison.

[paulvdh]

@retiredfeline

When chaining the 595 (a SIPO), the next shift register is driven by ~QH, not QH.

No it’s not.
It’s a QH’ (with an apostrophe at the end). This output pin (nr 9) is not inverted, it just bypasses the output latches. The datasheet from Ti has the internal schematic of the 74HC595

Note that the output of the register is inverted, but it goes though an inverting buffer again before it’s being output. If the output itself was inverted, then you’d have to invert half the data bytes while daisy chaining these things.

[Sprig]

@paulvdh

If the output itself was inverted, then you’d have to invert half the data bytes while daisy chaining these things.

Wouldn’t that technically mean inverting every other byte?

[thanpolas]

Hey @paulvdh,

thank you so much for the guidance!!! It has taught me a lot and indeed made the schematic easier to read.

By solving all the warnings and errors I am now able to open the PCB editor, which is to say that it’s such a bad UX to have that cryptic error message from Kicad… It’d be way way easier for me if it simply said “Resolve your Electrical Rules check before proceeding”.

I’ve deviated from your suggestion in two points:

1. I’ve positioned the shift registers as they were and drew the connecting line between them, my OCD couldn’t stand them being opposite against convention.

2. I’ve retained the noise reduction caps next to the shift-registers (vs the power section) so it’s explicit that these are noise reductions and must be positioned as close to the ICs as possible

I will now set this up on a breadboard and test as it’s not clear what’s going on there with the ~Q (Pin 7) and to generally verify the schematic.

Thank you again for your help!

edit: The PCB editor crash was not resolved due to solving the electrical checklist, I just opened it directly from the editor and the schematic was not connected (thus I could not import). The problem persists, but I have found a relevant issue on gitlab that I am following and trying to solve my local problem: Cannot open PCB Editor - Mac OS - Error Loading (Errno 34) (#12224) · Issues · KiCad / KiCad Source Code / kicad · GitLab

[ML9104]

You’ve swapped some things and are making it difficult for yourself. Do the following:
Label U1(10) Data_In
Connect U1(9) to U2(10)
Label U2(9) Data_Out.

Done.

[thanpolas]

yes, thank you, you’re right, SC is input and Q is output.

I’ve also pulled down all inputs as suggested by @teletypeguy

[ML9104]

That looks like it’ll work.
As you’ve tied the two PL signals together, you can only read all 16 inputs in one go. For more flexibility, you could also control the two PL inputs separately, allowing you to read the two 8-bit inputs individually.