Closed SchrodingersGat closed 6 years ago
seppestas
commented
7 years ago If we move the leds out of device.lib, wouldn't it make sense to rename device.lib to passive.lib indicating it contains passive components? Device is a pretty generic term imho.
seppestas
commented
7 years ago Wouldn't the sensors placed in sensor_multi-function.lib also fit in the sensor.lib library?
poeschlr
commented
7 years ago @seppestas wrote:
If we move the leds out of device.lib, wouldn't it make sense to rename device.lib to passive.lib indicating it contains passive components? Device is a pretty generic term imho.
The generic led symbol is not removed from device lib. The led lib will hold specialized symbols. (An example would be an atomic symbols for one special led that has the footprint pre assigned.)
In other words: the device lib holds only generic devices that are not intended to represent any specialized part. Maybe device.lib is not the best name but having a passive lib would not make it better. (some passive devices will be in a specialized lib with a footprint assigned)
suzizecat
commented
7 years ago Maybe device.lib is not the best name but having a passive lib would not make it better. (some passive devices will be in a specialized lib with a footprint assigned)
Maybe something like generic_device.lib would be better ?
seppestas
commented
7 years ago Maybe device.lib is not the best name but having a passive lib would not make it better. (some passive devices will be in a specialized lib with a footprint assigned)
What about the transformer.lib and sensors.lib both containing more generic components compared to the more specialized libs ("General purpose transformer" and "Sensors that do not fit other categories" respectively). Wouldn't having a library called passive.lib that contains "Generic / General purpose passive components" be consistent with this?
Of course doing this only makes sense if passive.lib only contains passive components, so there should not be leds in there. Personally I think having the generic led symbol in led.lib makes a lot more sense than having it in device.lib.
stevenj
commented
7 years ago Of course doing this only makes sense if passive.lib only contains passive components, so there should not be leds in there. Personally I think having the generic led symbol in led.lib makes a lot more sense than having it in device.lib.
As a standard diode is a Passive component, arguably a LED is also a passive component, because electrically it behaves the same as a not light emitting diode. Just Saying.
suzizecat
commented
7 years ago As a standard diode is a Passive component, arguably a LED is also a passive component, because electrically it behaves the same as a not light emitting diode. Just Saying.
Is a standard diode even considered as a passive component ? (since on Farnell website, there is the "Discrete Semiconductor" (with diodes) and "Passive Components" with capacitors, resistors, etc)
poeschlr
commented
7 years ago I think currently the device lib is the only lib that by design contains only generic symbols. All other libs do not really contain generic symbols but atomic or quasi atomic symbols. (or better: the goal for all other libs is to be atomic. Old symbols might not yet be atomic.)
The device lib also has transistors in there which are definitely not passive. It has generic photo diodes which are not passive either. (specialized photo diodes are currently in opto.lib will be in sensor_photo in the new scheme.) And a lot of other stuff. The only general symbols in the current sensor.lib are the pt1000 and pt100 symbols. We could move them to the generic lib. The opto lib does not contain such generic symbols. (feel free to check other libs. But i think this will be an ongoing process.)
I would be ok with splitting the generic lib. But it makes our live easier if we have clear libs where very generic symbols go. It makes it easy to define the look and feel of symbols in just one lib (or a specific set of libs) and tell everyone to use symbols that look similar to that lib. (currently we use the device lib for that.)
seppestas
commented
7 years ago As a standard diode is a Passive component, arguably a LED is also a passive component, because electrically it behaves the same as a not light emitting diode. Just Saying.
Is a standard diode even considered as a passive component ? (since on Farnell website, there is the "Discrete Semiconductor" (with diodes) and "Passive Components" with capacitors, resistors, etc)
According to Wikipedia an LED (and all other type of diodes and semiconductors) is as active well, however I don't have a reference to a more authoritative source. My rule of thumb: if the function on the current and/or voltage is linear, it's passive. This of course only holds true for ideal devices.
SchrodingersGat
commented
7 years ago @poeschlr I agree with your direction for device.lib - independent of whether we keep this name or decide on something else, this is exactly the purpose of this library.
suzizecat
commented
7 years ago @seppestas
According to Wikipedia an LED (and all other type of diodes and semiconductors) is as active well, however I don't have a reference to a more authoritative source. My rule of thumb: if the function on the current and/or voltage is linear, it's passive. This of course only holds true for ideal devices.
Well, in this case, a capacitor and an inductance (choke ?) aren't passive since the only component which i know to have a linear function between voltage and current is the resistor (U=RI) (capacitor and inductance got differential terms)
According to the same good old Wikipedia
Components incapable of controlling current by means of another electrical signal are called passive devices. Resistors, capacitors, inductors, and transformers are all considered passive devices.
In this case it's a little bit tricky with the diode, but i guess the point is that the behavior of the LED isn't the same if the current flow through anode-cathode direction or cathode-anode direction...
evanshultz
commented
7 years ago One other thing to mention is that Infineon makes former International Rectifier parts like IRS2092. This is a gate driver, yes, but it's specifically intended for audio applications. Is it best to put this kind of part with other gate drivers, or in audio_misc.lib?
poeschlr
commented
7 years ago Back to the device lib discussion. (sorry)
We could name the current device lib something like basic_device. (would make it clearer what to expect in this lib.)
I noticed that the switches lib currently only holds generic switch symbols. (It seems in the current master all switches finally moved from device into switches lib. Therefore the latest patch for 4.x that adds this lib by default is really needed) This means the switches and connectors lib currently only hold generic devices. (I would argue the logic family libs are also generic)
To clearly mark which libs hold generic devices we could also add generic as prefix/suffix. This might make it easier to write the klc for the new naming convention and use of default footprint field.
We could then simply state that all symbols added to any lib that is not marked as generic needs the footprint field assigned and they also need to be named by the manufacturer part number. (or mpn base for devices produced by different manufacturers using different conventions for option fields.) We could then even use travis to help checking this. (simply have a rule that is deactivated for libs having the generic prefix/suffix.)
Yes this would deviate from splitting the lib purely by function but a clearer KLC might be worth this tradeoff.
evanshultz
commented
7 years ago transistors.lib is massive. Almost 6000 lines as of now. Would it be good to split this up? I would think we would want to keep parts with the same symbol together so we can use ALIAS and for better maintenance, so perhaps we split by transistor type. transistor_fet.lib, transistor_bipolar.lib or transistor_bjt.lib, transistor_igbt.lib, etc. What do you think?
evanshultz
commented
7 years ago The transistor library could even be split more than I mentioned above, if desired. We could separate single and multiple transistor parts. This could result in transistor_fet.lib and transistor_fet_array.lib, or something. The core symbols would need to stay in sync fir visual purposes, but then it wouldn't be such a maintenance issue since the final symbols would still be unique in each library. Just an idea.
jcassette
commented
6 years ago In this repository, the connector symbol library has been renamed from conn to Connector (refer to first post)
However in kicad-footprints the libraries have been renamed from Connectors_*.pretty to to Conn_*.pretty
What is the logic behind this?.. I think it should be better to keep the same name everywhere.
Edit: I realize this should rather be addressed in kicad-footprints maybe
Following on from the work by @jkriege2 here
allegro.lib-sensor_current.libanalog_devices.lib(AD623/AD8236/AD42x to amplifier.lib [all int amps], ADE7758 to ic_misc.lib, ADuM6000 to regulator_switching.lib, ADuM7758 to interface???.lib)bbd.lib(all audio delay lines so audio_misc.lib)bosch.lib- move tosensor_motion.libbrooktre.lib- move tointerface_video.libcontrib.libmove to aninterface_<x>.libftdi.lib- mostly tointerface_usbgennum.lib- (all to video.lib: gs9020 is video processor, gs9025 is cable driver, and gs9032 is video serializer)infineon.lib(all to transistors.lib since they're just FETs with some protection built in)intel.lib- moves to multiple libs,mcu_intel.lib, oscillator, interfaceintersil.lib- moves todriver_gate,driver_motor, etcir.lib(AU* parts to sensors_current.lib and all others to gate_driver.lib)LEM.lib- move tosensor_current.libmaxim.lib- split into many libs. A lot of temperature sensor partsmicrochip.lib- mostly interface chipsnordicsemi.lib- tointerface_bluetoothnxp.lib(all to interface_i2c.lib)onsemi.lib-esd_protection/transistorphilips.lib- mostlyinterface_<x>powerint.lib(CAP* parts to ic_misc.lib and all others to regulator_switching.lib)silabs.lib(cp2xxx to interface_usb.lib, si3210 to interface_telecom.lib? [it's an analog phone interface], the rest to the newly created interface_am_fm.lib)siliconi.lib(actually Siliconix parts; driver_motor.lib and analog_switch.lib)supertex.lib(reference_current.lib, power_distribution.lib, regulator_switching_converter.lib, regulator_linear.lib; see below)texas.lib(too big to write out here; see post by @evanshultz on 22 Jul below)wiznet.lib(to interface_ethernet.lib)Worldsemi.lib(to driver_led.lib)Xicor.lib(all to digital_pot.lib)zetex.lib(move to gate_drivers.lib)Edits
microcontroller_tomcu_audio_adc_adc.lib->audio_adc_dac.libprocessor_tocpu_amplifier.libinto multiple librariespower_distribution,power_conditioning,battery_managementpower_librariesrf_libraries