Adding parts to V6 libraries (in 5.99)

Schematic Library Symbols
1

Hi all,

I have previously added a couple of parts to the libraries for V5, and I was planning to add the LM5156H to the libraries that will be in V6.
I noticed the KLC (3.0.28) is suspended, pending revision, so perhaps it is not a good idea to add parts to the libraries at this time, i.e. add to a moving target?
I do not want to interfere with ongoing efforts, because I am aware of how much effort is put into the new library layout and I do not want to be a nuisance.

I am on gitlab and have found the documented procedure which, I assume, are up to date. I am guessing the KLC on gitlab is the best place to start reading about the new conventions?

Is this a good time to go ahead and add a part or is it better to wait a bit until V6 is released?

m

2

If found this:

Contributions of library assets must be created in the latest stable version of KiCad.

in section G1.8 at https://klc.kicad.org/ , which leads me to believe I should wait.
Correct?
m

3

Generally, you’re right.
In practice it depends on what you want to add. Symbols or footprints? Anything particularly special?

4

Thanks for the reply.
I was hoping to add everything for the LM5156H, i.e. symbol, footprint and 3Dmodel.
It is a fairly new (september 2020) wide Vin (3.5V - 60V) boost/Sepic/Flyback controller, well featured, by Texas Instruments that is probably useful for a variety of battery powered applications.
(datasheet: https://www.ti.com/lit/gpn/lm5156h)

That sounds like a pretty neat controller to me.
I guess I will have to wait a bit. I do not want to interrupt the flow of developments.
m

5

That’s interesting…
The package for the LM5156H is HTSSOP-14. I looked at the footprints Packages_SSOP, hoping ithis package was alread present, but I got this error from kicad_nightly (version updated less than an hour ago):

Footprint library path ‘/usr/share/kicad/modules/Package_SSOP.pretty’ does not exist (or is not a directory).

Do I need a better reason to wait instead of interfering? It probably is too early.
Thanks anyway.
m

6

FWIW I believe adding parts to the kicad libraries is not a good idea. I’ve been keeping all my added parts in a personal library.

7

In the nightlies the library is called “Package_SO.pretty”, and it contains a footprint for HTSSOP-14. Your fp-lib-table might be outdated.

8

Those plural names are from KiCad V4.

9

I think he’s talking about contributing…

1 Like
10

I am talking about contributing indeed. If my efforts (that I will have to do anyway) can be to the benefit of the community, I would like to do something in return for the wonderful work that is being done by the developers and the librarians.
I am aware of the massive effort that goes into maintaining libraries. Every part helps.
m

1 Like
11

Probably a problem with the table.

12

It turns out, the history of KiCAD versions on my system resulted in the environment variables KICAD6_SYMBOL_DIR and KICAD6_FOOTPRINT_DIR to be set incorrectly and I had one hell of a time finding where it was set.

Anyways, that point is fixed now and I can find the HTSSOP-14 footprint. Adding the LM5156H probably is limited to adding the symbol.
I can do that later, when the lib’s are stable enough for the librarians to accept user additions.

m

13

That symbol doesn’t look like it’s going to be affected by KLC changes much.
Feel free to go ahead with an MR, just don’t expect it to be reviewed quickly.

14

Thanks. I agree, it should not be a big deal, even more so since the footprint seems to be already available. I’ll will get on with it in the coming week or so.
Thanks.

15

Request for comments (@chschlue suggested to go ahead):
A couple of days ago, I proposed to contribute the LM5156H to the V6 repo’s. In fact, there are to very similar parts: The LM5156H and the LM51561H.

Datasheet title:

LM5156xH 2.2-MHz Wide VIN 65-V Non-synchronous Boost/SEPIC/Flyback Controller with 150°C Maximum Junction Temperature

I made the symbols and created a schematic with them. I have not yet committed the parts and I have not done the merge request yet.

The LM5156H and LM51561H are controllers for switched boost/SEPIC/Flyback DCDC converters. The difference between the LM50156H and the LM51561H is that in the latter a function called “hiccup” is enabled. In the LM5156H this “hiccup function” is disabled.

The “hiccup function” handles the behavior of the controller after an overcurrent situation has occurred.

In the image below you can see the symbol in a schematic. The circuit in this version is non-operational, obviously, and is based on Figure 10-3 in the datasheet. I used it to test the symbol and run ERC checks.

LM5156-symboltest-02
LM5156-symboltest-021000×401 54.3 KB

Note that, according to the datasheet, pin 13 (PGOOD) can be left floating when not used.

Note also that the LM5156H and LM51561H are powered via pin 1 (BIAS). The naming is somewhat misleading, but it is what it is in datasheet. The Vcc pin is the output of the internal regulator.

There are two ERC messages remaining about the power pins only. The ERC errors are acceptable for the current state of this schematic.

ERC report (vr 02 apr 2021 08:45:09 CEST, Encoding UTF8)
***** Sheet /
[power_pin_not_driven]: Input Power pin not driven by any Output Power pins Severity: error
@(118,11 mm, 87,63 mm): Symbol #PWR06 [GNDS] Pin 1 [GNDS, Power input, Line]
[power_pin_not_driven]: Input Power pin not driven by any Output Power pins Severity: error
@(120,65 mm, 72,39 mm): Symbol U1 [LM5156H] Pin 1 [BIAS, Power input, Line]
** ERC messages: 2 Errors 2 Warnings 0

The datasheet for the LM5156xH is here: https://www.ti.com/lit/ds/symlink/lm5156h.pdf

If any of you have amendments to suggest, either to the symbol or to the information I have given here, please let me know.
I will probably generate the merge request in a couple of days.

16

In that case, I would probably make that pin Passive to allow being disconnected (floating). But you don’t mention exactly what the ERC error was for that pin. Was it a simple unconnected error that could be solved by placing a no connect (the blue X) on the pin, or was it an undriven input error?

17

Thanks for your suggestion.

Setting the pin to passive, does not solve the ERC error, which is:

[pin_not_connected]: Pin not connected Severity: error
@(148,59 mm, 72,39 mm): Symbol U1 [LM5156H] Pin 13 [PGOOD, Passive, Line]

Either way, when the pin is set to ‘passive’ or ‘open collector’, the same error is produced.

I am not quite sure what you mean by ‘the blue X’. Do you mean the electrical type ‘unconnected’ (which has a red X in my version of KiCAD)?

If so, that would force the pin to be always disconnected, which is not what is intended. The pin PGOOD can be used, if the designer wants to, but it does not have to be and if it is not used, the datasheet advises to leave it unconnected.

Leaving it open is better than connecting it, because the allowed voltage on pin 13 is limited to 16V (max 18V), while the Vsupply can be anywhere between 2.9V and 62V. My solution in the schematic is not intended for practical use, but intended as a way to avoid the ERC error.

The PGOOD pin is an open drain pin, so I figured the electrical type closest would be ‘open collector’.

It is, obviously, easy to ignore the ERC error, so in an actual design it is workable.

18

It’s the no connect symbol/tool in the right-hand tool bar of EESchema: (I’m on 5.1.9, 5.99 might use different graphics and/or tool tips here)
2021-04-02 11_10_01-Window

The no connect (along with the ERC hit that results from not using it) forces you as a designer to actually consider if you want pins connected or not when drawing the schematic. It will also flag a pin that you accidentally didn’t connect. The not connected pin-type in the symbol editor is for showing a pin that should never be connected, not what you want in this instance.

Come to think of it, I think I was wrong. You can put a no connect on an input type pin and avoid a “pin not driven” ERC hit.

19

Ahh ok, I see, but that would be up to the designer of the schematic. This solution is not part of the symbol, but part of the schematic.
That solution does work, in fact. I just checked it in eeschema (5.99). It does, in fact, get rid of the ERC error, but it does not make a difference to the symbol I was hoping to contribute.

20

Right. Sorry if I wasn’t clear. I was responding to one of the issues you seemed to be having by using your symbol in a schematic as a form of validation. I’d probably set the pin as input for my own libraries, but I’m not sure how KLC would want that pin. Last time I checked (several months ago) KLC for v6 hadn’t been released yet so you may need to discuss this with the library team (probably though the git tools when you submit, I forget the proper git terms…).

1 Like