kicad-developers team mailing list archive
Mailing list archive
Re: Kicad libraries for pcbnew
On Wed, 21 Jul 2010, Vesa Solonen wrote:
On Tue, 13 Jul 2010, Øyvind Aabling wrote:
I know that I've been a bit quiet lately (been busy with other
stuff :-), will try and find some more time for KiCad ...
I'll say take your time. There may be some things even more intersting than
KiCad in life... ;)
I can either keep the numbering as is (which could cause some
confusion and some blown components, I think), or I could change
the pin numbers to match eeschema - the question is: Are bridge
devices special enough to warrant an out-of-order pin numbering ?
I would vote yes, as these components (in contrast to lost of other
component houses) are used for bridges only, but what do you guys think ?
If the package is not used elsewhere, I'd say yes too as a mid term solution.
I'll try to avoid blowing too may, even thought there are plenty of free
bridges available :) Thanks to you it's way easier to start.
I've changed the bridges to match the eeschema BRIDGE part, although
it does look a bit strange with those out-of-order SIL pin numbers ...
It might look a little better with pin names like
P, M, AC1 and AC2 or something similar, but that would
require changing the BRIDGE part in eeschema as well.
The long-term solution is of course support for pin function-to-number
mapping, including, in this case, free interchange (with
backport to eeschema) of the two equivalent AC inputs.
On another note, I've also been looking further into
the problem that I've had with the KiCad 3D viewer on
the new (3D-not-yet-supported) ATI gfx card at home.
Is the problem with just KiCad 3D viwewer? What card model?
It's a Radeon HD 4670 (RV730XT), and only KiCad got it totally wrong.
The Mesa demos and varkon worked just fine.
I described the problem about six-seven months ago on
kicad-devel, but I can't remember the post number (or
find the piece of paper, where I wrote it down ...).
Kicad-devel is now totally gone on yahoo,
and google can't find the post on launchpad.
Whitedune did complain (a few times, not thousands like kicad (*))
about X11 BadMatch, but ignored them and worked just fine.
At certain angles, whitedune rendered surfaces that are very
close together wrong (choose the wrong surface to put in front).
It looked like a rounding error or viewpoint distance calc bug.
Both these whitedune problems are still present now, on another
(older) ATI card, so it has nothing to do with that specific
card (but could be related to the OpenGL Software Rasterizer).
*: After I got it not to crash by adding a call to gdk_error_trap_push().
That was the bad news, but the good news is, that one of the things that
has taken up my time lately is a switch from 32-bit to 64-bit Debian.
Memory limits should be far enough for somewhat larger boards...
Now at 908 parts, 6729 lines of code.
On Wed, 21 Jul 2010, Vesa Solonen also wrote:
I've turned the square and circular bridges (BR-GBPC*, BR-KBPC*, BR-WOB
and BR-WOG), so that the pin numbers matches the eeschema BRIDGE device
Forgot to ask: Any special reason not to use arcs for AC symbols?
Yes, IMHO, a sinewave made from two semi-circles looks awful :-)
Oval arcs could be an acceptable alternative, but
AFAICS, kicad can't do those (only _circle_ arcs).
Although arcs and sine curves are related
(to the circle :-), they're not really the same ...
I could also have used the chars '-', '+' and '~' (tilde),
but the tilde is raised, so that also looks silly :-(