search

KiCad / kicad-library

The schematic and 3D libraries for KiCad 4.0. Note that the footprint libraries are the *.pretty repos themselves. This is an orphaned repo, the news about the v5 libs, http://kicad.org/post/kicad-official-libraries/.
Other
749 stars 955 forks source link

RFC - Rearranging Symbol Libraries #1402

Closed SchrodingersGat closed 6 years ago

SchrodingersGat commented 7 years ago

Following on from the work by @jkriege2 here

Library Name Description Previous Name Notes
Basic Devices
device.lib Symbols for simple devices e.g. Resistors / Capacitors / etc. device.lib
elec-unifil.lib ???
led.lib LED device.lib
motor.lib Electric motors
power.lib Power symbols (global) special symbols library
pspice.lib Spice symbols
relay.lib relays
switch.lib Buttons and switches
Connectors
connector.lib Connectors, general purpose conn.lib Could be expanded in future e.g. connector_usb.lib / connector_JST.lib
Virtual
graphical_symbol.lib
logo.lib
mechanical.lib
Semiconductors (simple)
diode.lib Diodes
transistor.lib Transistors infineon.lib
thyristor.lib Triacs, thyristors, SCR, etc
valve.lib Valves
Displays
display_character.lib Character displays e.g. 16x2 text display display.lib
display_dot-matrix.lib
display_graphic.lib Pixel-based displays, etc display.lib
display_segment.lib 7-segment, LED bar displays, etc display.lib
Transformers
transformer.lib General purpose transformer
transformer_power.lib Power transformers
transformer_pulse.lib Pulse transformers
transformer_signal.lib Small signal transformers
Sensors
sensor.lib Sensors that do not fit other categories sensors.lib
sensor_audio.lib
sensor_current.lib Current shunts / transducers / etc sensors.lib / ir.lib / allegro.lib
sensor_gas.lib Gas sensors, various sensors.lib
sensor_humidity.lib Humidity sensors sensors.lib
sensor_magnetic.lib Hall effect, etc sensors.lib
sensor_motion.lib Accelerometers / gyro sensors.lib
sensor_multi-function.lib Sensors that sense multiple things e.g. temperature / pressure sensors.lib
sensor_photo.lib Light sensors, RGB, photoresistors sensors.lib
sensor_pressure.lib sensors.lib
sensor_temperature.lib sensors.lib
sensor_voltage.lib
sensor_touch.lib
Audio / Video
audio_adc_dac.lib digital_audio.lib
audio_codec.lib Audio Codec IC
audio_misc.lib Miscellaneous audio parts
video.lib gennum.lib
Linear Devices
amplifier_operational.lib Amplifiers (general purpose) linear.lib / analog_devices.lib
amplifier_audio.lib Audio amplifiers
amplifier_current_sense.lib Current sense amplifiers (separate to e.g. hall-effect current sensors)
amplifier_difference.lib Difference amplifiers linear.lib
amplifier_instrumentation.lib Instrumentation amplifiers linear.lib
amplifier_rf.lib RF amplifiers
amplifier_video.lib Video amplifiers
comparator.lib Comparators linear.lib
References
reference_current.lib Precise current reference references.lib
reference_voltage.lib Precise voltage reference references.lib
Power Management
battery_management.lib Chargers, etc texas.lib
power_distribution.lib e.g. load switch, ideal diode controller, hot-swap controllers, etc power_management.lib, texas.lib
power_supervisor.lib Reset monitor ICs, etc power_management.lib
power_monitor.lib Power monitoring devices
power_protection TVS, ESD protection, etc
Regulators
regulator_module_ac-dc.lib Modular ac-dc devices ac-dc.lib
regulator_module_dc-dc.lib Modular dc-dc devices dc-dc.lib
regulator_linear.lib Linear regulators
regulator_linear_controller.lib Linear regulator controller
regulator_switching.lib Switching regulators
regulator_switching_controller.lib Switching regulator controller
regulator_switching_module.lib Stand-alone switching modules
regulator_pwm_controller.lib PWM ICs
regulator_pfc.lib Power factor correction
Mixed Signal
analog_switch.lib Analog switches
adc.lib Analog -> Digital adc-dac.lib
dac.lib Digital -> Analog adc-dac.lib
digital_pot.lib Digital potentiometers xicor.lib, texas.lib
adc_dac.lib Devices with both ADC and DAC
Drivers
driver_led.lib LED drivers worldsemi.lib
driver_gate.lib FET gate drivers, half / full bridge drivers zetex.lib / ir.lib / power_management.lib
driver_motor.lib Motor control ICs texas.lib (?)
Timers
timer_oscillator.lib Timers / oscillators / crystals Oscillators.lib
timer.lib linear.lib e.g. NE555 linear.lib
timer_pll.lib PLL ICs linear.lib e.g. NE567 linear.lib
timer_rtc.lib Real time clock
Logic
logic.lib Generic logic symbols for gates / inverters / etc
logic_cmos40xx.lib 4000 series logic cmos4000.lib / cmos_iee.lib Previously split into IEC / IEEE variants. New library format could allow different graphical representation for each symbol, so users can choose which symbol they want
logic_74xx.lib 74 series logic
logic_translator.lib Level converters, shifters, etc texas.lib
isolator.lib Optocouplers / capacitive isolation / etc opto.lib, texas.lib
isolator_analog.lib Analog isolators If needed
CPLD / FPGA
cpld_xilinx.lib xilinx.lib
cpld_altera_intel.lib Altera.lib
fpga_xilinx.lib xilinx.lib
fpga_altera_intel.lib Altera.lib
fpga_actel.lib actel.lib
fpga_atmel.lib atmel.lib
Microcontrollers / Processors / DSP
mcu_8048.lib
mcu_8051.lib
mcu_atmel_avr Atmel AVR series atmel.lib
mcu_atmel_avr32 Atmel 32-bit AVR series atmel.lib
mcu_atmel_arm.lib Atmel ARM micro atmel.lib
mcu_cypress.lib cypress.lib
mcu_cypress_arm.lib cypress.lib
mcu_microchip_pic10 PIC10 series microchip_pic10mcu.lib
mcu_microchip_pic12 PIC12 series microchip_pic12mcu.lib
mcu_microchip_pic16 PIC16 series microchip_pic16mcu.lib
mcu_microchip_pic18 PIC18 series microchip_pic18mcu.lib
mcu_microchip_pic24 PIC24 series microchip_pic24mcu.lib
mcu_microchip_pic32 PIC32 series microchip_pic32mcu.lib
mcu_freescale_hc.lib Freescale HC series
mcu_freescale_coldfire.lib Freescale coldfire motorola.lib
mcu_infineon_c166.lib
mcu_nxp_arm.lib NXP microcontrollers nxp_armmcu.lib
mcu_parallax.lib
mcu_renesas.lib
mcu_st_stm32.lib STM32 micro stm32.lib
mcu_st_stm8.lib STM8 micro stm8.lib
mcu_texas_msp340.lib MSP340 micro msp430.lib
cpu_intel_x86.lib
cpu_amd_x86.lib
cpu_motorola_68000.lib motorola.lib
cpu_motorola_powerpc.lib motorola.lib
cpu_zilog_z80.lib Zilog.lib
dsp_microchip_dspic33 DSPIC33 series microchip_dspic33dsc.lib
dsp_texas.lib Texas DSP (digital signal processors) dsp.lib
dsp_freescale.lib Freescale DSP dsp.lib
soc_texas_arm.lib Texas ARM SOC (system on chip) texas.lib
Memory
memory_card.lib SD card, etc
memory_vram.lib Volatile RAM (DRAM / SRAM) memory.lib
memory_nvram.lib Nonvolatile RAM (MRAM / FRAM) memory.lib
memory_eeprom.lib EPROM / EEPROM memory.lib
memory_flash.lib FLASH memory memory.lib
memory_controller.lib Memory controller ICs memory.lib
Interface (Comms)
interface_can_lin.lib CAN / LIN interface.lib
interface_ethernet.lib Ethernet interface.lib / wiznet.lib
interface_i2c.lib I2C interface - expanders, isolators, etc nxp.lib, texas.lib
interface_lvds.lib LVDS interface.lib
interface_spi.lib SPI interface
interface_telecom Telecom interface interface.lib, silabs.lib
interface_uart.lib RS232/422/485 interface interface.lib
interface_usb.lib USB silabs.lib, texas.lib
interface_video.lib Video interface broktree.lib
RF Interface
rf_am_fm.lib AM / FM transceivers rfcom.lib
rf_bluetooth.lib Bluetooth ICs etc rfcom.lib
rf_antenna.lib RF antenna
rf_misc.lib Miscellaneous RF parts that don't fit elsewhere
rf_frontend.lib RF front-end paraphenalia
rf_wifi.lib WiFi
rf_zigbee.lib Zigbee / XBee

