Why no box for the power unit symbol? GEC and RACAL always drew it and that is what I am used to.
eagle does it without the box.
It allows you to overlay the power unit with other units and make them visually into one unit. (If both the power unit and logical unit are designed to allow for that.)
I can draw a box, or no box…
So far there are about 5 different options people have expressed, which could create up to 32 possible variations for one device! Oh, and some people said they would like smaller symbols or pins, so that is another set…
I think we would have to settle for one set for an official library, if it is possible to reach a consensus! Sufficiently motivated users could run the script and create their own versions.
I reverse engineered all the parts in 74xx.lib to create a data file, which can now be used to generate all the 74xx parts at will. possibly the data file might be easier to maintain than the 74xx.lib.
A typical entry looks like this :
COMP 74LS02 U
FPLIST
SO14*
14DIP*
DESC Quad Nor2
KEYW TTL Nor2
ALIAS 74HC02
DESC Quad Nor2
KEYW HCMOS Nor2
ALIAS 74HCT02
DESC Quad Nor2
KEYW HCTMOS Nor2
ALIAS 7402
DESC Quad Nor2
KEYW TTL Nor2
ALIAS 74LS28
DESC Quad Buffer Nor2
KEYW TTL Nor2 Buffer
UNIT NOR
2 ~ I L
3 ~ I L
1 ~ ~O R
UNIT NOR
5 ~ I L
6 ~ I L
4 ~ ~O R
UNIT NOR
8 ~ I L
9 ~ I L
10 ~ ~O R
UNIT NOR
11 ~ I L
12 ~ I L
13 ~ ~O R
UNIT PWR
7 GND P U
14 VCC P D
END
4 Likes
Yes this is true
by definition this will mean that some people will be unhappy. (one size fits no one)
I would vote that you get the final vote because you are prepared to put in some effort.
(As long as you do not violate the current klc without talking to the maintainers first. We are quite flexible iff we are asked nicely.)
1 Like
I don’t really mind what the official lib looks like, I can always generate my own version! I think I have covered all points in the KLC. My main motivation was to remove the hidden power pins, I did a design with mixed VCC, and ended up redoing a lot of symbols. For things like hex inverters/buffers, I prefer all the gates in one block instead of separate.
I think I would give most weight to the library maintainers, they will be carrying the can, but there is not always consensus there 
2 Likes
I would rather see alternate footprints of standard individual unit and “in a block” than the DeMorgan, has anyone ever used these on a real schematic rather than using schematic for teaching drawings?
Why not have both?
In my personal lib i have one symbol that is a single unit symbol and one for multi unit. (i use the suffix _MU for the multi unit version. The symbol without suffix is the single unit symbol)
Well we make it up as we go. We try to way up all possible options in the hope to come to a solution that benefits the largest number of users. (And still makes sense to us.)
Sometimes we find out later that our idea was not that bright.
Just recently we reverted the rule about the naming convention for symbols concerning different packaging options. (Now we use the manufacturer code for this, previously we thought it might be a good idea to have it human readable.)
Feedback from users can help a lot here.
I only need one I can create a syntax to generate both using the same data, I will need to rework the script for that.
Edit: I’ve put my code on https://github.com/bobc/kicad-symgen It’s a raw cut, so not suitable for regular use yet. I wanted to put it somewhere before the heat melts my PC!
2 Likes
Hey, I worked briefly for both GEC (Chelmsford) and Racal (Manor Royal), small world
The spacing between the power pins on @bobc’s units above doesn’t look like it matches the body width of the other units.
While I’m not too concerned about the official lib, if it’s not to my liking I just create my own anyway. Personally I would rather have the power pins attached to one of the units of a multi-unit component, it doesn’t matter which unit as they will all be on the schematic anyway. But I do have one question, will these symbols that are script generated be editable in the library editor? I thought there was an issue with all the units having to be the same?
Everything that can be used in eeschema should be editable in the library editor. (If you find something that isn’t, that woud be a bug.)
Each symbol has an option that enables this. Its called “all units are not interchangeable”
1 Like
I was at GEC McMichael in Slough, Racal Datacom in Hook and then Racal Research in Reading
Yes, I’m aware of that option, so in the case of 4 interchangeable AND gates they are no longer interchangeable when you add a power unit?
That’s correct. I think that means the annotation tool will not auto allocate gates to devices, or something.
Ideally, I would like to say to KiCad “these 4 units are optional and swappable; unit 5 is mandatory and not swappable”. If I can find the spec for the new schematic lib I will have a look.
3 Likes
It should not only be possible. It is often highly desirable. Requiring to connect pins that don’t need to be connected (like e. g. unused logic gates’ outputs) is under circumstances the same like requiring a completely unneeded waste of routing area which could potentially be used for connections that are actually needed. Being able to use those areas can save for example unnecessary vias or an unneeded trip around the board with a trace that could otherwise be routed where you want to enforce the unneeded connections.
You definitely should have a choice not to put on the schematic things that don’t do anything except bringing unnecessary clutter. Physical properties of the components prevent you from doing the same on the board because you can’t physically remove five gates from your inverter pack along with their associated pins (although I’ve seen designs that tried something along those lines but nothing should prevent you from NOT placing them on the schematic where they add no value.
Well - the current implementation is clearly flawed as no ERC errors are raised if for example no required supplies are connected to the component! THIS should never happen and should be addressed first and foremost!
Since supplies are not the same as functional units of the component. I believe they deserve to be treated differently in the long run. But - once more - first of all they must be “required” and errors must be raised when they are not connected where they should be.
Precisely that. We just need to remember that “optional” and “swappable” is not the same thing. One can imagine situations where optional is not swappable as well as where swappable is not optional.
No one said anything about any requirement to “connect” any pins. It would be absurd to suggest that KiCad should require you to use a component in your design. But if it is not on the schematic then you can not be explicit about the fact that it should be left unconnected.
Here we go again with this “clutter” nonsense. You are creating an engineering document, not a pretty picture. In KiCad this document describes the design of a circuit as well as the design of a PCB.
Yes, clearly I do not share your level of expertise or extent of experience.
1 Like
I removed those two sentences you referred to immediately after putting them in and I apologise for putting them in in the first place.
“unnecessary clutter” is not “nonsense” exactly because we are talking about engineering documents rather than art pieces. This is the main reason. Engineering drawings should clearly communicate the designer’s message and state clearly what is required to build the part. In order to be clear and not obscure the message they should omit things, which are either not necessary to build the part or are simply obvious. On mechanical drawings you don’t mark every right angle explicitly with 90 degrees angular dimension, do you? You’d have to if you wanted to be explicit, wouldn’t you? But this would bring the “unnecessary clutter” and is therefore omitted. This applies not only to dimensioning on mechanical drawings. The same applies for electronic schematics. Frankly, when I was working in an engineering company that does electronic stuff you probably yourself have in your car (ECUs), the guy who’d put supplies next to the logic blocks would be asked if he is really qualified to do the job he’s doing. The same if he’d put unused logic units on the schematic of an actual functional block.
IMHO there is hardly any more explicit way to tell that I don’t care about something than by NOT drawing it. Especially not drawing it among things, which I do care about and explicitly need to have connected. Again - no schematic with “unnecessary clutter” would pass a review at least in the company I worked for. And I am sure it’s not an isolated example because it seems like industry common standard and the schematics were eventually reviewed and approved by the customers, names you surely heard more than once.
The problem - once more - is not with things, which are not required and not being drawn. The problem is with things, which are not being drawn (like hidden supply pins) not raising ERC errors while they are actually required to build the working part! This needs to be addressed and corrected ASAP. At least IMHO.
The level of detail is paradoxical. If insufficient detail is provided, it can lead to assumptions made by subsequent readers. OTOH, if too much detail is present, then readers may find it hard to find relevant details.
At work we have similar debates about what should go on a drawing. One designer insists that a particular detail is part of the design and must be on the drawing, another (equally experienced) insists that detail is unnecessary for the design, and should be captured elsewhere. An example is approval ratings, they do not affect the function but affect the approval process.
There is no right answer, only techniques to alleviate the problem. What level of detail is appropriate is subjective, it depends on the author and organisation.
3 Likes
Avoiding clutter is why spare units are often put on a special (often last) sheet along with power units. This then allows any pins that should be tied for ESD reasons like CMOS inputs, to be done so. There is no need to connect to pins that can be safely allowed to float.
If you don’t make a habit of doing this, you will end up sooner or later with a CMOS input floating and causing high erratic current drain
4 Likes