www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Schnelles umschalten der Portrichtung möglich?


Autor: Lars Thalheim (laptop24)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich das Problem, dass ich an einem Pin eines ATmega128 sowohl Daten 
lesen, als auch schreiben muss.

Meine Frage ist also: Kann ich in schneller Folge den Pin in 
Leserichtung und dann in Schreibrichtung schalten, ohne dass der Chip 
Schaden nimmt? Bzw. gibt es evtl. eine Einschränkung der Marke "maximale 
Umschaltfrequenz ist 1/4 des Chiptaktes"... o.ä.?

MfG, L.

Autor: urfwanker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, da gibt's keine Begrenzungen. Es darf halt zu keinem 
Zugriffskonfikt auf Deinem Bus kommen.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja, selbst 1/4 Chiptakt macht selten einen Sinn. Du willst mit den 
Daten ja auch noch irgendwas machen. Aber eine Einschränkung gibt es 
nicht. Wer will, kann auch immer abwechseln DDR = 0x0 und DDR = 0xff 
schrebein. Das ist dann zwar halber Chiptakt, aber ansonsten zweckfrei.

Oliver

Autor: Lars Thalheim (laptop24)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Antworten.

Das hört sich erstmal gut an.

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wer will, kann auch immer abwechseln DDR = 0x0 und DDR = 0xff
> schrebein. Das ist dann zwar halber Chiptakt, aber ansonsten zweckfrei.

So sinnfrei ist das gar nicht. Unter der Voraussetzung PORT = 0x00, und 
daß an den Pins ein Bus in Wired-And-Schaltung hängt, sendet man damit 
die Bitfolge 0101010101... auf den Bus.

Autor: andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst z.B. auch einen Pullup-Widerstand verwenden und beide 
Sender/Empfänger die gemeinsame Leitung auf Masse schalten lassen. Dies 
wird z.B. bei der Diagnoseleitung in Fahrzeugen so gemacht. Ist halt 
fraglich welche maximalen Übertragungsraten man damit erreicht.

Autor: Lars Thalheim (laptop24)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eben das kann ich in diesem Fall nicht machen.

Es soll die Kommunikation zwischen zwei existierenden Systemen 
abgefangen werden. Der neue Chip soll quasi zwischen den beiden 
existierenden Kommunikationsteilnehmern sitzen und muss die original 
Kommunikation teilweise unverändert durchschleifen. Dabei habe ich 
keinen Einfluss mehr auf die eigentlichen Kommunikationsteilnehmer.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Lars Thalheim (laptop24)

>Es soll die Kommunikation zwischen zwei existierenden Systemen
>abgefangen werden.

Mitschreiben?

> Der neue Chip soll quasi zwischen den beiden
>existierenden Kommunikationsteilnehmern sitzen und muss die original
>Kommunikation teilweise unverändert durchschleifen.

Das kann ein AVR prinzipiell nicht vollständig verzögerungsfrei.

>Dabei habe ich
>keinen Einfluss mehr auf die eigentlichen Kommunikationsteilnehmer.

Sag doch mal genau, WELCHER Bus das sein soll und wie schnell er läuft.

MfG
Falk

Autor: Lars Thalheim (laptop24)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es handelt sich um eine Chipkarte mit Prozessor. Das Protokoll ist T=0 
oder T=1. Und die Chipkarten werden vom Terminal mit einem externen Takt 
(Clock) von 1MHz bis 5MHz versorgt.

Der Atmel soll nun zwischen Chipkarte und Terminal gesetzt werden. Dort 
wird die Kommunikation zwischen Terminal und Chipkarte beobachtet. Bei 
bestimmten Befehlen an die Chipkarte wird der Befehl abgefangen und 
durch den Atmel beantwortet. Er leitet also die Kommunikation nur dann 
an die Chipkarte weiter, wenn er die Befehle nicht selbst ausführen 
soll.

Das Ganze wird ein Testsystem, mit dem man dem Terminal auch mal falsche 
Antworten von der Chipkarte vorlegen kann, bzw. man kann das Timing der 
Übertragung auch mal aus den erlaubten Parametern verschieben 
(verzögern).

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Lars Thalheim (laptop24)

>Es handelt sich um eine Chipkarte mit Prozessor. Das Protokoll ist T=0
>oder T=1.

???

> Und die Chipkarten werden vom Terminal mit einem externen Takt
>(Clock) von 1MHz bis 5MHz versorgt.

Schon recht flott.

>Der Atmel soll nun zwischen Chipkarte und Terminal gesetzt werden. Dort
>wird die Kommunikation zwischen Terminal und Chipkarte beobachtet.

Selbst das reine Boabachten bei 5 MHz ist für den AVR alles andere als 
Penuts.

