Some thoughts on the underlying data model (symbols)

I think that proposal is really aimed at making the “use generic symbols for everything” workflow easier. This is because apparently exchanging a symbol is way harder than exchanging the pin mapping. (I guess if there would be an easy to use option to exchange the symbol used then such suggestions would not be made.)

Also notice that wayne basically said: “Nothing new in this suggestion” as the inheritance feature already takes care of this stuff.

I have been trying to follow the developer mailing list discussions but it’s difficult to see what all these features mean in practice. The developers probably have idea, implementation, use cases and even UI in mind. All I have is an abstact idea which people talk about. The discussion may have gone forward for years in several mailing list threads. Searching through the mailing list archives is nigh impossible, even when you know what you are searching for.

It would be much easier to accept what Wayne or you say if we had a concrete example - an end user need, a workflow and a step by step explanation how it works with a UI. For example, do we get rid of all those GSD - DSG - GDS etc. transistors and how that “inheritance” actually takes care of the one functional pin -> several physical pins problem.

And Wayne mentioned only pin mapping, not inheritance. I don’t see how that would solve the problem. EL84’s proposal and pin remapping (swapping pins on the fly) are two different answers to two different problems.

The big mistake @EL84 made was selling his suggestion as talking about the data model. Do a programmer this means the backed representation of data or the file format.

I am not sure if this really was the intention. Some (you included) suggested above that they really talk about how the user could interact with the underlying data model. But if that is the case then this was not communicated explicitly. (And programmers like all people are not yet able to read the mind of others. So they can only work with the information that is there in an explicit way.)

Where is the difference between right click->exchange symbol and select lets say pmos_GSD or right click exchange mapping and select pmos_GSD? (the right click-> exchange symbol interface will come with v6. This is because v6 will also need right click -> update symbol from lib and that one is just a specialization of the former.)
It is the same user interaction, both options need the mapping in the lib somehow (one as part of a symbol that just so happens to inherit the graphical representation of some central entity the other by using a separate file to represent only the mapping)

And the inheritance stuff can even be used to give the user a exchange mapping feature by simply filtering the options of the exchange symbol feature to list only parts that inherit the graphics from the same element.

There is however a catch. Wayne mentioned sometime in the past that inheritance might not get fully implemented in v6. So it might be that the full feature set will only come in v7. (But that does not change with any other suggestion as i would guess that the priority list will stay “get feature parity but with new file format” for v6.)

Everywhere I see a list of symbols - the symbol editor, add symbol dialog etc. - there are several pin number variants cluttering the list. I would rather have one generic symbol and choose the pin mapping separately, rather than having several “generic” symbols which actually aren’t generic because they leak implementation detail (symbol<->footprint pin mapping) into the user interface, and espcially into the symbol name itself.

I think it has been already said that those symbols which are meant to be generic actually aren’t generic because you’re required to know the footprint pin numbering when you select the symbol, or have a symbol name which conveys wrong information.

And some symbol groups don’t even have all possible pin order combinations.

1 Like

May be we need two views:

  1. Generic symbols View: All symbol with original pins (Not pin map data show)
  2. Atomic View: All symbol + pin map data applied

Default view may be Atomic for normal users that need quickly design a board.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.