Edits

  1. @schrodingersgat changed library names to singular
  2. @schrodingersgat changed microcontroller_ to mcu_
  3. @schrodingersgat renamed audio_adc_adc.lib -> audio_adc_dac.lib
  4. @schrodingersgat renamed processor_ to cpu_
  5. @schrodingersgat split amplifier.lib into multiple libraries
  6. @schrodingersgat added power_distribution, power_conditioning, battery_management
  7. @schrodingersgat added more amplifier categories, added transformer categories, improved regulator categories
  8. @schrodingersgat added suggestions by @poeschlr
  9. @evanshultz divested modules.lib, gennum.lib, bbd.lib, silabs.lib, texas.lib, worldsemi.lib; noted reset ICs in power_management.lib; fixed a few typos
  10. @schrodingersgat updated power_ libraries
  11. @schrodingersgat added rf_ libraries
SchrodingersGat commented 7 years ago

How about display_matrix (pixel based displays), display_segment (bar, 7-seg, etc) then?

poeschlr commented 7 years ago

dot-matrix displays fall (for me) more in the same category as 7 segment (or better 14 segment) displays because the have a clear separation between there "letters"

I think "graphical" describes the capabilities better. Simple might not be the best name. But would you search dot matrix displays or bar displays under display_segment?

SchrodingersGat commented 7 years ago

