PIC 16F684 - Problem beim Setzen von Portpins

[Bernd (Gast)]

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

[dermatse (Gast)]

A/D Converter deaktiviert?

[dermatse (Gast)]

Hallo

ich meinte:
PORTA 0 und 1, sind auf Digital IO konfiguriert?

Gruß

[Bernd (Gast)]

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

[McMix (Gast)]

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.

[Bernd (Gast)]

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.

[Jens M. (schuchkleisser)]

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.

[Klaus (Gast)]

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

[Jens M. (schuchkleisser)]

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.

[Peter D. (peda)]

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.

[Peter D. (peda)]

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.

[Volker S. (vloki)]

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.

[Bernd (Gast)]

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

[Larry (Gast)]

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.

[Bernd (Gast)]

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