Hallo,
ich weiß, die Frage gabs hier schon öfter, aber irgendwie hab ich keine
Antworten erhalten.
Ich arbeite mit VMLab und programmiere in Assembler die serielle
Schnittstelle. Nun kann ich über VMLab Zeichen an die serielle
Schnittstelle schicken und mir anschauen was im Speicher abgelegt wird.
Nun wird bspw. für 'a' der Hexwert E1 abgelegt, für die Taste Return D8,
für 'x' der Wert F8 usw.
Nur leider finde ich die Werte so in der ASCII-Tabelle nicht wieder?
Gruß, JK
der AVR als solcher hat keinen Zeichensatz, der kennt nur Bytes.
String/char-Konstanten im AVR haben also den selben Zeichensatz, den
auch deine Source-Code Files hatten (ausser der Compiler/Assembler
konvertiert die, ist aber nicht üblich)
Die Zeichen die über die Serielle reinkommen, haben denselben
Zeichensatz den dein Terminal sendet.
Wenn dein Terminal also für "a" ein 0xE1 sendet, hat alles seine
Richtigkeit... Wobei ich mich dann nach einem anderen Terminal-Programm
umsehen würde...
Tippe eher darauf, dass dein UART das Zeichen nicht richtig liest.
Setz einfach das höchstwertige Bit auf "0", dann kommt
was sinnvolles raus. Frag mich aber nicht, warum bei
dir dieses Bit gesetzt ist :-)
Gruß Reinhard
wenn es seine Richtigkeit hat, warum soll ich mich dann nach einem neuen
Terminalprogramm umschauen? Und um welchen Zeichensatz handelt es sich
hierbei?
Blöderweise ist das Terminal in VMLab eingebaut und im AVR-Studio wüsste
ich nicht, wie ich die serielle Schnittstelle simulieren soll.
> wenn es seine Richtigkeit hat, warum soll ich mich dann nach einem neuen
Terminalprogramm umschauen?
Weil es zwar insofern "richtig" ist, dass der AVR genau das Byte
empfängt, das vom Terminal gesendet wurde, aber "falsch" ist weil das
Terminal zum senden einen obskuren Zeichensatz verwendet, der für die
Weiterverarbeitung im AVR ungeeignet ist.
Hallo JK,
> nein, das stimmt schon, der "Fehler" ist reproduzierbar.
wie Reinhard schon geschrieben hat, ist bei 'a' und 'x' der Wert
richtig, außer dass das höchste Bit gesetzt ist. Bist Du sicher, dass CR
als 0xd8 erkannt wird? Eventuell hast Du Dich in Deinem ersten Beitrag
verschrieben und meintest 0x8d für CR (?)-- dann wäre einfach konsistent
bit7 gesetzt.
Notiere Dir doch ein paar der empfangenen Hex-Werte mit den
dazugehörigen korrekten Codes und vergleiche die Bits, um den Fehler
einzugrenzen.
Viele Grüße
Fred
Stimmt, wenn ich das bit 7 lösche kommt rechnerisch das korrekte
ASCII-Zeichen heraus. Wenn ich Enter drücke wird tatsächlich 8D im
Speicher abgelegt.
Doch was bedeutet das jetzt? Wenn ich auf Enter abfrage wird das wohl
auf meinem AVR nicht funktionieren, weil der HexCode nicht stimmt.
Was wäre denn der richtige Code für die Enter-Taste?
pacer wrote:
> Stimmt, wenn ich das bit 7 lösche kommt rechnerisch das korrekte> ASCII-Zeichen heraus. Wenn ich Enter drücke wird tatsächlich 8D im> Speicher abgelegt.> Doch was bedeutet das jetzt? Wenn ich auf Enter abfrage wird das wohl> auf meinem AVR nicht funktionieren, weil der HexCode nicht stimmt.> Was wäre denn der richtige Code für die Enter-Taste?
0x0D
Also ohne gesetztes 7.Bit
Du musst jetzt herausfinden warum VMLAB bei dir immer
das 7. Bit setzt.
Hi
Kann es sein , dass VMLab die Com-Schnittstelle auf 7 Bit gestellt hat?
Dadurch würde der AVR das Stoppbit als Bit 7 interpretieren. Bei
ausreichend langen Pausen zwischen den Zeichen entsteht auch kein
Fehler.
MfG Spess
