kicad / kicad-symbols Goto Github PK
View Code? Open in Web Editor NEWOfficial KiCad schematic symbol libraries for Kicad 5
Home Page: https://kicad.github.io/symbols
License: Other
Official KiCad schematic symbol libraries for Kicad 5
Home Page: https://kicad.github.io/symbols
License: Other
The various RF libraries have outstanding KLC issues which need to be addressed
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.
The footprint exists (Converter_ACDC_MeanWell_IRM-20-xx_THT.kicad_mod
) but no symbol for it is present.
For more details see: https://travis-ci.org/KiCad/kicad-symbols/builds/311840123?utm_source=github_status&utm_medium=notification
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)
Discovered the problem while checking KiCad/kicad-footprints#252.
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?
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
The symbols in Symbol_MultiFunction should be merged into Sensor.lib
See old issue: KiCad/kicad-library#1864
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.
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.
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.
Currently I/O expanders are sorted into Interface_Expansion however a possible alternative name should be considered which covers:
The footprint exists (Converter_ACDC_Vigortronix_VTX-214-010-xxx_THT.kicad_mod
) but no symbols for the component.
The following issues stayed unaddressed in PR #159
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)
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.
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:
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.
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
The symbols for the following component categories need to find a good home.
The symbols have been moved into the legacy libs by PR: #57
I would like to start the transfer of symbol libraries from kicad-library to here. There are two major tasks to achieve:
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
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
I fear the footprint filters need to be adjusted for the new footprint naming convention. (Pitch -> P, ...)
Move obsolete symbols:
Many of the symbols in Video.lib
require attention to bring in line with KLC requirements.
See #12.
See #32.
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.
Hi all!
I'm just pondering a bit with the transformers in our lib. We currently have three varieties of symbols:
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
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
See #9 (comment): missing or wrong default footprints, broken FPfilters, etc.
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.
For more details see: https://travis-ci.org/KiCad/kicad-symbols/builds/311840123?utm_source=github_status&utm_medium=notification
original issue KiCad/kicad-library#443
See discussion in #31
The old motorola library still needs to be transferred from the legacy kicad-library
repo
The footprint exists (Converter_ACDC_TRACO_TMLM-10-20_THT.kicad_mod
) but no symbol for it is present.
See #11 (comment).
Items noted in that PR:
Here are some things that could be fixed.
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.
The various Xilinx CPLD / FPGA libraries have many hundreds of KLC violations and require attention. Some symbols are obsolete and can probably be removed.
See old issue: Triac symbols needs correction, or new symbo
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.
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.
https://kicad.github.io/symbols/Memory_EEPROM
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.
The footprint exists (Converter_ACDC_TRACO_TMLM-05_THT.kicad_mod
) but no symbol for it is present.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.