> Bei
>bestimmten Befehlen an die Chipkarte wird der Befehl abgefangen und
>durch den Atmel beantwortet. Er leitet also die Kommunikation nur dann
>an die Chipkarte weiter, wenn er die Befehle nicht selbst ausführen
>soll.

So einfach wie du denkst wird das ganz sicher nicht machbar sein.

>Das Ganze wird ein Testsystem, mit dem man dem Terminal auch mal falsche
>Antworten von der Chipkarte vorlegen kann, bzw. man kann das Timing der
>Übertragung auch mal aus den erlaubten Parametern verschieben
>(verzögern).

Das klingt eher so, als ob ein CPLD oder FPGA nötig ist.

Warum pachst du nicht die komplette Emulation der Chipkate in den AVR. 
Das könnte schon eher machbar sein.

MfG
Falk

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was du brauchst ist ein µC mit mehr Dampf zb ARM7 und 2 SPI 
Schnittstellen.

Die eine SPI zur KArte, die andere zum Chipleser, und der µC spielt 
dazwischen das Gateway.

Mit dem Umschalten bekomst du nur Datenmüll, da dann zwei Outputpins 
gleichzeitig Treiben.

Autor: Bernd Rüter (Firma: Promaxx.net) (bigwumpus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was machen denn diese Season-Interface für die ganzen Pay-TV-Karten ?
Da wird die Kommunikation zwischen CAM und Card abgelauscht und 
beeinflußt. Die werden zur Kommunikation auch an PCs angeschlossen.
Die richtigen Cracks leiten Key-Anfragen an die Card über das Netzwerk 
an eine andere Card weiter, die für alle die Antworten zentral erstellt.

Autor: Lars Thalheim (laptop24)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwei Datenpins treiben parallel? Einer vom Atmel und einer vom Terminal 
oder der Chipkarte?

Na ja. Ganz so ist es eigentlich nicht. Die Kommunikation nach T=0 bzw. 
T=1 ist immer nach dem Master-Slave-Prinzip. Das Terminal sendet eine 
Anfrage an die Chipkarte (Kommunikation in eine Richtung). Dann 
Antwortet die Karte (Kommunikation in die andere Richtung).

Der Chip dazwischen muss also NUR die Anfrage vom Terminal abwarten, und 
dann die Datenflussrichtung an seinen eigenen Pins auch umschalten. Man 
hat dann also eigentlich zwei Busse mit jeweils einem Master und einem 
Slave. Der Atmel ist allerdings beides, weil er in beiden Bussen hängt.

So die Theorie...

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau Lars, dazu muss der µC aber 2 Schnittstellen haben, und es gibt 
KEINE Umschaltung der Richtung.

Sind µC, Terminal und Chipkarte auf den selben Bus, dann kracht es in 
dem Fall.

Daten die der Termianl zur Chipkarte sendet und von µC abgefangen 
werden sollen, müssen elektrisch getrennt werden. Wenn die Chipkarte 
diese Daten parallel zum µC wirst du ein undefiniertes Verhalten 
bekommen.

Autor: Lars Thalheim (laptop24)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber genau das sage ich doch. Ich habe dann zwei Busse:

Ursprünglich: Terminal <--> Chipkarte
Anschliessend: Terminal <--> Atmel <--> Chipkarte

Sowas darf's natürlich nicht sein:

          Atmel
            |
Terminal <--+--> Chipkarte

Da Terminal und Chipkarte jeweils eine Leitung zur Kommunikation 
verwenden, brauche ich am Atmel entsprechend zwei Pins. Aber an einem 
ATmega128 werden sich ja wohl zwei Pins finden lassen. ;-)

Wie anfangs geschrieben, war für mich nur die Frage, ob man die 
Datenrichtung an einem Pin beliebig oft und schnell umschalten kann.

Die Idee ist also: Der Atmel beginnt (genau wie die Chipkarte) am Pin 1 
zu lesen. Die gelesenen Daten untersucht er, ob er selbst darauf 
antworten soll. Wenn nicht, dann schreibt er die empfangenen Daten auf 
Pin 2 zur Chipkarte raus. Dann schaltet er die Datenrichtung um. Damit 
kann er die Antwort von der Chipkarte am Pin 2 lesen und auf Pin 1 
schreiben. Dann wird wieder zurückgeschaltet und die nächste Anfrage vom 
Terminal kann am Pin 1 gelesen werden...

Damit haben wir einen typischen "Man in the middle".

Was ich vergessen habe. Die Kommunikationsfrequenz ist bei weitem nicht 
so hoch wie der Takt. Der Takt (Clock) liegt ja zwischen 1 und 5 MHz. 
Die Kommunkationsgeschwindigkeit liegt aber nur bei ca. 9600 Baud.

Damit dürfte also auch genügend Rechenzeit übrig bleiben, um die Daten 
zwischen Empfangen und Senden auszuwerten.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.