Should we just leave it as display.lib and then see where the categorization falls as the library grows?

poeschlr commented 7 years ago

TlDr: I would split the display libs along the line of graphical/non graphical

That would make it a bit more future proof. I would aim for something where we only need to split libs again when v6 comes out. (In other words, if we think this lib might be split as soon as more symbols are added we should split it now.) If @Misca1234 carries on as he does now we will shortly reach that point. (one display symbol, footprint 3d model a week -> that sums up over the next 2 to 3 years until v6 comes out. He might also stop tomorrow who knows.)

But i might be wrong. Your call. It is hard to predict where the contributors take us. (And i'm sure we will be forced to split a few libs during the lifetime of v5 while others stay "empty". I just hope to limit this as far as possible.) I understand why limiting libs might be a good idea. (Some people would like one large lib. I'm more the fine grained type. I don't think from a maintainance point of few there are problems as long as it is easy to see where a symbol should go. There is of course the danger that there exists a component that falls into multiple categories.)

Side note, (explains my stance a bit i think): I hope that the contribution frequency stays at the current rate or even increases further. (The last year saw much more activity then the year before that. That year saw more activity than the year before, ...) A large part of that is a reduced response time between initial PR opening and first feedback (even if it is only by travis) And i think the clear KLC also helps. A clear library structure might further increase interest by contributors. (Or everybody hates us for putting the bar too high and they stop contributing. God i hope not.)

SchrodingersGat commented 7 years ago

@poeschlr I appreciate your points - if we can predict future use it is better to make the change now rather than later. I'll ponder over this one (it's way too late at night here already :) )

