Schematic library organization improvements #1082
Comments
|
I like the idea, and thanks for raising the topic. There are certainly some large improvements that can be made here. One thing to consider is that some symbols are generic (e.g. Perhaps the libraries could be separated into subdirectories for each manufacturer, with a naming scheme for function. Then generic libs stay in the top-level directory and follow the same function-specific naming scheme e.g.
The trouble with that is that many of the libraries currently sort by function e.g. "interface.lib" Some of these make sense e.g. "transistors.lib" where there are many parts with generic names that don't necessarily match a particular manufacturer. The way that aliases work (in the current library scheme) mean that you cannot alias parts across multiple libraries (e.g. share symbols). Perhaps someone should go through the libraries and determine if that library is best represented by manufacturer or by function? |
|
We could also have a directory structure that sorts by function:
etc |
|
One requirement should be that each library has a unique name even within the directory structure e.g.
This might also be a good reference - https://www.cskl.de/fileadmin/downloads/PCBLIBRARIES/Documentation/IPC-7351C-Land-Pattern-Naming-Convention_.pdf |
|
Few thougts before you start fundamental changes. The Eeschema library management is in change into Symbol Library Table. If the code will be "borrowed" from Pcbnew library table it will support remote GitHub libraries. And here is the whole heart of the problem: In current state of that code, where paritcular repositories are downloaded as "ZIP blobs", IMO there is no way to support subfolder structure. |
|
@keruseykaryu fair point - I am trying to get the pretty libs into a single repo (with subfolders). Hopefully the devs agree. Wayne (lead dev) has said that he does not want the new symbol libs divided into multiple repositories... |
|
I noticed a similar, erhmm, choice when I decided it was a good idea to submit a new component. I tried to raise the issue in the forum (https://forum.kicad.info/t/how-to-choose-which-library-a-new-component-goes-into/6523), but it seems good if I add my observations here as well. Note that the LM4810 and LM4811 I am talking about here are both dual headphone amplifiers, essentially beefed up opamps, sort of, but linear devices. I can think of at least three libraries to store them into, but not the one currently used for the LM4811. This raises the question for newbie contributors how to decide where to submit a new component to. I do not like to add to confusion, so I want to do this right. I have not found much detail in the KiCAD library convention (https://github.com/KiCad/kicad-library/wiki/Kicad-Library-Convention), but perhaps I overlooked it. My explanation in the forum: I am creating a new component that I want to contribute: the LM4810 by TI. Both are dual headphone amplifiers and linear components. I noticed, however, that the LM4811 is in a library called 'digital-audio'. I can understand that LM4811 being used in that context, but the only thing digital that the LM4811 has is its touch button volume control. The LM4810 does not. (datasheet: http://www.ti.com/lit/gpn/lm48101) What shall I do? Put the LM4810 in the 'digital-audio' library next to its little sister, break the family ties and put the LM4810 on its own into the 'audio' library, or would it be better to move both somewhere else (I propose into the 'audio' library)? What do you all think? m |
|
Usually when I'm faced with such a decision I go along these pathes:
Basically there is no clear ruling (at least on my side) ... Usually I look at the proposed lib and decide: If it feels OK, I leave it, otherwise I suggest another lib and we can discuss it in the PR ... I would say a good starting point is: So not really a clear answer from me ... anybody else? cu |
|
I can work with your anwers @jkriege2. |
|
If you want, just include the move from digital-audio to audio in your PR and comment on that in the PR comment ... then it should be fine (you can also ref this discussion and if I have some time I might simply review that PR ;-) cu |
|
I have done that @jkriege2 (the move I mean). It's up for review as we speak. |
|
@evanshultz i assume this has been addressed in some of the newer discussions about library reorganization. If not please reopen over at the new symbol repo |
With the massive KLC update winding down, there are a couple topics that stand out to me with may be worth discussing and resolving as a team. Certainly the below items are non-inclusive, but they're the one that jump out at me right now.
Below I've made a lot of observations but not always suggested solutions. I'm imagining a discussion where we gather ideas and identify problems that lead to a good solution rather than start with a proposed solution.
Since Eeschema is so powerful with regards to searching, some of this is less important. It seems quite easy to find the parts I want regardless of library. But there are some cases in which I may need to hunt in multiple libraries and I can only see the contents of one library at a time. And when it comes to librarians, it will mostly be behind-the-scenes for the users but improvements for us will have a ripple effect to KiCad users.
1 Libraries are divided in a variety of ways, some by type, some by vendor, some by... another method. It feels to me haphazard and without a clear structure.
There are Maxim parts in linear.lib and maxim.lib, for example.
PIC micros are in microchip_picXX.lib, but MSP430 micros are in msp430.lib and not texas_msp430.lib.
There are logic devices in 74xgxx.lib, 74xx.lib and cmos4000.lib. They could be grouped into logic_74xgxx.lib, 74xx.lib, logic_c4000.lib, etc.
Can we set up a set of rules for library names?
2 Some library names seem nondescriptive and, in my opinion, do not properly describe the library contents. If I consider all the possibilities, it would seem fewer libraries that were more specific would be better for KiCad users.
For example, what would I expect to find in dc-dc.lib? Is it DC-DC modules that form a complete voltage conversion solution? A DC-DC controller IC without the power and magnetic components? A DC-DC converter IC that does include switches and/or diodes in the package? ac-dc.lib suffers from a similar problem. It's very unclear to me what I should expect to be in that lib using the same logic as above. And consider that a flyback controller or TL494, for example, could be used for low-voltage DC-DC conversion and also an offline AC-DC converter. One option would be putting these symbols into smps_controller.lib, smps_converter.lib, smps_module.lib, etc.
digital_audio.lib has ADCs, DACs, SRCs, DIRs, and other audio parts. adc_dac.lib has, it appears, (typically) non-audio ADCs and DACs. While these names are reasonably descriptive, is there still a better way?
In a somewhat different but also related way, device.lib is also so huge that it's overwhelming. This is another library with a very generic name that would likely be better off broken down into multiple libraries. Move the transformers, and possibly the other magnetic parts, to an appropriate library. The rest break into passive.lib, diode.lib, passive_network.lib, meter.lib, etc.
Also on the topic if library names, some are capitalized and some aren't. This is minor but inconsistent.
Can we revisit the constituent symbols in the KiCad libraries to make sure the symbols are divided/grouped most usefully for KiCad users?
The text was updated successfully, but these errors were encountered: