kicad-developers team mailing list archive

[Johannes Sprigode <jos@xxxxxxxxxxx>]

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 <devel@xxxxxxxxx
> <mailto:devel@xxxxxxxxx>> wrote:
>
>
>     > On Sep 16, 2019, at 6:12 AM, Clemens Koller <cko@xxxxxxxxx
>     <mailto:cko@xxxxxxxxx>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: OpenPGP digital signature