It is obvious that there can be only one physical pin as SCH_PIN which in turn however can be referenced in a multitude of functionalities. A very simple solution below.
There is a class SCH_PIN ... and there is /// A container for several SCH_PIN items typedef std::vector<SCH_PIN> SCH_PINS; As the comment for above typedef already suggests SCH_PINS should be a public property of SCH_PIN as a container/(collection) class rather than just a typedef. SCH_PINS then contains, among other properties as required, SCH_PIN as a property. With that, just about any level of device functionality can be defined. If SCH_PINS is nil then the one and only SCH_PIN is seen by the system. With SCH_PINS (as a selectable property) <> nil that selected PIN is seen. A basic real world example SCH_PIN 3 can be (in any desired order, whatever the preferred prime pin should be) PE0 PTCXY ACO CP4 SDA1 SCH_PINS = nil --> SCH_PIN = PE0 SCH_PINS = ACO --> SCH_PIN = ACO etc ad infinitum With this kind of object structure it is easily possible to go 'down' many levels, however, the system always sees just one SCH_PIN relevant for all the follow through connections, tests etc. Cheers On 17/09/19 10:03 PM, Ian McInerney wrote: > Unfortunately, no I don't agree that the grouping should be by > peripheral. The purpose of a schematic is to capture the electrical > connections of a circuit, and allow the designer to reason about it. > On most chips, the electrical specifications of the same peripheral > type can differ between instances (e.g. I2C0 has different specs than > I2C1 because they use different pins). > > The most useful grouping for capturing these differences are the ports > (since those map to the raw pins). The electrical characteristics are > usually defined on a per-port basis (so all pins of a port will > usually share the same Vcc, contribute to a per-port current > limitation, have the same voltage tolerance, etc). If you abstract the > IC into the peripheral functions, it becomes a lot harder to analyze > the electrical characteristics when doing a proper design. For > instance, say you want to use the STM32F413ZH. This chip has multiple > SPI ports, but one of them (SPI1) has pins that are not 5v tolerant, > and are only 3.3v tolerant. It becomes easier to analyze and work with > when you group by port/pins because the datasheet doesn't tell you > that SPI1 as a whole is not 5v tolerant only that pins PA4/PA5 (which > it uses) are not 5v tolerant. This limitation is also present for all > other peripherals that share those pins. > > This same reasoning also applies to FPGAs, and I think it is better to > keep the same reasoning across device types so people don't have to > learn multiple ways of using the symbols and analyzing the design. > > > As for the generation of pin constraints to map into the embedded > software, I have been thinking of ways to do that but I haven't had > time to write up a full RFC for it. I am approaching it from an FPGA > viewpoint first though, since those pin constraint maps can be very > tedious to write and it would be nice to ensure there is consistency > between the schematic and the options (such as pull-up/down status, > CMOS voltage level, etc). Initially I am thinking of just introducing > text fields the user fills in, but I am also going to investigate if > we can define a new properties field type for selecting values from a > discrete set. Then the symbol can define the valid field values and > the user can choose from them. This will be a long time in > development, since it will rely on the new file format and also > Eeschema Python bindings for generating the constraint files. > > -Ian > > On Mon, Sep 16, 2019 at 7:51 PM Andy Peters <[email protected] > <mailto:[email protected]>> wrote: > > > > On Sep 16, 2019, at 6:12 AM, Clemens Koller <[email protected] > <mailto:[email protected]>> wrote: > > > > Hello, Tim! > > > > I agree that in the near future, the demand for (I'd call it) > "Table Based Design Entry" will rise tremendously, > > when we reach pincounts in the high hundreds and thousands. > > > > It is a lot of work to draw and maintain complex MCUs/SoCs/FPGAs > in some schematic when pins can have 8 different functions which > might change during product development. A current example: i.MX8 > [1] with i.e. 625 pins. > > So, it might not even be sufficient to be able to import (and > export) .CSVs. It might be a good idea to prepare for some > automatism to be able to update and version control pin > multiplexing changes! > > > How about this? > > We can all agree that grouping MCU pins by peripheral makes the > most sense. So rather than having a big box symbol (or symbols) > with pins in a default order, why not have each part of a > component be a peripheral? Instead of having a multisymbol part > with one or two or three boxes for my EFM32GG11B820F2408GL192 in > the library, instead of EFM32GG11B820F2048GL192 as the part name > and within the part have all of the valid peripherals for that > device? > > Here’s the cool thing. This device has, say, I2C0, I2C1, I2C2, > UART0, UART1, USART0, USART1, TIMER0, TIMER1, all of it, and there > are a fixed number of peripherals for a given device. Each > peripheral is a symbol (a sub-part of the device) you can place on > your schematic. Need a UART? Place the EFM32GG11_UART0 symbol on > the schematic. Since this particular chip family gives you several > choices for each pin, the symbols are “Smart” and have a drop-down > menu you use to assign the pin. Those assignments also > automatically set pin direction and the other ERC stuff. For > peripherals which have one location for their pins obviously this > drop-down doesn’t exist. > > Cool, right? It can be better. Any pin not explicitly designated > for a peripheral that can be used as GPIO gets enabled in the GPIO > symbol. In that symbol then you set the direction, etc after you > place it on the schematic. > > Since all of the ARM vendors these days have some kind of software > tool that handles peripheral setup including pin assignments, > having the ability to read that output (whatever it is) and then > parse it and set up the individual blocks would be very cool. > > Right now I just rely on sensible net names to keep my MCU pinouts > straight. I used to make a custom symbol for each MCU in a design > but that got to be too much. > > FPGAs are a different can of worms. > > -a > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
