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.
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
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
Maik,
> "Zum Beispiel wird nirgendwo im Manual erwähnt, daß Pin RA4 kein High erzeugen
kann."
Also bei mir steht in jedem Manual zu allenPIC'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
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.
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
@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
@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.
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.
