In the mean time, we could perhaps discuss in which library we want the MAX9814 to appear.
It is a linear device, intended for audio use -> audio.lib is the most logical place, I think.
But perhaps there are people that would prefer maxim.lib?
m
Allright, the footprint is done, except the 3D part.
I will check everything tomorrow and if I am satisfied I will push to the repo’s and do the pull request.
The 3D remains to be done.
m
The new footprint is waiting for approval by the library maintainers.
The PR is #38: Pull Request
Is it ok for the time being @SchrodingersGat ?
Once it is accepted, I can use this new footprint to complete the MAX9814 component.
m
1 Like
@mifi I’ll script a 3d model for you when it has been approved (I’m the one who added all the other QFN and DFN) unless you want to try it out yourself 
Simply add the parameters and run the script
But you should not manually draw it
1 Like
Hi @Shack,
That would be wonderful if you could do that for me. I am currently trying to finish the MAX9814 component, i.e. getting the KLC script errors out.
m
I am battling with the Not Connected pins.
According to the KLC, the must be set to invisible (rule 4.7.iii).
However, the datasheet explicitly mentions they should be connected to GND, and hence they must be visible:
I am probably not the first one to run into this conflict in KiCAD.
I did notice a small discussion last Januari (NC (no connect) pins?), but it does not deal with the fact that an NC is to be connected and invisible at the same time.
And this thread (NC pins layout, please help) touches it, but not exhaustively.
What do I do about this?
- Setting the NC pins to invisible and leave them unconnected in the schematic would violate the datasheet.
- Renaming them GND and stacking them with pin 7 would be a solution, but that makes the relation with the datasheet unclear, because the datasheet names them NC.
- Setting the NC pins to invisible and have the PCB designer create extra GND connections in pcbnew to the NC pins and the Epad, as recommended in the datasheet. I believe this is the current status quo. I do not like the idea that not all electrical connections are in eeschema, but it is like it is, I guess.
Any suggestions?
m
No problem, you should still add a reference to the 3d model, it will do nothing if there is no model but will ease it quite a bit when somebody needs to add the model
Yes, I will do that when the 3D model exists. the KLC does not allow me to do that any sooner, does it. I believe I had the scripts fail on me when I did this, but I am not sure.
m
No according to KlC you should always have a reference to the 3d model, I’ll check the tracis script and see if I can help you out
I’ll write them on git
Arghh the commit string mentions the MAX9814 instead of the footprint. Sigh.
That is what happens if one is doing two things at the same time…
Oh well.
The script checks out ok.
m
Does anyone have some input in my struggle with NC pins and the Epad pin 15?
It is getting ugly, but my current solution to get all connections to be made in eeschema is as in this screenshot (note pins 4, 11 and 15 bottom right):
As you can see, I have added a pin 15 for the EP, as I believe was suggested by @Shack (on github anyways, I think 
)
m
1 Like
Looks good to me.
If the EP pad was just for mechanical mounting I wouldn’t have it numbered at all, but as they want it on GND your solution is the logical choice.
The QFN footprint will have the center pad as #15 then instead of no number… no way around that IHMO.
2 Likes
Do answer your question about nc pins:
I think in this case NC means that this package pin is not bonded to the chip die itself. They probably recommend connecting it to gnd for EMC reasons.
In this case I would give it the electrical type of either power input or input, make it visible and call it nc as it is called this way in the datasheet.
Only give the electrical type nc to pins which should not be connected to anything. (@SchrodingersGat or @jkriege2 should we clarify this in the KLC?)
2 Likes
I tried calling the pins ‘NC’, @Rene_Poschl, but that makes the KLC scripts fail. So I used ‘NoC’ instead, which seems to work. The scripts accept this setup (as in the picture above).
Thanks @Joan_Sparky. I could not think of a better solution myself, but it is a bit confusing for users that have not studied the datasheet in detail.
m
You can’t take care of everything at that stage. If people use provided resources without proper experience/knowledge it can’t be your fault if they do it wrong
2 Likes
Note to @Shack:
The name of the footprint has changed and as a consequence the name for the 3D model has changed too.
Was: DFN-14_3x3mm_Pitch0.40mm
Now is: DFN-14_3x3mm_Pitch0.4mm (note the 0.4 instead of 0.40) and so is the reference to the 3D model.
On request by @SchrodingersGat.
m
If the travis script fails and you have a valid reason for it, just state this reason in the pull request description. It will be reviewed by a librarian anyway.
If the travis script fails and you have a valid reason for it, just state this reason in the pull request description. It will be reviewed by a librarian anyway.
That is a good point. I will do that.
m
I am waiting for the footprint to be accepted before I push the component with a valid reference to it’s footprint.
That should not be a problem, as I have already made all the changes to the footprint that were requested.
m