Verständnisfrage zu IO-Directionregister

[MC (Gast)]

Tag an alle,
ich kann nirgends herausbekommen, warum so viele RISC-Prozessoren 
Directionregister für ihre IO-Ports haben. Wieso benutzen die  keine 
(quasi)bidirekionalen Ports wie z.B. der 8051?
Das ständige umstellen der Richtung ist doch lästig.

Danke schon mal für eure Antworten,
MC

[Matthias L. (Gast)]

>Das ständige umstellen der Richtung ist doch lästig.

WIeso? Benutzt du deine Pins alle paar (Mikro)Sekunden abwechselnd als 
Ein- und Ausgang?

>(quasi)bidirekionalen Ports wie z.B. der 8051?
Die sind doch Unfug!

Die haben einen Pull-Up Widerstand und einen Pull-Down-Transistor.
Als Ausgabe kann man nun nur zwischen Active-Low und passiv-High wählen.
Das ist nicht besonders geeignet, um schnell-schaltende Signale 
auszugeben.
(naja gut, der 8051... für den ist wohl was anderes schnell... ;-)

Bei den Atmels kann hat active-High UND active-Low.
Und wenns als Eingang konfiguriert ist, dann ist der Ausgangstreiber in 
High-Z und der Pin ist somit eingang.

[w. (Gast)]

Dafür hast du hir Gegentaktausgänge, also aktiv low undaktiv high.

altenativ extern pullups verwenden, den port immer low lassen und mit 
dem direktion register den Ausgang setzen. beim einlesen erhälstdes 
ports dann verhält sich der Port, wie du es  vom 51er gewohnt bist.

[w. (Gast)]

edit

Dafür hast du hier Gegentaktausgänge, also aktiv low undaktiv high.

Altenativ kanst du externe Pullups verwenden, den Port immer low lassen 
und mit dem direktionregister den Ausgang setzen. Dann verhält sich der 
Port, wie du es  vom 51er gewohnt bist.

[Timmo H. (masterfx)]

@ w. (Gast)
Wenn du dich anmeldest kannst du auch richtig editieren anstatt einen 
neuen Post zu machen

[MC (Gast)]

>WIeso? Benutzt du deine Pins alle paar (Mikro)Sekunden abwechselnd als
>Ein- und Ausgang?
z.B. bei einer Software-I2C.

>Die sind doch Unfug!
Wieso?

>altenativ extern pullups verwenden,
also mehr externe Bauteile.

Leute, ich möchte mich jetzt nicht mit euch streiten.
Mich interessiert eigentlich, warum das genau so ist. Hat das 
irgendeinen Vorteil bezüglich der Architektur oder so???

[Matthias L. (Gast)]

>bezüglich der Architektur oder so???

Das ist einiges aufwändiger als im 8051.
Hat aber Vorteile bezgl. der QUalität der Ausgangssignale (schnelle 
Signale)

>z.B. bei einer Software-I2C.
Die meisten AVRs haben Hardware I2C. Da wird die Umschaltung 
entsprechend automatisch gemacht. Software I2C ist doch eh nicht so 
schnell.
Alternativ:
>>Altenativ kanst du externe Pullups verwenden, den Port immer low lassen
>>und mit dem direktionregister den Ausgang setzen. Dann verhält sich der
>>Port, wie du es  vom 51er gewohnt bist.

[MC (Gast)]

>Hat aber Vorteile bezgl. der QUalität der Ausgangssignale (schnelle
Signale)
Das ist des Rätsels Lösung!?

[w. (Gast)]

Ja,
aktiv lOW und aktiv high gibt in beide Richtungen belastbare Signalpegel 
und steile Flanken beim Potentialwechsel

[Sven P. (Gast)]

Spart für mich als Anwender reichlich Bauteile drumrum. Für Atmel fällt 
das vielleicht in die Schublade "Da is noch Platz aufm Chip und teurer 
wirds auch net -- also machen wirs doch so."

[Peter D. (peda)]

Matthias Lipinsky wrote:
> Das ist einiges aufwändiger als im 8051.
> Hat aber Vorteile bezgl. der QUalität der Ausgangssignale (schnelle
> Signale)

Nö, die Schaltflanken sehen beim 8051 auch gut aus.
Der Trick ist, daß beim 0->1 Schalten für 2 Taktzyklen ein starker P-FET 
nach VCC zieht.
Bloß dauerhaft kann der 8051 keinen hohen High-Strom liefern.

Neuere 8051 können aber auch als Gegentaktausgang gesetzt werden, d.h. 
der High-Treiber ist dann dauerhaft an.


>>z.B. bei einer Software-I2C.

Da setzt man dann den Ausgangspin einmalig auf low und schaltet immer 
nur das DDR-Bit um (DDRx = 1: low, DDRx = 0: high).


> Software I2C ist doch eh nicht so
> schnell.

Ganz im Gegenteil, SW-I2C ist viel zu schnell. Da müssen noch massig 
NOPs oder Delays rein, um die 100kHz einzuhalten.
SW-I2C ist aber einfacher zu verstehen und zu implementieren als HW-I2C.



Peter

[Matthias L. (Gast)]

>SW-I2C ist aber einfacher zu verstehen und zu implementieren als HW-I2C.

Meinst du? Kann ich mir nicht vorstellen, dass das einzelne 
Bit-geschubse für das Verständnis sorgt. Aber will es mal nicht 
abstreiten.