Pinswap erzwingen

Oliver Betz schrieb:

> Pinswap und Gateswap erzwingen

__FULL__ ACK. Oder alle Bibs ( besonders Stecker, TTL-ICs, Processoren,

Speicher,... ) überarbeiten ;).

Gruss R. Scherer

Scherer Ralf schrieb:

Pinswap und Gateswap erzwingen

 

__FULL__ ACK. Oder alle Bibs ( besonders Stecker, TTL-ICs, Processoren,

Speicher,... ) überarbeiten .

in welcher Art? Ich will ja normalerweise die Sicherheit gegen

versehentliche falsche Vertauschung.

Servus

Oliver

--

Oliver Betz, Muenchen (oliverbetz.de)

Oliver Betz schrieb:

Scherer Ralf schrieb:

Pinswap und Gateswap erzwingen

__FULL__ ACK. Oder alle Bibs ( besonders Stecker, TTL-ICs, Processoren,

Speicher,... ) überarbeiten .

 

in welcher Art? Ich will ja normalerweise die Sicherheit gegen

versehentliche falsche Vertauschung.

1. Die Sicherheit ist dadurch gegeben, dass ein Swap nicht durch einen

     Klick erledigt ist.

2. Wer konsequent ERC und DRC benutzt ist klar im Vorteil.

Logisch, das man z.B. bei TTL-Gattern die Eingänge auf einen anderen

Swaplevel legt als die Ausgänge.

Logisch, dass man z.B. beim uP die XTAL-Pins auf einen an deren

Swaplevel als die PortPins. Aber ansonsten hätte ich keine Hemmungen

alle IO-Ports eines uP auf Swaplevel 1 zu legen.

Bei Steckern kann ein Swaplevel 0 nicht verhindern, dass der

Gegenstecker falsch angeschlossen ist.

Gruss Ralf

Scherer Ralf schrieb:

Pinswap und Gateswap erzwingen

__FULL__ ACK. Oder alle Bibs ( besonders Stecker, TTL-ICs, Processoren,

Speicher,... ) überarbeiten .

 

in welcher Art? Ich will ja normalerweise die Sicherheit gegen

versehentliche falsche Vertauschung.

 

1. Die Sicherheit ist dadurch gegeben, dass ein Swap nicht durch einen

    Klick erledigt ist.

Dann könnten wir das mit dem Swaplevel ja ganz weglassen.

2. Wer konsequent ERC und DRC benutzt ist klar im Vorteil.

Die prüfen das nicht.

Logisch, das man z.B. bei TTL-Gattern die Eingänge auf einen anderen

Swaplevel legt als die Ausgänge.

Logisch, dass man z.B. beim uP die XTAL-Pins auf einen an deren

Swaplevel als die PortPins. Aber ansonsten hätte ich keine Hemmungen

alle IO-Ports eines uP auf Swaplevel 1 zu legen.

Und wenn ich ein Signal zwischen zwei Ports tauschen will?

Also, ich finde das mit dem Swaplevel schon nicht schlecht, aber man

sollte eben die Möglichkeit haben, auf Wunsch die Vorgabe zu

ignorieren.

Servus

Oliver

Am 24.03.2010 08:03, schrieb Oliver Betz:

Scherer Ralf schrieb:

 

Pinswap und Gateswap erzwingen

 

__FULL__ ACK. Oder alle Bibs ( besonders Stecker, TTL-ICs, Processoren,

Speicher,... ) überarbeiten .

 

in welcher Art? Ich will ja normalerweise die Sicherheit gegen

versehentliche falsche Vertauschung.

Kein Automatismus kann eigenes Nachdenken wirklich ersetzen.  Aber er

kann nützlich und bequem sein.

Hier finde ich die Konstruktion mit dem Swaplevel durchaus sinnvoll

gegen Flüchtigkeitsfehler,  wenn er in den LBRs überall richtig drin

ist.  Eine sehr weitgehende Freigabe in den LBRs finde ich heikel;

abgesehen davon verwende ich eh nur eigene LBRs mit eigenen Fehlern.

Für PINSWAP fände ich die vorgeschlagene Ergänzung sehr nützlich,  zB

zum Berichtigen eigener Eingabefehler oder bei unperfekten LBRs:

  - bei gleichem Swaplevel sofort tauschen,  wie bisher.

  - bei verschiedenem (auch 0) Rückfrage ähnlich VALUE, aber mit Infos

wie:

      Pin OE / Pad 1 an Netz A0 hat Swaplevel 0,

      Pin D0 / Pad 2 an Netz AEN hat Swaplevel 1.

      Wirklich tauschen ?  J/N

Man könnte sich das sogar für Pins verschiedener Devices vorstellen.

Bei GATESWAP wird das schwieriger.  Vielleicht wie oben mit der dritten

Möglichkeit "Gates haben unterschiedliche Anzahl Pins -- Tausch nicht

möglich".

Grüße,  Hans

Oliver Betz schrieb:

Scherer Ralf schrieb:

 

Pinswap und Gateswap erzwingen

__FULL__ ACK. Oder alle Bibs ( besonders Stecker, TTL-ICs, Processoren,

Speicher,... ) überarbeiten .

