edacore is an open source project to fulfill the part library needs of all open source Electronic Design Automation tools, and ideally the rest of the EDA industry. This is an ambitious project with high quality standards and long term goals. The project is still in an early stage.
The project was announced by Peter Stuge in the EDA devroom at FOSDEM 2015. There is a ?video recording of Peter's presentation and the slides are available: for online viewing and for download.
Stay tuned! You can join #edacore on irc.freenode.net as well as follow @edacore on?https://twitter.com/edacore to connect with the community.
EDA File Format Documentation
Ok I am a gEDA user. I have been for over 10 years now. I don't question that kicad might be more user friendly because of how gEDA is designed to have a user defined workflow. This makes it easier to automate, something few EDA packages really do as well IMHO. It was geared around people calling all of it's different utilities from the command line, scripts or makefiles. That said there is a gui just for people who only want to take a schematic and make a board from it. It also has hierarchical design.
Bassman 59 describe the M4 system as a "cluster fuck." Please understand you don't have to use that. The M4 option is there so that you can have programatically defined properties in your footprints. For example some people like being able to change SMT pad lengths for hand assembly on prototypes and then shrink them back down automatically for reflow assembled boards.
For any EDA package you have to track what symbols and footprints you use with model number components.
Looking to see what gEDA library looks like now? It is available here. No need to install anything.
http://www.gedasymbols.org/
Yes CERN has pumped some coding time into kicad that has added some PCB layout features which I am a little jealous of however kicad seems to have more reliability issues. gEDA is *very* reliable. I am currently on both developer mailing lists because both communities are working to create a more common code base. We are all tired of duplicating work.[/b]I didn't know about it before!
Could you please provide more info about this? Are there some planning about it?
Those are really good news! I'm very happy to know it! Joining in common goals is very needed for OSS projects.
@Dave, as much as I hate to say this compared to altium, orcad or protel all opensource EDA is really a personal play thing because of user base. KiCAD has some disadvantages that to me are kind of glaring but I am more interested in adding things than starting/being in a flame ware. The UI experience of gEDA might feel like a toy if you are new to the *nix way of thinking about things but after you get used to it there are things you realize are possible that would be very hard if no impossible to do in a "modern" integrated GUI. Keep in mind I started out as an electronics hobbyist who took up Linux way later on.
@Circuiteromalaguito there was a meeting this year at FOSDEM in Belgium. The videos are for some reason not posted on their website yet but you can find them here. https://video.fosdem.org/2015/
The project is supposed to be hosted here http://edacore.org/
You can see the gEDA half of the dialogue here http://comments.gmane.org/gmane.comp.cad.geda.user/45312
The KiCAD part is on a mailing list you have to join yahoo us access here https://groups.yahoo.com/neo/groups/kicad-users/info
The folks who do circuit simulation where there (icarus, gnucap, ng-spice and etc) as were the EDA people from QUCS, KiCAD and gEDA. One person proposed EDAcore and started a dialogue that has span both the gEDA, KiCAD and newly minted EDAcore mailing lists. It has ebbed and flowed since then. I get the impression a number of us are quietly hacking away at things but no group work has kicked off so far.
I really like the gEDA devs but they have their ideas of how things should go. They have not included a lot of contributions of the years because they were not in the same language as their other code or did not meet their coding standards. To be fair even some of DJ's stuff never got included. This has limited the functionality of the gEDA suite with out these 3rd party widgets. It has however made the suite run very reliably. The PCB tool has had it's issues but with extensive testing it passes. I am hoping that PCB getting doxygen documentation will help speed things along.
There has been talk of incorporating some of CERN's contributions to KiCAD as they were written to be portable between suites. However most people who have looked at the PCB tool that is paired with gEDA will tell you the source is a mess. gEDA and the PCB tool have different origins and PCB's architecture was never so carefully controlled. The gEDA source code I can read the PCB source just confuses the heck out of me. Eventually DJ or one of the Peters pointed out to me that it has no unified concept of what a PCB is. I get the impression from people that KiCAD's PCB tool has architectural issues of it's own though possibly less seriously. I get the impression that basically both groups want to flush out the mess their current code has them in before combining forces.
My *personal* hope in the short term is that we work on compatibility with non-free software formats because right now.
OrCAD - gEDA has this in a limited way (I have never used it). It should get cleaned up and moved to EDAcore so KiCAD can use it.
EagleCAD - CERN is writing import for this into KiCAD but we could move that to EDAcore and add export which would help entice more of the open hardware community to migrate
Protel - The published their file format spec but no one has written a library to interpret it.
Altium - Unlike the others they keep their format closed so we are all waiting on this I guess. http://hackaday.com/2014/10/15/reverse-engineering-altium-files/
PS: The QUCS talk was really good. Even if you don't care about gEDA or KiCAD you might want to watch it.
PPS: In case you think I am just waiting for others to do the work keep in mind I have been quietly working on something for a little while. I will release it when I feel ready. It should ultimately change openocd, gEDA and KiCAD but in a more minor way.
For those who want a quick summery of what killed it.
*Kicad - is trying to clean up the underlying concept of how it handles a schematic in eeschema. I think they are also trying to work out how to do hierarchy and a few other things geda already has. (someone on the kicad side should really say more, I am on their users list but not their internal dev one)
It is stalled.
KiCAD rightfully went back to focusing on their own stuff.
gEDA went through some internal turmoil.
EDAcore will probably resume but when I can't say.
I started to write the story of geda from birth to death when I realized how late it was. At the 7th paragraph when I realized that talking now was risking our current quasi stable politics.
gEDA is painfully close to getting a small band of leaders with authority to fix things. (I am a proposed member.)
Hello.
I wrote this as a very early draft in order to understand KiCad better and the planning of the project.
I'm sure it's highly inaccurate, full of mistakes and written in a not so good English.
This is part of my personal project to understand KiCad, some inaccurate research notes and personal ideas I would like to refine.
Any feedback (corrections, suggestions, information sources...) will be very welcomed.
I would like to know opinions about it, inconsistencies and other ideas. I would like to research about KiCad history and involved developers in a detailed way too, if the KiCad Team agree on it.
I plan even to persuade the teachers in my vocational school to make this possible Spanish/English article as homework.
It will be about:
- Software: KiCad, other useful tools such as QUCS.
- FOSS: Importance in society and what can provide to electronics.
- OSHW: Explaining historical roots, such as homebrew computers and the classic hacker culture, plus current trends.
- Advantages in learning electronics by using: Copyleft learning material, FOSS/OSHW communities, forums and mailing lists, videoblogs.
- Active Learning in electronics.
My basic understanding about the development of KiCad:
----------------------------------------------
I see KiCad is manpower limited and needs to complete certain goals and not waste resources.
I think to understand KiCad have very important tasks to be done to be future proof:
- I understand KiCad needs desperately a massive and careful refactoring.
* Maybe there's still too much cowboy coding and stuff to clean before implementing important but complex features.
* Maybe part of that refactoring could help making the code easier to understand to new developers.
** This would mean following somewhat strict and defined coding practices, very documented code and other stuff developers are aware of it for sure.
My understanding about potential KiCad sectors
-----------------------------------
- Hackers: People very enthusiastically interested and active in electronics and programming field that just would like to participate in a community project.
* They can be programmers with interest in electronics, even being very skilled professional programmers donating part of their spare time.
* They can be in the electronics field but interested in programming too as a secondary field to explore.
- Hobbyists/Makers: Some already switched from Eagle to KiCad, but many of them switched to free but vendor lock-in alternatives or may encounter some barriers: Interoperability, UX, performance on low end computers.
- EEs: They are used to many high end solutions such as Cadence Allegro, Altium, OrCad and others.
* They might be very used to certain features and/or workflows, probably more in very complex designs.
* Reach these goals are very difficult to do, but not impossible if the project grows.
- Companies, educational sector, NGOs:
* Organizations don't wanting to spend big sums of money in EDA software or unable to afford it, even using old versions or illegitimate ones.
* They might have developers in their organization. In other cases like certain countries, they could hire one for less than the license cost.
** This way they may be able to contribute to make KiCad match their needs and even finally reduce costs. And avoid illegitimate practices, too.
Some goals I personally consider important:
----------------------------------------------
* Advanced and reliable file format interoperability: Deal with it, the situation is even worse than Office suites and needing to redo projects might unmotivate many people.
* Usability: People are already extremely used to common practices and features in popular propietary software.
** I don't see pragmatic to be the small guy in town fighting against the big ones, I believe a different strategy should be done.
** I think behaving more like them and not look too different might be better in a logic and comprehensive way by "copying" the good usable stuff and avoid the bad ones.
*** Maybe it could make transition easier. I think LibreOffice does it in a smart way.
* Very powerful scripting capabilities and a central repository, even trying to surpass capabilities of high end and mid end EDA software.
* Easy collaborative Edition, providing visual diffs and other stuff.
My defense on "Release early, release often"
------------------------------
- Release incremental releases with minor and less bug prone but useful changes could give more sense of activity.
* This could provide more stimulation to users about the project, having new things to use and explore.
** You can think about it as giving small gifts to keep interest in following new versions.
* I think this could enhance the community feeling and promote a more active participation.
* People like to see new things, it's something wired in our brains.
* Because of these minor but interesting releases, there could be more media exposure and work as a form of marketing.
- Having two branches: stable and experimental
* This could be done until the refactoring gets done. The stable one would just provide these small updates as minor improvements.
* Would this require too much extra work?
* Can it be done without interrupting the mainline important future proof branch?
Thanks in advance.
Kind regards.
Hi,
nice analysis!
> I think to understand KiCad have very important tasks to be done to be future proof:
> - I understand KiCad needs desperately a massive and careful refactoring.
> * Maybe there's still too much cowboy coding and stuff to clean before implementing important but complex features.
> * Maybe part of that refactoring could help making the code easier to understand to new developers.
> ** This would mean following somewhat strict and defined coding practices, very documented code and other stuff developers are aware of it for sure.
That is all true, but.. it 100% applies to all projects I worked / am working and that is maybe the "rule" unfortunately.
I once read somewhere that we are still in the early stages of software development. The humanity still dont have 100 years of software development so there are still lots of questions how to solve this issue with softwares. That will be the holly grail solution.
I estimate that such type of a task like that in a project like this would need a year or more of work with a team in the same room re-designing and re-writing the software (from scratch?).
During this time, no new support can be added (or it need to be merged or rewrited again in the end... )
That is a problem unfortunately for real companies / products: "we cannot stop to make a refactoring of the software, because we must continue to support and ship the product !".
And this is a nightmare for developers :/
The good thing here, is that KiCad is not a company so there is no problem to stop "shipping the product"
That is a point you can explore in your "thesis" and evaluate the pros/cons etc..
Cheers!
Mario Luzeiro
I can not post that right now. Things are just calming down.
gEDA did not start on atari. PCB did. Later on gEDA and PCB developers got together because most of them were users and at the time gEDA was the only open source schematic capture and PCB was the most modern layout tool that was open source.
The trouble with EDA core is not one of file format. People have this idea that we have no good way to represent the data when it is stored. That is not true. The real issue is the layers above it. Look at the number of translation utilities between gEDA and Orcad or geda and kicad. The real issue is how you represent the data after the file is read because you want some kind of data structure that can elegantly be read by functions to do 3 different things.
1. Make a netlist
2. Make a 2D drawing. (for a schematic)
3. Make a BOM
gEDA in it's start embodied the ideas of EDAcore in that it was not distributed as 1 package but as a family of them.
libgeda - library to handle schematics
gschem - program to manipulate schematics graphically
gattrib - program to tweek symbol attributes in a spreadsheet
gnetlist - prgram to make a netlist from a schematic
and etc.
For users this was a pain but the intention was for 3rd parties to use libgeda to write stuff that used our file format and etc. libgeda's functions had a reasonable amount of documentation and example code to let you do this.
In the here and now I am hoping we kind of return to that model. I would like gEDA to have an interface to KiCAD's libraries it can natively support their symbols and vice versa. Then we could collectively move on to doing the same thing for Eagle. Later we could do the footprints.
Schematic support is not really possible as I see it. At least not in a way that would work cleanly. There would always be translation issues.
C/C++ is not an issue. Actually DJ and others have long wanted to make the code of PCB more C++ in feel.
A larger fight inside of gEDA is Scheme and Python. We have an optional alternative netlister in the next release that adds python as a dependency which has been controversial.
KiCAD took a very different approach on a number of levels that make our codebases very different in architecture. I am not making a judgement here. gEDA's architecture has some things I don't care for too. Blending the two would be a larger project than ether of them individually.
The Document Foundation is a good example *now*. They had a lot of internal struggles early on.