|
Anzeige
|
Schnelles umschalten der Portrichtung möglich?
Gast
#728674
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.
Gast
#728678
Nein, da gibt's keine Begrenzungen. Es darf halt zu keinem Zugriffskonfikt auf Deinem Bus kommen.
Gast
#728682
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
Gast
#728880
Vielen Dank für die Antworten. Das hört sich erstmal gut an.
Gast
#728924
> 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.
Gast
#728960
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.
Gast
#728976
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. @ 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
Gast
#729206
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). @ 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
Gast
#729255
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. 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.
Gast
#729302
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...
Gast
#729431
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.
Gast
#729480
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 |
Anzeige
|
