|
|
|
|
|
|
by LM358
817 days ago
|
|
|
>wouldn't the code and its comments become documentation that would otherwise be in the well-drawn schematic? Technically, yes, but 99% of EEs would not approve of code in some weird new DSL as documentation for a circuit.
While it may contain the same information as a drawn schematic, it is much more inscrutable and introduces mental overhead when you actually need to read it. There's also a huge difference between a poorly laid out schematic and an excellent one; the latter makes it easier to follow the flow of signals and power through relevant parts of the circuit and allows you to easily pick out the different parts/modules and how they play their part in the circuit as a whole, all with a quick glance at a drawing. I guess a (poor) software analogy would be that you could surely implement a function as a bunch of GOTOs and/or BRANCH commands, but just making a nested for loop would make the logic much clearer. |
|
|
The major issue is that there are a lot more stake-holders in a schematic design than just the person who draws it.
Often the person who draws the schematic is not the person who lays out the PCB, so the schematic needs to encode information about how to lay the PCB out. For example, you may have several components in parallel in a filter circuit; the order that they are placed on the schematic can be used to communicate which order they should be placed on the board (but does not affect the electrical correctness of the schematic at all), and this in turn helps to betray the function of these components.
Even if the whole PCB design is being done by one engineer, other engineers need to be able to review it. If a schematic is electrically correct but otherwise a mess, it makes reviewing it a lot more difficult.
Then there will be third-parties who need to read the schematic and understand the design - for hobbyist products this could be the end-users, and in consumer products it might be service engineers. A well drawn schematic makes a PCB easier to understand and therefore easier to debug, repair, and modify.
In the analogy of software vs schematics, schematics are both code and documentation at the same time.