Werner Almesberger
2016-01-15 15:00:19 UTC
This is a somewhat long story about the journey towards KiCad 4.
This journey is still not over, but I'm beginning to feel that it
may have a destination that is not a circle.
It all began with an Ubuntu update last December. My 14.04 LTS
("Trusty") was getting long in the teeth, so I thought it was time
to upgrade to "Wily" 15.10. Alas, when trying to trick the upgrader
into going from LTS to non-LTS, I ended up with "Xenial", the
experimental 16.04.
This caused a number of problems, e.g., Chromium failing to do SSL
with Google services (but getting along with most of the rest of the
world), and Xfig becoming very eager to segfault, but eventually I
solved all that.
However, one big problem remained: KiCad. I had been using an older
version of KiCad (I think it was bzr 4150), but some of the libraries
it depended on were no longer available under Xenial.
As it happens, new and shiny KiCad 4 (bzr around 6400) had been
released recently. Since holding on to an increasingly distant past
is usually not the most sustainable of plans, I decided to try moving
on and to welcome the new.
The first thing I tried was to see how pcbnew performed. When I had
poked at newer KiCad versions before, I had always experienced
extreme slowness in the "legacy" canvas. The OpenGL canvas was snappy
but lacked (and still lacks) some of the functions available in
"legacy", so one has to switch back and forth between the two.
To my dismay I found that "legacy" was still slow. Worse, I found
that eeschema had adopted the new zeitgeist, and had become
unbearably slow as well.
This did not look good at all. In the past, when people reported
poor graphics performance of KiCad, their complaints were brushed
aside with the argument that developer time was precious and they
couldn't waste time on supporting slow hardware.
I had used weak video cards in the past since most of what I do is
2D anyway, and I'm already replacing broken fans way too often, so
I prefer my video cards to be without them. So I had accepted that
my hardware may just not be elite enough.
But I recently had to replace a failing ATI card with a more modern
Radeon HD 2400, which is even sufficient for some games. So was that
*still* not good enough to draw a few lines in KiCad ?
After a bit of searching I found this bug report
https://bugs.launchpad.net/kicad/+bug/1003859
Lo and behold, disabling EXAPixmaps did the trick, and both eeschema
and pcbnew's "legacy" canvas both returned to decent performance.
[ I could have sworn I had written about the EXAPixmaps problem
before. But I can't seem to find a trace of it. Maybe that mail
was somehow lost without me ever sending it. ]
The next problem I hit was that the title block (the info box on the
bottom right) of schematics sheets has grown considerably. So now it
overlaps with a good part of the circuit.
The solution for this is to define one's own page layout. There is a
tool for this, called "pl_editor". I made a page layout that is
reasonably close to the original version:
https://gitlab.com/anelok/anelok/blob/master/common/eeschema-layout.kicad_wks
I still may adjust it some more to match exactly the old version.
Then I'll move it over to the eda-tools repo.
This solved the most glaring issues with eeschema. I made some
changes to the schematics (replaced the slider with tactile switches),
then launched CvPcb to update the footprint associations. This was
instantly rewarded with all hell breaking loose.
CvPcb cheerfully informed me that the old definitions had to be
replaced, and offered to lend a help with that upgrade. Of course,
this didn't work.
So I manually created the new footprint table and copied over the
libraries from anelok.pro:
https://gitlab.com/anelok/anelok/blob/master/hw2/fp-lib-table
Alas, CvPcb wasn't completely satisfied with this either, and only
picked up a tiny number of footprints. I had to redo all the rest of
the associations. (The main change seems to be that footprint names
are now prefixed by the name of the library they come from, e.g.,
"0402" is now "stdpass:0402".) Oh well, fortunately Anelok isn't all
that big a circuit ...
At the end of this, I could delete anelok.cmp. All the information
in it now seems to be contained in the netlist.
There may still be surprises in eeschema, and I haven't really tried
pcbnew yet, but I'm beginning to feel more confident about that
migration to KiCad 4.
The benefits of using KiCad 4 include:
- easy installation from pre-build distribution packages,
- files compatible with what other people are likely to use,
- access to the CERN push router in pcbnew, and
- scripting capabilities.
I have high hopes for the push router. And the scripting may give us
back the automation for which Wolfgang had added command-line options
so many years ago, but that was lost after incompatible changes to
the internals of KiCad.
To be continued ...
- Werner
This journey is still not over, but I'm beginning to feel that it
may have a destination that is not a circle.
It all began with an Ubuntu update last December. My 14.04 LTS
("Trusty") was getting long in the teeth, so I thought it was time
to upgrade to "Wily" 15.10. Alas, when trying to trick the upgrader
into going from LTS to non-LTS, I ended up with "Xenial", the
experimental 16.04.
This caused a number of problems, e.g., Chromium failing to do SSL
with Google services (but getting along with most of the rest of the
world), and Xfig becoming very eager to segfault, but eventually I
solved all that.
However, one big problem remained: KiCad. I had been using an older
version of KiCad (I think it was bzr 4150), but some of the libraries
it depended on were no longer available under Xenial.
As it happens, new and shiny KiCad 4 (bzr around 6400) had been
released recently. Since holding on to an increasingly distant past
is usually not the most sustainable of plans, I decided to try moving
on and to welcome the new.
The first thing I tried was to see how pcbnew performed. When I had
poked at newer KiCad versions before, I had always experienced
extreme slowness in the "legacy" canvas. The OpenGL canvas was snappy
but lacked (and still lacks) some of the functions available in
"legacy", so one has to switch back and forth between the two.
To my dismay I found that "legacy" was still slow. Worse, I found
that eeschema had adopted the new zeitgeist, and had become
unbearably slow as well.
This did not look good at all. In the past, when people reported
poor graphics performance of KiCad, their complaints were brushed
aside with the argument that developer time was precious and they
couldn't waste time on supporting slow hardware.
I had used weak video cards in the past since most of what I do is
2D anyway, and I'm already replacing broken fans way too often, so
I prefer my video cards to be without them. So I had accepted that
my hardware may just not be elite enough.
But I recently had to replace a failing ATI card with a more modern
Radeon HD 2400, which is even sufficient for some games. So was that
*still* not good enough to draw a few lines in KiCad ?
After a bit of searching I found this bug report
https://bugs.launchpad.net/kicad/+bug/1003859
Lo and behold, disabling EXAPixmaps did the trick, and both eeschema
and pcbnew's "legacy" canvas both returned to decent performance.
[ I could have sworn I had written about the EXAPixmaps problem
before. But I can't seem to find a trace of it. Maybe that mail
was somehow lost without me ever sending it. ]
The next problem I hit was that the title block (the info box on the
bottom right) of schematics sheets has grown considerably. So now it
overlaps with a good part of the circuit.
The solution for this is to define one's own page layout. There is a
tool for this, called "pl_editor". I made a page layout that is
reasonably close to the original version:
https://gitlab.com/anelok/anelok/blob/master/common/eeschema-layout.kicad_wks
I still may adjust it some more to match exactly the old version.
Then I'll move it over to the eda-tools repo.
This solved the most glaring issues with eeschema. I made some
changes to the schematics (replaced the slider with tactile switches),
then launched CvPcb to update the footprint associations. This was
instantly rewarded with all hell breaking loose.
CvPcb cheerfully informed me that the old definitions had to be
replaced, and offered to lend a help with that upgrade. Of course,
this didn't work.
So I manually created the new footprint table and copied over the
libraries from anelok.pro:
https://gitlab.com/anelok/anelok/blob/master/hw2/fp-lib-table
Alas, CvPcb wasn't completely satisfied with this either, and only
picked up a tiny number of footprints. I had to redo all the rest of
the associations. (The main change seems to be that footprint names
are now prefixed by the name of the library they come from, e.g.,
"0402" is now "stdpass:0402".) Oh well, fortunately Anelok isn't all
that big a circuit ...
At the end of this, I could delete anelok.cmp. All the information
in it now seems to be contained in the netlist.
There may still be surprises in eeschema, and I haven't really tried
pcbnew yet, but I'm beginning to feel more confident about that
migration to KiCad 4.
The benefits of using KiCad 4 include:
- easy installation from pre-build distribution packages,
- files compatible with what other people are likely to use,
- access to the CERN push router in pcbnew, and
- scripting capabilities.
I have high hopes for the push router. And the scripting may give us
back the automation for which Wolfgang had added command-line options
so many years ago, but that was lost after incompatible changes to
the internals of KiCad.
To be continued ...
- Werner
