kicad-lib-committers team mailing list archive

[Joachim Preissner <joachim@xxxxxxxxxxxxxxx>]

Hi guys,

I believe purpose driven libraries were the starting point at the very beginning of KiCad. 
I assume e.g. regul (BTW, why regul, not regulators?) should once keep all power supplies - it grew… - then dcdc and acdc evtl. were introduced -
although a SMPS is still a regulator (while regul today is for LDO only). And to almost 100% all purpose libs contain manufacturer specific part numbers
instead of generic e.g. „RS485-tranceiver“.
Looking at the file todays structure suggests that the manufacturer libs already dominate the purpose.

Well, here is my opinion and why I believe manufacturer specific libraries have their justification to co-exist.
aliasing: Functionality of ICs is getting more complex, i.e. second source and identical devices are reducing. Specifically since pinout is symbol content.
	This further reduces aliasing between suppliers. E.g. even modern LDOs do not share pinout across suppliers anymore.
maintenance: If a manufacturer finds resources to support/maintain its parts in KiCad, individual pull requests for many files is ineffective for both -
	the KiCad lib maintainers and the manufacturer. 
In my opinion purpose of ICs is something to be referenced in the tags.

While generic parts like R, L, C, D, transistors etc. are still the candidates for purpose libs (often need to follow EN-, US- etc .norms).

Best Regards
Joachim



