Hallo Zusammen, Ich hänge nun schon den 3ten Tag an meinem USART Problem des PIF18F24 und bin am verzweifeln. Ich habe recht viel Erfahrung mit uControllern aber jetzt stehe ich am "Schlauch". Meine PIC24F Testumgebung: MPLAB, ICD3, ext. 16MHz Oscillator Alles läuft soweit einwandfrei, kann auch an den Port Pins wakeln. MEIN PROBLEM LIEGT BEIM USART (1): - Habe die notwendige Initialisierung mindestens 10 mal peinlich genau kontrolliert und dabei auch unterschiedliche Beispiele aus www studiert: Die Initialisierung TXSTA1: TXEN=1, TX9=0, SYNCH=0, BRGH=1 RCSTA1: SPEN=1 BAUDCON1: 0x40 SPBRG1: 0x8A NICHTS GEHT RAUS. Das TRMT (Transmit Emty) zeigt nur vor dem ersten Beschreiben des TXREG1 "Emty" an, dann nicht mehr. An der TX1 Leitung rührt sich natürlich auch nichts. Wer hat ein ähnliches Problem erlebt? Kann mir jemand weiter helfen? Vielen Dank Walter
Walter F. schrieb: > an meinem USART Problem des PIF18F24 Welcher PIC den genau? PIC18F24 gibt es mehrere... PIC18F24K20, PIC18F24K22, PIC18F24J50, PIC18F24J11,.... Walter F. schrieb: > Meine PIC24F Testumgebung: PIC24 wäre aber eine ganz andere "Baustelle"!?
Hallo Chris, habe mich vertan. Ursprünglich wollte ich einen PIC24F einsetzten. Ich brauche aber dessen Performance nicht. Deshalb verfalle ich automatisch mal in die Vergangenheit. Programmiere gerne Assembler, der klopft mir dann immer so schön auf die Finger..... Also es ist ein PIC18F26K22. Ansonsten bin ich ganz begeistert von den Features; mein erster PIC. Viele Grüße aus München Walter
Läuft der PIC soweit oder sind die Configuration Bits falsch eingestellt (Watchdog eingeschaltet, falscher Oszillator ausgewählt). Wurde der Tx-Pin auch als Ausgang konfiguriert? Ich habe gerade erst gestern Nacht eine UART-Bibliothek in C für PIC18 Controller geschrieben. Kann dir noch ein paar Infos geben wenn ich wieder zu Hause bin. PS: Poste doch mal deinen Code, dann geht die Fehlersuche schneller.
Hallo be stucki, vielen Dank für Deine Antwort. Blöde Frage von mir: bestückst Du auch? Die Quelldatei im Anhang, hoffentlich klappt es. Die DO´s arbeiten einwandfrei. Habe ne lange Nacht gehabt, Doku gewälzt usw. Muss was saublödes sein. Ich schätze das hängt an meiner noch immer mangelhaften System-Struktur-Kenntnissen mit dem PIC zusammen. Bin so froh wenn ich da weiterkomme! Viele Grüße aus München Walter
LoadBaudRateReg1
MOVLW H'00'
MOVWF SPBRGH1
MOVLW H'8A'
MOVWF SPBRG1 ;Baud Rate Generator for 115.200 Baud
LoadBaudRateContrReg1
MOVLW B'01000000'
MOVWF BAUDCON1
Also SPBRGH1:SPBRG = 0x008a = 138, der passt zu den Tabellen 16.5 für
115.2kb, SYNC=0, BRGH1=1, BRG16=1 - OK
BAUDCON1 initialisierst du mit B'01000000' - also ist dort BRG16=0,
sollte aber 1 sein !
Die ganze CONFIG-Geschichte habe ich jetzt nicht nachgelesen was da
Default-Einstellungen sind.
Damit das ganze auch wirklich mit 64MHz läuft, würde ich auf jeden Fall
die PLL definitv einschalten (OSCTUNE.PLLEN = 1).
(habe leider keinen passenden Chip hier um das zu testen)
btw: Um Klarheiten bezüglich der Konfiguration des Kontrollers zu bekommen, soll/kann man die Templates von MICROCHIP verwenden (z.B. 18F26K20TEMP.ASM) und diese anpassen und mit eigenem Code "füllen". Dort sind die CONFIG-Register vorgegeben (welche man gegebenfalls anpasst), Grundprogramm für Interruptvektoren mit der notwendigen Registersicherung/Wiederherstellung, etc... Eine Angabe wie: MOVLW B'00001111' MOVWF 30001H sagt mir NICHTS und ist nebenbei eine eher ungewöhliche Art und Weise! Nachsehen im DB hilft natürlich weiter. Nur gibt es da noch ein Dutzend weitere CONFIG-Register und welchen Defaultwert haben diese?? Oder wurden ein paar CONFIG-Register von der IDE aus eingestellt, wenn ja, woher soll man das wissen wenn nicht dokumentiert ;-)
Walter F. schrieb: > Blöde Frage von mir: bestückst Du auch? Nur meine eigenen Leiterplatten :) Hier mal einen Teil meines Codes:
1 | void UARTinit(void){ |
2 | SPBRG=0x0A; // 115.2kBaud bei fosc=20MHz (effektiv 113.6kBaud) |
3 | TXSTAbits.BRGH=1; // High speed mode |
4 | TXSTAbits.SYNC=0; // Asynchronous mode |
5 | RCSTAbits.SPEN=1; // Enable serial port |
6 | TXSTAbits.TXEN=1; // Enable transmit |
7 | }
|
8 | |
9 | |
10 | void UARTsend(uint8_t data){ |
11 | while(!TXSTAbits.TRMT); |
12 | TXREG=data; |
13 | }
|
Der Code läuft momentan auf einem PIC18F452, sollte aber auch für andere PIC18 funktionieren. Beim Initialisieren der USART sollte (muss evt. sogar?) eine bestimmte Reihenfolge eingehalten werden, wie die einzelnen Register beschrieben werden. Dies steht irgendwo im Datenblatt in einem grauen Kasten im Kapitel USART (hab die Seitenzahl vergessen). Chris B. schrieb: > Die ganze CONFIG-Geschichte habe ich jetzt nicht nachgelesen was da > Default-Einstellungen sind. Wenn du die Configuration-Bits meinst: - Oszillator auf RC - Watchdog eingeschaltet auf 1:128 - VBOR eingeschaltet auf 2V Um so die wichtigsten zu nennen. Alle anderen Register im Controller werden standardmässig mit 0 initialisiert, es gibt jedoch aus Ausnahmen die mit 1 initialisiert werden (z.B. TRIS-Register) oder undefiniert sind. Grundsätzlich so, dass jegliche Peripherie ausgeschatet ist und du nichts kaputt machen kannst. Steht alles im Datenblatt.
Nachtrag: Hab gerade deine I/O Konfiguration angeschaut (TRIS-Register). Setze den Tx-Pin (RC6) auf Ausgang. Ohne jetzt nachgelesen zu haben behaupte ich mal, dass die Richtung nicht von der USART definiert wird.
Hi Chris, ich hab's gefunden. Der Code ist OK, nur die Art und Weise wie ich das dann verifiziert habe nicht. Mit dem EMU da in Single Step über die UART-Ausgabe zu gehen funktioniert natürlich nicht. Da läuft dann der Prozessor gerade 150nS dann steht das Ganze wieder im "Halt" und das wars. Dann sieht man auch nie das TXEMTY Bit und nix geht raus Jetzt stehen die Bits wie ne Eins am TX Ausgang. Diesen Fehler habe ich vor 20 Jahren schon einmal gemacht, aber leider vergessen. Wollte wohl auch zu gründlich verifizieren Mensch, bin ich froh. Wollte schon Busfahrer werden! Aber ganz was anderes: Ich bin sehr Hardwarenah und habe mit C (leider) nichts am Hut. Wir suchen (gegen Bezahlung natürlich) jemanden der in C gut ist und eine Seite C-Code mit Mathe drin in einen PIC32F26 Assemblercode (das dann als Unterprogramm aufrufbar ist) umsetzt. Eingangsvariable 1x 11-Bit. Ausgang Wert A: von 0x80 bis 0xff Ausgang Wert B: von 0x00 bis 0xod Das Ganze klingt wohl seltsam, aber die Werte benötigt ein Schrittmotorcontroller zur Rampenberechnung. Es ist alles gut dokumentiert, der Quellcode in C (ATMELuP 1 Seite) ist auch als Datei vorhanden. Haste da Lust auf ein paar Mäuse? Gruß Walter
Hi, vielen Dank auch für Deine Unterstützun. Ich habs gefunden. das war nicht der Code, der ist OK. Es war der EMU. Da darf man nicht im Single-Step rüber, denn der uP ist da nur ganz kurz am werkeln und wird gleich wieder abgewürgt. Dann kann natürlich nichts rausgehen. Ich wette, da sind schon etliche reingefallen. Viele Grüße aus München Walter
be stucki schrieb: > Nachtrag: > Hab gerade deine I/O Konfiguration angeschaut (TRIS-Register). Setze den > Tx-Pin (RC6) auf Ausgang. Ohne jetzt nachgelesen zu haben behaupte ich > mal, dass die Richtung nicht von der USART definiert wird. Im Datenblatt steht explizit, dass der auf 1 gesetzt werden muss (Eingang). Das macht das Modul selbst.
jkghj schrieb: > Im Datenblatt steht explizit, dass der auf 1 gesetzt werden muss > (Eingang). Das macht das Modul selbst. Vielen dank für die Info. Habs nun im Datenblatt nachgelesen, man sollte nur, muss aber nicht: > For all modes of EUSART operation, the TRIS control > bits corresponding to the RXx/DTx and TXx/CKx pins > should be set to ‘1’. The EUSART control will > automatically reconfigure the pin from input to output, as > needed. http://ww1.microchip.com/downloads/en/DeviceDoc/41412F.pdf Seite 268 Werde in diesem Fall meine Code anpassen. Walter F. schrieb: > Aber ganz was anderes: > Ich bin sehr Hardwarenah und habe mit C (leider) nichts am Hut. Wir > suchen (gegen Bezahlung natürlich) jemanden der in C gut ist und eine > Seite C-Code mit Mathe drin in einen PIC32F26 Assemblercode (das dann > als Unterprogramm aufrufbar ist) umsetzt. Bei Microchip können in C-Projekte auch Assembler-Files hinzugefügt werden (mit dem richtigen Compiler). Geht dies evt. auch andersrum? Also ein C-File in einem Assembler-Projekt?
Walter F. schrieb: > Aber ganz was anderes: > > ......... Wir > > suchen (gegen Bezahlung natürlich) jemanden der in C gut ist und eine > > Seite C-Code mit Mathe drin in einen PIC32F26 Assemblercode (das dann > > als Unterprogramm aufrufbar ist) umsetzt......... > > Haste da Lust auf ein paar Mäuse? Nö danke, mache das nur als Hobby etc. PIC32 (komplett andere Architktur) Assembler ist ja ne ganz andere Nummer, das hat mit 8 und 16 Bit MICROCHIP Assembler nicht mehr viel gemeinsam - ausser das es auch Assembler ist. Ich bezweifle ob man "so nebenbei" 1 Seite C-Code mit Mathe in Assembler besser hinbekommt, als es ein Compiler kann. Und selbst wenn man noch einige Taktzyklen gegenüber einem optimierten C-Compilat rausschinden kann, stellt sich die Frage, ob das bei einer Schrittmotorsteuerung noch eine Rolle spielt (gut möchte mich da nicht zu weit aus dem Fenster lehnen weil ich mich mit Schrittmotoren noch nie beschäftigt habe ;-) )
Thread beobachten
Seitenaufteilung abschaltenBitte 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.