Ja, dachte ich auch, aber funktioniert nicht. Kann es sein, dass die internen PullUp Widerstände den Tristate verhindern???

Wenn du es so machst wie ich es geschrieben habe: Nein.

Bei einem PIC würde die von Benedikt beschreibene Vorgehensweise nicht funktionieren. Die in PORTx geschriebene 0 würde ignoriert werden, falls am als Input konfigurierten Port von außen eine 1 anliegt. Beim Umschalten auf Ausgang behält er die 1. Es müsste also erst auf Ausgang geschaltet werden und danach der Wert 0 in das Register geschrieben werden.

Vielleicht ist das beim Atmel ähnlich?

Gruß,
Ltof

_________________
„Schreibe nichts der Böswilligkeit zu, was durch Dummheit hinreichend erklärbar ist.“
(Hanlon’s Razor)

Also ich habe von +10V eine LED mit Vorwiderstand an jedem Portpin von Port B und D.
Wenn ich das so definiere wie Du beschrieben hast, fliessen im Low-Pegel 25mA (das ist OK) und im "Tristate" 7µA (das ist nicht OK) in den Pin rein. Könnte das vielleich mit den internen Schutzdioden zusammenhängen?
Am Pin liegt ja mehr Spannung an als An Vcc des Controllers...

Zitat : Ltof hat am 17 Nov 2007 17:16 geschrieben :

Vielleicht ist das beim Atmel ähnlich?

Nein, zum Glück nicht. Die PORT Geschichte bei einem PIC ist ja nur ein einziger Bug (Port wird von extern auf Low gezogen, und wenn man dann den Port ausliest, liefert er logischerweise eine 0, obwohl von der Software her der Ausgang auf 1 ist).

Zitat : cosmoxx hat am 17 Nov 2007 17:30 geschrieben :

Könnte das vielleich mit den internen Schutzdioden zusammenhängen? Am Pin liegt ja mehr Spannung an als An Vcc des Controllers...

Ja.

Die angegebenen 7µA entstehen durch die interne Beschaltung des Pin als Eingang.
Ein Ausgang ("PORT") kann beim Atmel nur High oder Low sein - nie Tristate (="open Drain / open Collector") - dies erreicht man nur durch den "Umschalttrick" mittels dem Data-Direction-Register (DDRx) - wobei dann aber tatsächlich nur die Ausgangstreiber im Chip abgeschaltet sind - die vorhandene Eingangsbeschaltung bleibt aber elektrisch angeschlossen...

Zitat : Benedikt hat am 17 Nov 2007 18:08 geschrieben :

Die PORT Geschichte bei einem PIC ist ja nur ein einziger Bug (Port wird von extern auf Low gezogen, und wenn man dann den Port ausliest, liefert er logischerweise eine 0, obwohl von der Software her der Ausgang auf 1 ist).

Als Bug würde ich das nicht bezeichen. Für normale Anwendungen muss man das beim Programmieren einfach wissen und berücksichtigen. Diese Eigenschaft ließe sich daneben sogar dazu verwenden, einen überlasteten/kurzgeschlossenen Port softwaremäßig zu erkennen.

Wie ist denn das beim AVR gemacht? Hat der zwei verschiedene Port-Register für Eingabe und Ausgabe?

Gruß,
Ltof

_________________
„Schreibe nichts der Böswilligkeit zu, was durch Dummheit hinreichend erklärbar ist.“
(Hanlon’s Razor)

Zitat : Ltof hat am 19 Nov 2007 09:56 geschrieben :

Wie ist denn das beim AVR gemacht? Hat der zwei verschiedene Port-Register für Eingabe und Ausgabe?

Ja, mit der Richtungsumschaltung eigentlich sogar 3. Ich finde das ganz hilfreich. Klar, es ist gewöhnungssache, aber ich halte das für eine böse Fehlerquelle.

Zitat :

Ja, mit der Richtungsumschaltung eigentlich sogar 3. Ich finde das ganz hilfreich. Klar, es ist gewöhnungssache, aber ich halte das für eine böse Fehlerquelle.

Falscher Relativsatz. Du meinst mit Fehlerquelle wohl den PIC.

Der Assemblerprogrammierer muss aber sowieso aufpassen, was er tut. Dafür bekommt er aber auch das, was er bestellt hat.
Die Basic- und C-Leute wundern sich nur über rätselhafte Resultate.

Die Read-Modify-Write-Problematik findet sich aber schon in den ältesten Single Chips von Intel wie 8048 & Co.
Hier gilt also wirklich "It's not a bug, it's a feature"


_________________
Haftungsausschluß:



Bei obigem Beitrag handelt es sich um meine private Meinung.



Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.



Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !

Zitat : perl hat am 19 Nov 2007 14:18 geschrieben :

Die Read-Modify-Write-Problematik findet sich aber schon in den ältesten Single Chips von Intel wie 8048 & Co. Hier gilt also wirklich "It's not a bug, it's a feature"

Wobei das bei denen aber wieder anderst war, denn diese Controller hatten garkeine Richtungsumschaltung, denn alle Ports waren gleichzeitig Ein und Ausgang. Ein starker P Kanal Fet über einen Takt an, nachdem man einen Pin auf High schaltet, um die Anstiegszeit ordentlich hinzubekommen, danach nur noch einen Pullup. Das fand ich bei den 8051er echt genial.

[OT]

Zitat :

Die Basic- und C-Leute wundern sich nur über rätselhafte Resultate.

Moin perl,
Zumindest was Basic betrifft stimme ich dir voll und ganz zu, das ist meiner Meinung nach das reinste Gekrüppel...
Was C betrifft jedoch nicht, denn der Maschienenkode ist schon sehr krass; das bekommt man kaum besser hin. Die Optimierung des avr-gcc' macht das schon sehr gut.

Zumal man über den Präprozessor und das Einbinden externer Programme, z.b. nen Treiber für ein LCD, sein Programm sehr gut und überschaulich gestalten kann. Weiterhin lassen sich Mnemonics per Inline-Assembler einbauen oder ganze Maschienenkode-Teile einbinden.

Also, so genialen Asm-Kode bekommt man kaum selbst hin - Es sei denn, man will das Programm nie portieren o.ä. Da bekomme ich dann auch wesentlich besseren Asm-Kode als avr-gcc es könnte.
[/OT]

_________________