Hi,
On 09.02.2016 14:48, Wayne Stambaugh wrote:
Now that we've discussed this, we need to put together a task list that
can be added to the road map so they don't get lost in the noise. I
propose adding an ERC improvement section to the Eeschema section of the
version 5 road map. As of right now, I have one definable task and that
is to test for different label names on the same net and warn the user
when that occurs. Are there any other tasks that need to be added to
this list from this discussion?
I have a few more ERC enhancements on my list, not sure whether they
should go on the roadmap:
1. Add device configurations
The component can specify configuration options that can be set in the
properties of the component after it has been placed. Configuration
affects pin types and pin names. Useful for selectable peripherals.
2. Add narrowable pin types
The component can specify a set of valid pin types. Similar to
configuration, but a bit of a special case since it is less abstract.
Useful for connectors (that can have power_out pins then) and digital
I/O pins (that we might want to narrow down to "input" or "output" when
placing the component.
3. Add reference voltages
For digital pins (input, output, bidi), allow the component to declare
that these are referenced relative to other pins (e.g. Vcc_io and GND).
Components connected to each other must use the same references on their
pins. Useful for checking that 3.3V components aren't accidentally
connected to 5V components.
For power_in and power_out pins, a voltage relative to another pin can
be given. Useful for making sure that 5V supply pins are actually
connected to a 5V supply.
One special case of this would be a "connected-to" constraint that would
require two pins to be always connected (e.g. for two power_in pins of
the same voltage).
This could also be extended to describe differential pairs in the schematic.
4. Add "pull_up", "pull_down" and "pull_updown" pin types
These should be connected to a power rail (ideally, one that is listed
as a reference) through a connector. Useful for configuration pins,
especially together with device configurations.
5. Allow multiple pin definitions in a single device
Where device configurations create alternative mappings, it may also be
useful to have two definitions for the same pin that should be connected
in parallel. Useful for bootstrap configuration, where the pin would
have both a "pull_up" definition, and a "bidi" definition, and both the
resistor and the data bus should be connected.
6. Add generated symbols for ICs
Because the pin list becomes fairly dynamic with all these changes, and
drawing rectangles around pins becomes tedious, it should be possible to
generate the symbol automatically from the current pin configuration.
This could also be useful for symbols representing sub-sheets.
7. Add tabular pin connections
As an alternative to hidden power pins, create a table that can be
placed like a normal component listing connections between power pins
and nets. This is saner than having hidden connections, and does not
clutter up the schematic with a special unit that just defines the power
pins and requires wires to be drawn to power symbols.
8. Add pin and unit swap hints
These would be taken over into the netlist, so pcbnew can display
options to swap units and pins during routing.
Simon
_______________________________________________
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
