Re: [Kicad-lib-committers] Adding a new library - lineartech

[Joachim Preissner]

Hi Carl,

yes, they could fit into existing ones. There will be only a hand full or two - 
like not fully populated QFNs, or BGA with
insulation barrier between the ball rows…

For item 5 - I found the option now ;) ( shame on me).

Best Regards
Joachim


> Am 14.05.2016 um 14:39 schrieb Carl Poirier :
> 
> 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  > 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 > >:
>> 
>> 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 > > 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 >> >:
>>> 
>>> 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 

Re: [Kicad-lib-committers] Adding a new library - lineartech

[Joachim Preissner]

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 :
> 
> 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 
> .
> 
> Carl
> 
> On Sat, May 14, 2016 at 10:16 AM, Patrik Bachan  > 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  >:
> 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  > 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 > >:
>> 
>> 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 > > 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.
>> 
>> 

Re: [Kicad-lib-committers] Adding a new library - lineartech

[Carl Poirier]

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

.

Carl

On Sat, May 14, 2016 at 10:16 AM, Patrik Bachan 
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 :
>
>> 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 <
>> joac...@tailored-ip.com> 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 :
>>>
>>> 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 <
>>> joac...@tailored-ip.com> 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 <
 joac...@tailored-ip.com>:

 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 

Re: [Kicad-lib-committers] Adding a new library - lineartech

[Patrik Bachan]

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 :

> 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 <
> joac...@tailored-ip.com> 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 :
>>
>> 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 <
>> joac...@tailored-ip.com> 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 <
>>> joac...@tailored-ip.com>:
>>>
>>> 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
>>> 

Re: [Kicad-lib-committers] Adding a new library - lineartech

[Carl Poirier]

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 
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 :
>
> 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  > 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 > >:
>>
>> 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?
>>
>>
>> 
>>
>> Am 04.05.2016 um 21:23 schrieb Carl Poirier :
>>
>> 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.