Hi,
ich habe ein Problem mit einem Portzugriff auf dem pic16f84.
ich meine ich habe das hier auch schonmal irgentwo gelesen, das es zu
problemen kommen kann, wenn man mehrere male auf das portregister mit
einem bitbefehl zugreift.
zb
bcf portb,0
bcf portb,1
bcf portb,2
bcf portb,3
bcf portb,4
...
bcf portb,7
das seltsame ist:
ich mache nach dieser befehlsreihe nochmal eine auswahl in 8 funktionen,
in denen noch etwas mit den i/o registern (tris) gemacht wird.
sie sind von der struktur her alle gleich, probleme tauchen nur in der
ersten funktion auf, dort sind dann alle portbits auf 1.
welche funktion ausgeführt wird, wird über ein routierendes bis in einer
8 bit variablen entschieden.
d.h. die funktion 1 wird nach einem btfss, ausgeführt, wenn sie dran
ist, die funktion 8 erst nach weiteren 7...
das die funktionen das machen was sie sollen und das dort kein fehler
vorliegt ist damit bewiesen das wenn ich den oberen assembler code
gegen:
clrf portb
eintausche, alles so läuft wie es laufen sollte.
wie kann das sein, was kann ich machen?
ich habe mal jeweils 4 nop's zwischen die befehle gesetzt, hat aber
nichts geändert...
komisch ist auch, das das problem nur mit der ersten funktion
auftaucht....
maddin
Hi,
meinst wohl das "read-modify-write"-Problem, oder? Am einfachsten und
auch sehr effektiv ist es, eine 'Schattenvariable' einzuführen. Damit
ist ein Register gemeint, in dem Du die Bitmanipulationen erledigst und
es dann jeweils als Byte an PORTB übergibst.
Gruss,
Edson
nein, leider ist es das wohl nicht, denn ich greife auf den prot b in
dem bereich nur schreibend zu, ich wechsle zwischen den bitzugriffen
nicht die richtung!
beim write read problem, fängt man sich ja einen fehler ein, weil man
etwas von einem ort liest, dann verändert, die richtugng wechselt, und
anschließend in ein anderes register zurück schreibt, so wie ich das mal
verstanden habe, jedoch wird in diesem fall ja, von port b output
gelsen, verändert, und nach port b output zurück geschrieben ....
ich arbeite schon sehr lange mit pics, doch soetwas ist mir noch nie
untergekommen....
dank dir trotzdem, maddin
>ich wechsle zwischen den bitzugriffen>nicht die richtung!
Darum gehts beim "read-modify-write"-Problem nicht. Auch wenn Du schon
lange mit PICs arbeitest, hier liegst Du falsch.
>ich greife auf den prot b in>dem bereich nur schreibend zu
Wenn Du ein Bit manipulierst, liest der PIC unabhängig von Deiner
Absicht nichts zu lesen trotzdem den gesamten Port zurück und schreibt
Ihn dann als komplettes Byte auf die Ausgangspins.
Das 'modify' beim rmw-Problem hat nichts mit den TRIS-Registern zu tun!
Gruss,
Edson
hallo meister eder,
das ist schon klar, lies jedoch mal folgenden text:
Jedesmal, wenn auf ein Port (PORTA..PORTE, GPIO) schreibend zugegriffen
wird, dann wird zunächst das gesamte Port gelesen, das gelesene Byte im
Prozessor modifiziert, und dann das veränderte Byte in das Port
zurückgeschrieben. Also wird auch dann, wenn nur ein einzelnes Bit
verändert werden soll (bsf, bcf), jedesmal das ganze Port angefasst.
soweit - sogut
Beim anfänglichen Lesen des Ports liest der Prozessor nicht etwa das
Portregister (z.B. PORTA oder PORTB) aus, sondern liest die momentanen
Pegel an den Pins des Ports ein. Bei Pins, die auf
>>Output eingestellt sind<<
macht das keinen Unterschied, wohl aber für Port-Pins, die auf Input
eingestellt sind. Deren Bits im Port-Register können dadurch
unbeabsichtigter Weise verändert werden. Nach dem Umschalten auf Output,
haben diese Pins dann einen anderen Pegel als beabsichtigt.
ich bin für jeden tipp dankbar, nur wie schon geschrieben, werden die
ports in dem codebereich nur als output beschrieben.....ich kann mir
also keinen falschen wert von aussen einfangen, oder!?
vor allem, warum geht das nur mit ersten funktion nicht, und mit den
anderen 7 schon?
maddin
Ok,
>Bei Pins, die auf>>>Output eingestellt sind<<>macht das keinen Unterschied, wohl aber für Port-Pins, die auf Input>eingestellt sind.
Woher stammt denn das Zitat? Ein stark belasteter Ausgang kann
jedenfalls zum falschen zurücklesen eines Portpins führen. Dazu wurden
bei den PIC18 die LAT-Register eingeführt. Man benutzt sie
ausschliesslich für die Ausgabe...
Gruss,
Edson
Hallo,
hat leider etwas gedauert aber man muss ja auch mal arbeiten... :)
An der Belastung liegts also in dem Fall nicht.
Die Seiten von sprut kenne ich, das Zitat ist auch nicht wirklich falsch
wie es da steht. Aber es ist leicht misszuverstehen.
maddin Zitat:
>>ich mache nach dieser befehlsreihe nochmal eine auswahl in 8 funktionen,>>in denen noch etwas mit den i/o registern (tris) gemacht wird.
könnte das wie folgt ein Teil der Fehlerquelle sein?
sprut Zitat:
>Nach dem Umschalten auf Output, haben diese Pins dann einen anderen Pegel als >beabsichtigt.
In dem Kontext schon möglich, oder?
Ohne das Programm zu kennen kann ich nur noch auf einen Bankfehler
tippen. Könnte bei vielen I/O-Umschaltungen schon mal übersehen worden
sein. Aber das ist nur spekulativ...
Gruss,
Edson
hallo meister eder,
ich habe momentan portb mit einem clrf ratzekal auf 0 gesetzt, das geht
auch.
weiterhin habe ich folgendes versucht:
movf PORTB,w
andlw h'FE'
movwf PORTB
das sollte den befehl:
bcf PORTB,0
ersetzen, so habe ich alle ersetzt...
mit dem ergebnis, das es nur noch schlimmer wurde.
ein bankfehler ist ausgeschlossen, denn ich nutze zur sicherheit auch
noch makros für solche aktionen wie bankwechsel usw...zumal ich nur in
speziellen regionen einen bankwechsel mache, ansonsten käuft der gesamte
code immer auf bank 0 - so schließe ich diese fehlerquelle aus..
aber der hinweis mit dem i/o ist gut - ich werde das nochmal überprüfen,
ich schätze das wird es sein. durch diese routinen sind einige port pins
von portb auf input gestellt, das werde ich heute abend mal ändern - man
muss ja auch mal arbeiten.
dank dir, bis dahin.
maddin
