SoylentNews is people
SoylentNews
The computer-aided design software packages (ECADs) available to electronics folks for creating schematics and printed circuit board layouts have long been an aggravation when trying to share data with someone who uses a package produced by a different vendor--due to proprietary file formats that are (apparently, purposely) incompatible.
Many years ago, Cadsoft's EAGLE was available as a demo that would do very limited PCB creation but which had unlimited ability to view/print already-created files. It was also cross-platform. For a short time, EAGLE-compatible files became a quasi-standard for amateurs and pros on a budget.
In 2006, however, Cadsoft got greedy and DRM'd their stuff so that it would lock you out of your work product under certain circumstances, as described by Markus Zingg on October 24. Cadsoft quickly lost what little luster it had in the community. CERN engineers are hoping to produce a package that will do the same job - but better.
More down the page...
Now, Cian O'Luanaigh at CERN, the European Organization for Nuclear Research, reports
[...]so far, the engineers who design [printed circuit] boards often have had no option but to use proprietary tools.[1] That's about to change: CERN experts are adapting the open-source software KiCad to make it an efficient tool for designing open-source hardware. This Free Software makes it easier for electronics engineers to share their designs.
KiCad development began in 1992. The software--which runs on the computer-operating systems GNU/Linux, Windows, and Apple OS X--creates schematics for printed circuit boards with up to 32 copper layers with additional technical layers. Since 2013, experts in the CERN Beams department have made important contributions to KiCad as part of the Open Hardware Initiative (OHI), which provides a framework to facilitate knowledge exchange across the electronic design community.
"Our vision is to allow the hardware developers to share as easily as their software colleagues," says Javier Serrano, head of the BE-CO-HT section and OHI initiator. "Software sources are easily shared online because they are text files and everyone has access to editors and compilers that turn the sources into a program. On the other hand, in the case of hardware design, most of the time this is done using proprietary tools. Therefore, in order for people to modify the sources, they need to use those proprietary tools."
When [development on] the KiCAD project started at CERN, many free tools were already available to hardware designers but none was easy enough to use when designing a complex circuit. Among them, KiCad showed the best potential.
"We started by cleaning the basic code and introducing a new graphical engine," says Tomasz Wlostowski, a member of the BE-CO-HT section who, among other things, is in charge of supervising the development of new features for KiCad. "With our contribution, we aim to develop KiCad up to a point where it becomes the de facto standard for sharing, and more and more users, including corporate ones, start working with it."
Next week, the team is going to release two new features that many in the free/Open Source EDA community have been asking for: differential pair routing and trace-length matching.
"Thanks to the new differential pair routing, you can more easily design PCBs that support fast signals over a long distance and with less noise. This is particularly important for devices that deal with great amounts of data," says Wlostowski.
"The second tool--length matching--automatically ensures that two signals take exactly the same time to cross the PCB. When the feature is selected, the tool automatically adds meanders to adjust the delay. This is very useful when timing and synchronisation become important parameters to take into account."
[...]Raspberry Pi and Arduino have already donated to the CERN KiCad initiative. You can join the effort to enhance KiCad and make it an efficient tool for PCB design by making a donation via the CERN and Society website.
[1] This guy has a list of what he perceives as the shortcomings of the current KiCad package.
(Score: 1) by tftp on Friday February 27 2015, @06:52AM
Eagle felt clumsy and its design flow seemed out of order. You did your schematic capture and along the way assigned foot prints and place them as you go. Why people like that design flow is beyond me. I prefer: schematic capture -> check & double check schematic -> BOM generation -> foot print assignment -> board layout.
Most workflows start from the central library. You build your schematic with known good components; each of them consists of a schematic symbol, a footprint, and a link to the ordering system (usually a company-specific component code.)
I am unsure how you could draw the schematic first and then, at a later step, assign footprints - not only this has to be an endless source of mistakes; it also creates confusion, as a 8-pin symbol, for example, can be used (unintentionally) with a 8+1 pad footprint - and then you end up with an unconnected bottom paddle. The library workflow prevents this mistake because each part that you insert into the schematic is valid and self-contained.
(Score: 3, Interesting) by LoRdTAW on Friday February 27 2015, @03:08PM
I agree that it can really come back to screw you. It did happen to me. But that was because the KiCad DRC (design rules check) is severely flawed. I can for instance drop a transistor into my schematic and then assign it a DIP 8 foot print. In reality I should have the freedom to do so as you could be using a DIP transistor array. In schematic capture, unconnected pins must be designated as so by placing a no connect on them (basically an X). If you fail to denote unconnected pins as unconnected, it fails the schematic capture DRC.
BUT here is where KiCad needs to get its shit together. If I assign a DIP 8 to a 3 pin transistor symbol on the schematic, the layout tool DRC does not list the remaining five unconnected pads as an error. That should be reported to the user. And there should also be a method of selecting that foot print and then place the same NO-CONNECT X on them to bypass the DRC for special cases.
I believe this design flow stems from the fact that in reality PCB schematic capture and layout is nothing more than a list of connections from one component to another. And many of those devices share the same foot prints (DIP, SOIC, QFP etc.) So a small ARM u-c can re-use the same footprint as a CPLD or another 100 pin QFP device. So they decided to unbundle components from foot prints. It makes sense to large degree for a small project to start simple and allow easy footprint sharing. But it also can come back to haunt you if you are not extra careful.
KiCad does have a footprint filter that can be used to assign one or more foot prints to a device which helps users ensure they have the right foot print. But being an OSS project, they don't have that as a priority. And to top it off the component to footprint assignment program is very, very broken in its latest release.
I just checked their latest build. They must be non-functional alcoholics as there is no way the new footprint names are in any way intuitive. They are asinine and overly verbose for no reason. They are also STILL lacking a search tool for foot print names. I hope someone puts a stop to this pathetic permanent beta phase. IMHO they need new project leadership.
The author of the article hit the nail on the head with this line: The project is stuck in permanent beta. I am not moving from old-stable until they fix this mess.