Alternative option - is to treat each PCB as separate component with its own schematic etc. Makes sense for large systems having many identical PCBs.
I’d love to familiarize myself with them. Could you reference something to read for me, please?
1 Like
I am not aware of one single book that will teach you about system design practices. I would even guess that there are many such books out there that will contradict each other in some detail.
I think what @bobc wanted to say is something similar to this:
The first thing you do is define the interface. After that different people can work on the different parts of the system without needing to talk to each other every few seconds. (The interface can change if necessary. But changing it is connected to costs depending on how late in the project you want to do it.)
In your case the connectors are the first thing that will be defined. Split the pcbs according to some logic not by “this pcb has a bit of space left i can put something there”. This will make later maintenance a lot easier and also make the interface definitions easier. (If there is a logic behind what goes onto what pcb then you will be able to find out half a year down the line what is going on.)
4 Likes
To follow up on what @Rene_Poschl said. One of the reasons I spend way more time on this forum than would be indicated by my actual Kicad usage is the practical tips I pick up on these kinds of things here. This is where all that ‘theory’ gets put into practice.
4 Likes
I am familiar with interfaces.
My concern is coming from real life where you have to make changes on the go.
For example, we designed a radio, put some unbalanced amplifier. Speaker has one output connection and one connection to the ground. The first prototype is made and manager doesn’t like the volume, it is not that loud. Now we have to make changes to the schematics to use balanced amplifier to get more power from batteries. Because we have a bridged output we have to use two separate wires to the speaker. In ideal world we would always have 2 wires going to the speaker but in real we had only 1 connection and for the second one we used the same ground wire which is going to the battery case. And in this example we have to change interface. We don’t have common ground anymore.
And I am sure stuff like this happens with more complicated projects more often. In software engineering it is common to use linters and static code analysis to find errors and design flaws. In electrical engineering there is an electrical rules checks and design rules checks.
It is common to have checker and the more complicated project we would have then more sophisticated checker we need.
If you need a prototype to find out that your amplifier does not give the results expected then either management does not give you good enough specifications or you do not do enough to ensure you are within the given specifications.
You know simulation is a thing. And if you say the speaker did not fulfill what you thought it would then you should have measured it beforehand.
Just to be clear: I do not say it is a useless feature. Your example is just not really a good one as it shows that you did not do enough during the planing phase. In nearly every engineering discipline finding a mistake one phase later means it will cost about 10x more to fix it. (This is what i hope you learn with this project. Making a few measurements early on could have saved you a lot of problems.)
Software engineering is the worst industry to use as an example as well. A large portion of software projects run over budged, over time or have a massively reduced set of features compared to what is planned beforehand. (And that is before we even ask if it has security critical bugs.)
This industry has not yet really figured out how to manage their projects such that you get the success-rate of for example pure electrical or mechanical engineering. (One reason is that the cost of failure is much lower. So there is less need for getting it right the first time round)
3 Likes
Thank you for explanation, Rene. I agree, in non-software cost of the change is huge. Unfortunately my exposure to it is only at hobbyist level.
Anyway it is pretty darn interesting how people define future characteristics of devices.
Software engineering is difficult. It happens due unpredictable complexity, bad staff and management. Sometimes even simple name of the button can make a difference. Also, unlike real engineering there is no way to build a model of future. In electrical engineering it is possible to build a schematic and run model to simulate the physical processes. In software engineering you can build a prototype but it won’t be functional until the actual code will be written. And by the time when actual code will be written the requirements will be changed. Incredible flexibility of software unties hands managers giving them freedom to changes constraints at any given point of time. Also, software heavily depends on other software which is also going through changes. For example, I support large integration with Facebook and they rollout updates every 3 months giving you 3 months to upgrade or your project will become unusable. Imagine you have to design devices with chips which is available for sale only for 6 months and you can’t buy enough of them for future use and you will get new devices specs at first day of those 6 months. Speed of changes is crazy. And if you don’t keep up, your software looks old, becomes incompatible and you can’t sell it. Therefore features are getting removed and results of bad previous decisions get accumulated making software slow or unstable. There are also human factors involved. Industry is young, has a high demand in specialists which attracts unqualified staff.
I love this. People in software still think their way is the best, their tools are the best (include git for everything).
A bit off topic but ok. My comment was not meant as a “the tools are not adequate”. It was more a “the philosophy is not really comparable to other engineering disciplines”. (This is why cherry picking one sentence as a quote seldom is a good idea. This feature helps here on the forum one answers a post with many different questions. But you used it to pull my comment in a direction where i never intended it to go.)
But lets answer your main point about git (After all it might be useful for others to understand when to use git and when to use a different approach)
There are basically two major philosophies for version control systems. One is a centralized approach where you have a central server plus a person responsible for getting stuff merged onto the central server. And one is decentralized where everyone is responsible for merging stuff.
Git is a decentralized tool that aims at making it easy to merge different contributions while still keeping everything clean. It is an amazing tool for exactly that purpose. This system works as long as your file format is text based and merge able. (Source code typically is exactly in that format) If the file format is neither of that you are better off using a centralized system like svn. (You need locks in that case to ensure nobody else touches the same file at the same time.)
For kicad files i would say you can use either. For library management git is fully ok (as long as everybody involved uses the same version of kicad.) Lib files are easily mergeable if you understand the file format. (After a few merges you will get to know the format well enough to do the job.)
For designs it is a bit of a different story. I don’t think you can work on the same design at the same time no matter what tool you use. If you can trust everybody involved git is totally ok. Otherwise go for a more centralized approach that offers locks will be required.
One of the reasons why git is king in software development is that it puts the burden for merging on the contributor instead of the project manager. (This is by design. Watch the talks by Linus Torvalds to get more information) The idea is to make merging as painless as possible. This should encourage the use of branches for developing new features. And it should really encourage many small commits that document what is going on.
This allows for many people working on the same project at the same time while nobody is really required to be up do date of what everybody else is working on. (So perfect for large scale open source projects like the linux kernel.)
If this is not your style of working on projects (Meaning you want more centralized control) then you really need to use a different tool as this is the core of why git exists.
1 Like
From my 10+ years in software engineering git is the best tool for code management.
Personally I don’t like assets (symbols, packages, 3d models) management in KiCad. For non-software engineers it is complicated to manage.
Assets storage has to be centralized with background updates and easy contribution right from KiCad interface. It will help to grow community around KiCad because libraries will have more components. Also getting anonymous usage statistics for components will tell you which components being actively used by community and if those are substandard, bring them to standard or supply authors with guidelines.
The official lib will always need some manual checks by maintainers otherwise you will not get the high standard for parts we have now. So there must be a way to communicate between the contributor and the maintainer. This is why github is used for the library. It offers an easy to use (relative to other tools) interface for contributing and most importantly for communication. The most important part of the communication platform is an easy way to share image files. (Screenshots, dimensioned drawings with annotations about what is wrong, …)
We also need an easy way to merge different contributions. (So git is ideal here. Other version management tools would make it much harder)
Believe me we thought about this a lot over the years. Unless something better than github comes along the lib will stay there. In part having some burden for contributing is a blessing in disguise. It filters out a lot of low quality contributions. (A lot of contributors already fail the “please provide screenshots and link to the datasheet” filter. If that is the case i already know i do not need to waist my time on the contribution.)
Usage does not really tell you anything about quality. A footprint for a resistor will always be used much more than one for an esoteric part like an RF module. The only thing you learn from a pure usage statistic is what parts are popular. (So electronic part distributors would be more interested in that statistic then we library maintainers.)
4 Likes
I love ASCII base file format from KiCad is a beautiful thing make it work with any version control tool (include git). Allow user to script the hell out of it.
Multi boards features are not key features in design in my view. I would think the gain of development time vs. user to gain are too low for me. Only cool thing about multi-boards may be 3D model view of board plugin to each other. But KiCad version as I know of before 4.0.1 version already able to do that by using export VRML features, and import special footprint with the other board VRML.
When the connector across the board have to be change, the cost of updating their names across boards is way lower than the cost of designer to change all the circuitry, firmware to make it work.
Multi-Board projects make a lot of sense.
Adding a way for a project file to contain multiple schematic and board files is the easy part, but it doesn’t help much without connectors as “special” components and tracing nets through multiple boards and configuration options.
Commercial solutions for that exist, I’ve seen that in action down to defining a pinout for a connector including a few GPIO pins that are connected to an FPGA, adding multiple copies of the connector to a board and having the EDA tool output a VHDL fragment and pin configuration table to make the GPIOs appear as a two-dimensional array indexed by pin and slot number.
To have that happen we need to special-case connectors as components. I’d be all in favour of that, as this would also allow assigning electrical types to pins, which would allow us to mostly get rid of PWR_FLAG.
2 Likes
You can only get rid of the pwr flag if ERC is able to follow a power supply line through passive components (fuses, inductors of a filter, …)
The connector side of things can already be done in the current version of KiCad by creating project specific connector that defines power supply pins as power output.
I like the idea of a special connector component. But that special to me is not special. I would just create a connector symbol on my project library, and use it for all the board projects. When update the connector name, input/output/power types … will be propagated. And some easy renaming feature in symbol editor would event better.
The electrical type would need to be inverted on the other side of the connection, so you have two components that need to be synchronized.
2 Likes
And the footprint needs also to be inverted. (Including possible additional fields for BOM creation.) Meaning the inheritance feature of the new symbol file format could come in handy here. (Inherit pin numbers and pin names but not pin types, footprint or BOM information. There could be a special inheritance rule stating “invert pin types” to make it easier.)
1 Like
To me avoiding in/out type should be easier if this connector is go through more than 2 boards, the output pins may not all come from one board, you then need invert for each individual pins!. I think the only designer can save themselves in this case. Unless ERC take in multiple boards for checking it. Event ERC work, we then still don’t need to specify type on connector other than passive or unspecified still.
Kind of defeats the purpose of ERC if you go about it that way.
I mean ERC for multi-boards work, then the intput/output define are at the component level (FPGA, MCU…), connector should just be transparent (no need to dictate what type on the connector level).
1 Like
I have to elaborate on contributed parts and statistics.
Let’s take a TDA2003. It is outdated, deprecated and discontinued. But it is still being used, produced and successfully sells on Chinese market.
You could think “it is deprecated, it should not to be in our libs”. But when you have statistics, you could see, people still using it.
If you have contributed library, which is open for community and people can submit their components with statistics you can notice that some component is used more often than others. Next, librarian could take this component and verify that this component meets standards. If it doesn’t but component is widely popular, the librarian can fix the component and add that component to common repository.
Also, you should never remove components from the library. You can always have an “obsolete” category. I have some devices which is 20-30 years old. There are also enthusiasts who restores old devices. It costs nothing to keep it.