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.poirie...@gmail.com>: > 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 <carl.poirie...@gmail.com>: >> >> 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 >>> 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.poirie...@gmail.com>: >>> >>> 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 < >>> joac...@tailored-ip.com> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-lib-committers > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~kicad-lib-committers Post to : kicad-lib-committers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-lib-committers More help : https://help.launchpad.net/ListHelp
