Hallo Gemeinde, ich stehe auf dem Schlauch. Nun will ich wieder mal ein wenig mit meinen PIC's was machen und habe Probleme. Ich möchte über den PIC über RS232 ein paar Daten an einen PC senden. PIC 16F690, 8 MHz, MPLAB Über #use habe ich die Async-Schnittstelle auf 9600 Baud eingestellt und die Pins definiert. Im Test-Programm sende ich über printf(); eine (1) int8 Variable. Im Debugger messe ich über die Stoppuhr eine Dauer von über 4 ms!!!! für die Übertragung. Das kann doch nicht sein, oder? Das muss doch selbst bei 9600 Baud schneller gehen....... Im echten Programm muss ich 3 Variablen senden und habe dafür weniger als 1 ms Zeit. Wenn ich die Baudrate auf 115200 setze, wird die Übertragung nicht schneller..... Wo liegt mein Fehler??? Ich stehen auf dem Schlauch... Danke für Eure Hilfe. Gruß Uwe
>Wenn ich die Baudrate auf 115200 setze, wird die Übertragung nicht >schneller..... Wo liegt mein Fehler??? Ich stehen auf dem Schlauch Da ist sicher was falsch....aber solange wir Deine Initialisierung nicht sehen und Du uns nur SAGST DU habest die Pins definiert......schwierig zu finden. Poly Oschi hat recht: Zuerst sicherstellen, dass Du mit der richtigen Taktfrequenz arbeitest! Dann sicherstellen, dass die Pins richtig fdefiniert sind Dann sicherstellen, dass die UART richtig initialisiert ist. Wenn DU das Teil im Emulator laufen laesst, kannst Du das mit der Taktfrequenz prima feststellen und genau sehen, was passiert. Ist das Protokoll ansonsten in Ordnung? Gruss Michael
Hallo, den Takt habe ich nicht nachgemessen, bin aber sicher, das er passt. Habe ich mit den Oscillator Befehl auf 8 MHz eingestellt und in einer anderen Anwendung läuft das auch. Die Pins sind korrekt, zumal der 690er nur 1 Pärchen (RB5 + RB7) hat. Ich hatte zuerst keine Pins definiert, da ging gar nichts. Analogpins sind nicht konfoguriert. Bin momentan im Urlaub, kann daher nichts messen. Ich vermute mal, das mit der Einstellung der UART etwas nicht stimmt, aber ich habe keine Erfahrung damit. Wenn ich mir die Register anschaue, ist da erstmal nichts Verdächtiges zu sehen. Ach so, ich programmiere in C. Das, was ich im Output-Fenster sehen kann, ist OK. Bis das erste Zeichen im Fenster auftaucht, sind schon 2 ms rum. Hat nicht jemand von euch mal ein Codeschnipsel für mich? Gruß Uwe
Uwe schrieb: > Im Test-Programm sende ich über printf(); eine (1) int8 Variable. Hallo, wenn du die als Text sendest, sind das je nach Zahl 3 ASCII-Zeichen, und die brauchen bei 9600 Baud mehr als 3 ms - was soll daran überraschend sein? Ein Oszi wirkt bei solchen Rätseln oft Wunder. Gruss Reinhard
Hallo Reinhard, > wenn du die als Text sendest, sind das je nach Zahl 3 ASCII-Zeichen, und > die brauchen bei 9600 Baud mehr als 3 ms - was soll daran überraschend > sein? Daran habe ich mich garnicht aufgehalten....was mich stutziger macht ist: > Wenn ich die Baudrate auf 115200 setze, wird die Übertragung nicht > schneller..... > Ein Oszi wirkt bei solchen Rätseln oft Wunder. Na ja....ich habe das so verstanden, dass bisher noch keine HW laeuft.....nur der Simulator, und da misst auch kein Oszilloskop was. Gruss Michael
1 | // USART Setup |
2 | #ifdef __DEBUG |
3 | SPBRG = 10; // 115.2k baud (-1.36% error) |
4 | TXSTA = 0b10100100; // High speed, 8bit, transmitter enabled |
5 | RCSTA = 0b10000000; // Enable module, receiver disabled |
6 | #endif |
Läuft bei mir prima (mit 20MHz, müsstest also das SPBRG anhand des Datenblattes setzen, aber da kannst du den Wert herauslesen. Achja, ich verwende nur TX zum Debuggen). Alleine die Übertragung dauert >3ms, wie schon erwähtn wurde. Wie sendest du die Daten? putch oder printf? Printf ist eine sehr Zeitaufwändige Funktion, die dir eventuell als Bremsklotz dient...kannst ja im Simulator ausmessen... MFG Patrick
@Reinhard. > wenn du die als Text sendest, sind das je nach Zahl 3 ASCII-Zeichen, und > > die brauchen bei 9600 Baud mehr als 3 ms - was soll daran überraschend > > sein? Ja, das kann sein. Ich habe mit der seriellen Übertragung noch keine Erfahrungen und kann die 4 ms für eine 3-stellige Zahl nicht einsortieren. Da fehlt mir einfach noch das Licht am Fahrrad. @Patrick Danke für die Konfig. Ich werde das mal probieren und auf meine Gegebenheiten (8MHz) übertragen. Welche Möglichkeiten, eine Zahl zu übertragen, außer über printf() gibt es denn noch? Ich meine gelesen zu haben, putc() bzw. puts() soll da nicht besser (Speed) sein? Gruß von einem Unwissenden Uwe
Hallo, ich habe jetzt mal die ganze UART von Hand konfiguriert. Und siehe da, es funktioniert wie es soll. Wenn ich die manuelle Einstellung wieder auskommentiere ist alles wieder langsam. Ich sende über printf(); ein 'a' und in einer 2. Funktion die Zahl 10000. Bei der "alten" Einstellung braucht mein System 1,22 ms für das 'a' und 3,67ms für die Zahl. Bei der manuellen Einstellung 304 µs und 920 µs. Ich habe die Register RCSTA, TXSTA und das Baudregister in beiden Fällen verglichen. Der Unterschied ist nur, das in der automatischen Konfig das Empfangsregister dauernd eingeschaltet ist. Wenn ich dies manuell auch herstelle, kann ich das Phänomen nicht herstellen, bleibt also schnell. Schon komisch. Die Einstellung auf 115200 Baud passt in beiden Fällen, das SPBG Register steht auf den selben Wert SPBG = 16, SPBGH=0. Die Schnittstelle ist aber um den Faktor 4 langsamer. Kann mir das jemand erklären? Gruß Uwe
scheinbar benutzt du den CCS Compiler diese ganzen Geschichten wie #use sind der größte Müll, deswegen gibts bei denen auch alle paar Wochen ein update mach die Einstellungen "per Hand", dann weißt du auch was passiert
ttl schrieb: > scheinbar benutzt du den CCS Compiler > diese ganzen Geschichten wie #use sind der größte Müll, deswegen gibts > bei denen auch alle paar Wochen ein update > mach die Einstellungen "per Hand", dann weißt du auch was passiert Hallo, ja, du hast recht, ich benutze den CCS. Den Verdacht hatte ich auch schon, aber da die TXSTA, RCSTA und BAUDCTL Register quasi identisch gesetzt wurden, hatte ich das erst mal verworfen.... Nun denn, ich werde das die kommende Woche mal im "echten Leben" testen. Bin schon gespannt. Gruß Uwe
Hallo, ich schon wieder. Habe das Testprogramm gerade in den PIC geladen und getestet. Einstellung der UART auf 115200 BAUD. Zur Übertragung von einem 'b' werden 164µs und für die Zahl 10000 504µs benötigt, jeweils mit dem Oszi gemessen von erster fallenden bis letzter steigenden Flanke des Datenpakets. Wenn ich die automatisch konfigurierten Parameter vom CCS nehme, ist es das gleiche. Dann scheint es wohl am MPLAB zu liegen, das da wohl durcheinander kommt :-) Hat noch jemand eine andere Erklärung dafür? Sind die gemessenen Zeiten zu den Daten passend für eine 115200er Konfiguration? Gruß Uwe
Das kannst du ja selber ausrechnen: Die "normale" RS232 Einstellung hat folgendes Protokoll START-Bit|Byte|(Parity-Bit)|STOP-Bit Das heisst, dass bei 115200 Baud soviele Bits (10 oder 11) übertragen werden. macht am Schluss mit meinen Einstellungen: 1/(115200 / 10) = ~86us für 1 Byte Der Rest kommt von der Printf-Funktion oder anderen Ausgabe-Funktionen. Dass das einzelne Zeichen 'a' weniger lang hat, als die Zahl 10000 ist logisch, da die Zahl in 5 einzelne Zeichen zerlegt wird. In ASCI gibt es nur die Zahlen 0 bis 9.
Uwe K. schrieb: > Habe das Testprogramm gerade in den PIC geladen und getestet. > .... Dann scheint es wohl am MPLAB zu liegen, das da wohl Hallo, dann hast du 4 Tage damit verbracht, einen Simulator-Bug zu finden... Traurig. Kann aber passieren, auch Profis. Gruss Reinhard
Hallo Patrick, dein Rechenweg macht Sinn, kann ich nachvollziehen. Vielen Dank dafür. @Reinhard Ja, so scheint es wohl zu sein. Mal ist man der Hund, mal der Baum......... Gruß Uwe, der jetzt erst mal wieder weiterkommt....
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.