Forum: Mikrocontroller und Digitale Elektronik PIC16C: USART will nicht senden


von infiniter (Gast)


Lesenswert?

Hallo!

Wer kennt sich mit dem PIC16C745 oder ähnlichen mit USART aus?
Habe alle wichtigen Register konfiguriert:

movlw  b'1100000'
movwf  TRISC
banksel  TXSTA
bcf  TXSTA, TX9  ; nur 8bit-Senden
bcf   TXSTA, TXEN  ; Transmission erst einmal sperren
bsf  TXSTA, BRGH  ; High Speed Modus für alle Transmissionen
bcf  TXSTA, SYNC  ; Asynchronen Modus setzen
banksel  RCSTA
bsf  RCSTA, CREN  ; kontinuierlicher Empfang erlaubt
bsf  RCSTA, SPEN  ; serieller Port an
bcf  RCSTA, RX9  ; nur 8bit Empfang
bsf  INTCON, GIE
bsf  INTCON, PEIE

Dann will ich einen drei Byte großen Puffer senden, nur um zu testen, ob 
die Daten rausgehen:

Transmit
  banksel  W_save
  movwf  W_save  ; W retten
  movlw  .156
  banksel  SPBRG
  movwf  SPBRG  ; Baudratengenerator auf 9600 Baud setzen
  bsf  TXSTA, TXEN  ; Transmission erlauben
  banksel  BUFFER0
  movfw  BUFFER0    ; dann erstes Byte laden
  banksel  TXREG
  movwf  TXREG      ; und Byte (BUFFER0) abschicken
  nop
  nop
  nop
  banksel  PIR1
  btfss  PIR1, TXIF  ; warten, bis TXREG leer (TXIF = 1)
  goto  $-1
  banksel  BUFFER1
  movfw  BUFFER1    ; zweites Byte laden
  banksel  TXREG
  movwf  TXREG    ; Byte (BUFFER1) abschicken
  nop
  nop
  nop
  banksel  PIR1
  btfss  PIR1, TXIF  ; warten, bis TXREG leer (TXIF = 1)
  goto  $-1
  banksel  BUFFER2
  movfw  BUFFER2    ; drittes Byte laden
  banksel  TXREG
  movwf  TXREG    ; Byte (BUFFER2) abschicken
  nop
  nop
  nop
  banksel  PIR1
  btfss  PIR1, TXIF  ; warten, bis TXREG leer (TXIF = 1)
  goto  $-1
  bcf  TXSTA, TXEN  ; Stop Transmission
  banksel  W_save
  movfw  W_save    ; w wiederherstellen
  pagesel  CLRBUF
  call  CLRBUF    ; und noch den Puffer löschen
        return

Nur, es kommt nichts raus am Pin TX.
Eigentlich sollten alle Einstellungen richtig sein.
Leider habe ich keinen verwertbaren Beispielcode im Netz finden können.

Falls jemand eine Idee hat, wäre nett.

Danke schon mal!

Gruß,
Maik

von Jangomat (Gast)


Lesenswert?

Hallo,
Erste Zeile:
Bist du in Page 1?
Du mußt Bit 6 als 0 (Ausgang Tx) definieren und Bit 7 (Rx) als 1 (bei 
Dir ist Bit 7, welches Du vergessen hast 0 und Bit 6 eine 1)
Weiter habe ich nichts geprüft, aber das mußt Du in jedem Fall ändern.

von infiniter (Gast)


Lesenswert?

Hmm, das ist es ja gerade. Ich habe mich nach dem Manual gerichtet, wo 
steht, daß man die Bits 6 und 7 setzen muß, also 1. Ist zwar unlogisch 
für einen Ausgang, aber man schaltet ja noch die serielle Schnittstelle 
ein.

Ich probier es trotzdem mal aus. Microchips Manuale sind ja lausig. Was 
ich schon an Unstimmigkeiten an dem PIC gefunden habe! Zum Beispiel wird 
nirgendwo im Manual erwähnt, daß Pin RA4 kein High erzeugen kann. Toll! 
Hat man sich eine Schaltung gebastelt und eine Platine geätzt, darf man 
wieder einen R reinstricken.

Zur Bank: Klar habe ich die richtige Bank. Hatte nur jetzt nicht den 
Code davor eingefügt, wo der banksel steht.
Daß ich daß nicht gesehen habe, daß da nur 7 Bits gesetzt werden!!! 
Blindheit umgibt mich... kopfschüttel

Danke für deine Hilfe!

Maik

von infiniter (Gast)


Lesenswert?

Nee, doch nicht. Habe im Programm doch alle 8 gesetzt, nur hier die 
letzte 0 gelöscht, warum auch immer.

von Jangomat (Gast)


Lesenswert?

Hallo,
Du mußt trotzdem Bit 6 als 0 definieren (0=Ausgang), sonst kommt nichts 
raus.
Im manual ist hier mit Setzen nicht die Wertigkeit 1 gemeint, sondern 
die korrekte Definition der Richtung.
Also TRIS:=b10xxxxxx

von infiniter (Gast)


Lesenswert?

Habe ich eben gemacht, tut sich nichts.
Ansonsten ist es logisch.

Halt weiterprobieren...

von Andreas Jäger (Gast)


Lesenswert?

Maik,

> "Zum Beispiel wird nirgendwo im Manual erwähnt, daß Pin RA4 kein High erzeugen 
kann."

Also bei mir steht in jedem Manual zu allen PIC's in der 
Port-Übersicht und in der PORTA-Beschreibung, dass RA4 "open collector" 
ist! Und das bedeutet nun mal, dass ein pull-up zu verwenden ist.

MfG
Andreas Jäger