jkriege2 commented 7 years ago

@poeschlr There actually are analog isolators (usually called isolation amplifiers, see e.g. http://www.analog.com/en/products/amplifiers/isolation-amplifiers/ad215.html ... and we even have some in the LIB) ... and there are parts that combine an LED and an LDR, which can also be used as an analog isolator (although slow).

jkriege2 commented 7 years ago

@SchrodingersGat here are some I2C examples:

and for SPI:

jkriege2 commented 7 years ago

@SchrodingersGat What about the name logiclevel_translator.lib ... level is maybe a bit generic?

jkriege2 commented 7 years ago

About displays: I would like to see

One could think about splitting out the two special cases:

but not really sure ... what is best

Best, JAN

SchrodingersGat commented 7 years ago

Ok I have updated graphic_ and added interface_i2c and interface_spi. Time for bed :) Thanks for the suggestions.

poeschlr commented 7 years ago

About displays: I would like to see display_character (7seg, typical LCD-displays for text ...) display_graphic (graphic displays maybe also LED DOT-matrix in here)

I like that. My only problem is where do led bar displays fit here. Maybe they should go into the led lib? (Can be seen as led array. Has similarities to a resistor array.) I would put typical dot matrix displays into the display_character lib. (they can not really display graphics.) As dot matrix i see a display where there are small fields with a specific number of dots. These fields are then repeated a number of times over the display with some space in between them. Each such field is typically reserved to display one character or symbol at a time. (Very similar to how a n-segment display is build)

Edit: make it more clear what i mean only two display libs

Sadly led bar "displays" would not fit in either lib. I would suggest to move them into a led lib because they can be seen as led arrays. Putting them int the character lib might be a bit of a stretch but i can see them fitting in there as well.

poeschlr commented 7 years ago

What about relay.lib Maybe relay_mechanical and relay_solid_state? (The later is currently often in opto.lib, SSR are not really used for the same usecases as isolators.)

poeschlr commented 7 years ago

