Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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,

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

> 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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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:

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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,

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

> 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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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,

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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,

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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,

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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.

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

“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

[Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

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