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
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....
