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
750 stars 951 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

Some notes on the (currently unassigned) libs above

  1. I don't like the word "periphery" - I don't think it is technical enough
  2. The remaining unassigned libs are mostly manufacturer specific. We will have to go through them and decide what functions to assign.
SchrodingersGat commented 7 years ago

Rather than making new tables below, please make any adjustments (after discussion) to the table in the comment at the top.

SchrodingersGat commented 7 years ago

Plurals

Plural 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_extrasubs

evanshultz commented 7 years ago

powerint.lib has most parts that are internal FET regulators, and also a few line discharging parts that I think go into ic_misc.lib.

You need audio_misc.lib or something like that for SRCs, mic preamps, etc.

Where do CODECs go? I assume audio_adc_dac.lib, but what else would go there? Why not call it audio_codec.lib?

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?

jkriege2 commented 7 years ago

Some more comments:

Best, JAN

ghost commented 7 years ago

+1 for singular.

There were suggested libraries starting quarz... that I don't see in the table above. Would these better as piezo... since the material used might be crystal or ceramic? Whether it's a filter or a resonator, it is the piezoelectric effect that they have in common. But if we stick with the suggested name, it should be quartz... (I'm being very picky :wink:)

What will be left in device if inductors move to a separate library as @jkriege2 suggests above? Just resistors and capacitors? If so, why not split into two libraries for clarity?

How about shortening microcontroller_ to mcu_? Anyone using one ought to recognise the acronym.

peripheral instead of periphery?

SchrodingersGat commented 7 years ago
  1. Alright, singular names it is (I have updated the table accordingly).
  2. I also prefer mcu_ as a prefix (we already have soc_ and dsp_
  3. Should processor_ be shortened to cpu_?
  4. Regulators (switching). Agreed that we need to arrive at some categorizations here
  5. Transformers - my knowledge here is lacking, but happy to split into multiple categories when we arrive at some good names
  6. peripheral.lib - the suggested contents of this library still seem very broad to me. Can we narrow this down?
  7. piezo / quart / etc - what is the function of this library (not the material it is made of!) Is it oscillators? Resonators? Other?
ghost commented 7 years ago

piezo / quart / etc - what is the function of this library (not the material it is made of!) Is it oscillators? Resonators? Other?

OK, I see that there have been edits on the other thread that prompted my comment :smile: : https://github.com/KiCad/kicad-library/issues/1398#issuecomment-313926433

That now suggests two libraries:

oscillators.lib (formerly: Oscillators.lib) quarzes_filters.lib (formerly: Oscillators.lib)

If oscillators.lib is passive piezoelectric oscillating devices (i.e. standalone crystals, crystal resonators with built-in capacitors and ceramic resonators), that's good. But it should not IMHO include oscillator ICs.

Piezoelectric filters can be made of quartz crystal or ceramic material. So quartz_filters.lib does not sit well with me.

pointhi commented 7 years ago

After a quick look

@SchrodingersGat probably kicad-symbols would be a more appropiate name for the repo than symbols

nbxmike commented 7 years ago

You may as well combine the NXP and Freescale processors to NXP or you will need to do it later.

evanshultz commented 7 years ago

@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:

evanshultz commented 7 years ago

@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?

evanshultz commented 7 years ago

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.

diggit commented 7 years ago

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. At least my workflow is:

  1. find online which components suits the purpose and is available
  2. choose correct generic symbol (it is fast, keywords like: gds, zener, tvs, diode, fet, npn, .... works well)
  3. rename symbol to match selected device
  4. assign correct FP

I have similar workflow for linear regulators, because in 70% cases, the one I choose to use is not in libs.

SchrodingersGat commented 7 years ago

@evanshultz - @pointhi Can you please check you first bullet? It looks like the same lib name is repeated.

Read it again ;) It's a very subtle mistake that I made in the original table, which I have now fixed.

SchrodingersGat commented 7 years ago

@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?

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!

SchrodingersGat commented 7 years ago

Amplifiers

Currently the amplifier organization is pretty rough. What are some broad categorizations for amps?

gauravjuvekar commented 7 years ago

@SchrodingersGat Er, I don't think others can edit the post. That's not how github works.

SchrodingersGat commented 7 years ago

Sorry @gauravjuvekar you are completely correct - please ignore that. I forgot that I have special powers.

image

Update : Make suggestions and I will add them to the table :)

jkriege2 commented 7 years ago

I think you need to be Member or Owner to edit a non-own post. JAN

gauravjuvekar commented 7 years ago

Can we create separate rf_* libs. I know that currently there aren't many rf components in the libs, but there are a large number of categories in rf out there.

Eg, see https://www.digikey.com/products/rf-wireless/en I guess rf_{trasmitters, receivers, transceivers} could go in interface_rf, but there are a lot of non-interface components like amplifiers, mixers, couplers, variable attenuators, active balun ICs, switches, etc.

