← Back to team overview

kicad-lib-committers team mailing list archive

Re: Adding a new library - lineartech

 

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>
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>:
>
>> 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> 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
>>>
>>>
>>>
>>> Am 11.05.2016 um 02:41 schrieb Carl Poirier <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> 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>:
>>>>
>>>> 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>:
>>>>
>>>> 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> 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)
>>>>> using the "Contact this team's admins" link on the
>>>>> kicad-lib-committers team
>>>>> page (https://launchpad.net/~kicad-lib-committers).
>>>>> For more information see
>>>>> https://help.launchpad.net/YourAccount/ContactingPeople
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Mailing list: https://launchpad.net/~kicad-lib-committers
>> Post to     : kicad-lib-committers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-lib-committers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>

PNG image

PNG image


Follow ups

References