I’m starting a kicad project using a 100 pin microcontroller. What’s the best way for me to manage all the different Nets? Buses with numbered elements don’t really make much sense in my application, but I don’t really want 100 individual wires crisscrossing all over my diagram either. Should I use net labels to just teleport my signals from the micro out to wherever they need to go?
There’s probably not a right answer, but I’m looking for your opinions.
For similar projects i generally “simply” use labels that make sense. So i have a label for the temperature input 1 (TEMP_1) and am free to connect it to whatever pin of they microcontroller i want. (Note that i use the name of the signal as the label name not the name of the controller pin. It is much easier to change the assignment in software than it is to reroute hardware.change
Net labels.
I keep most wires away from the micro, to leave plenty of room for descriptive labels.
Plus, much easier to pin swap labels than re-route wires.
For an example, have a look at the Olinuxino64.
It’s one of the 40+ example projects linked to from the KiCad website itself, and you can directly clone the whole project ( Schematic, PCB layout) as a KiCad project from github.
Very cool, I hadn’t seen that, thank you. Looking at the PDF for that schematic it looks like there are buses which contain nets with a variety of names. It was my understanding that buses have to contain numbered signals all with the same name prefix. Is that not the case?
Why look at the PDF when you have the whole KiCad project?
In the ol’ day’s of KiCad busses were very simple. Mostly there were none. You just put local labels on wires, and the bus entries and blue bus lines were just graphical hint of where those local labels go to.
Now buses care more sophisticated. The’re complex enough (especially with hierarchical sheets) to take a deviation from working on your project, and putting in some conscious effort with the only goal of learning to understand how buses work.
For example, the numbered buses you mentioned are called
A vector bus is a collection of signals that start with a common prefix and end with a number. Vector buses are named [M…N] where PREFIX is any valid signal name, M is the first suffix number, and N is the last suffix number. For example, the bus DATA[0…7] contains the signals DATA0, DATA1, and so on up to DATA7. It doesn’t matter which order M and N are specified in, but both must be non-negative.
But there is also:
A group bus is a collection of one or more signals and/or vector buses. Group buses can be used to bundle together related signals even when they have different names. Group buses use a special label syntax: <OPTIONAL_NAME>{SIGNAL1 SIGNAL2 SIGNAL3}
This text was directly copied and pasted from chapter 6.5.3 of:
Eeschema / Help / Eeschema Manual F1
The Olinuxino64 is a relatively complex project. For learning buses and Hierarchical design my suggestion is to start with something simple.
For example, make a Hierarchical design with a few sheets. and give each sheet a single IC. Put a Z80 on one sheet, a RAM chip on another, and an Eprom on yet another sheet, then start connecting stuff while reading the manual. Also make a PCB out of it in an early stage, and just put the chips next to each other on the PCB, or in a triangle. Then you can see from the ratsnest lines if modifications you make in the schematic are reflected in the PCB.
The advanced buses you describe are not available in the current stable version of KiCad! They will be added in version 6.
I’m on my mobile right now so I can’t actually open the project at the moment.
Thank you for pointing out the documentation. I was mistakenly reading documentation for an older version.
Group busses are described under version 5.1.5 documentation at docs.kicad.org? Which, incidentally, has an erroneously listed publication date of May 30, 2015.
This might be a mistake in the documentation.
I do not use buses much, because I usually just make small PCB’s with a single uC and a few sensors and such.
About a month ago I saw the rosco_m68k project on hackaday, and the maintainer of that project had a wish to use KiCad. So I spend a few hours on it to port an Eagle project into KiCad, and in the mean time experimented a bit with buses.
Now there is a Data bus with local labels attached to a hierarchical label like so:
I imported the hierarchical label into the main sheet, and also did that with other sheets and connected them together:
And it all seems to work.
I’ve read before that this is not (fully?) implemented (yet), but why then is it described in the official KiCad V5 manual? I am currently using: Version: 5.1.5-52549c5~86~ubuntu18.04.1, release build. No nightlies or experimental builds.
The project I just pulled from github is free of DRC errors:
git clone https://github.com/roscopeco/rosco_m68k
However, If I disconnect the address bus on the main sheet I get DRC errors on the PCB:
So these “advanced bus” things are at least partially implemented in KiCad. I am aware that this is an example of the deaf leading the blind. I do not have much experiences with buses, while for Rosco_68k it’s his very first introduction to KiCad.
@Rene_Poschl: I can distinctly remember you writing this was not implemented (yet) in KiCad a long time ago (2 or 3 years?), when did you last check what is actually implemented in the current stable version of KiCad?
The vector styles have always been in KiCad (at least since version 4, i have never used a version before that). What will come with version 6 are the group buses, intelligent fannout and other niceties.
And i am quite certain that this is not in v5 as it was announced over on Post-v5 new features and development news
I did some more reading, and the current Eeschema Manual specifically mentions KiCad V6 for the buses.
Eeschema / Tools / Bus definitions (mentioned in the manual) is also not present in KiCad V5.
So the current workaround for the “Group bus” is to use global labels.
I would suggest the use of separate hierarchical pins instead of global labels. Global labels introduce knowledge dependencies to the project and therefore limit reusability of hierarchical sheets.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.