SchrodingersGat commented 7 years ago

@gauravjuvekar this is a good idea, I was only just thinking where antennae would go. I agree there is a place for rf_ libs separate from RF ICs

gauravjuvekar commented 7 years ago

I think antenna should also be a separate library. It also has a lot of subdivisions (type: patch, chip, wire), surface / edge mounts, etc

jkriege2 commented 7 years ago

@SchrodingersGat: some comments about amplifiers:

Just ideas ...

JAN

SchrodingersGat commented 7 years ago

amplifier_current_sense shouldn't/couldn't that go to sensor_current?

I think that's fair.

I'm missing amplifier_difference (for components like these: http://www.ti.com/lit/ds/symlink/ina157.pdf) ... basically OPAMPS, but with (calibrated) resistors inside Also maybe amplifier_power and/or amplifier_highvoltage? (not so sure about these ... but there we could put e.g. opamps that also work at 100V ...)

I've added _difference, _power, and _rf but I don't think that _highvoltage is a category all on its own...

SchrodingersGat commented 7 years ago

Added transformer categories.

jkriege2 commented 7 years ago

will people know that amplifiers.lib or ic_amplifiers.lib contains OPAMPS? ... i.e. are all amplifiers OPAMPS or one of the others ...

JAN

poeschlr commented 7 years ago

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 LEM.lib could go into the sensor_current lib. Edit: There is only one symbol in bosch.lib that could go into sensor_motion. Another lib with only one symbol: contrib.lib should go into one of the interface libs. (It is a modem) Maybe we would need some sort of interface_special lib? The symbols in brooktre.lib are video interfaces. New lib interface_video (or should we have one lib per video standard?) Only a few symbols are in bbd.lib. some could go into oscillator but most might need a new lib called delay (don't really know what these components are used for.) The ftdi.lib could be renamed into interface_converter or we split it up.

evanshultz commented 7 years ago

amplifier_current_sense shouldn't/couldn't that go to sensor_current?

I disagree. The sensor is the part that actually senses the current. ICs like we see in linear.lib now that are "current sense" parts are simply amplifying an external sensor, like a resistor or transformer/inductor winding. I do not think those ICs belong in sensor_current.lib.

I also do not like having so many sub-categories for opamps. Why would you break out chopper-based amps? Their benefit is low input offset voltage, but you can get non-chopper amps with excellent performance here as well. It seems that we'd be splitting up parts which are otherwise interchangeable, cutting users off from seeing all opamp possibilities they might want to choose.

poeschlr commented 7 years ago

Gennum is now semtech the gennum.lib would need to be split up into multiple libs. (non of the symbols have a description which makes this a bit harder.)

graphic.lib does not exist in the current master branch. It has been renamed to graphic_symbols.lib (or has it been deleted and the graphic_symbols lib is a completely new lib?)

intel.lib mostly into a new mcu_intel.lib but also some into oscillator, interface*, ...

intersil.lib either driver_gate or driver_motor

maxim.lib split up in many libs. (many temp sensors but also some other stuff.)

microchip.lib mostly interface chips. (some gate drivers)

nordicsemi.lib only one chip is in there. should go to interface_bluetooth

nxp.lib some i2c led controllers and i2c multplexers

onsemi.lib mostly esd_protection but also transistor

philips.lib mostly interfaces

Where should digital potis go? Where should i2c, spi, ... io expander go? should h-bridge drivers go into diver_gate or driver_motor?

nbxmike commented 7 years ago

At the rate at which sub-categories are being proposed, the library revision better have some kind of search tool across ALL libraries.

I am no op-amp expert and rely on others to tell me that part of a design, so I would not necessarily know which of the categories to look in for a part number I've been provided. I doubt I am alone in allowing other people with more specific expertise to dictate portions of my designs, I could see us getting very frustrated with so many finely sliced parts libraries. Right now, grep is my go to solution for this but I think less command line experienced people would prefer a built in tool.

poeschlr commented 7 years ago

When placing a part in eeschema the search field gives results in all libs.

Edit: After this reorganization they will be in less categories than they are now. Currently a lot of them are in manufacturer specific libs.

poeschlr commented 7 years ago

The note for connector lib:

Could be expaned in future e.g. connector_usb.lib / connectos_JST.lib

I don't think generic connectors need a specialized symbol. The only symbols we could add is for multi row connectors where each row has a separate connector on the wire side. Or for connectors that don't follow a pure numeric numbering scheme.

jkriege2 commented 7 years ago

@poeschlr I would say:

@SchrodingersGat :

JAN

jkriege2 commented 7 years ago

About OPAMPs: I wouldn't separate out the chopper-amps ... as far as I know they are (to the outside) like OPAMPs (they have In+, In- and VoltageOut .. possibly+control pins) ... but OTA-amplifiers, or transconductance amplifiers have a current output, not a voltage output ... shouldn't they be separated out?

SchrodingersGat commented 7 years ago

@poeschlr I have applied your suggestions to the table, thanks :)