von infiniter (Gast)


Lesenswert?

Ja, richtig. Leider überlesen. ;O)

Ist aber auch doof, daß man sich das ganze Manual durchlesen muß, nur um 
den PIC richtig zu initialisieren. Auch Sektionen, die man gar nicht 
braucht.

Z.B., daß man auch per ADCON1 die Ausgänge von Port A auf Digital I/O 
stellen muß, weil sie sonst nicht setzbar sind...

Aber das ist das bekannte Chaos bei Microchip, die haben einfach zuviele 
Typen.

von Steffen (Gast)


Lesenswert?

Wenn Du meinst, das Du bei anderen Prozessoren nicht das ganze Manual 
durchlesen musst, dann bist Du auf dem Holzweg!

Chaos????? Wo???? Bei wem????

MfG
Steffen

von Jangomat (Gast)


Lesenswert?

Hallo nochmal,

vielleicht stellst Du mal den kompletten Code rein.
Was machst Du mit den Interrupts?

von infiniter (Gast)


Lesenswert?

@Jangomat

Nun ja, ist nicht der erste, mit dem ich mich beschäftige.
Und meine Kollegen, von Beruf Ingenieure, arbeiten hauptsächlich mit 
8051-Prozessoren und können von derlei Schwierigkeiten ein Lied singen.

Zum meinem Problem nochmal:

Ich habe sogar das hier 
http://www.sprut.de/electronic/pic/grund/rs232.htm
vorgestellte Programm 1:1 übernommen (bis auf das INCLUDE und die 
LIST-Direktive) und in meinen PIC gebrannt. Nichts!
Ich kann mit dem Oszilloskop sehen, daß an den PIC gesendete Daten am 
RX-Pin ankommen, aber er reagiert nicht drauf.
Genauso wie in meiner Software, die zum Test nur Daten rausschicken 
sollte. Daß muß ja gehen, ganz gleich, ob der PIC auf Signale am RX-Pin 
reagiert kann oder nicht. Auch ist der PIC nicht defekt, da ich noch 
einen unbenutzten OTP hatte, dem ich das obige Progrämmchen einbrannte. 
Kein Erfolg.
Ich bin total ratlos, weil viel falsch machen kann man ja nicht. Ein 
paar Register setzen und dann ein Byte in TXREG legen, und raus müßte es 
gehen....

Tja, Pech. Das war's mit mir und Microchip. Zur Beendigung des 
Projektes, dessen Kern dieser PIC ist, werde ich die serielle 
Datenkommunikation wohl softwaremäßig ermöglichen müssen. So umständlich 
und schei... das auch ist.

Danke nochmal und Gruß!

Maik

von Jangomat (Gast)


Lesenswert?

Stell doch bitte trotzdem Deinen kompletten Code hier rein.
Am PIC liegt es nicht.

von Tom (Gast)


Lesenswert?

und du bist dir auch sicher das deine verdratung richtig ist?
vieleicht sind ja nur Tx und Rx vertauscht.

von infiniter (Gast)


Lesenswert?

@Tom

Das wohl eher nicht, ich bin angehender Techniker und lange genug in der 
Branche, um solche Fehler zu vermeiden. Selbst wenn nichts an den 
Ausgängen dran war, kam nichts raus.
Momentan ist aber ein USB-zu-RS232 Wandler (FT232) am UART 
angeschlossen, d.h., TX zu RX und RX zu TX, so wie es sein soll.

@Jangomat

Braucht es nicht. Oben stehen die Registereinstellungen, sowie der Teil 
des Codes, der sendet. In einer Schleife mache ich nichts weiter, als 
einen 3 Byte großen Puffer zu füllen und dann "Transmit" aufzurufen.

Mittlerweile habe ich die softwaremäßige Implementierung der UART mal 
getestet. Das geht soweit, nur die Bitlänge muß ich noch anpassen. Auf 
sprut.de war ein Beispiel, aber die Werte dort passen nicht. Auf dem 
Oszi sind die Bits länger als 104us bei 9600 Baud und 6 Mhz Befehlstakt. 
Weil ich aber zuerst vergaß, den jetzt simulierten TX-Ausgang (immer 
noch RC6) permanent auf 1 zu setzen, so wie es sein soll bei RS232, lief 
das Programm dann auch. Später, als ich ein "bsf PORTC, 6" machte, nicht 
mehr. Im Manual steht, man sollte solcherlei Anweisungen besser 
vermeiden, sofern auf peripheren Ausgang umgeschaltet wurde (UART). Das 
aber ist ja nicht der Fall. Und trotzdem gibt es Ärger. Soll das eine 
Art Hardwarebug des PIC sein? Naja, morgen kommt zum Glück ein PIC16F76, 
der ist pinkompatibel und hat wenigstens Flash, da dauert das Löschen 
wenigstens nicht so lange. Wenn doch auf der PC-Seite die Geschichte mit 
LabView und USB funktioniert hätte, dann könnte ich mir das alles 
sparen! Denn die Kommunikation über USB mit dem internen USB-Controller 
des PIC funktionierte ja. Das mit dem UART ist ja nur eine Notlösung.

von Jangomat (Gast)


Lesenswert?

Schade,
dann kann ich Dir nicht helfen.
Wenn Du in C programmieren würdest, dann würde der RS232-Teil als Info 
vermutlich ausreichen, da sich der Compiler um den Rest kümmert. In 
Assembler muß man bei 'ungeklärten' Problemen das Programm aber doch 
ganzheitlich anschauen. Aber Du hast ja einen (mühsamen) Ausweg 
gefunden. In diesem Sinne weiterhin viel Erfolg.

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
Noch kein Account? Hier anmelden.