Let’s imagine I have two hierarchical sheets on my main page. One has an output pin called OUT[0…63] and the other has IN[0…63]. I’d like to connect the two.
Right now I’m doing this by expanding the entirety of one bus, and then using net ties to connect to to the other bus, like this:
You can rename a bus at the moment it goes into a Hierarchical sheet.
So on the top level sheet you name the bus: IN_[0..63], and in the hierarchical sheet you name the bus OUT_[0..63] and then connect the bus on the top level to the hierarchical sheet connector.
A while back I posted an example project with all sorts of bus behavior in:
For posting on this forum, the forum software does some unfortunate translation. When you type two dots (which is what KiCad needs in a vector bus) then it displays three dots after submitting your post. You can prevent this by enclosing the name with backticks as both Qu1ck and I did.
Your way nets will get single name at PCB while it looks that OP wants to have different net names in part of his PCB then at the other part. If he didn’t wanted this then even connecting each wire to wire he would connect them directly and not by net-ties.
Yes, true. In KiCad a net can have only one net name. If you want to preserve the net names then you have to use net ties.
Without net ties, ERC gives a warning that it renames a net because KiCad does not know whether the connection is intentional or not. This is not an error, and it can be easily suppressed if it’s intentional.
Adding net ties, also results in having to place net ties on the PCB.
I don’t know why the gtaubman added net ties. did he do it to preserve net names, or was it only to suppress the ERC warnings?
Edit: Changed wording of the last sentence to make it clear that I now how net ties work, but am not sure why gtaubman used them in this way. (Edit done as a response to JamesJ’s followup post.)
I don’t know why the net ties were added. Is it mandatory to preserve net names, or was it only to suppress the ERC warnings?
They are primarily there for separating areas of the schematic that are connected electrically, but require logically separate routing. E.g. for managing multiple grounds (such as analog and digital grounds) - these are all ‘ground’, but should only connect together at one star grounding point. It makes that layout intent clear from the schematic perspective.
Thank you for your responses! It sounds like my net tie solution isn’t necessary as I don’t actually need the net names to be different. I was just doing it to suppress ERC warnings. Instead I can just connect a bus from one hierarchical sheet to the other like this:
I guess it’s safer to give the bus a name in the top level sheet too. I don’t use buses much and I vaguely recall some problems when I did not name the top level bus, but that may have been a bug too. It was too long ago to recall details. Bugs may have been fixed, implementation of KiCad may have changed subtly. It’s also easy to just try it out and examine the results.
It depends really. You need to look from other people’s perspective and attempt to make the schematic as readable for others as you can. If you think that somebody else can understand what the bus is supposed to connect, you don’t have to.
If you have 5 sheets connected with a bus and every sheet connects with a hierarchial label named I2C, I can see in every sheet that I am looking at an I2C bus. Than I don’t need extra labels to comprehend.
Sometimes I add labels when I also need to use prefixes for busses. If I have 3 different DCC busses (don’t ask) than I may to want to explicetely specify some extra information in root schematic with an additional label.
In this schematic I perhaps could add labels, but it is IMO too simple/unjustified. The DCC busses comming out the atmega sheet are TTL level, the other two are higher voltages. I did not specify, but I could. And I would prefer to use plain texts instead of an actual label.
It is sorta usefull outside of model railway as well. You can transfer power and information over 2 whole conductors. I know one guy who had to use DCC for a motor cycle because of it’s limited wiring.
Having programmed Xnet, Lnet and DCC. I found that DCC is the only protocol which is… well somewhat normal. All the others have such strange elements embedded…
I can see that, but from a software perspective, it’s horrible. The PWM nature of it means that the standard, and in most cases well refined UART peripherals on modern microcontrollers can’t be used.
Some advanced micros like the NXP LPC4357 have a peripheral that might be able to recover data from the PWM, but I’ve not tried.
The use case on model railways does need to be polarity agnostic, but for other applications, where the polarity can be fixed, you can easily inject DC onto a standard (for example) RS485 pair.
The physical electronics are no more complicated, but it does allow a standard UART peripheral to be used, with all the advantages - on my controller to power station link, I used 100 byte fixed length messages, sent by DMA. I just compose a message, and call a single HAL function, and that’s it. At the receiver, I get an interrupt and then 100 byte message magically appears in a buffer.
The DCC on the other hand is akin to bit bashing I used to do for SPI on 8051 devices.