@jkriege2 I have added digital_potentiometer.lib :) I think driver_motor contains standalone motor controller ICs, while driver_gate contains things like half/full-bridge drivers etc (they're used for more than just motors)

SchrodingersGat commented 7 years ago

@jkriege2 what about timers like 8253, which are specifically designed as µC-periphery ... do they fit in timer.lib?

Yes, I'd expect so.

jkriege2 commented 7 years ago

@SchrodingersGat about drivers: Just starting from the lib-name in driver_gate I would expect driver-ICs that are used to drive the gate of a MOSFET, not half or full bridge drivers (although both might share the same functioning principle ...) ...

I scanned a bit the webpages of semiconductor manufacturers:

Most of them separate (at least) between:

  1. MOSFET/IGBT drivers
  2. Motor drivers/controllers (with sub-cats like stepper, bldc, DC, ...)
  3. some also have load/relay drivers

I think we should use the same categories, e.g.

  1. driver_motor (for all motor-related products)
  2. driver_gate (for ICs that are supposed to drive high-power MOSFETs/IGBTs)
  3. driver_load_other or driver_load for all others
  4. maybe we could think about having motor_controller for motor-controll ICs like stepper-controllers or BLDC-controllers that do not necessarily contain drivers for the motor.
jkriege2 commented 7 years ago

Also I just stumbled about MCU-companion chips like RESET-ICs and voltage supervisors ... where to put those? periphery?

What about the IO-expanders and other periphery that does not fit in any existing lib (yet)?

JAN

SchrodingersGat commented 7 years ago

Reset ICs should go in power_supervisor.lib - this lines up with how they are categorized on digikey.

I/O expanders (etc) are yet to be allocated. As no better name has been suggested, perhaps a series of peripheral_ libraries is needed.

jkriege2 commented 7 years ago

+1 on both ;-)

jkriege2 commented 7 years ago
gauravjuvekar commented 7 years ago

most of ftdi will also go to interface_usb or interface_rs232 In that case, can periphery_uart also go to interface_rs232

Also, where do we place peripherals like dma controllers / bus arbitrators / watchdog, etc

poeschlr commented 7 years ago

opto_isolator.lib might not be the best name. (And opto maybe not the best category) Opto is more the how is an isolator implemented than a functional description.

Maybe better would be isolator_opto and further libs for each type of isolator. ('isolator_induction', 'isolator_capacitiv', ...) But i don't like categorizing by internal technology. Yes inductive isolators tend to be used for signals with higher frequencies but there might be opto-isolators out there that can handle similar frequencies to cheap induction based isolators. (Or there are specialized induction based isolators for low frequency/ low power applications)

I would not split them up to be honest. maybe just isolator_digital? (I don't think there are analog isolators. If they are ever invented or if a contributor finds one we can simply add a new lib called isolator_analog)

Another lib still missing is the level_translator.

I personally would place the level translator and the isolator stuff either under logic or under their own signal translation category. (The later might be more future proof.)

poeschlr commented 7 years ago

Something similar with the display libs. under display_lcd there will be monchrome and color displays but also lc based segmented displays. Under display led i think there mitht be led bars, 7 segment, oled displays and in future maybe full color displays (TVs use leds already maybe in future there will not be lcds. also lcd display has a redundant display in it. it should be display_lc).

i would suggest the following function based lib names:

SchrodingersGat commented 7 years ago

@poeschlr regarding the display_ libraries:

I think there are few enough symbols that display_led and display_lcd are OK (at least for now). We have to ensure that we don't over-specialize, creating too many libs.

If a certain library becomes too large we can always split further down the road.

SchrodingersGat commented 7 years ago

opto_isolator.lib might not be the best name. (And opto maybe not the best category) Opto is more the how is an isolator implemented than a functional description.

Fair point. What about just isolator.lib - if we find this has too many symbols we can later expand by sub-category.

SchrodingersGat commented 7 years ago

Also I think we don't have any place for I2C transceivers/drivers/hubs and SPI switches/transceivers/... maybe interface_spi.lib + interface_i2c.lib

@jkriege2 can you give me some examples of what you mean by such components? :) It will help me to better understand their categorization.

SchrodingersGat commented 7 years ago

I personally would place the level translator and the isolator stuff either under logic or under their own signal translation category. (The later might be more future proof.)

Should we add logic_translator.lib for e.g. parts that are not covered by the 40xx and 74xx series?

poeschlr commented 7 years ago

@SchrodingersGat wrote:

I think there are few enough symbols that display_led and display_lcd are OK (at least for now). We have to ensure that we don't over-specialize, creating too many libs.

I really think led and lcd are bad names. There are lc based 14 segment displays and there are led based 14 segment displays. These would be in different libs if we split by technology.

If you only want to libs maybe the following might be a good split: