Hi Jon,
first of all, thanks for listening my thoughts.
I waited to send this letter a few days to wait for things to clear up to me.
I think that this still apply although some things might be a little clearer
now, so, in a way it is a little obsolete. I am sending it the same because
I do not want to kill its spirit...
...but please continue to keep in mind that these are my 0.00000000000002
cents humble opinions...and really nothing more...
On Thu, Dec 14, 2017 at 08:21:29AM -0500, Jon Evans wrote:
Hi Marco,
The idea of aliases is to be "templates" for buses when you also give names
to a bus.
Ok clear.
Let's call them templates then because for me an alias is just an alias.
This is a little different than you describe, and I think is a
powerful feature.
I do not want to be unrespectful and ungrateful especially since I am not
a dev but... there are many powerful features that we (actually you devs)
can concoct but not all of them would probably turn out to be of such
usefulness even if very powerful and feasible.
I think that we should always keep in mind a need to be fulfilled and
some cases of use in witch such a feature turns out to be useful.
And even if it turns out to be of some usefulness, there is always a
trade-off between an increase in complexity of the design process
and benefits to the designer and in the complexity of the schematics.
If we are not able to find an example in witch this feature literally
kills a big deal of work, then I am afraid that we are introducing some
rarely used, obscure to grasp and difficult to document feature.
I mean that schematics are to be understood in printed form. The meaning
(of the syntax) of the drawings should as of immediate comprehension as
possible. Every template/macro/alias that we add to the schematics should
probably:
1) be documented in printed form (no, a pop-up window is not enough) on
the design sheets
2) must be easy to read (as in a paper print) even if you do not know
KiCad at all
because this feature, if I got it right, seems to me more a kind of
"programming" than "describing" a circuit design
If you define an alias called MEMORY, you can then define *multiple
different* memory buses, so they have to have different prefix names. But
you can also choose to use aliases *without* a prefix name, and then
everywhere you use that alias will be part of the same set of nets.
So, a more realistic and simple example would be:
Define alias "USB" containing "DP", "DM"
Ok
If I do not see this definition somewhere on the sheet, am I still able
to understand the schematics just looking at a print on paper of it?
If I need to see also the "alias" definition to understand the
schematics, where can I look at this template definition on the sheets?
Now in one sheet you have a USB hub. You can define four different buses
with names and the alias, and get nets like "PORT1.DP" and so on.
But on a simpler design, you might not need four ports, so you can just use
"{USB}" in your bus name and get nets without any prefix.
But it seems to me that this is the same name of a net on the bus with
name "USB"...
I think both options of how to use buses are valid and useful, and I also
understand your confusion when presented with all these options at once.
Would you be so kind to continue with this example and show how could be
represented, for instance, a 4 USB bus schematic? Or other examples that
could benefit from this feature?
I do not really "see" it if I haven't a real example to look at... it's
my lack of imagination, I know...
With that in mind, do you have any thoughts on how we could preserve the
power of this feature while making it easier to understand?
If we (you devs) find really worth, my suggestion is to:
1) clearly divide the template/class definition from the istances syntax
(but I do not know how though...).
The confusion to me arises from this "all in one" approach.
2) find a way to describe it "on paper" to make schematic sheets readable
to non KiCad users (normal elect. engineers)
My suggestion here is to keep it as simple, and clear, as possible.
Between powefulness and readability, if it is not really worth it, I
personally prefer the latter.
Best regards,
