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 meinte: PORTA 0 und 1, sind auf Digital IO konfiguriert? Gruß
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.
:
Bearbeitet durch User
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.