kicad-developers team mailing list archive

[Manveru <manveru@...>]

2009/10/8 Brian Sidebotham <brian.sidebotham@...>
>
>
[...]
>
> I am pretty much against pins being anything other than integers. It's
> probably just a personal thing, but all packages I come across simply
> use integers so they would directly relate to the kicad module. The
> SOT-23 package has a fixed pin numbering scheme, that is the only PCB
> module you should have to create. Anyone creating a new part will not
> have to create another version of the SOT-23 which would need to be
> audited to make sure it is all the same as the other ones. Then of
> course, a user might need to adjust their SOT-23 because it's not
> quite right for their process and they have to go through and edit 10
> or more of them instead of just one.
>
> I know the problems with different pinouts and the same symbol. SOT-23
> transistors, diodes and FETs are a good example. The amount of SOT-23
> packages you would have to create would be unreasonable and end up
> unmaintainable, and for-ever growing.

I think you do not understand me correctly - I am thinking about
single module with the new feature of cvpcb allowing tie unique name
with module pin number. I hope I am describing it clearly.

> I am a fan of a heavy symbol system, although sometimes when things
> are in a hurry I have the odd moment of liking a light symbol system.
>
> I am not really strongly opinionated about it, but I think the heavy
> system has benefits for many users who have posted up questions on the
> kicad-users group. They expect to select a component and it already
> have its correct package assigned. CVPCB is nice, but I think in
> reality it shouldn't be needed. I think most people who use the
> standard libraries just want a plug-and-play schematic + pcb entry
> tool. I have never used a symbol or module from the standard library
> because I know what we want and need. KiCAD provides pretty easy to
> use tools to generate them so it didn't take too long to create a new
> set of libraries for our company.

I am not observing users list now. I would like to have profit from
simple symbol system with limited number of modules and some mapping
system in between. I was even thinking about an additional
functionality, which would allow KiCad to keep schematic symbol decals
in separate files (common for large amount of parts) and build an
library as the database of part numbers together with mapping between
the decal and the module. This may certainly need lot of rework in
KiCad, but for a lot of logic elements, amplifiers, some bus
converters KiCad would have common set of symbols kept under one
design standard. This may make a web system for sharing libraries on
the net much simpler.

> The problem in schematic entry as I see it is that you are limited to
> picking an object that has all of the graphics primitives in it along
> with the pinning information. I think you would really require a set
> of graphical representations (Say a 2-input AND gate, NPN transistor,
> PNP transistor, etc) which could have pin locators on it (I also do a
> lot of my pins as zero length. I don't see that they really need any
> length other than to draw them a different colour and I always end up
> in black and white anyway).
>
> Then an electrical symbol can be based on a graphical representation,
> a module definition and all the other user fields that we have now and
> the pin numbering information.
>
> So that would give you:
>
> * Common Graphics Symbols
> * Schematic Symbols
> * PCB Modules

This is what I am thinking about.

> Changing a common graphics symbol means that someone could change how
> all transistors look, or how all diodes look, etc. But this might be
> abstracted too far and be a dream.

The perfection is a target to which we all should head for.

> Don't forget too, that as some processors have different amounts of IO
> pins available depending on the package type, you will inevitably have
> to do some distinction at the schematic level for some parts depending
> on their package anyway.

This is a problem for which I do not find a good solution for now. I
have some ideas, but there is a problem with usability.

> Apologies for the long email and good luck with everything.

:-)
--
Manveru
jabber: manveru@...
    gg: 1624001
  http://www.manveru.pl