Hi! Also ich hab um ein Byte zu senden den UART auf 19200 Baud gestellt und mal gemessen wie lang es dauert: 2 ms. Sende ich ein Word dauert es 4 ms. Kommt also auf etwa 4000 Bit pro Sekunde. Warum ist das so langsam und was kann ich dagegen tun? Die eingestellte Datenrate verspricht doch das Fünffache! Und selbst mit 9600 wäre es noch mehr als das Doppelte. Ich verwende Bascom und der restliche Code dauert nur 100 us. MvG Julia
Richtige Taktquelle gewählt? Externer Quarz oder interner Oszillator (-> default!!)? Welchen Takt benutzt Du? Baudraten-Register richtig gesetzt? Auf welchen Wert hast Du eingestellt?
Wie misst Du? Verwendest Du die Hardware-UART oder die Software-Emulation, die BASCOM anbietet? Mal ein Oszilloskop an die TxD-Leitung gehängt, sind Pausen zwischen den einzelnen Bytes zu sehen? Könntest Du Deinen Quellcode posten?
Ein Byte dauert (1/19200)*10 Sekunden.. 1 Startbit und 1 Stopbit. Mich würde auch interessieren, WIE du misst.. Wer misst, der misst Mist :) dave
Lassen wir sie erstmal antworten.. ;) bevor wir mit dem Mist weiter machen G dave
Also mit dem Oszilloskop in die TxD reingeschnuppert ergibt ein sehr seltsames Muster welches sich nicht wiederholt aus einzelnen Bits und Pausen/mehreren Bits mit dem gleichen Wert dazwischen. Scheint sich aber nicht richtig zu wiederholen obwohl jedes Byte auf &B01010101 gesetzt ist. Jedes einzelne Bit ist 0,05 ms also 19200 kommen auch raus. Quellcode kann ich nicht posten weil der auf dem Notebook ist und ich meinen USB Key versaut habe. (Wilde Silvesterparty...) Er bersteht aber zu Testzwecken aus in etwa: Do Portd.4 = 1 'Zur Kontrolle wie lang ein Zyklus dauert, daher meine waitus 10 'Angaben Portd.4 = 0 M = &B01010101 ' M isn Byte Print M Loop
Angehängte Dateien:
-
TXD.gif
3,4 KB
Hi hier ist was über die TxD Leitung fließt, wenn ich eine Pause einlege. Wenn ich den AVR nicht warten lasse folgt exakt die gleiche Sequenz ohne Abstand über die komplette Sendedauer. Dauert also für das Byte 01010101 insgesamt 2 ms (die Länge der Pulssequenz im Bild) Viele Grüße, Julia
bekommst du denn die daten sauber uebertragen?? wenn nicht such mal die einstellung, die passt
Das Oszillogramm scheint die Übertragung mehrerer Bytes darzustellen, sieht aber sehr seltsam aus. Statt Portd.4 auf 1 zu setzen, 10 µs zu warten und dann Portd.4 wieder auf 0 zu setzen, könntest Du ja vor jedem Print (also vor jedem Senden eines Bytes) den Zustand von Portd.1 invertieren. Wenn das so erhaltene Ausgangssignal auch noch in Deinem Oszillogramm auftauchen würde ... Eine Zeitachse o.ä. wäre auch hilfreich.
Also die Dten werden einwandfrei übertragen nur halt zu langsam. Aber auf das Oszillogramm kann ich mir auch keinen Reim machen. Wie gesagt, das ist nur ein ganz simples Oszi und die Grafik ist matlab. Wie gesagt, der pulsetrain ist 2 ms lang, ein einzelnes Bit 0,2 ms und es wird exakt die im Bild gepostete Zeichenfolge immer und immer wiederholt, der invertierende spike liegt genau zwischen zwei bits. Leider kann ich schlecht noch ein Bild posten bis der Kamerakku wieder voll ist (wie bereits erwähnt, der USB Key ist ner Party zum Opfer gefallen). Ich kann in dem Oszigramm absolut nicht die einzelnen Elemnte von 19200 8 Datenbits ein Stoppbit und keine Parität erkennen. Viele Grüße, Julia
Oh, der invertierte Spike liegt zwischen zwei "Bytes" also zwischen exakt zwei von den Pulsetrains wie im Bild
Genau, das ist ja das setsame, denn dass sieht mir so gar nicht wie ein "Byte" aus. Was könnte das sein? Viele Grüße, Julia
Hi, ich hab den Printbin Befehl ausprobiert, und der funktioniert anscheinend für ein Byte ganz gut, auch wenn ich mir da nicht so ganz sicher bin ob da evtl. der invertierte Wert ankommt, aber für ein Single, Integer oder Word geht es nicht. Und wenn ich zwei Bytes nacheinander sende geht auch nur noch Mist durch die Leitung. Wie kann es sein dass Printbin schneller als Print ist???
Print liefert nicht ein Byte, sondern mehrere - nämlich die ASCII-Repräsentation des (dezimal-)Wertes. Deren Länge ist vom Wert abhängig. Ist der Wert beispielsweise (dezimal) 65, dann liefert Print zwei Bytes an der seriellen Schnittstelle ab, nämlich 0x36 und 0x35, '6' und '5'. Bei (dezimal) 204 sind's bereits drei Bytes (0x32, 0x30 und 0x34, halt '2', '0' und '4'. Steht hinter dem Variablennamen kein Semikolon, so wird noch ein Zeilenvorschub angehängt, was ein oder zwei weitere Bytes (0x0d und eventuell 0x0a) zur Folge hat. Damit gibt Dim a As Byte A = 65 Print A deutlich mehr als nur ein Byte an der seriellen Schnittstelle aus, nämlich den String 0x36, 0x35, 0x0d (0x0a). Printbin gibt hingegen eine definierte Anzahl an Bytes, die vom Typ der Variablen abhängt; ein Byte resultiert in einem Byte, ein Integer resultiert in zwei Bytes und ein Long resultiert in vier Bytes. (Das ist in der BASCOM-Dokumentation beschrieben) Das dürfte das Phänomen klären - und darauf hinweisen, daß irgendwas mit der Baudrate der seriellen Schnittstelle überhaupt nicht stimmt. Vermutlich läuft der Controller mit einer anderen Taktfrequenz als angenommen.
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.