ADA4870ARRZ - high power high speed amplifier #1611
Conversation
it seems that there's something fishy with kicad GIT build. When pressing 'E' to edit pin properties, when these pins are stacked, even when an unique pin to edit is selected, the edit is applied to all pins at the same time. Hence I have editted manually the stacked pins properties such, that they pass through KDC
|
Hi @dejfson Thanks for another contribution. As you've been told at KiCad/Housings_SSOP.pretty#41 and KiCad/Relays_SMD.pretty#1, always include a screenshot and link to the datasheet (or other documentation) when submitting a PR. Review comments:
|
|
Hi, ok i'll do the changes tomorrow (hopefully). The only one not clear to me is how to fit the pin names to the ordinary triangular opamp symbol. I've been searching for one before in kicad libs, but all the symbols with 3 additional pins were with pin names invisible, and i think it is not what we should want in this case right? |
|
Pin names visibility is done on a case-by-case basis. It will be OK to what cannot fit nicely in the symbol body to be invisible. Pin placement (top, bottom, side, etc.) is also case-by-case. Update the symbol what looks best to you and then let us know why for the review. Thanks! |
|
Hi, before I do go deeper into component definition, what about this one: |
|
to be said, the picture above is not finished, i just want to first get green light to a form+text around the pads before I finish the symbol |
|
It's looking much more nice now! Thank you. I'd rather have straight pins than angled ones. What about moving PAD to the y-axis and putting TFL on bottom, which leaves room for /ON and /SD on top? That should work nicely. Also, squeezing the pin text offset to 10mil should clean things up a bit too. Lastly, did you contact ADI about the possible/recommended PAD connections? |
|
And so that it is included in the PR, the datasheet is at http://www.analog.com/media/en/technical-documentation/data-sheets/ADA4870.pdf. |
|
You mean something like this? |
|
this version represents the last patch |
|
@dejfson This is looking good. Thanks! Please lower the pin text offset and bury the NC pins inside the triangle so they not likely to be accidentally connected. Then I'll review. |
|
I have put NC pins inside body, but i'm not sure whether i understand what you mean by 'lowering pin text offset' would you elaborate on this? thaaanks |
|
Change "20" to "10": |
|
hmm. fancy feature :) done. thanks |
|
Thanks! Final few things:
|
|
Hi @evanshultz, thanks for comments, repaired the three bottom comments, but i do not understand your first comment about removing the text by the pins. Could you elaborate what you mean? If i remove the 'PAD', 'TFL', '\SD' and '\ON' texts, nobody will know what these pins are assigned to. Or is it something else?
|
|
The user can refer to the datasheet for pins. The generic triangle symbol doesn't leave room for pin text for all pins in all cases, like this one. Also, instead of using a line between the pin and the triangle, just lengthen the pin and remove the line. |
|
I'm sorry, but I cannot agree at all with your statement, that user can look in the datasheet. Actually, I'm working in electronics industry for more than 25 years and I can tell you, that there is nothing worse, than having a printed version of the schematic in front of you, and 'trying to guess' what this and that 'undocumented' pin does. When you have the schematic opened in the computer of course this might be an argument, but for printed versions this is from my experience very far from reality that one has a datasheet to a hand. I do not think that leaving the pin names in the form I did makes so disastrous effects on the quality of the library component I have made, and thus I'd like to ask you to accept my argument above. Hence here's the deal: i have repaired the pin lengths, but left the pin names there. If you can accept the component as is, please merge it (we've both lost already 3 days for this), if not, just close the pr because i'm not intending to spend any minute more on this. thanks |
|
Is it possible to swap place of the number and the texts, perhaps it is more readable ? |
|
@jkriege2 @SchrodingersGat |
|
I do not think that we should be allowing nameless pins. It's a hard problem:
I'm not sure how to provide a solution that isn't ugly - but I think that having blank symbols isn't the right way to do it... |
|
For rectangular symbols I would require names ... that's clear I think anyways. If we do that, I would add a small lib of examples to the KLC and require people to stick to them as far as possible (i.e. have a few OPAMPs in different configs, an instrumentation Amp ...). Just a random example: PS: What will the new .sweet-fileformat do for us here? |
|
@SchrodingersGat Having random text instead of pins names seems harder to maintain and, IMO, is ugly. In most cases, the pin name is either blank or contains the same text that would also be free-floating on the symbol. I don't like any result that is possible currently, but leaving off the few pins where names don't fit seem the least offensive to me. Yes, I realize pin names are nice but is having a browser tab open when using KiCad such a burden (until there is a better way)? |
|
Hmmm I played around with the text-size per pin and text besides pin: What do you all think? This might be an option ... also small text for some pins and text inside might: |
|
@SchrodingersGat What do you think? |
|
I think the first option looks neater... Both are adequate though I think. Both will necessitate a change to the KLC to allow smaller pin names but that's fine. |
|
Gentlemen, (scanned from one un-named electronics design journal) Please let me know your decisions. |
|
@SchrodingersGat Do you know what will be possible for pins in the new SWEET-format? |
|
Download this - https://lists.launchpad.net/kicad-developers/binDp0KdUNMWc.bin and rename to a .odt That's the "latest" spec doc for the new format |
|
This is out of topic but I always wandered why isn't JSON used as the format for sweet files. That would reduce the code lines to maintain by using existing serializers/deserializers that can instantiate objects from readable text files. |
|
Yeah JSON would be a very good idea! |
|
@SchrodingersGat @jkriege2 So is either one a solution here? I personally like the 2nd option because it retains a different color for pin text which seems more readable. And the pin text seems more closely related to each pin instead of being squeezed between pins. JSON has a lot of overhead compared with the current file format, especially when the amount of information carried is small. Not saying it's good or bad, just that it is what it is. |
|
Second option is good for me |
|
As we are now close to moving all the symbols to the new kicad-symbols repository, this PR will have to be reissued at https://github.com/kicad/kicad-symbols Thanks for your contributions, and sorry for the inconvenience |
No description provided.