RFC - Rearranging Symbol Libraries #1402
Comments
|
Some notes on the (currently unassigned) libs above
|
|
Rather than making new tables below, please make any adjustments (after discussion) to the table in the comment at the top. |
PluralsPlural naming does not work well for everything. However I think that non-plural naming can work in all cases. Should we enforce a non-plural naming scheme or is anyone really passionate about plural names? Examples of plurals that just sound wrong
I propose we name function_extra_sub, otherwise we get a weird combo of functions_extra_sub, function_extra_subs |
|
powerint.lib has most parts that are internal FET regulators, and also a few line discharging parts that I think go into You need Where do CODECs go? I assume More libraries are needed for SMPSs more. Break out DC-DC internal FET (regulators) from DC-DC external FET (controllers). We already have a lot of each. And generic SMPS controllers like UC3842 and NCP1200 deserve their own library. They're a different ballgame than integrated DC-DC parts. Lastly, where do PFC controllers go? They're a totally different type of IC (unless you're talking about single-stage flyback or oddball topologies like the Clark converter of PFC buck) and I think they should be in their own library. Lastly, transformers are a total wasteland. I'd like to find a paradigm that works. I've tried 3 categorization schemes and none of them worked well for me. Does anybody have anything that works? It may take multiple libraries to cover AC line frequency, SMPS, gate drive, ethernet, and all other kinds of magnetics. Additionally, do coupled inductors go here or elsewhere? What about common mode chokes? Do those have their own libraries? |
|
Some more comments:
Best, |
|
+1 for singular. There were suggested libraries starting What will be left in How about shortening
|
|
OK, I see that there have been edits on the other thread that prompted my comment 😄 : #1398 (comment) That now suggests two libraries:
If Piezoelectric filters can be made of quartz crystal or ceramic material. So |
|
After a quick look
@SchrodingersGat probably |
|
You may as well combine the NXP and Freescale processors to NXP or you will need to do it later. |
|
@pointhi Can you please check you first bullet? It looks like the same lib name is repeated. Unless someone objects, I volunteer to propose the divesting of the following libs:
|
|
@SchrodingersGat Is the above a "all edit" table? Or are we making suggestion with one person (you, I assume) as mediator and editor of the table? |
|
Finished with analog_devices.lib, infineon.lib, and zetex.lib. I like the idea of separate diode libraries IF the symbols are different. For example, regular Si diodes, Schottky/SiC, zener/TVS, etc. This will result in the least amount of unique symbols so it's the easiest to maintain. |
|
In my opinion, there is no need for device specific symbols for such simple devices. Generic symbols are IMO enough. There is only several permutations with so few pins. Then splitting them does not make sense, they could all got to device.lib.
I have similar workflow for linear regulators, because in 70% cases, the one I choose to use is not in libs. |
Read it again ;) It's a very subtle mistake that I made in the original table, which I have now fixed. |
It's open to editing, but only after discussion here :) Please add edit comments at the end of the table as I have been doing, if you edit anything! |
AmplifiersCurrently the amplifier organization is pretty rough. What are some broad categorizations for amps?
|
|
@SchrodingersGat Er, I don't think others can edit the post. That's not how github works. |
|
Sorry @gauravjuvekar you are completely correct - please ignore that. I forgot that I have special powers.
Update : Make suggestions and I will add them to the table :) |
|
I think you need to be Member or Owner to edit a non-own post. |
|
Can we create separate Eg, see https://www.digikey.com/products/rf-wireless/en |
|
@gauravjuvekar this is a good idea, I was only just thinking where antennae would go. I agree there is a place for |
|
I think antenna should also be a separate library. It also has a lot of subdivisions (type: patch, chip, wire), surface / edge mounts, etc |
|
@SchrodingersGat: some comments about amplifiers:
Just ideas ... JAN |
I think that's fair.
I've added |
|
Added transformer categories. |
|
will people know that JAN |
|
What about (multi purpose) signal level translators and signal isolators? (currently they might go into the logic libs but i think giving them a separate lib might be a good idea.) The symbols of the |
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. |
|
@poeschlr I agree with your direction for |
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
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... |
|
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 |
|
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) To clearly mark which libs hold generic devices we could also add generic as prefix/suffix. 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.) Yes this would deviate from splitting the lib purely by function but a clearer KLC might be worth this tradeoff. |
|
|
|
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 |
|
In this repository, the connector symbol library has been renamed from |
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_librariesThe text was updated successfully, but these errors were encountered: