PIC 16F684 - Problem beim Setzen von Portpins

Bernd Gast 13.10.2019 22:25 #6002322

Lesenswert?

•

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

Angehängte Dateien:

test.asm (521 Bytes) | Codeansicht

PIC16F684.jpg (77 KB)

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

dermatse Gast 13.10.2019 22:38 #6002328

Lesenswert?

•

▲
▼

A/D Converter deaktiviert?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

dermatse Gast 13.10.2019 22:40 #6002331

Lesenswert?

•

▲
▼

Hallo

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

Gruß

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Bernd Gast 13.10.2019 23:13 #6002356

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

McMix Gast 13.10.2019 23:18 #6002358

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Bernd Gast 13.10.2019 23:32 #6002367

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Jens M. (schuchkleisser) 14.10.2019 05:25 #6002441

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Klaus Gast 14.10.2019 08:54 #6002504

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Jens M. (schuchkleisser) 14.10.2019 09:06 #6002514

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Peter D. (peda) 14.10.2019 09:13 #6002525

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Peter D. (peda) 14.10.2019 09:16 #6002526

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Volker S. (vloki) 14.10.2019 09:19 #6002529

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Bernd Gast 14.10.2019 10:22 #6002614

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Larry Gast 14.10.2019 10:30 #6002626

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Bernd Gast 14.10.2019 21:01 #6003407

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

PIC 16F684 - Problem beim Setzen von Portpins

Antwort schreiben