I have my own libs for logic devices, microcontrollers, etc. now.
Updated when something new comes by.
This way I also get a common style for the components in the schematic (everybody making a device seem to have his/her own style).
Open the ‘source lib’.
Get the component and modify to your need (power pin visible and defined as inputs)
Open the ‘target lib’ where it shall go in.
Press ‘save component’
Just some minutes for each component.
Thanks for the tip. I’ve only just starting getting used to the library editor and copying components, and your right its not that slow to do either. It’ll definitely save me time in the long run with re-imports of netlists. Cheers.
Probably the best thing to do. Twenty years ago when an entire board of TTL logic ran at 5V, hidden power pins made tidier schematics. These days it is normal to see three or more logic supplies on one pcb and I would question if it still makes sense
I’m often ask for parts replacement in system designed in the late 70s. And all these new high density electronics do not survive long if you go high off the ground. Radiation destroys these small structures.
Sold some ceramic 80286 to the NASA not long ago.
There are also components that look like an ‘normal’ ic, but the logic inside is built of small Tetrodes.
The lifetime is another problem if you have to think in decades. Bad with that ‘new’ stuff.
It definitely does but needs to be done right. See how it is done in EAGLE for a good example. It makes the schematic much tidier and allows e. g. creating separated decoupling sheets with ease.
Something as described in this tutorial?
In short: multi unit symbol with an extra unit for power pins. (Has drawbacks in the current library file format that will be fixed in future versions. We hoped it will be included in v5 but this seems very unlikely at the moment. Most likely in v6 or in the worst case even later.)
We library maintainers see this as the best option with the current symbol library format. In fact, new symbols are not accepted with hidden power pins. (Sadly nobody volunteered to fix the current 74xx lib. Are you prepared to do it?)
Could it be scripted? A chance to practice my Python-fu…
We need a new symbol name or risk havoc with existing designs
old designs could use the rescue feature. (Or do i understand this feature incorrectly again?)
The library is also only rolled out with a new release (The next one would be 4.0.7). The current symbols live on in the commit tagged as 4.0.6.
This way one could download the old lib and use it to rescue old projects manually if the rescue feature does not work as intended.
If this rescue feature does not work as i think, we librarians might be screwed any ways. Especially after the recent major updates to the opto, regul and linear libs.
Of course. The lib file is text based, so one could write a parser for it and change the symbols in the desired manner this way.
I’m just not sure if it would be less work than doing it manually. Simply changing the visibility of the power pins does not correct these symbols.
In short - yes. In a more elaborate way it is slightly more than only “extra unit for PWR pins”. It is also about making a subtle distinction between that “extra” unit and “regular” units. In EAGLE the supply units with their pins are hidden from schematics by default but automatically connected to their respective nets. Similar to what KiCAD does with power pins. Yet, unless I am mistaken now, the unused (not invoked in EAGLE terms) units are not automatically connected in KiCAD? Once this is solved I can imagine “fixing” the lib(s).
Is this a new feature? I never knew this was possible in eagle. (I used version 6.5)
I’m personally not a fan of auto connecting anything. Everything should be explicitly shown in the schematic. (Everything else is too error prone.)
As stated above, currently we don’t have much options. What can be done with the new library format remains to be seen.
@jkriege2 had a suggestion which I think is better, rather than process the current library (I did that with the opto library to fix some graphics) which can get messy, and tends to be a one shot thing, write a script to generate symbols from a text file. This means the style can be altered in the script, and easily regenerate the components. Also, it should make adding new components easier, especially if data for these can be generated from somewhere.
I created a basic script, it generates components like this
from a text file like this
COMP 74xx574 IC
UNIT
2 D1 I L
3 D2 I L
4 D3 I L
5 D4 I L
6 D5 I L
7 D6 I L
8 D7 I L
9 D8 I L
SPC L
11 CLK CI L
1 ~OC I L
19 Q1 O R
18 Q2 O R
17 Q3 O R
16 Q4 O R
15 Q5 O R
14 Q6 O R
13 Q7 O R
12 Q8 O R
END
UNIT PWR
20 VCC P T
10 GND P B
ENDNo, it’s not a new feature. In fact I don’t remember it not being there.
To be frank, I never encountered any errors related to this feature. One needs to remember what kind of supplies are needed and used and if something’s forgotten or misconnected then ERC flags this out. It’s really useful and IMHO the way to do this kind of things. Littering the schematics with dozens of supply symbols and/or bypasses is definitely not a good idea. And currently KiCAD does this too. Although in a way that leaves open wishes.
[quote=“Rene_Poschl”]As stated above, currently we don’t have much options. What can be done with the new library format remains to be seen.
[/quote]
I find the “eagle way” very much the way it should IMHO work. Not that I am a great fan of EAGLE. Just seems to be noticeably better than what KiCAD offers now. And if the extra flag for units (“gates” in EAGLE speak) is implemented, then converting the lib(s) should be possible with a kind of script.
What about adding a “_PWR” suffix or something like that?
One problem I have discovered, is that if I forget to place the power unit, there are no DRC errors, and nor does pcbnew flag any errors. We could really do with a “mandatory/auto place” flag which is what @silverdr may be referring to. I never used EAGLE long enough to figure out how it handles units.
(Emphasis mine.)
I agree. In general it’s considered questionable practice to simply leave all unused pins completely disconnected. In many (perhaps the majority) of cases, the manufacturer cautions you to terminate unused input pins in some way. Placing only one section of a multi-unit part goes against that guideline.
If the suggestion by @Andy_P was implemented it would force you to place ALL sections of a multi-unit part, and either connect the pins or mark them with the “Unconnected” flag. If one of those sections happened to be the “power unit”, you’d be forced to deal with it - either make connections, or explicitly mark it as unconnected.
OK, I’ll concede that this “clutters” the schematic a bit. In practice there is almost always some white space along an edge of a schematic sheet where you can tuck a few “power units” along with their associated bypass capacitors, and maybe some of the ancillary power stuff (switches, fuses, pilot lamps, current sense resistors, divider networks to sense rail voltages, etc).
Dale
This is precisely what brought me to this topic. I am currently forcing myself to migrate everything to KiCAD and this was one of the major things that hit me. Currently one can create a pretty complex schematic, manufacture the board, populate it etc. only to discover that [some] power lines are missing. A thing that should never happen when using ERC/DRC!
If there is e.g. a logic chip with interchangeable gates (“units”), one mustn’t be forced to use all the units. Unconnected/“missing” units should not be flagged as an error. It’s the unconnected supply “units” that should be flagged, even if neither “invoked” nor visible. That’s the difference I wrote about when writing about making a distinction between “regular” and “power” units. Power units should be connected automatically to their respective nets, similar to what KiCAD currently does with hidden pins but if their nets do not exist (i. e. there is nothing to connect them to) this should raise the error flag. Those units probably don’t have to be called “power” as in EAGLE nor “supply”. It could be called something like “required” for example.
I usually draw all of the spare units and power units on a special page. This makes it easier for someone else to figure out if there are spare gates etc for a modification.
Drawing the power units together makes it simple to figure out if there is enough decoupling
+1 I was once told I over documented code. I rarely code. Go back after a year and tell me I over documented my code. What is obvious today is a head scratcher tomorrow.
Unfortunately, KiCAD makes it difficult to simply add a page where you collect unused sections, place your general notes, summarize revision history, etc. (Especially that Note saying, "Last Ref Des used . . . . Unused Ref Des . . . . "!)
Dale
So very much true!
Personally I usually place all the “units” on the dedicated portion of the schematics anyway. I consider this to be one of the so-called “best practices”. Similarly to you I guess. One reason for that is that I may not want to leave them “floating” in the end. Another is that I can always quickly check and see what units I have still available in case I want to do some changes to the design that would require additional units. The same applies to “power” units. I usually place them if not for any other reason then because most of the time I need to add bypasses anyway. So - all of those are very much in line with your views and I fully agree with you. Now, having said that - I still believe that while “best practices” should be encouraged, they must not be enforced. That means that it is not an error if I don’t put an unused unit on the schematic (for any reason). It is not an error as long as I know what I am doing and it doesn’t break things. It might generate a warning at best but I certainly wouldn’t like to be forced to do things I know I don’t have to in order to have a working design. Summing up: warning - fine, error - please no.