Hallo zusammen, ich kappier da mal wieder was nicht! Ich habe nen Attiny45 mit Half-Duplex UART (von Nerd Ralph -> http://nerdralph.blogspot.de/2014/01/avr-half-duplex-software-uart.html?m=1) per RS232/USB-Converter an WinXP gehängt. Schaltung und Beispielcode habe ich, so wie im Blog, übernommen. Pin-Nummer habe ich in der "BasicSerial3.S" auf PB 4 gestellt. Hier mein Problem: Wenn ich mit 'serOut' einen Textstring ans Hyperterminal schicke, kommt dieser problemlos und korrekt an. Auch mit 'TxByte(97)' erscheint ein "a" im Terminal. Alles soweit OK. ABER: Wenn ich mit dem AVR mit RxByte() ein Zeichen lese, enthält die Variable nicht den, der Taste zugehörigen, ASCII-Code. Bei Tastendruck "f" steht in der gelesenen Variable '198', der ASCII-Code wäre aber '102'. Führe ich bei Tasteneingabe 'if(variable==198) TxByte(102);' aus, wird dann auch die korrekte Taste "f" angezeigt. Ich habe im Hyperterminal sämtliche Einstellungen durch. Im AVR das Fusebit CKDIV8 ist deaktiviert Baudrate ist für COM2 und im Hyperterminal auf 115200 Baud 81N eingestellt. Hatte auch schon vermutet, dass das Byte vom AVR 'falschrum' gelesen wird, aber auch das verdrehen der Bitfolge im Byte hats nicht gebracht! Und ja, das Tastaturlayout im WinXp ist auf 'Deutsch' eingestellt. Alle sonstigen Programme etc. nehmen die Eingaben korrekt an... Kann man da doch noch was umstellen? Hat da jemand nen Tipp für mich? Suchmaschine hat mir bisher nicht helfen können! Gruss Armin
Die Ausgabe aufs Terminal funktioniert ja einwandfrei! Nur die Tastatureingaben stimmen nicht und ich hab keine Ahnung wieso...
Armin R. schrieb: > Nein, mit internen 8MHz. keine gute Idee, miss doch mal die Taktfrequenz wenn du dir die Bitmuster deiner beiden Werte anschaust ist da einfach eine 0 eingeschoben, deutet sehr auf falschen Takt hin
Ok, stimmt. Müsste die Ausgabe vom AVR ins Hyperterminal dann aber nicht auch spinnen?!? Das Ergebnis in der Variable ist ja auch immer das gleiche. Geht das nur mit Quarz? Ich müsste nämlich alle übrigen Pins haben, also eigentlich kein Platz fürn Quarz...
reduziere doch einmal zu Testzwecken die Baudrate auf 9600.tritt der Fehler nicht mehr auf weisst du das es an dr Baudrate liegt
:
Bearbeitet durch User
Ah, ich Depp. Da hab ich tatsächlich nicht dran gedacht! Werde ich morgen Früh direkt mal machen und berichten...hab jetzt schon alles aus gemacht. Schonmal vielen Dank für die Tipps und erstmal Gute Nacht!
Armin R. schrieb: > Müsste die Ausgabe vom AVR ins Hyperterminal dann aber nicht auch > spinnen?!? nein, deine Sende/Empfangsroutinen sind ja nicht symetrisch, vor allem wird die Empfangsroutine einen Jitter haben > Das Ergebnis in der Variable ist ja auch immer das gleiche. > Geht das nur mit Quarz? Eigentlich ja, du bist da der tausendste der das erleben muss >Ich müsste nämlich alle übrigen Pins haben, also > eigentlich kein Platz fürn Quarz... Du kannst zum Einstellen die Bitbreite eines vom PC gesendeten Bytes messen und die Delays in deinen Routinen entsprechend anpassen wie es z.B. PeDa in seinem Bootloader macht
Man kann den internen RC-Taktgeber kalibrieren, so daß er in der Toleranz läuft. Mit einem Uhrensketch zu kontrollieren.
Ging leider doch erst Nachmittags... Habe mir ein paar Beiträge zu PeDas Bootloader mal angeschaut. Ist ja schon etwas umfangreicher! Hab mich dann mal an die Einstellungen in der "BasicSerial3.h" rangetraut, Zwecks Timingkorrektur. Erstmal hatte ich die Baudrate auf 9600 Baud gesetzt. AVR Studio bzw der Errortext in der "BasicSerial3.h" meinte aber, die Baudrate sei zu niedrig. Mit mindestens 38400 Baud gings dann, allerdings immer noch mit sporadischen Übertragungsfehlern. Die endgültig funktionierende Lösung steht auch in der "BasicSerial3.h"! Ich habe in der Definition von 'RXDELAY' den Wert '+1.5' auf '+2.5' erhöht, um das Empfangs-Delay zu erhöhen. Damit funkioniert die Übertragung sogar mit 115200 Baud tadellos! Also ist es tatsächlich, wie von euch direkt erkannt, ein Timingproblem gewesen. Vielen Dank für eure Tipps!
Nachtrag: Wenn ich TXDELAY auf '+3' und RXDELAY auf '+4' stelle, kann ich sogar auf 230400 Baud raufgehen.
Schön, nur läufts so auf einem anderen t45 oder mit Quarz vielleicht nicht mehr.
Das mag sein. Habe ja nur meine "Erfahrung" teilen wollen. Bei mir klappts jedenfalls so auf diesem Tiny. Kann heut Abend mal nen anderen T45 füttern und sehen wie der damit umgeht ;-)
So, hat zwar was länger gedauert, aber wie angedroht jetzt nochmal eine Erfahrung meinerseits: Hab jetztl noch 3 weitere Tiny45 mit dem Programm gefüttert und CKDIV8 deaktiviert. Läuft einwandfrei mit den internen 8Mhz und 230400Baud und den Delays RX+4 und TX+3. Kleinere Delays ergeben Fehler... Ein Mega32 läuft auch mit internen 8Mhz bei 230400 problemlos, CLKDIV8 natürlich deaktiviert. Allerdings kann ich da die Delays beide wieder auf den ursprünglichen +1,5 belassen :-) Gruss Armin
Armin R. schrieb: > Ein Mega32 läuft auch mit internen 8Mhz bei 230400 problemlos bei 5V und 20-25 Grad .. allen die das nachmachen wollen empfehle ich die Diagramme Calibrated 8 MHz RC Oscillator Frequency vs. Temperature sowie Calibrated 8 MHz RC Oscillator Frequency vs. Vcc zu beachten
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.