What is the difference between regulator_switching_module.lib and power_module_dc-dc.lib or power_module_ac-dc.lib (I think this came out of a suggestion by @evanshultz but i can't really follow it.)

jkriege2 commented 7 years ago

More questions:

  1. Should we split transistor.lib maybe into transistor_bipolar.lib, transistor_fet.lib, transistor_igbt.lib, transistor_ujt.lib
  2. General question: Should the generic transistor/diode/... symbols from device.lib reside there, or should they be moved to the respective specialized libs? Maybe not, as they are no good bases for ALIASes, as they don't specify packages.

Best, JAN

evanshultz commented 7 years ago

I still feel there's a level of classification missing. Libraries with ICs in them should start with ic_, such as ic_comparator.lib. Otherwise we will have libraries all spread out that are related. And it further clarifies the content of a library, so that it's clear to users that ICs are in this library.

Why not rename triac to thyristor? The explanation says it's for all thyristors, and these are pretty rare so lumping them all together should be fine. If not, it seems odd to put diacs, scrs, and other thyristors into a library named triac?

Can we fill in the expected use of the transformer libraries? We would have power transformers at the line frequency, high frequency power transformers (SMPS), gate drive transformers, audio bandwidth transformers (both high power and low power), ethernet/digital transformers, etc. How do all of those map to the libraries above? And also, how do we name transformers? If the transformer is a single-source part then we could use the MPN. But what if it's a custom or generic transformer?

I think we need audio_misc.lib or ic_audio_misc.lib. Where do SRCs go? DIRs and DITs? Audio volume control ICs? Mic preamps like THAT1583 and THAT5263. Those are parts in the market, some of them are in the library now, and it's unclear to me where they should live.

Where does a part like AD7533 go? This is an existing library part.

I would like to change amplifier.lib to amplifier_operational.lib or amplifier_opamp.lib (but that sounds weird). Otherwise it's ambiguous to me what goes into that library. Audio power amplifiers would seem to fit. What about OTA? It's better than linear.lib, but it's still not well-classified to me.

Does amplifier_audio.lib encompass linear and switching power amplifiers? Like TPA3251 and TDA7577 and MAX9710 and MAX9715? And why is it not in the "Audio / Video" section?

What exactly is in power_conditioning.lib? Is this some AC in, DC out PFC pre-regulator?

Here is your answer, @poeschlr. power_module* libraries are complete, OTS power supplies. They do come in both varieties (AC in and DC in, with DC out) and I think a user would reasonably expect them to be segregated. That part is fine. I have no idea about regulator_switching_module.lib. However, since we have regulator_switching_controller.lib we should have regulator_switching_converter.lib. These are external switch (not only FET) and internal switch parts, and they are grouped differently. Check out the part taxonomy at any IC vendor or distributor. But there is another group of parts: generic PWM controllers like SG3525 and TL494. Those could be separate from the parts in the libraries above which are generally relatively fixed-function DC-DC converters. So I think that's a third library, perhaps named regulator_smps_controller.lib or regulator_pwm_controller.lib. PFC controllers deserve, I think, their own library. Suggest regulator_pfc_controller.lib. Is that too much?

Should adc-dac.lib be adc_dac.lib (note underscore?

I assume driver_gate.lib here is only for ICs since transformers appear to be captured above. Another reason to preface IC libs with ic_. Would this lib include audio-focused gate drivers like IRS20957 and IRS2092? Those are certainly not a general-purpose gate driver and we have broken out audio parts for other categories.

Why timer_oscillator.lib if it only contains oscillators and crystals? Wouldn't crystal_oscillator.lib or clock.lib be a better name?

Since there's a lot of overlap, where many ICs will handle both protocols, how about interface_rs232_rs485.lib to combine the two separate libs?

To @jkriege2

  1. I think they're close enough to leave together. We'd need transistor_igbt.lib and a ton of others. Lots of library management overhead for probably little benefit, from my perspective, since in many circuits I could use either. Would having transistor_array.lib (for parts with multiple transistors) fall into the same category of being too much?
  2. I like this idea. At least if there's a symbol update we don't have to hunt around in multiple libraries. Seems easier to manage if like parts (and symbols) are kept together.
poeschlr commented 7 years ago

If we mark libs that have ics in them with ic we have 80% of the libs starting with ic Not sure if that helps anyone. I see ic more as a technology than a function.

SchrodingersGat commented 7 years ago

@jkriege2 - General question: Should the generic transistor/diode/... symbols from device.lib reside there, or should they be moved to the respective specialized libs? Maybe not, as they are no good bases for ALIASes, as they don't specify packages.

My thinking was the device.lib contains generic transistor symbols without package association. transistor_x.lib is for specific parts with footprints assigned.

@poeschlr - If we mark libs that have ics in them with ic we have 80% of the libs starting with ic Not sure if that helps anyone. I see ic more as a technology than a function.

Definitely agreed. ic_ is not the important functional qualification, and MOST devices will be ICs anyway.

@evanshultz - why not rename triac to thyristor? I think we need audio_misc.lib

Ok, done! :+1:

@evanshultz - what exactly is in power_conditioning.lib? Is this some AC in, DC out PFC pre-regulator?

I was thinking PFC etc

Since there's a lot of overlap, where many ICs will handle both protocols, how about interface_rs232_rs485.lib to combine the two separate libs?

I have merged all RS232/422/485 into interface_uart.lib

@evanshultz - Why timer_oscillator.lib if it only contains oscillators and crystals? Wouldn't crystal_oscillator.lib or clock.lib be a better name?

Fair point, I see crystals and clock ICs as being similar but separate. Perhaps two separate libs?

poeschlr commented 7 years ago

General question: can we reduce the amount of acronyms here? I'm getting lost a bit. (This might be the reason why i still don't fully understand the description by @evanshultz. What is an OTS power supply?)

I think we should keep this discussion as clear as possible to help us and future contributors determine what symbol should go in what lib. (Remember: not everyone learned this stuff in english)

SchrodingersGat commented 7 years ago

Question - where should things like SD-cards / SIM card live?

evanshultz commented 7 years ago

I was thinking PFC etc

@SchrodingersGat I still don't know what you mean. Can you give an example?

@poeschlr My apologies. OTS = off the shelf. Not custom-designed. My understanding is that if the lib name includes module it would be for something like this. I don't know why there would be 3 module libs, though.

evanshultz commented 7 years ago

on_semi.lib divestiture:

evanshultz commented 7 years ago

All parts in allegro.lib can go to sensor_current.lib.

evanshultz commented 7 years ago

nxp.lib mapping:

evanshultz commented 7 years ago

All xicor.lib can go to digital_pot.lib.

evanshultz commented 7 years ago

Worldsemi.lib (which doesn't need to be capital) are all integrated/smart LEDs. They don't fit into display*.lib or driver_led.lib, I don't think, and led.lib is generic. So... anybody have ideas?

poeschlr commented 7 years ago

Well we put the smart transitors made by infineon into the transistor lib. By that logic smart leds can go into the led lib. Truly generic (led) symbols go into device lib or am i wrong about that?

evanshultz commented 7 years ago

supertex.lib break out:

evanshultz commented 7 years ago

The siliconi.lib should really have been siliconix.lib, and the parts inside should go:

evanshultz commented 7 years ago

That's a good chunk of the libraries, but texas.lib is huge and I didn't touch it. I'll tackle that one tomorrow if nobody else has done it.

poeschlr commented 7 years ago

I would not really list exactly which symbol will go where. A better way is to find out which libs will be needed in the new lib system for splitting the legacy lib. What symbol goes where is better determined while moving a lib to the new system. (otherwise we do double the work.)

evanshultz commented 7 years ago

They will need to move at some point, and I mentioned if there wasn't an obvious mapping to the libraries already created above. Isn't that the same goal?

jkriege2 commented 7 years ago

Hi!

the analog multipliers are also a problem ... maybe we need something like analog_misc.lib or linear_misc.lib for such special function ICs or anything that doesn't fit anywhere else ...

JAN

SchrodingersGat commented 7 years ago

@jkriege2 such libraries will become apparent as we reorganize and find symbols that need a home but don't have one.

Question - where should things like SD-cards / SIM card live?

Any ideas on this one?

jkriege2 commented 7 years ago

About SD/SIM: Why not keep them in connectors? They are "just" connectors for such devices in the end ...

JAN

poeschlr commented 7 years ago

or a new lib under the connectors category? example: connector_card (maybe a better name is needed.)

jkriege2 commented 7 years ago

iff we split connectros.lib ... Has there been a consensus on that?

suzizecat commented 7 years ago

About SD/SIM: Why not keep them in connectors? They are "just" connectors for such devices in the end ...

Even if finally, it doesn't change anything, there is some "eSIM" card which should become available soon. These are SIM card which you'll solder directly on your PCB, so these won't be "just" a connector for a long time... But since it should be managed by the FP association, this isn't really important

I would vote for the connector_card or even only card since you'll be able to add some other cards readers (like smart cards). I don't know too if there is a lot of cards out there (i already saw some connectors allowing both sim and SD cards) and if it'll be worth adding a new lib just for that.

It's just a suggestion thought since i absolutely don't know how to handle these other cards...

pointhi commented 7 years ago

what about simply adding a connectors_misc.lib for things like sd-card-connectors?

stevenj commented 7 years ago

This all looks great, my only comment so far is:

mcu.lib - Micros that don't fit anywhere else cpu.lib - Processors that don't fit anywhere else dsp.lib - DSP chips that don't fit anywhere else soc.lib - SOC chips that don't fit anywhere else

Whats actually in these now? It seems like future maintenance rot waiting to happen. Ie, If a Silicon Labs EFM32 gets contributed, it doesnt have anywhere to go, because there isnt a silabs_mcu_arm library. And its only one chip, so meh just stick it in mcu.lib

But then another gets contributed and so on, I think it would be better NOT to have generic mcu/cpu/dsp/soc libs and make specific libs for whatever is in there, even if that means they only have one part. Then in future if someone contributes a part, they dont have a dumping ground to stick it, and the process is to create a new library following the scheme already laid out.

poeschlr commented 7 years ago

@pointhi connector_misc only makes sense if we have specific connector libs for different connectors. (Which we don't really have) Currently the connector lib is the connector_misc lib.

evanshultz commented 7 years ago

Just a few part types to consider. I realize they all aren't in the library now, but where would we classify them?

I'm not really sure about the vactrol, but the rest may have no other place but a miscellaneous IC library which I still don't see above?

poeschlr commented 7 years ago

google tells me vactrols are isolators. Which would mean they go into isolator.lib? (or isolator_analog.lib)

SchrodingersGat commented 7 years ago

@evanshultz good points - I'm not sure immediately where they should go.

evanshultz commented 7 years ago

I still think the regulator library names need some work. I was finally able to sort it out in my head.

The word "regulator" is used for the first term in these libraries. But it's also common to differentiate DC-DC ICs with the words "regulator" if the transistor (not necessarily a FET) is inside and "converter" if the transistor is external. That confluence of terms is what was bothering me. I think the first word in the library should change to "power", and then it's not awkward to use the name "regulator" elsewhere in the library name.

With that sorted out, I propose the following:

I scrolled up and realized there already was a Power Management section using power as a prefix. Regardless of what section the above goes into, I still think this is a better way to go. Also, power_switching_module could still be retained.

I went around the web to see how others had classified these types of parts, both as manufacturers and as sellers/organizers of these parts.

Here are Digi-Key's categories: image

And Mouser's: image image

Farnell: image

TI: image image

Linear Tech: image

ST: image

evanshultz commented 7 years ago

Breaking out the last of the old libraries (that I see haven't been divested):

texas.lib is huge so I'm giving it a section to itself (and using the names I proposed above):

This is all that I see that needs to be mapped from the old to the new library. Please point out if you see any unmapped libraries or if you find parts which currently don't have a nice home.

A few more things:

EDIT: Changed power_management.lib to power_distribution.lib above, and finished writing out the 3rd bullet point above.

SchrodingersGat commented 7 years ago

@evanshultz I have made your proposed changes to the power libs, they make sense.

power could be renamed to power_symbols, this makes the most sense.

ghost commented 7 years ago

power.lib is a special Eeschema library. Its name can't be changed because this name is hardcoded in application. Remeber that, there are two component place command: first for devices, second for power ports. The second one uses power.lib as an exclusive source of symbols.

Going too far in libraries rearrangement you are lost some Eeschema basics!

SchrodingersGat commented 7 years ago

@keruseykaryu that is very good to point out. It was my understanding that the Place Power command searched all libraries and only displayed components marked as power. But it appears I am wrong on this.

So, power.lib must remain unchanged.

ghost commented 7 years ago

Well. It seems we both have right.

The old Eeschema (pre 4.0) searches for power.lib and display only components in this library when Place power command was used. New Eeschema indeed searches for power symbols in used libraries and allow to select any power port from any library.

So. If you need to be compatible with KiCad <4.0 you should stay with power.lib. For KiCad >4.0 it really doesn't matter, because new component selector code is more flexible.

evanshultz commented 7 years ago

Thanks @SchrodingersGat and @keruseykaryu. I didn't realize the special nature of power.lib.

Two things: