kicad / kicad-symbols

Official KiCad schematic symbol libraries for Kicad 5

⚠️ 301 Moved Permanently

Location: https://gitlab.com/kicad/libraries/kicad-symbols

kicad-symbols's Issues

Where should chips go that hold a unique id?

Currently we have 3 such chips from Maxim. Where to put them?
Example chip: http://pdfserv.maximintegrated.com/en/ds/DS2401.pdf

Edit: maybe something like Memory_ReadOnly, or Periphery_ID

Symbols for spice simulation need different pin numbering than used for connecting to footprints

Sadly there is (at the time of writing) no way to define different pin numbers for spice simulation and footprint connection. As ngspice seems to be inflexible with regard to pin numbering we might need to add specialiced symbols for simulation purposes.

Original discussion with more details: KiCad/kicad-library#182

Edit: Ideally this is fixed by introducing a new abstraction layer between symbols and simulation models. But this will have to wait till version 6. (Or even later)

Issues with Power Protection lib

• Some symbols have off grid pins
• Footprints are linked that do no longer exist under that name

For more details see: https://travis-ci.org/KiCad/kicad-symbols/builds/311840123?utm_source=github_status&utm_medium=notification

Problems with regulator libs

• Wrong footprints assigned.
  • Converters_DCDC_ACDC has been split in Converter_DCDC and Converter_ACDC
  • multiple symbols reference Package_TO_SOT_SMD:TSOT-23-6_MK06A, this does not seem to exist under that name any more.

Electrical pin types for some of these symbols might be wrong.

More details see travis report of the PR that transferred these libs.

Wrong pin description for XMega C4

original issue KiCad/kicad-library#443

Transformers library

Hi all!

I'm just pondering a bit with the transformers in our lib. We currently have three varieties of symbols:

1. Symbols for specific transformers with footpritns linked (these are fine and mostly have a nice style already!
2. some generic transformers in device.lib, but without distinction between air/ferrite/iron-cores (diferent symbols) and with rather arbitrary pin-numbers. Also these use very old style with huge coil-curls.
3. Generic Tranformer symbols TRANF1-TRANSF8 in Transformer.lib with same pin-numbering as in item 2, nicer style but no metadata etz. also there are no variants with case/shielding-pin, which might be useful in some cases.

Therefore I was thinking whether we should come up with generic transformer symbols that cover all cases in device.lib. Naming could be e.g.:

  Transformer[_<NP>Pri][_<NTP>TapPri][_<NS>Sec][_<NTS>TapSec]_<Air|Iron|Ferrite>[_Case]

  NP = number of primary coils without tap (2-pins)
  NTP = number of tapped primary coils (3-pins)
  NS = number of secondary coils without tap (2-pins)
  NTS = number of tapped secondary coils (3-pins)
  _<Air|Iron|Ferrite> = core material
  [_Case] = presence of case/shielding-connection pins

For the numbering I would number primary coil-pins 1,2,3,...,18,19 and secondary coil pins 21,22,23,..., The shielding pin would be 0 (if present). This would leave us with enough pin-numbers for all variants (also multi-tapped, although I'm not sure how to encode these in names, maybe _<NT2P>DblTapPri ...)

The problem we are left with then are the footprints: Either we adopt a generic scheme (like done for switches) with above pin-numbers and somehow the same encoding in the names, so FPFilters work, e.g. Transformer*1Pri*2Sec*Case* could filter out all transformers that have 1 primary and 2 secondary coils. But if manufacturers have then two or three types of trafos in one package, we would have to duplicate that footprint with different pin-numbering and would essentially encode the symbol in the footprint (not so nice IMHO).

Alternatively we see the generic symbols as templates only that people can copy to Transformer.lib and the renumber the pins as appropriate for their type of trafo. We should then remove any FPFilters from the generics. (seems to be the better option to me). I would like to see these generic symbols in device.lib and not in Transformer.lib to make it even clearer what they mean.

What do you all think on that?

Best,
JAN

Symbols as I would propose them:

Existing Symbols in device.lib

Existing Symbols in Transformer.lib

Separate former linear library physically and logically

I reworked the whole lib but separated symbols logically, so some footprints were not available for all ALIASes of a symbol. Each symbol should be unique both logically and also physically.

Also merge the following:

• KiCad/kicad-library#1858
• KiCad/kicad-library#1611

Mistyping in pin name of microchip/pic16f145X ICs

originally reported by @fredbar in issue KiCad/kicad-library#750

---

Small thing. The TX pin on RC4 is written as TK.
Corrected on all members of the family and checked also all libs for same mistake.
Pull request on the way.

Issues with audio lib

• Some symbols have illegal footprint fields (not of the format [lib]:[footprint])
• Some have footprints assigned that do not seem to exist
• Off grid pins
• Some symbols have no entry in the dcm file
• Split lib into:
  • audio_adc_dac.lib
  • audio_codec.lib
  • audio_misc.lib

For more details see: https://travis-ci.org/KiCad/kicad-symbols/builds/311840123?utm_source=github_status&utm_medium=notification

KLC complient symbols for HDMI connectors would be a nice addition.

Discovered the problem while checking KiCad/kicad-footprints#252.

Logic_74xx:74HC7014 has no power pins

Don't know how this got past peer review (!), but pins 7 and 14 are missing.

I will address this issue in an upcoming Logic_74xx.lib refresh.

Video Library needs KLC fixes

Many of the symbols in Video.lib require attention to bring in line with KLC requirements.

INA138/INA168 Schematic symbol has incorrect pinout

See old issue: KiCad/kicad-library#1864

Memory_EEPROM contains some NXP MCU

https://kicad.github.io/symbols/Memory_EEPROM

• for example: MC68HC11A0CC

Naming for expansion devices

Currently I/O expanders are sorted into Interface_Expansion however a possible alternative name should be considered which covers:

• Port expanders
• Shift registers

Missing symbols for Vigortronix VTX-214-010 family

The footprint exists (Converter_ACDC_Vigortronix_VTX-214-010-xxx_THT.kicad_mod) but no symbols for the component.

RJxx symbols are oriented with their pins downwards instead of towards the right like other connector symbols

See discussion in #31

Missing symbols for TRACO TMLM10 and TMLM20 family

The footprint exists (Converter_ACDC_TRACO_TMLM-10-20_THT.kicad_mod) but no symbol for it is present.

Transferring symbol data

I would like to start the transfer of symbol libraries from kicad-library to here. There are two major tasks to achieve:

1. Library Reorganization

The new libs will be sorted by function. Outline of examples for new library names - KiCad/kicad-library#1402

This can be handled (mostly) by script. We just need to work out which symbols to transition.

My script for managing this can be found here - KiCad/kicad-library-utils#184

2. Footprint Association

I am working on another script which will look through all the symbol files and work out which footprint associations need fixing. I'll have a PR up for that one soon.

Both of these steps can be performed for individual libraries, to make it easier. I will make a TODO file in this repo.

This means that once a library is marked as "complete" we can not accept any changes to it on the kicad-library repo

Issues with "Singles" libraries

Sounds like a relationship problem...

Many of the libraries merged in #13 do not have correct footprint associations. These need to be of the form <Library>:<Footprint>, and they also need to match existing footprints in the official footprint libs.

Symbol naming guideline

Mostly already included in KLC v3.
original discussion see KiCad/kicad-library#1398

@evanshultz if everything has been included in the new KLC feel free to close this. Otherwise please add a short summary of the missing parts.

Find a better name for a combined lib for optical interruption and (optical, capacitive, ...) proximitry sensors

Currently named as Sensor_Proximity.

Combining these two types of sensors makes sense because all of them detect the presence of some external part.

Other suggestions have been Sensors_LightBarrier or Sensor_PhotoInterrupter. But these might be to specific to only optical interruption sensors.

Issues with DSP libraries

See #9 (comment): missing or wrong default footprints, broken FPfilters, etc.

Indicate on the schematic symbol the physical motion of a potentiometer

See the previous discussion at KiCad/Potentiometers.pretty#23.

Let me summarize the issue here. Let's use an audio volume control as the most basic and easy-to-understand circuit that surfaces the issue. In this case, pretend there is a rotary volume control which should make the music louder when turned CW and quieter when turned CCW.

Here is a circuit fragment:

The "CW" and "CCW" text allows the user to know how the wiper will move when the schematic is being constructed. The wiper must be at the top when the pot if fully CW so the signal nearly passes through the pot, and when the volume pot is turned fully CCW the wiper should be at ground so no signal is present at the second opamp.

Without these pieces of text, the schematic designer has no way to know where the wiper will be when the pot is fully at either end. The only way to sort it out would be to design the schematic, place the parts on the board to see ratsnest (routing is optional), and then trace out the connections while reading the pot datasheet. Things will work out half the time, and the other half of the time the user will need to flip the pot symbol so the ends of the element are reversed. It's truly a random 50-50 event.

By adding the CW and CCW text, and adhering to a standard in the library, we can guide the user to the physical behavior of the pot at the schematic level, allowing reasoning through the desired circuit operation and then properly connecting the pot terminals. No more guessing and going back to fix the schematic (netlist) for things the user could not have possibly known before layout.

There are other types of pots, too, besides rotary ones. Slide potentiometers are one example. In that case, instead of "CW" and "CCW" the pot pins would need a different name. But in the end the user will still need to know which way the wiper is moving as the slide pot is moved. Otherwise you're back to rewiring the schematic. Or, in this case, one could flip the slide pot footprints 180 degrees.

I hope this makes the problem more obvious. Does it help? Some nomenclature needs to be developed for the pot pins, then this needs to be codified so it's not broken in the future and KiCad users will have confidence in the pot symbol and footprints. Likely some footprints need to be updated as well.

Footprint filters need to be adapted for the new footprint naming conventions

I fear the footprint filters need to be adjusted for the new footprint naming convention. (Pitch -> P, ...)

Issues with logic libs

See #11 (comment).

Items noted in that PR:
Here are some things that could be fixed.

• There are no packages or package types (just "SSOP" without pin count) listed in part descriptions
• No supply voltages given in descriptions
• Some hyphens in FPfilter, such as 74LVC1G02
• Some descriptions use all lowercase letters
• 74LS09 is describes as "Open Collect" instead of "Open Collector"
• The datasheet links in Logic_74xx don't work for me
• At least in the IEEE libs there are some lowercase letters for pins names; do we allow that?

There was a recent discussion about having a separate power symbol for even single-gate logic. I still support this so I want to resolve that discussion. I believe @jkriege2 was with me on this point.

Missing alias for DS2401

Should smart fets (intedned for switching batteries) be placed under power_management or transistor_smart (inteligent)?

Some intelligent FETs have been moved into power_management via pull request #42. I merged it to get all the other contributions in there. But i feel the question about smart fets in general still stands.

Infineon (which hosts the datasheets for internal rectifier datasheets, might mean they own them.) places all their smart (intelligent) fets into the smart fet category. (No matter their originally intended application.)
https://www.infineon.com/cms/de/product/power/smart-low-side-high-side-switches/

ITS428L2-DS has the exact same features as IPS6011 (including reverse battery protection.) The later is one of these transistors placed into power_management.

RC1 Tagging

I got notification from the devs that tagging release candidates of the library would be helpful. Unfortunately I do not know when RC1 will be branched.

Incorrect type of R,S pins in 4013, 4027 in Logic_CMOS_4000

A user on https://forum.kicad.info/t/new-logic-cmos-4000-library-4013-symbol/8923 has noticed incorrect pins on these parts :

The R and S inputs on the 4013 in the new library are marked "active low". HEF4013B has active high C(lear) and S(et) inputs, according to the Product spec.

This error was introduced when the parts were scripted with symgen.

I will submit a PR to fix this soon.

How do generic components now work?

I have been using kicad-symbols as my library now in addition to kicad-library.

It seems the generics are either not put in yet or using a different convention. I am trying to understand it.

Currently, the generics of inductors, resistors, caps, etc... are all under the pspice library (only non-CamelCase library) and the diode and capacitor at least are unusably large. Is it against the convention to put all passive components around the size of the resistor so common components like capacitors are actually usable with most IC schematic components?

Pictured is the difference.

Missing symbols for TRACO TMLM-05 family

The footprint exists (Converter_ACDC_TRACO_TMLM-05_THT.kicad_mod) but no symbol for it is present.

Motorola Library

The old motorola library still needs to be transferred from the legacy kicad-library repo

Issues with sensor libs

See #12.

Missing symbols for MeanWell IRM-20 family

The footprint exists (Converter_ACDC_MeanWell_IRM-20-xx_THT.kicad_mod) but no symbol for it is present.

Issues regarding micro controller libs

• Some have very long pin names. Remove alternative functions from them.
• Some footprint fields don't include the lib name
• Some footprint filters are missing
• Some of the assigned footprints do not exist that way any more

Directory structure

There are now LOTS of libraries in a flat structure which makes them difficult to parse. Now that we are organizing by function, should we also split by directory (for large groups, at least). Each library must be uniquely named within the entire directory structure

• Sensor
  • Sensor_Pressure
  • Sensor_Temperature
  • Sensor_Motion
• MCU
  • MCU_Cypress
  • Microchip
    • PIC10
    • PIC12
    • PIC16
    • PIC18
    • PIC24
  • Texas
    • MSP430
    • Tiva
  • ST
    • STM32F3

Issues with remaining symbol libs

See #32.

• Improper FP filter syntax
• Missing/wrong default footprints
• Footprint library names are wrong
• Footprint filter formatting
• Ensure all pin types are correct (BIDI for SDO pin, for example)

Xilinx libraries need work

The various Xilinx CPLD / FPGA libraries have many hundreds of KLC violations and require attention. Some symbols are obsolete and can probably be removed.

Memory symbols require extensive rework

• Many lacking good description
• Many lacking footprint information
• A lot of KLC issues to fix

Move obsolete symbols:

• Memory_Controller
• Memory_EEPROM
• Memory_EPROM
• Memory_Flash
• Memory_NVRAM
• Memory_RAM
• Memory_ROM
• Memory_UniqueID

Triac symbols needs correction, or new symbol

See old issue: Triac symbols needs correction, or new symbo

Broken datasheets for NXP logic ICs

Originally reported by @bobc in KiCad/kicad-library#1802

---

NXP logic products are now transferred to Nexperia, so a lot of datasheet URLs have stopped working. :)
It should be possible to fix with a global search/replace.

Remaining issues after power_management lib transfer

The following issues stayed unaddressed in PR #159

• LTC4357DCB, LTC4359-DCB, LTC4365TS8, RT9701, PM8834* have only 1 fpfilter, but no footprint set
• fix LTC4007 footprint+fiilter
• fix LM5051, LT1641-1, MIC2026-1BN fpfilter

Some MCU symbols are very large because of long pin names

Currently some MCU symbols still list all alternative functions in their pin names. This results in very large symbols. A better approach is to reduce the pin name to the main identifier.

device.lib missing

Hi!

I just noticed, that we do not yet have device.lib/.dcm ported ... What's the status on that one, or did it slip through?

JAN

KLC issues in RF libraries

The various RF libraries have outstanding KLC issues which need to be addressed

touch screen controllers

Several touch screen interfaces are currentlx in Driver_Display.lib.
I would put them into Interface_HID, as they do not SRIVE a screen, but interface the HID-component (HID=Human Input Device)

Sensor_MultiFunction should be merged into Sensor

The symbols in Symbol_MultiFunction should be merged into Sensor.lib

Original discussion about the orginazition of this repo

KiCad/kicad-library#1402

Find libs for symbols in legacy/microchip

The symbols for the following component categories need to find a good home.

• Serial to parallel converter
• I2c and SPI I/O expanders
• Clock divider
• A/D converter (I assume this should be moved to adc.lib)

The symbols have been moved into the legacy libs by PR: #57