Hi. Ich habe ein Programm geschrieben, welches ein ASCII-Zeichen mittels der USART-Routine von Peter Fleury empfängt und als Hex-Zahl auf einem Display ausgibt. Zudem sendet es empfangene Zeichen als Echo zurück. Das komische ist nun, dass es das Zeichen zwar korrekt an HyperTerminal zurücksendet, aber auf dem Display nur bis 127 (0x7F)[⌂] korrekt anzeigt, bei 128 (0x80)[Ç] zeigt es 199 (0xC7)[Ã] an, bei 129 (0x81)[ü] erscheint 252 (0xFC)[³] - darüber ist auch alles falsch. Hier ein Screenshot wie ich Hyperterminal eingestellt habe. Hat jemand von euch eine Idee woran das liegen könnte? Vielen Dank, Felix
Könnt mir bitte jemand sagen was ich denn falsch mache, dass mir außerhalb der Codesammlung nie jemand antwortet?
Kann dein Display vieleicht nur Zahlen bis 127 anzeigen? Vieleicht Code/Verwendete Hardware mal posten vielicht weiß dann jemand mehr.
@felix: vermutlich sagst du gleich "hab ich shcon 10fach gemacht" .... aber trotzdem :-) kontrolliert mal gaaaanz genau den Pegelwandler (verm. Max232) inkl. der Aussenbeschaltung, Masse, etc... Ich hab auch schon öfter solche komischen Phänomene mit der rs232 gehabt wenns mal schnell gehen sollte... war stets ne vergessene Masse oder nen anderer Fehler in der Hardware greetz Danny
Danke, ja hab ich gemacht, mir ist aufgefallen, dass es 9,9 V statt 12 liefert, aber das dürfte eigentlich kein Problem sein. Das echo stimmt ja auch, irgendwie muss der µC das Bit 7 versauen, aber richtig wieder zurückgeben. Mein Display ist ein HD44780 kompatibles LCD, Umwandlung nach Ascii mach ich folgendermaßen: char buffer[9]; //Ausgabebuffer deklarieren unsigned int c = uart_getc(); itoa(c,buffer,10); lcd_writetext (buffer); Liegt dort irgendwo der Fehler oder im 8-Bit Modus der RS232-Schnittstelle? Danke, Felix
Vorsicht mit Hypterterm, da gibt es noch einige weitere Einstellungen wie Terminalemulation und Charset! Teste auch mal ein anderes PC-Programm.
Ich kenne leider die Lib von P.Fleury nicht, deshalb die Frage: Welcher Rückgabetyp ist denn bei uart_getc() definiert? unsigned int scheint mir für einen 8-Bit Wert Verschwendung, evtl. fehlt auch einfach nur ein type-cast.
Kann es sein, dass dein Display einen anderen Zeichensatz verwendet als das Hyperterminal? Schau mal ins Datenblatt und kontrolliere das bitte. MFG Kai
@Profi: Ja, da habe ich mir auch schon Gedanken gemacht. Habe aber alle Einstellungen auf Standard. @thkais: In der uart.h steht: extern unsigned int uart_getc(void); Im low Byte gibt es das zuletzt empfangene Byte vom Ringpuffer zurück und im High-Byte den letzten Empfangsfehler. @kai: Ja, das kann scho sein. Allerdings gebe ich das Zeichen nicht als ASCII-Zeichen aus sondern als Nummer. Die Konvertiereung erledigt itoa(); Zum Eingeben verwende ich dann halt bspw. ALT+129. Somit kann ich die Steuerbefehle viel einfacher halten. Was Ich damit bezwecken will, ist dass ein anderer µC Befehle sendet und er einfach mit einer switch(); Anweisung nachschaut, was er bei dieser Nummer tun soll. Display und Hyperterminal dienen momentan nur zum debug während der Entwicklung. Vielen Dank euch allen, Felix
@Felix und auch alle anderen, die sich über derartige Effekte wundern: Hyperterminal vergessen und sich HTerm ziehen: http://www.der-hammer.info/terminal/index.htm Screenshot: http://www.der-hammer.info/terminal/bilder/term_large.png Da kann man sicher sein, wenn es klemmt, liegt es mit Sicherheit nicht am Terminalprogramm. Gruss Jadeclaw.
Danke für den Tipp! Damit gehts. Ich denke der Grund ist, dass man zwar mit ALT+XYZ den ASCII Code eingibt, aber Hyperterminal das jeweilige Zeichen als ANSI schickt, d.h. Code deckt sich nur in den ersten 128 Zeichen. Das kann man aber auch umstellen, werde ich vielleicht später mal versuchen. Nochmals Vielen Dank euch allen! Felix
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.