Hallo, ich versuche gerade Werte o.ä im Putty anzeigen zu lassen. Das Problem ist wenn ich "Hallo" schreiben will kommt der obere Balken, siehe Bild. Wenn ich 123 schreiben lassen will kommt das untere.. Wisst ihr wo der Fehler liegen könnte? http://gyazo.com/0b11463ae6aa7e560be972faacc26ff9 $baud = 9600 Print "123" Danke. Ps: das Kabel benutze ich http://www.amazon.de/gp/product/B00425S1H8/ref=oh_details_o09_s01_i00?ie=UTF8&psc=1 und das Pollin Board.
:
Bearbeitet durch User
zunächst einmal... du kannst bilder im post anhängen, wenige hier werden irgendwelche hoster besuchen in der hoffnung die sind schadfrei ! ;) zum anderen sehe ich nur ein bild, die rede war von zwei... oder täusche ich mich? und ich würde für serielle kommunikation auf ein terminal á la hyperterminal (oder wie die auch alle heißen) zurückgreifen... putty ist da glaube ich die etwas abgespeckte variante
Angehängte Dateien:
Ich meine oben im Putty den Balken und weiter unten das qrs. Ich hab bei Youtube schon gesehen das es mit dem Putty gehen muss....
Hi >Ich meine oben im Putty den Balken und weiter unten das qrs. >Ich hab bei Youtube schon gesehen das es mit dem Putty gehen muss.... Anscheinend stimmt etwas mit deiner Senderoutine nicht: Zeichen 1 2 3 -> q r s ASCII-Code 0x31 0x32 0x33 0x71 0x72 0x73 Bei 'Hallo' würden bei gleichem Offset von 0x40 Zeichen oberhalb von 0x7F entstehen -> nicht darstellbar. MfG Spess
Hi, und gibt es da eine Idee wie ich das richtig anzeigen lassen kann?
Das ist eigentlich nur ein Testprogramm... $regfile = "m8def.dat" $crystal = 1000000 $baud = 9600 Do Print "hallo" Waitms 500 Loop End
> $crystal = 1000000
Bei Verwendung des internen Taktgenerators ist das nicht ungewöhnlich,
dass die Baudrate nicht exakt eingehalten werden kann.
Allerdingsd vermisse ich ein CONFIG COM1 und aus der BASCOM Doku geht
nicht hervor, auf welche Defaults die UART dann eingestellt wird.
Allerdings deutet vieles darauf hin, dass dein Mega eben nicht mit 1Mhz
läuft, sondern vielleicht mit 900kHz, oder mit 1.1Mhz. Beim Mega8 ist
das alles noch sehr schwankend, weswegen da auch immer ein QUarz
empfohlen wird, der dann natürlich auch aktiviert und bei crystal
angegeben werden muss.
:
Bearbeitet durch User
ok, das versuch ich mal, ich stell ihn einfach mal auf den 8mhz um , ist ja auf dem board mit drauf. ich melde mich ob es was gebracht hat .
Pascal B. schrieb: > 0b11463ae6aa7e560be972faacc26ff9.png Ich liebe aussagekräftige Dateinamen. Nimm mal ein vernünftiges Diagnoseprogramm für die Serielle Schnittstelle. Das Zeugs was Putty da abliefert kann doch kein Mensch lesen - passt zum Dateinamen. Mit HTerm z.B. könntest du dir direkt angucken, was da für Binärdaten übertragen werden. Putty ist ein Terminalemulator, der alle möglichen Steuersequenzen interpretiert. Das willst du gerade nicht, wenn du analysieren möchtest, was da auf der Schnittstelle los ist bzw. schief geht.
Perfekt , Ihr seid die Besten. Es war tatsächlich am Quarz gelegen. Mit den 16Mhz gehts wie gewollt. Die Frage am Rande ist allerdings ob es mit dem internen generell nicht geht? Danke euch !
Pascal B. schrieb: > Die Frage am Rande ist allerdings ob es mit dem internen generell nicht > geht? Es funktioniert auch mit dem internen. Verschiedene Geschwindigkeiten ausprobieren. 4800baud geht fast immer. Der interne Oszillator läßt sich auch mit dem OCCCAL Register nachstellen.
Lukas schrieb: > Verschiedene Geschwindigkeiten ausprobieren. 4800baud geht fast immer. Um diese Aussage auf eine theoretische Basis zu stellen, wäre die Antwort auf die Frage interessant, was einen Baudratenfehler von z.B. 5% bei 4800Bd von einem Fehler von 5% bei 19200Bd unterscheidet, wenn die Signale ansonsten sauber über die Leitung gehen.
Mike schrieb: > Lukas schrieb: >> Verschiedene Geschwindigkeiten ausprobieren. 4800baud geht fast immer. > > Um diese Aussage auf eine theoretische Basis zu stellen, wäre die > Antwort auf die Frage interessant, was einen Baudratenfehler von z.B. 5% > bei 4800Bd von einem Fehler von 5% bei 19200Bd unterscheidet, wenn die > Signale ansonsten sauber über die Leitung gehen. Die Frage ist weniger wissenschaftlich zu lösen als besser die Antwort in BASCOM zu suchen. "$baud = 9600" Durch diese Zeile wird USART initialisiert. Anscheinend ohne das UC2X Bit zu berücksichtigen (BASCOM V2.0.7.5). Bei 1MHz Oszillatortakt ergibt sich dadurch ein Baudratenfehler von 7%. Bei $baud=4800 nur noch ein Fehler von 0,2%. Bei 8MHz Systemtakt und 9200 Baud liegt der Fehler dann auch nur bei 0,2%. Der Baudratenfehler ist im Compilerreport von BASCOM aufgeführt. Bei 8MHz Oszillatorfrequenz sollten 19200 Baud oder 4800 Baud kein Problem sein. Bei 1MHz ist der Fehler bei 19200 Baud auch 7%. Im Datenblatt zum Mega8 "Examples of Baud Rate Setting" gibt es weitere Infos zur Beziehung zwischen Baudrate und Systemtakt.
Lukas schrieb: > ohne das UC2X Bit zu berücksichtigen (BASCOM V2.0.7.5). Bei 1MHz Sorry, sollte U2X Bit heißen.
Lukas schrieb: > Bei 8MHz Systemtakt und 9200 Baud liegt der Fehler dann auch nur bei > 0,2%. Du missverstehst da etwas. die angegebenen 0.2% Fehler entstehen deshalb, weil man mit 8Mhz die angegebenen 9600 Baud nicht exakt erreichen kann, weil es keinen entsprechenden ganzzahligen Teiler gibt. Aber Voraussetzung dafür ist, dass die 8Mhz auch wirklich 8Mhz sind. Hier geht es aber um etwas anderes. Hier geht es darum, dass die 8Mhz eben nicht 8Mhz sind, sondern ein wenig kleiner bzw. größer, je nachdem wie der RC-Schwingkreis im IC gerade drauf ist. Weicht der Schwingkreis um 6% von den 8Mhz ab, dann tut er das bei ALLEN Baudraten! 6% sind 6%, egal welchen kleineren Takt du davon ableitest (und was anderes tut man ja nicht, bei der Einstellung der Baudrate) > Bei 8MHz Oszillatorfrequenz sollten 19200 Baud oder 4800 Baud kein > Problem sein. Bei 1MHz ist der Fehler bei 19200 Baud auch 7%. Du redest von etwas ganz anderem bzw. gehst von ganz anderen Voraussetzungen aus. Du setzt voraus, dass die Taktfrequenz auch tatsächlich die ist, die draufsteht. Das ist aber bei einem Mega8 bei Benutzung des internen Taktgebers (der entgegen landläufiger Meinung eben KEIN Quarz ist, sondern ein RC-Schwingkreis) aber nicht so. Gerade die älteren AVR weichen da schon mal kräftig davon ab und halten die Frequenz auch nicht besonders gut. Man kann da mit dem OSCCAL Register gegensteuern, braucht dann aber im Sommer andere Korrekturwerte wie im Winter, weil das ganze temperaturabhängig ist.
:
Bearbeitet durch User
Karl Heinz schrieb: > Lukas schrieb: > >> Bei 8MHz Systemtakt und 9200 Baud liegt der Fehler dann auch nur bei >> 0,2%. > > Du missverstehst da etwas. > die angegebenen 0.2% Fehler entstehen deshalb, weil man mit 8Mhz die > angegebenen 9600 Baud nicht exakt erreichen kann, weil es keinen > entsprechenden ganzzahligen Teiler gibt. > Aber Voraussetzung dafür ist, dass die 8Mhz auch wirklich 8Mhz sind. Nein, kein Mißverständnis. War und ist mir schon klar. > Hier geht es aber um etwas anderes. Hier geht es darum, dass die 8Mhz > eben nicht 8Mhz sind, sondern ein wenig kleiner bzw. größer, je nachdem > wie der RC-Schwingkreis im IC gerade drauf ist. > Weicht der Schwingkreis um 6% von den 8Mhz ab, dann tut er das bei ALLEN > Baudraten! 6% sind 6%, egal welchen kleineren Takt du davon ableitest > (und was anderes tut man ja nicht, bei der Einstellung der Baudrate) Dadurch kann der abweichende RC-Oszillator bei unterschiedlichen Baudraten mit ihren unterschiedlichen Fehlerraten bei Nennfrequenz den Fehler ausgleichen, bei anderen vergrößern. Hab da vorher nicht auf den Punkt geantwortet :( >> Bei 8MHz Oszillatorfrequenz sollten 19200 Baud oder 4800 Baud kein >> Problem sein. Bei 1MHz ist der Fehler bei 19200 Baud auch 7%. > > Du redest von etwas ganz anderem bzw. gehst von ganz anderen > Voraussetzungen aus. Du setzt voraus, dass die Taktfrequenz auch > tatsächlich die ist, die draufsteht. Nicht unbedingt. Hab das nur nicht weit genug erläutert. Wenn für 8MHz Systemtakt verschiedene Baudraten eingestellt werden, gibt es verschiedene systembedingte Baudfehlerraten. Weichen die 8MHz von ihrer Sollfrequenz ab, verkleinert sich der Baudratenfehler zu der einen Baudrate. Gleichzeitig könnte eine andere Baudrate gar nicht mehr funktionieren. Ich möchte das gar nicht im einzelnen Ausrechnen - deshalb war mein Vorschlag, das auszuprobieren, was geht. Das BASCOM ausgerechnet bei 1MHz und 9600 Baud eine mangelhafte Konfiguration verwendet, war Pech für den TO. Immerhin wird der große Bauderror im Compilerreport angezeigt. > Das ist aber bei einem Mega8 bei Benutzung des internen Taktgebers (der > entgegen landläufiger Meinung eben KEIN Quarz ist, sondern ein > RC-Schwingkreis) aber nicht so. Gerade die älteren AVR weichen da schon > mal kräftig davon ab und halten die Frequenz auch nicht besonders gut. > Man kann da mit dem OSCCAL Register gegensteuern, braucht dann aber im > Sommer andere Korrekturwerte wie im Winter, weil das ganze > temperaturabhängig ist. Ja, keine Frage, daß der interne Oszillator driftet. Auch unstabilisierte Versorgungsspannung von zB direkt versorgenden Batterien können einem plötzlich Rätsel aufgeben. Ich bin ja auch für einen stabilen Takt. Bei einer Schaltung, die aber sonst keinen Quarz benötigt und um schnell ein paar Debuginfos ausgeben zu lassen, würd ich immer wieder versuchen, den internen zu verwenden. Die guten Erfahrungen haben bei weitem überwogen. (dies ist nur die Meinung des Authors und erhebt keinen Anspruch auf Allgemeingültigkeit :)
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.