kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

I think it would be nice if the symbols were actyally dynamic, in the sense
the the pin funtion is selectable interactively in eeschema, instead of
syncing it with an extetnal db. The external db if implemented coukd ocf
still be used to generate this dynamic symbol, in theory.

Den 14/02/2017 11.41 skrev "Clemens Koller" <cko@xxxxxxxxx>:

> Hello, Stromtium!
>
> Thank you for your heads-up!
> I fully agree here and can't resist to "think big" and motivate when we
> are planning to support some future design entry methodologies in the long
> term.
>
> Today, we already have:
>   400++ configurable Pins of a FPGA
> + 300++ muxable Pins of a CPU
> + 300+ Pins I/O Connector
> + RAM
> + lots of other stuff
> ----------
> = Ridiculous to draw and manage single pins in schematic symbols spread
> over 30 pages.
>
> Solution:
> - Table based entry with import/export functionality. I mean SQL here and
> _not_ (only) spreadsheets. There will be demand for a *Synchronize*-button
> at some point in time.
>
> - "Schematic symbols" are generated dynamically. (Similar to these Pin Mux
> Tools which are generating C-code for CPU initialization / device trees).
> These symbols might look completely different than rectangular boxes with
> feathers on the sides, placed on a page.
>
> - Grouping +folding/unfolding and zooming/scaling of symbols could come in
> handy.
>
> The I/Os and their properties of a component might get grouped by i.e.
> POWER, USB, ETH, DDR2, SPI, ...
> Then they can be dynamically arranged / ordered by group,pinno or
> group,pinname, ...
> Putting this table/view in a frame to place it on a schematic sheet is
> then a nice goodie, but not even necessary.
> Search & replace capability and the import/export functionality is a must.
>
> This might affect the file formats of library components as well as the
> schematics.
>
> Regards,
>
> Clemens
>
> On 2017-02-14 10:54, Strontium wrote:
> > Can I make the suggestion, for CPU/MCU/FPGA type parts that have lots of
> configurable pins, drawing an actual component is tedious and somewhat
> pointless as its just a box (or multiple boxes, one for each subunit) with
> pins.
> >
> > Some CPU's have so many functional units and pins that fitting it all on
> one giant box is also pointless as it may not even fit on a a3 page, so you
> end up with multiple parts in a component for various functional divisions
> and then multiple versions of the same component to account for different
> GPIO multiplexing arrangements, which change and evolve as the design
> evolves.  It quickly becomes a maintenance problem.
> >
> > For example, you decide GPIO 7 is good for a LED, but later, oh no GPIO
> 7 is the last SPI chip select, oh ok, swap it with GPIO 184, but no, its
> not that easy now you have to edit the component to reflect it, and now
> every design you have that uses the same CPU ends up with a unique version
> of the component to match its GPIO muxing.
> >
> > I believe it would be far preferable for these types of components
> simply to define the functions of each pin in a table, and then when
> placing the part, its just an empty box (like a nested sheet).  You then
> right click on the part select "Add pin" and then select from the list of
> unplaced pins the one you want, and its function.  You then drop the pin on
> one of the 4 sides of the box.
> >
> > Basically like the nested sheet/sheet pin in concept, except you can
> select which pin to import from the list of pins not yet utilised.
> >
> > This way one only need to define a single component, and editing it is
> just a matter of editing a table of pins, which is very easy compared to
> drawing a component with 100's of pins.  You then "draw" the part uniquely
> for your design on your schematic, as you use each pin, but you only ever
> have one part defined in your library.
> >
> > Schematic DRC would then have an Error/Warning for pins not used.  This
> would make it much easier with complex parts, for example, you have a USB
> page, you only need the pins from the cpu chip for USB sub unit, and if you
> decide to change the OTG ID pin to a different GPIO, you don't need to
> redraw your part, or have multiple "versions" of your part, you just delete
> the old ID GPIO pin, and add the new one.
> >
> > This would be in addition to the current graphical parts, which are
> preferable for basic components and standard building blocks.
> >
> > Steven
> >
> > On 13/02/17 18:32, Oliver Walters wrote:
> >> Here is a good example of where such a feature would be very well
> received: https://forum.kicad.info/t/component-occupies-entire-
> page-newbie/5272/22
> >>
> >> On Thu, Jan 5, 2017 at 12:10 AM, Chris Pavlina <pavlina.chris@xxxxxxxxx
> <mailto:pavlina.chris@xxxxxxxxx>> wrote:
> >>
> >>     I second this suggestion. Numerous people have been proposing this
> for
> >>     quite a long time in IRC, it's a popular idea. A large number of
> parts
> >>     are configurable, and forcing the pins to be non-configurable makes
> ERC
> >>     pretty weak.
> >>
> >>     On Wed, Jan 04, 2017 at 07:22:37PM +1100, Oliver Walters wrote:
> >>     > As far as I am aware, this (
> >>     > https://lists.launchpad.net/kicad-developers/msg23302.html <
> https://lists.launchpad.net/kicad-developers/msg23302.html>) is the latest
> >>     > proposal for the new symbol format.
> >>     >
> >>     > Is this the case?
> >>     >
> >>     > Reading through this I have an idea that I think will be very
> useful.
> >>     >
> >>     > Currently each PIN can only have one TYPE (INPUT, OUTPUT,
> OPEN-COLLECTOR,
> >>     > etc) which means that for parts with multiple alternate-functions
> on a pin,
> >>     > ERC is essentially useless if the pin can be used as an INPUT or
> an OUTPUT
> >>     > (or something else).
> >>     >
> >>     > Further, labelling all the possible alternate functions on a pin
> means that
> >>     > either the symbol grows exceedingly wide, or many functions are
> missed.
> >>     >
> >>     > I suggest that the pin type should have facility for alternate
> functions to
> >>     > be specified which would solve both of these problems. Once a
> symbol is
> >>     > placed in the schematic, any multi-function pins are set to
> "default"
> >>     > values (e.g. GPIO for a micro) but the other functions can be
> selected.
> >>     >
> >>     > See proposed "addition" to format here:
> >>     >
> >>     > http://i.imgur.com/5m38eTT.png
> >>     >
> >>     > Cheers,
> >>     > Oliver
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> >
> >
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> 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
>