Man beachte den Smilie. Niemand will das wirklich.

in welcher Art? Ich will ja normalerweise die Sicherheit gegen

versehentliche falsche Vertauschung.

1. Die Sicherheit ist dadurch gegeben, dass ein Swap nicht durch einen

    Klick erledigt ist.

 

Dann könnten wir das mit dem Swaplevel ja ganz weglassen.

Na ja, ganz sooo rigoros würde ich das nicht sehen. Der SL macht bei

Pins unteschiedlicher Funktion schon Sinn, wobei, s.u.

2. Wer konsequent ERC und DRC benutzt ist klar im Vorteil.

Die prüfen das nicht.

ERC prüft aber z.B. ob 2 Outputpins verbunden sind.

Logisch, das man z.B. bei TTL-Gattern die Eingänge auf einen anderen

Swaplevel legt als die Ausgänge.

Logisch, dass man z.B. beim uP die XTAL-Pins auf einen an deren

Swaplevel als die PortPins. Aber ansonsten hätte ich keine Hemmungen

alle IO-Ports eines uP auf Swaplevel 1 zu legen.

Und wenn ich ein Signal zwischen zwei Ports tauschen will?

Darum haben meine uP Ports einen Swaplevel.

Also, ich finde das mit dem Swaplevel schon nicht schlecht, aber man

sollte eben die Möglichkeit haben, auf Wunsch die Vorgabe zu

ignorieren.

Genau.

Tschüss

Ralf

Scherer Ralf schrieb:

Logisch, dass man z.B. beim uP die XTAL-Pins auf einen an deren

Swaplevel als die PortPins. Aber ansonsten hätte ich keine Hemmungen

alle IO-Ports eines uP auf Swaplevel 1 zu legen.

Und wenn ich ein Signal zwischen zwei Ports tauschen will?

 

Darum haben meine uP Ports einen Swaplevel.

Das birgt aber erhebliche Risiken bezüglich der Zweitfunktionen von

Ports, die einklich grundsätzlich hardcoded und sehr restriktiv vergeben

sind...

Also, ich finde das mit dem Swaplevel schon nicht schlecht, aber man

sollte eben die Möglichkeit haben, auf Wunsch die Vorgabe zu

ignorieren.

 

Genau.

Ack.

Und endlich Gateswap direkt im Board machen dürfen.

Tilmann

Tilmann Reh schrieb:

Scherer Ralf schrieb:

 

Logisch, dass man z.B. beim uP die XTAL-Pins auf einen an deren

Swaplevel als die PortPins. Aber ansonsten hätte ich keine Hemmungen

alle IO-Ports eines uP auf Swaplevel 1 zu legen.

Und wenn ich ein Signal zwischen zwei Ports tauschen will?

Darum haben meine uP Ports einen Swaplevel.

 

Das birgt aber erhebliche Risiken bezüglich der Zweitfunktionen von

Ports, die einklich grundsätzlich hardcoded und sehr restriktiv vergeben

sind...

Du hast natürlich recht. Leider kann ich die Pins am uP nicht schön im

Uhrzeigersinn der Reihe nach anschliessen und dann erwarten das das

funktioniert. Ich liebe Symmetrie.

Vor und nach einem Swap muss ich mir "leider" den Schaltplan ansehen und

darüber nachdenken was ich da mache. Sonst könnte das ja jeder.

Aber Bibliotheks- und Symbolgestaltung ist z.T. auch Geschmackssache,

wie so vieles.

Z.B.:

Man kann einen uP als einen "Bollen" gestalten hat Vorteile.

Man kann einen uP in "Funktionsgruppen" aufteilen könnte auch Vorteile

haben.

Wie man es macht... es ist immer falsch ;).

Ralf

Hello Oliver Betz !:

gelegentlich möchte ich Signale an Pins tauschen, deren Swaplevel

nicht gleich ist. Zum Beispiel, weil ich bemerke, etwas falsch

angeschlossen zu haben, aber es gibt mehrere andere Gründe.

 

Eagle macht mir das unnötig schwer: Oft muß ich einen Knickpunkt ins

Signal einfügen, das Stückchen am Pin löschen, neu verdrahten.

 

Deshalb schlage ich (ungefähr seit es Eagle 3.5 gibt) vor, Pinswap

nach einer Sicherheitsabfrage für beliebige Pins zu ermöglichen.

 

Nachdem es ohnehn schon einen Fehlerdialog gibt, könnte man doch einen

"ich will aber" Knopf hinzufügen.

Full ACK meinerseits !!

Gruss

--

Grzegorz Zalot

complex ltd.

office tel/fax : +48 32 2505840

mobil : +48 501 301515

http://www.complex.org.pl/

Scherer Ralf schrieb:

Pinswap und Gateswap erzwingen

__FULL__ ACK. Oder alle Bibs ( besonders Stecker, TTL-ICs, Processoren,

Speicher,... ) überarbeiten .

 

Man beachte den Smilie. Niemand will das wirklich.

ah so, sorry, stand auf der Leitung.

Servus

Oliver

--

Oliver Betz, Muenchen (oliverbetz.de)