Added ST Regulators, Barometer and Linx GPS

[suzizecat]

I :

• created the complete ST LDK130 LDO regulator family in regul lib,
• added ST LPS25HB Barometer in sensors lib
• created the linx lib for RXM-GPS-RM/FM GPS modules from Linx.

I don't know if these GPS modules should be in rfcomp thought...

Since it's my first contribution, i apologize if there is some mistakes with the KLC but i tried to be as accurate as possible.

[poeschlr]

First of all thanks for your contribution.
It would be a lot easier for us if you could split the pull request into 3 requests such that one lib changes per request. It would also help if you could provide a screenshot of the added symbols including a screenshot of the pin table. Please also provide a link to the datasheet you used to design the symbols.

Also have a look at our library convention and the faq.
And finally have a look at the output of our testing system (travis)

The main problem with your symbols seems to be that you have invisible pins defined as power input. Invisible power input pins are global labels. This is why we no longer allow the use of invisible power input pins.
If you want to stack power input pins, only give the visible pin the electrical type power input. all other pins should be of type passive.

Something similar is true for stacked power output and output pins. Here the reason is that the electrical rule check does not like it when more than one such pin is on a net. This means give only one pin the output type and all others should again be of type passive.

Tthe schematic editor does not like this. You need to finish all pins before stacking them because opening the pin properties of stacked pins changes the name and electrical type of all pins in the stack.

Another problem is that some of your symbols have text fields with the wrong size. (Yes i know this is kind of pedantic but we try to have all symbols look similar.)
An easy way to change this is by opening the field properties dialog:

[poeschlr]

I nearly forgot. The regul lib is undergoing a major overhaul at the moment.
We will not merge any changes to this lib before pull request #948 is merged. (Another reason to separate the parts of this pull request.)

[suzizecat]

Thanks for your return. I'll look into it, but i don't know why i got 60mil text size since i left it unchanged... If it's the default value, shouldn't it be the right size ?

I apologize for stacked pin, i missed the point where this special case is described.
Is there a way to really split this pull request or should i create three completely new pull request ?

Thanks for the time you took to explain all of that to me (and for the great job of all lib maintainers) !

EDIT : I don't also really understand travis output :
Minuses and underscores in footprint filter 'DFN-*' should be escaped with '?' or '*'.
Should I write '?-' ? The fact is that i need to include the minus to avoid selecting the whole DFN_QFN lib... Or may i use something like *:*QFN* ?

[jkriege2]

yes, 60mil is the default set by KiCAD, but this should be changed to 50mil in the future ... here we expect 50mil.

About the stacks: Actually that was introduced a few days back only ;-)

I don't think you can split it ... so best option is possibly close it and open 3 new ones (you need to make 3 branches for that and could transport you changes with patches between them ...)

JAN

[jkriege2]

Please also note that I'm currently working on an overhaul of regul.lib (see #948) ... so please orient your symbols on the standard set there (+ I will maybe delay your PR until mine is done ... or I could incorporate your devices there ... any way you wish ;-)!

Best,
JAN

[suzizecat]

@jkriege2 I'll try to comply to your work, and i don't mind if you include my work to yours, or delay it. It's as you prefer.

BTW, do you have a "standard" size for your components ? Here's how mine looks.

[jkriege2]

There are several symbols with that pin-layout in my PR ... just have a look there for sizes. Also please split by fixed and adjustable regulators (i.e. ADJ-version is usually no ALIAS of fixed versions), if pin names are different for them ;-)

Best,
JAN

[suzizecat]

I'll have a look, then.
I left these pins as it since the datasheet provide this pin naming in their pin table (Datasheet) page 6 and since it's the only difference.

Julien

[jkriege2]

Hi!

I added the LDK130-family to my larger overhaul: #948