Davon abgesehen, dass diese Newsgruppe deutschsprachig ist und aus deiner Beschreibung das Problem nicht einmal richtig hervorgeht, das du hast: bitte keine (unmarkierten) Crossposts. Du hast hier:
formatting link
auf ein identisches Posting bereits Antworten bekommen.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Tja, das ist mir glatt durch die Lappen gegangen. Bin sonst nur in englischsprachigen Newsgroups unterwegs. Ich bitte um Nachsicht.
Nun - da bitte ich um Entschuldigung und Verständnis. Ich habe - wie das sonst überall guter Stil ist - nicht nur ein Problem beschrieben und um (kostenlose) Antwort gebeten, sondern gezeigt, dass ich doch tatsächlich Code geschrieben habe, der das Problem hat. Und ich habe - das sollte Dir als AVR Guru allerdings bei sorgfältigem Lesen durchaus ersichtlich sein - das Problem so beschrieben, wie es sich mir darstellt.
So, nun mal Tacheles. Ich habe keine unmaskierten Crossposts vorgenommen, weil dies technisch gar nicht möglich ist zwischen avrfreaks und dieser NG. Ich habe lediglich verschiedene, sehr unterschiedliche Foren besucht und dort eine Frage gestellt. Dass ich einen fast identischen Text benutzt habe - nun, ... was soll's?
Und ich möchte Dir für Deine Antworten und Tipps auf avrfreaks danken. Die waren sehr hilfreich. Dieses Posting ( oh, shit, ... diese "Nachricht") hier nicht ;-)
Wie ich bei solchen Nachrichtenaustauschen immer zu sagen pflege: "Du weisst nicht, was ein Killfile ist?" -
So, nun zurück zum technischen Problem auf Deutsch:
AVR ATmega16 mit 8,000 MHz Quarz LCD 4 bit Modus RS232C über UART und MAX232 RS232 ist über Prolific RS232C-USB Adapter an Mac mit OS X 10.4.9
Ich möchte den ATmega16 für einen Test als "Terminal" betreiben. D.h. über RS232C ein Zeichen lesen, dieses auf LCD anzeigen und über die serielle Schnittstelle zurück an den Mac senden.
Ich mußte dazu die Zeichen in drei Arten von "Codes" aufteilen, damit ich überhaupt etwas vernünftiges angezeigt bekommen:
Scan Codes (= das, was ich per UDR Lesezugriff von der seriellen Schnittstelle als "Tasten Code" / Scan Code erhalte)
LCD Character Code (= derjenige Wert, der an das LCD gesendet werden muss, damit das dem Tastendruck entsprechende Zeichen auf dem LCD erscheint)
Code, der auf der seriellen Schnittstelle gesendet werden muss, damit auf dem Terminalprogramm (ZTerm) auf dem Mac das dem Tastendruck entsprechende Zeichen erscheint.
Da ich keinen auch nur annähernd diese Dreiteilung berücksichtigenden Code im WWW gefunden habe, habe ich nun nachgefragt, wo mein Problem liegt - zumal ich bisher keinen Erfolg bei der Darstellung der Zeichen in ZTerm auf dem Mac gehabt habe - das ist nach wie vor der Stand.
Ich muss allerdings erst noch die restlichen Posts hier lesen...
Mit 8MHZ bekommst du keine 115200 baud hin. denn 8000000/8/115200=8.6805555556 Das heißt du bist sehr weit von einem brauchbaren geraden Teilungsfaktor weg.
Entweder du benutzt eine ungerade Taktfrequenz wie 8*115200*8=7372800 MHZ oder 10*115200*8=945600MHZ oder gehst mit der Baudrate soweit runter bis du einen ordentlichen Teilungsfaktor erreichst. z.b. 38400 Baud mit 26.041666667 als Teilungsfaktor.
Z.B. in der Nomenklatur. Es gibt keine "Scan-Codes" bei einer RS232-Übertragung. Das Terminalprogramm auf der Senderseite bzw. die darunterliegenden Teile des Betriebssystems wandeln die Scan-Codes der Tastatur in einen bestimmten Zeichensatz und das Terminalprogramm sendet das Ergebnis dieser Wandlung und nicht etwa die Scan-Codes der Tasten. Welcher Zeicehnsatz verwendet wird, stellt man bei Terminalprogrammen typischerweise über die Wahl der Terminalemulation ein.
Im Terminalprogramm geschieht noch eine zweite Wandlung bei der Darstellung eingehender Zeichen. Es wählt für das Zeichen den jeweils passenden Glyphen des für die Anzeige verfügbaren Zeichensatz aus. Damit das korrekt funktioniert, muß natürlich ein Zeichensatz mit einer passenden Codierung verwendet werden.
Ob die bisher beschriebenen Sachen korrekt funktionieren, kannst du einfach austesten, indem du die "local echo" Funktion des Terminalprogramms aktivierst. Wenn damit für jede Taste das erwartete Zeichen auf dem Bildschirm erscheint, dann passt soweit erstmal alles.
Und dein Problem reduziert sich maximal auf die Codewandlung für das LCD. D.h. das Echo über RS232 sollte bereits funktionieren. Tut es das nicht, passen die Schnittstellenparameter nicht. Wie andere im Thread dir schon mitgeteilt haben, ist 115200 bei einem 8MHz-Quartz eine ungeeignete Bitrate. Selbst bei optimaler Einstellung des Atmel (die du nicht vorgenommen hast) liegst du gut drei Prozent neben der Sollbitrate. Diese Abweichung ist meist zu groß, um eine zuverlässige Kommunikation zu erzielen. Für hohe Geschwindigkeiten auf der seriellen Schnittstelle gibt es Quartze mit geeigneten "unrunden" Frequenzen, z.B.
7,3728 oder 14,7456 MHz.
Zum Schluß noch das Problem des LCD-Zeichensatzes. Die meisten Text-LCDs bilden wenigstens den Bereich der "druckbaren" Zeichen des
7Bit-US-ASCII-Zeichensatzes (Codes 32..126) 1:1 ab. Netterweise tuen das auch so ziemlich alle bekannten Terminalemulationen. D.h., wenn du nicht gerade Umlaute oder ß verwenden willst/mußt, sollte schon alles erledigt sein. Falls doch, mußt du dir halt aus dem Zeichensatz der Terminalemulation und dem Zeichensatz des LCD die Schnittmenge der in beiden enthaltenen Zeichen raussuchen und im Atmel eine entsprechende Wandlungstabelle und Wandlungsroutine unterbringen. Die nicht in der Schnittmenge enthaltenen Zeichen des Terminalzeichensatzes kannst du dabei entweder auf ein Platzhalterzeichen umbiegen oder statt dessen auf ähnliche oder auch völlig andere Zeichen des LCD-Zeichensatze mappen. Obwohl informationstheoretisch die erste Variante "richtiger" ist, wird man I.d.R. die zweite Variante wählen, um den Zugriff auf diese Zeichen von außen weiterhin zu ermöglichen.
.=2E.was kein Wunder ist, da es diese Dreiteilung nicht gibt: Es handelt sich in allen drei F=E4llen um sog. ASCII- Zeichen. Der Wert 0x41 wird im ASCII-Zeichensatz immer als "A" dargestellt. Nur mit Umlauten und Sonderzeichen gibt es einige Verwirrungen (siehe Wikipedia unter "ASCII").
Unter "Scan Code" versteht man in allgemeinen die Codes, welche von einer Tastatur an einen PC (oder MAC) gesendet werden, wenn eine Taste gedr=FCckt wird. Wenn ich Dich richtig verstanden habe, h=E4ngt die Tastaur am MAC und der MAC sendet =FCber RS232 ASCII- Zeichen an den ATmega16, oder?
Wenn ich Deine nicht sehr konkrete Fehlerbeschreibung richtig verstehe: bekommst Du etwas auf dem Display angezeigt, wenn Du Zeichen zum ATmega sendest? Nur das zur=FCck Senden der Zeichen vom ATmega zum Terminal-Programm auf den MAC funktioniert nicht? Wenn das Terminalprogramm auf ASCII-Emulation (oder auch VT100- oder ANSI-Emulation) eingestellt ist, sollten ASCII-Zeichen ohne weitere Ma=DFnahmen direkt angezeigt werden - lediglich Umlaute und Sonderzeichen k=F6nnen Probleme machen. Wichtig ist, dass Du beim ATmega und dem Terminalprogramm die gleiche Datenrate (ich w=FCrde zun=E4chst mal mit einer v=F6llig unkritischen Datenrate, z.B. 9600 Baud, anfangen) und gleiches Datenformat (z.B. 8N1) einstellst und - ganz wichtig - Hardware- und Software- Handshake ausschaltest, sonst funktioniert es nicht.
Jaja, schon klar. Aus Sicht des AVR kommt "irgendwas" über den UART an. Was das ist, kann der AVR nicht "erkennen" - es ist halt nur ein einzelner Wert. Dass irgendwas schief läuft, war mir schon klar. Ich hatte ja ASCII-kompatible Werte für einzelne Zeichen erwartet - nur die kamen eben nicht an. Da es sich offensichtlich nicht um ASCII handelte, habe ich diese Werte "Scan Codes" *genannt*.
Ja.
Hmmm??? Nun, das Local Echo sagt mir nur, dass mein Terminalprogramm Zeichen auch auf den Bildschrim schreibt. Es findet ja (normalerweise) kein Loopback im Terminal-Rechner auf der RS232C Gerätetreiber-Ebene statt.
Das ist mir - dank der zahlreichen Posts - inzwischen klar. Und mit
38k4 funktioniert's ja auch mit akzeptablen Fehlerraten.
Alles klar inzwischen. Danke Dir, Heike, für die ausführliche Erklärung!
Und damit verschiedene Leute gleichzeitig sich mit deinem Problem beschäftigen lassen, ohne dass die die Chance haben, vom jeweiligen Gedankenfortschritt der anderen Gruppe zu partizipieren, sodass Doppelarbeit entsteht. *Genau das* ist es, was Crossposts verpönt macht -- egal ob diese nun rein im Usenet stattfinden oder in Mailinglisten oder in Webforen oder zwischen diesen. Ihnen liegt die Auffassung zu Grunde, möglichst viele andere Leute gleichzeitig mit genau deinem Problem beschäftigen zu wollen, statt sich im Vorfeld die Mühe zu machen, es an exakt einer Stelle zu posten und es dann dort zu verfolgen. Zumindest ein gegenseitiger Hinweis, dass du das gleiche Problem zeitgleich noch woanders ,,in Auftrag'' gegeben hast, gehört dann zum guten Ton (damit andere nachschauen können, ob es noch den Aufwand wert ist, sich da erst reinzudenken).
Da du das nicht einsehen willst: sorry, ich mag keinen Geist mehr in deine Probleme stecken. Tschüss.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Deiner Meinung nach. In der USENET Etikette und der des anderen Forums steht davon nichts. Da das aber Deine Ansicht ist, Jörg, kann ich natürlich schlecht mit "Ja, das ist so" bzw. "Nein, das ist nicht so" antworten.
Nun, es steht jedem frei zu antworten oder es eben nicht zu tun. *Das* ist die wahre Natur (meiner Meinung nach ;-) von unmoderierten NG bzw. Mailing Lists oder Foren.
Ich halte es für mich so, dass ich Lösungen, die ich - egal wo - erhalten habe, auch den anderen mitteile. Das ist dann die notwendige Rückkopplung, damit andere sehen, ob sich schon was ergeben hat. Und es sich "lohnt", sich reinzudenken.
Jau - das ist der wahre Ham Spirit. Ich kann's immer noch nicht ganz nachvollziehen, was ich Dir denn getan habe. Ich schätze Deine Beiträge hier und in den verschiebenen anderen Bereichen sehr, lese meist die ganzen Posts von Dir und lerne jede Menge dazu.
Deshalb nochmals in aller Form: Danke!
Frank DG1SBG
--
Frank Goenninger DG1SBG
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.