Der Kürze wegen setze ich den Quelltext mal direkt hier rein:
#include <P16f684.INC>
__CONFIG _HS_OSC & _WDT_OFF & _PWRTE_ON & _MCLRE_OFF & _BOD_OFF
org 0x00
goto init
org 0x100
init bsf STATUS,RP0 ; Bank 1
bcf TRISA,0 ; RA0 output
bcf TRISA,1 ; RA1 output
bcf STATUS,RP0 ; Bank 0
mainloop bsf PORTA,0 ; RA0 auf high
bsf PORTA,1 ; RA1 auf high
nop
nop
bcf PORTA,1 ; RA1 auf low
bcf PORTA,0 ; RA0 auf low
goto mainloop
end
Ich setze also erst RA0 auf high, dan RA1 auf high. Dann zwei nop, dann
setze ich RA1 auf low, dann RA0 auf low. Das ganze in einer Schleife.
Seltsammerweise wird RA0 beim setzen von RA1 auf high schon auf low
gesetzt (siehe Foto, habe es leider nicht besser hinbekommen). Hat da
jemand eine Erklärung dafür? In der Vorschau ist die Formatierung des
Quelltextes verloren gegangen, deshalb hänge ich die Quelldatei auch
noch dran.
Bernd
Hallo,
ich war davon ausgegangen, dass defaultmäßing nach Reset der Port als
Digital-IO konfiguriert ist, ist aber nicht so, ANSEL steht auf 0xFF.
Nun habe ich es auf 0x00 gesetzt, das Verhalten ist aber immer noch das
gleiche.
Bernd
RA0 und RA1 werden auch als Portpins für das PICKIT genutzt. Bist du
sicher, dass das Bild nicht die ISP Signale der Debugsession zeigt?
Vielleicht solltest du mal testweise auf das Port C ausweichen.
Es läuft keine Debugsession, das Programmiergerät ist nicht
angeschlossen. Auf Port C funktioniert es wie erwartet, es reicht sogar,
wenn man einen der beiden Ausgänge auf Port C legt.
Du bist simpel zu schnell.
Der Prozessor liest die Ports, setzt das Bit und schreibt die Ports
wieder zurück.
Der erste und der zweite Befehl überlappen sich (so wie alle Befehle
beim PIN, 4 Maschinenzyklen und so...), so das der 2. Read vor dem 1.
Write gemacht wird und damit das im 1. Write gesetzte Bit wieder
zurückspringt.
vgl. S. 33 im DaBla.
Und/Oder deine Last ist zu groß und der Pin braucht eine Zeit um von Low
nach High zu kommen, und der Chip liest das ansteigende Signal wieder
ein bevor es VIH erreicht.
Mach ein NOP oder was anderes dazwischen, oder setze beide Bits in einem
Befehl, und es wird gehen.
Jens M. schrieb:> Mach ein NOP oder was anderes dazwischen, oder setze beide Bits in einem> Befehl, und es wird gehen.
Oder beim Ausgeben nicht auf den Port sondern auf das dazugehörige Latch
schreiben.
MfG Klaus
Klaus schrieb:> Oder beim Ausgeben nicht auf den Port sondern auf das dazugehörige Latch> schreiben.
Das gibt's beim 684 nicht. Lesen liest Pins, schreiben schreibt Latch.
Aber höhere PICs haben getrennte Register, damit genau das nicht
passiert, da kann man die Latches RMW'n ohne das solche Effekte
auftreten.
Bernd schrieb:> Seltsammerweise wird RA0 beim setzen von RA1 auf high schon auf low> gesetzt
Ist das altbekannte PORT vs. LAT Problem.
PORT liest den echten Eingang und das dauert halt Zeit. Daher setzt das
nächste BSF ihn wieder zurück.
Für Ausgaben also immer das LAT-Register nehmen.
Jens M. schrieb:> Das gibt's beim 684 nicht.
Dann helfen nur NOPs zwischen den BCF/BSF-Befehlen oder einen neueren
pinkompatiblen PIC nehmen, vorzugsweise PIC18.
Bernd schrieb:> ich war davon ausgegangen, dass defaultmäßing...
Schau besser mal ins Datenblatt:
##########################################
Note:
The ANSEL (91h) and CMCON0 (19h)
registers must be initialized to configure
an analog channel as a digital input. Pins
configured as analog inputs will read ‘0’.
##########################################
Da du RMW Befehle benutzt, passiert genau das was da zu sehen ist.
Der zweite Befehl zum setzen von RA1 liest für RA0 eine 0 und die wird
wieder ausgegeben.
Hallo,
erst mal Dank für die vielen Hinweise. Die Zeit kann es nicht sein, ich
hatte probeweise sogar eine Zeitschleife von 3µs zwischen den Befehlen,
es hat nichts genutzt. ANSEL hatte ich initialisiert (siehe oben) aber
CMCON0 nicht, das werde ich heute Abend mal versuchen und dann
berichten.
Bernd
Da fehlt nach ANSEL noch ein:
CMCON0 = 7;
"111 = Comparators off. CxIN pins are configured as digital I/O"
Sowas kann man eigentlich selber im DB nachlesen.
Jetzt funktioniert es. Es fehlte das CMCON = 7. Dass sie intern als
Read-Modify-Write abgearbeitet werden hätte ich eher bei solchen
Befehlen wie XORWF u.s.w. aber nicht bei den Bit-Schreibbefehlen
vermutet. Dank an alle, die geholfen haben
Bernd
PIC16F684.jpg
(77 KB)