> Am 14.05.2016 um 16:30 schrieb Carl Poirier <carl.poirier.2@xxxxxxxxx>:
> 
> Hi guys,
> 
> The inclusion of manufacturer-specific libraries predate my arrival in the project so I cannot tell. Joachim, can you come up with a list of your symbols and in which original lib you would put them, so that we can compare the different options?
> 
> By the way, there is a script for moving parts from one library to another. It's here <https://github.com/KiCad/kicad-library-utils/blob/master/schlib/move_part.py>.
> 
> Carl
> 
> On Sat, May 14, 2016 at 10:16 AM, Patrik Bachan <patrikbachan@xxxxxxxxx <mailto:patrikbachan@xxxxxxxxx>> wrote:
> Hi all,
> Why should we have separate Interface library for LTC? There is already Interface library. With separate library, aliasing is limited and same function symbol similarity is difficult to maintain.
> 
> I am not big fan of current library naming dualism purpose/manufacturer.
> Was there any special reason to create manufacturer specific libraries?
> 
> Patrik
> 
> 2016-05-14 14:39 GMT+02:00 Carl Poirier <carl.poirier.2@xxxxxxxxx <mailto:carl.poirier.2@xxxxxxxxx>>:
> Hi Joachim,
> 
> Are the LTC-specific footprints fitting in some already existing pretty libs?
> 
> As for point 5, I had never noticed it myself, so I had to ask on the mailing list. There is an option in the preferences to disable that behavior, so yes it is desired.
> 
> Carl
> 
> On Wed, May 11, 2016 at 7:14 PM, Joachim Preissner <joachim@xxxxxxxxxxxxxxx <mailto:joachim@xxxxxxxxxxxxxxx>> wrote:
> Hi Carl,
> 
> thanks, well then - let’s get it in :)
> 
> I’d suggest now to make the files 
> LTC_DataConversion, LTC_Interface, LTC_Power, LTC_SignalCondition, LTC_Timing, LTC_Protection, LTC_RF.
> There are also a few specific footprints. Should they go into the existing prettys or is an extra Housings_LTC preferred?
> 
> To item 5:
> Although the symbol is defined with fields at certain positions (e.g. centered footprint ref.) and certain alignments (left aligned
> device name and reference), when placing it in the schematic, the fields loose alignment and position (see attachments).
> Is this a desired behavior? If yes, ok - if not, is it OS related (I’m using Mac OSX).
> 
> Eventually the position of the field on the symbol has an effect on this behavior?
> 
> Best Regards
> Joachim
> 
> <schematic.png><symbol.png>
> 
> 
>> Am 11.05.2016 um 02:41 schrieb Carl Poirier <carl.poirier.2@xxxxxxxxx <mailto:carl.poirier.2@xxxxxxxxx>>:
>> 
>> Hi Joachim,
>> 
>> I had a look at your files. The library is very great and already gigantic!
>> 
>> In response to your questions:
>> 
>> 1. Yes, let's split them right away.
>> 2. That would be LTC_Power as per rules 2.X
>> 3. No not really, you simply put them close. I suggest you have a look at the Microchip_pic* libraries as an example.
>> 4. Yes, go for (a) (our libs are not consistent on that matter however). Also, don't put the exposed pad on the symbol. The footprint name will already indicate it in most cases by containing a "-1EP" as per rule 7.3. You can make the symbols much smaller as well.
>> 5. I'm not sure to understand your question.
>> 6. Using aliases is the way to go.
>> 
>> Please clarify question five so we can discuss it!
>> 
>> Regards,
>> 
>> Carl
>> 
>> On Thu, May 5, 2016 at 5:18 PM, Joachim Preissner <joachim@xxxxxxxxxxxxxxx <mailto:joachim@xxxxxxxxxxxxxxx>> wrote:
>> Hi Carl,
>> 
>> Google is rejecting the zip due to the .lib files inside.
>> Please accept the .txt renamed zip - provided it passes the gmail filter.
>> 
>> Thanks & Regards
>> Joachim
>> 
>> 
>> 
>>> Am 05.05.2016 um 21:48 schrieb Joachim Preissner <joachim@xxxxxxxxxxxxxxx <mailto:joachim@xxxxxxxxxxxxxxx>>:
>>> 
>>> Hi Carl,
>>> 
>>> well the easiest way to get an idea about my work in progress might be a look into the attached project. It should work out
>>> of the box. It includes a bunch of (partial) schematics to prove the symbols support a proper component placement.
>>> 
>>> To the zip I also added the LibraryRules.txt file with a few open questions I’d like to discuss in advance.
>>> The current lib reports ~500 parts. I’d suggest to even start with several files.
>>> Many OpAmps are defined as aliases of generic units "OpAmp…", since they share all the same pinout often across all suppliers.
>>> I’d appreciate your opinion on this approach.
>>> 
>>> My preferred symbol type is e.g. the LT3991 on page DC-DC-1. The exposed pad is also visually indicated on the symbol by the shaded square.
>>> 
>>> Further below I just copied my few questions from the included file…
>>> 
>>> Best Regards
>>> Joachim
>>> 
>>> Initial Questions:
>>> 1. Provided the library will grow beyond 1000 parts, should it be split already at setup?
>>>     Lineartech_Power (all power, LDO, Switcher, input protection, etc.)
>>>     Lineartech_Mixed (mixed signal, ADCs, DACs, interfaces, etc.)
>>>     Lineartech_Signal (pure analog signal conditioning, OpAmps, comps, references, etc.)
>>>     Lineartech_RF (mixers, modulators, demods, etc.)
>>>     Lineartech_Other (anything not in above ones)
>>> 2. Which library name complies to the nomentclature?
>>>     LTC_power, LTC_Power, Lineartech_Power - which is preferred?
>>> 3. Should device name, reference and footprint fields be also placed on 0.1inch grid?
>>> 4. Pin names shall never overlap.
>>>     If the footprint field in the center overlaps with pin names - 
>>>         a. move footprint field out of center to a non overlapping position
>>>         b. enlarge the symbol outline
>>>         c. the footprint field may overlap pin names (since it can be re-positioned in the schematic)
>>>     I'd go for first a. then c.
>>> 5. Under wich conditions are the field locations in the symbols de-referenced in the schematic?
>>> 6. What is your opinion on the multi-part OpAmp devices?
>>> 
>>> 
>>> <LTCLIB_Share.zip>
>>> 
>>>> Am 04.05.2016 um 21:23 schrieb Carl Poirier <carl.poirier.2@xxxxxxxxx <mailto:carl.poirier.2@xxxxxxxxx>>:
>>>> 
>>>> Hi Joachim,
>>>> 
>>>> We would be very grateful for your contribution. Can you please send us a list of the symbols included in your lib? We'll first look at the library structure.
>>>> 
>>>> Right off the bat, I can tell you if your lib is passing the checklib.py script, it's a good start and probably not much will need adjustment for integrating into KiCad's library. Additionally, if you can maintain this lib over time that would be awesome.
>>>> 
>>>> Regards,
>>>> 
>>>> Carl
>>>> 
>>>> On Tue, May 3, 2016 at 6:24 PM, Joachim Preissner <joachim@xxxxxxxxxxxxxxx <mailto:joachim@xxxxxxxxxxxxxxx>> wrote:
>>>> Hi there,
>>>> 
>>>> what is the best way to add a new symbol library?
>>>> I tried it as a PR - which was closed as too large.
>>>> Over the time I created a lib of LTC parts (I'm working close with LTC)
>>>> ~500 parts.
>>>> My current files are passing the checklib.py script. There is also a set
>>>> of schematic files
>>>> available where I checked, if the pinout is practical.
>>>> I understand that reviewing each and every device in detail is very time
>>>> consuming.
>>>> 
>>>> Is there a way to a review on "generic" level or even accredit me to
>>>> maintain this lib?
>>>> Please advise.
>>>> 
>>>> Thanks
>>>> Joachim
>>>> --
>>>> This message was sent from Launchpad by
>>>> Joachim Preissner (https://launchpad.net/~v-joachim <https://launchpad.net/~v-joachim>)
>>>> using the "Contact this team's admins" link on the kicad-lib-committers team
>>>> page (https://launchpad.net/~kicad-lib-committers <https://launchpad.net/~kicad-lib-committers>).
>>>> For more information see
>>>> https://help.launchpad.net/YourAccount/ContactingPeople <https://help.launchpad.net/YourAccount/ContactingPeople>
>>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 
> --
> Mailing list: https://launchpad.net/~kicad-lib-committers <https://launchpad.net/~kicad-lib-committers>
> Post to     : kicad-lib-committers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-lib-committers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-lib-committers <https://launchpad.net/~kicad-lib-committers>
> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
> 
> 
>