Hi all,
As some of you know, I've been working on some new features for Eeschema
that expand the capabilities of buses.
These features are not yet complete, but I wanted to share my progress to
get early feedback.
Since there are a number of things, I have made a ~4 minute demo video, in
which I
“Bus Group” sounds like a group of busses, rather than a bus composed of
groups. People doing a layout might also be thinking in graphical terms when
they see “Vector” (ie: the direction the bus goes in or something), rather than
in mathematical notation terms.
Can we just call everything a Bu
Hello, Jon!
Thank you for your work! I just watched your video and want to give you some
feedback:
I would prefer not to use the term "Bus Vector". A bus is simply a list (or a
collection) of arbitrarily named nets. A bus group would be - in my
understanding - a group of (different) busses.
I
Maybe we could adapt from c++ here? having the notation instead
of {ALIAS}, the same way c++ uses templates.
one could do MEMORY{ D[15..0]}. And get MEMORY.OE MEMORY.WE and
MEMORY D15 etc. Just to be more clear that it is an alias and not a
net-name.
- Kristoffer
On 2017-12-14 12:43, Clem
Hi Clemens,
On 12/14/2017 12:43 PM, Clemens Koller wrote:
> Hello, Jon!
>
> Thank you for your work! I just watched your video and want to give you some
> feedback:
>
> I would prefer not to use the term "Bus Vector". A bus is simply a list (or a
> collection) of arbitrarily named nets. A bus
Hello, Orson!
On 2017-12-14 13:12, Maciej Suminski wrote:
>> But when you add aliases I run into troubles to keep things separate/clear:
>> {RAM} appears to me as an unnamed bus containing the net RAM. WTF is that?
>
> I accept you might not like it, but this comment is not really respectful.
I
First of all: awesome Jon! A really nice feature and video!
My 0.2 cents here...
On Thu, Dec 14, 2017 at 12:43:45PM +0100, Clemens Koller wrote:
> Hello, Jon!
>
> Thank you for your work! I just watched your video and want to give you
> some feedback:
>
> I would prefer not to use the t
Hello all,
Please do not put much focus on the names that I used to refer to the
concepts (vector vs group). I needed a clear way to separate these concepts
to write the code, and those names are the "working titles". They do not
need to be the final names, and probably don't even need to be visi
Hi Marco,
The idea of aliases is to be "templates" for buses when you also give names
to a bus. This is a little different than you describe, and I think is a
powerful feature.
If you define an alias called MEMORY, you can then define *multiple
different* memory buses, so they have to have differ
If I recall correctly, you are allowed to name an alias using
format, so there is nothing preventing you from doing so. I would rather
not impose such constraint on aliases, but I am interested in other
opinions.
Regards,
Orson
On 12/14/2017 01:09 PM, kristoffer Ödmark wrote:
> Maybe we could ad
Hello!
On 2017-12-14 14:08, Marco Ciampa wrote:
>> But when you add aliases I run into troubles to keep things separate/clear:
>> {RAM} appears to me as an unnamed bus containing the net RAM. WTF is that?
>> MEMORY{RAM} appears as a bus named MEMORY containing the single net RAM.
>> I would expect
On Fri, Dec 15, 2017 at 10:54:01AM +0100, Clemens Koller wrote:
> I was also considering the ellipsis '...' but in classical ASCII, they
> are three characters wide, that's why I ended up with .., + or * to keep
> it short.
... and the problem with 3 chars is?
> But since we arrived in Unicode,
On 2017-12-15 11:01, Marco Ciampa wrote:
> On Fri, Dec 15, 2017 at 10:54:01AM +0100, Clemens Koller wrote:
>
>> I was also considering the ellipsis '...' but in classical ASCII, they
>> are three characters wide, that's why I ended up with .., + or * to keep
>> it short.
>
> ... and the problem w
On Fri, Dec 15, 2017 at 11:38:00AM +0100, Clemens Koller wrote:
> On 2017-12-15 11:01, Marco Ciampa wrote:
> > On Fri, Dec 15, 2017 at 10:54:01AM +0100, Clemens Koller wrote:
> >
> >> I was also considering the ellipsis '...' but in classical ASCII, they
> >> are three characters wide, that's why
Yeah, definitely stay away from anything non-ASCII in the syntax, but the
narrower ellipsis character should be fine for display….
> On 15 Dec 2017, at 10:54, Marco Ciampa wrote:
>
> On Fri, Dec 15, 2017 at 11:38:00AM +0100, Clemens Koller wrote:
>> On 2017-12-15 11:01, Marco Ciampa wrote:
>>>
Le 15/12/2017 à 12:28, Jeff Young a écrit :
> Yeah, definitely stay away from anything non-ASCII in the syntax, but the
> narrower ellipsis character should be fine for display….
... but not in plot files, as pdf files have a searchable text.
Because Kicad is a internationalized tool, we avoid an
Hmm okay, we seem to differ in opinions once again. But you are right,
nothing stops me from naming my aliases like that anyway.
I have checked schematics for students, and I know that I would be very
confused if the aliases they have used did not immediatly pop up for me
somehow. Be it synta
Jon,
I finally had time to watch your video. The new bus connection work
looks great! Hopefully I'll be able to find some time in the not too
distant future to take a look at the code. I'm really interested in the
new real time connection algorithm. Keep up the great work.
Cheers,
Wayne
On
On 2017-12-13 11:15 PM, Jon Evans wrote:
As some of you know, I've been working on some new features for Eeschema
that expand the capabilities of buses.
[snip]
https://youtu.be/z6x0xiKgDIc
Those are some interesting changes to working with buses.
There is one documentation type problem I see
Hi Kevin,
Are you thinking about when someone is editing the schematic later in
eeschema, or when someone exports to a PDF or prints it?
Both concerns have been raised and I think are valid.
I like the idea of some kind of mouseover info, or showing the contents in
the message panel (that one is a
> On Dec 13, 2017, at 9:15 PM, Jon Evans wrote:
>
> Hi all,
>
> As some of you know, I've been working on some new features for Eeschema that
> expand the capabilities of buses.
> These features are not yet complete, but I wanted to share my progress to get
> early feedback.
User perspective
Yes, buses can travel through hierarchy just like nets -- hierarchical
sheet pins and ports can carry buses or nets, no need for a new type of
label.
In my branch I am currently changing the color of hierarchical ports/pins
that connect buses (to the same color as bus wires)
-Jon
On Fri, Dec 15,
Le 15/12/2017 à 18:16, Andy Peters a écrit :
>
>> On Dec 13, 2017, at 9:15 PM, Jon Evans wrote:
>>
>> Hi all,
>>
>> As some of you know, I've been working on some new features for Eeschema
>> that expand the capabilities of buses.
>> These features are not yet complete, but I wanted to share my
Holy crap this is dope. I wanted to do something along similar lines a
long time ago, but I've never had nearly enough time for it. I would use
this stuff SO much.
I love that you demoed it on the project I REALLY wish it existed for :D
On Thu, Dec 14, 2017 at 04:15:34AM +, Jon Evans wrote:
>
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 wa
Personally I think this feature would be huge boost for readability.
Most people who will review a schematic knows what nets are on a USB
connection, or a SPI connection or similar. I see them as an
abbreviation, just the same as everyone knows what USB is, even though
it stands for Universal S
> On Dec 19, 2017, at 12:06 AM, Marco Ciampa wrote:
>
>
>> 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 u
Hi Marco,
Thanks a lot for your feedback.
I agree with you and others who have commented on the desire for there to
be some way to know what is going on if you make a PDF or printout from a
schematic using the alias feature.
I'll think about this, and if anyone else has ideas on this, please let
Another thing, maybe not force the usage of the dot ".", I would rather
like to force the dot myself, or be able to use "_" or whatever i fancy.
So instead putting CH0.{ADC}, or CH0_{ADC}.
- Kristoffer
On 2017-12-19 21:28, Jon Evans wrote:
Hi Marco,
Thanks a lot for your feedback.
I agree w
This would be problematic for users like me who use the underscore
character in names for readability.
On 12/19/2017 3:57 PM, kristoffer Ödmark wrote:
> Another thing, maybe not force the usage of the dot ".", I would rather
> like to force the dot myself, or be able to use "_" or whatever i fancy
Why would this be problematic for users like you to be able to chose
whichever character you fancy instead?
On 2017-12-19 22:03, Wayne Stambaugh wrote:
This would be problematic for users like me who use the underscore
character in names for readability.
On 12/19/2017 3:57 PM, kristoffer Ödma
On Dec 19, 2017, at 1:28 PM, Jon Evans wrote:
> 2) Design needs multiple copies of a similar bus with distinct net names
>
> Say you are designing a big data collection device. It has a large FPGA and
> 8 channels of ADC. Each ADC needs its own set of signals going straight back
> to the FPG
Using an underscore as a replacement for the period will add another
reserved character which will add complexity to the parser and/or
require quoting when saving to the file which makes the file format less
readable.
On 12/19/2017 4:52 PM, kristoffer Ödmark wrote:
> Why would this be problematic
Then dont use a underscore? If the dot is not inserted, nothing hinders
you from not putting a underscore there?
On 2017-12-20 13:32, Wayne Stambaugh wrote:
Using an underscore as a replacement for the period will add another
reserved character which will add complexity to the parser and/or
re
Hi Kristoffer,
No offence, but is there any added value in using a configurable
separator character or is it just your preference? It seems to me that
adding such feature will complicate the code a lot for a small benefit,
but I may not see the full picture. Perhaps it is just a convention that
we
I see no value in adding a forced separator, I am not talking about a
configurable, maybe this has been unclear. I am talking about no
separator. So that I can put a dot or whatever i feel like anyway.
On 2017-12-20 14:47, Maciej Sumiński wrote:
Hi Kristoffer,
No offence, but is there any ad
With out a separator, how does the connection algo know when a dot is
part of a name or the separator between the name and the sub-connection
or rre you suggesting that there be no separator so DATA[0..7] would
break out into DATA0, DATA1, ...? If so, I'm not sure this would be
feasible. @Jon, se
I will have to think about this some more and look through the code to be
sure of the impact (or lack of impact)
The connectivity algorithm generates the names (with the dots) but doesn't
necessarily need to parse the strings afterwards except for ERC checking.
The syntax of defining bus labels is
On 2017-12-20 16:58, Jon Evans wrote:
For user experience, it might be a bit annoying to have to remember to
insert a separator character if you want one to appear.
So I guess one question would be: do we want to support no separator
character at all? Or default to a dot if the user doesn't e
I will take a look to see if there would be any issues with this.
Keep in mind, your example isn't quite right -- DATA[0..7] would still
become DATA0, DATA1, etc with or without this change. The dots aren't
added to the vector-notation buses, only when you name a bus group by
putting a prefix behi
Dear all,
apologies for randomly jumping into this. When I switched from Altium Designer
to kicad for most of my simpler designs (sometime in about 2013), the thing I
missed most about Altium Designer's schematic editor was the "harness"
feature, which in Altium are distinct from buses and are i
41 matches
Mail list logo