Some questions about conventions
werner at openmoko.org
Fri May 22 20:55:37 CEST 2009
?lvaro Lopes wrote:
> The only problem I see here is that if component is small or name too
> big, and we use upper/lower for VCC/GND they will overlap. I guess
> this should be done on a case-by-case basis.
Yes. Common sense should always trump rules :-)
> 300 mil is OK if pin number is 2 or 3 characters wide. But for small
> packages (less than 10 pins) there's a lot of wasted space. Decreasing
> this to 200 mils would make schematic more compact, while maintaining
Okay, that makes sense.
> Yes - but there's a simple problem which might be hard to overcome
> - we cannot change position of pin name - it's always centred in
> relation to the pin itself, so drawing connections to the pin will
> overlap with the name.
Ah, I see. As a quick work-around, how about disabling the pin name
and adding a text field (50 mil height !) with just that name ? We
can then later try to get a "pin inside and on top" option into
KiCad, and update the component accordingly.
> See the attached alternative for that component. Does it look better ?
Yeah, much clearer ! I would omit the "driver" for nOE, just like
There's also the small issue that this is now slightly different
from the typical way how a driver with inverting enable signal is
drawn, i.e., without the inverter circle on the enable input (NXP)
or with separate inverter (TI). So at a quick glance, this may
look like a non-inverting enable.
Having one circle on the outside and another the inside would be
too confusing. Labeling it as nOE helps to disambiguate, so your
solution is consistent and understandable. Or perhaps we should
break with the "inverter circle always on the box" convention
here and only have the circle inside.
I'd lean slightly towards the latter, because it seems to be
closest to how one would expect a driver with inverted enable
input to be depicted, based on past experience.
> Sorry for sending this as a .diff, but gmail is blocking the
> attachment if I use the original .lib.
Hehe, no problem :)
More information about the Gta03