Hallo Zusammen, ich versuche im Moment mein Olimex P28 Board mit ATMega8 mit der Seriellen Schnittstelle des PC zu verbinden. Die Tool-Chain funktioniert und ich kann alle Olimex Beispiele compilieren und auch erfolgreich auf den Chip flashen... Leider tappe ich im Bereich UART ziemlich im Dunkeln. Das HyperTerm von Windows bleibt dunkel obwohl ich meiner Meinung nach alle Ausgänge korrekt vom ATMega8 auf den MAX gesetzt habe (TX und RX des MAX auf TX und RX vom ATMega8). Die COM1 von Windows ist auch korrekt auf 9600,8,N,1 gesetzt. Das Tutorial hier hat mir leider gestern Nacht nicht geholfen... . Zunächst dachte ich, es läge am Reset. Während des Tastendrückens bin ich mit dem Finger an den einen Pin gekommen und im Terminal erschienen ein paar Zeichen (Pfeil nach oben)... . Leider nicht die, die ich erwartet habe. Also geht was - nur was?? Nun meine Frage - hat jemand hier ein UART Sample (Hello World auf RS232 oder so) mit einer detailierten Beschreibung, wie die HW und das Terminal zu verschalten sind und welche Settings zu setzen sind? Ich will einfach ausschliessen, dass ich den Wald vor lauter Bäumen nicht sehe und an der falschen Stelle suche.... . Merci für jede hifreiche Anregung! Axel
Ist bei den > Die Tool-Chain funktioniert > und ich kann alle Olimex Beispiele compilieren und auch erfolgreich auf > den Chip flashen... gar kein UART Beispiel dabei? Das kann ich mir fast nicht vorstellen. Ansonsten poste halt mal, was du bisher mit UART programmiert hast und wie dein > ich versuche im Moment mein Olimex P28 Board mit ATMega8 mit der > Seriellen Schnittstelle des PC zu verbinden. eingestellt ist, also Taktrate physikalisch (Taktquelle?) und chip-logisch (AVR Fuses?) und programmlogisch (F_CPU=?) > obwohl ich meiner Meinung nach alle Ausgänge > korrekt vom ATMega8 auf den MAX gesetzt habe (TX und RX des MAX auf TX > und RX vom ATMega8). "Der MAX hat keine TX und RX." Er hat TXin/TXout und RXin/RXout und je nach MAX Variante einen bis paar Paare davon. Es müssen letztendlich jeweils paarweise RXD auf TXD zusammenkommen. Die Verbindung könnte man z.B. so machen: Beispiel mit Kreuzung zwischen PC und MAX232:
1 | Buchse/ Stecker/ |
2 | Stecker Buchse |
3 | TXD PC -- DB9-m/f -- 1:1 -- DB9-m/f -- RXin1 MAX232 RXout1 -- RXD AVR |
4 | RXD PC -- DB9-m/f -- 1:1 -- DB9-m/f -- TXout1 MAX232 TXin1 -- TXD AVR |
5 | GND PC -- DB9-m/f -- 1:1 -- DB9-m/f -- GND Atmega8 |
6 | |---- PC ------|--- Kabel -------|---------- Targetboard ------------| |
Angehängte Dateien:
-
fuses.jpg
130 KB
Hallo Stefan, doch ein UART Beispiel ist dabei - incl. des Project Files für AVR Studio. Gleich zu Anfang wir der Takt (Quarz) gesetzt: #define _AVR_ATmega8_ 1 #define OSCSPEED 8000000 /* in Hz */ Der MAX232 ist mit R1OUT (RX) und T2IN (TX) auf den ATMega8 PIN TXD und RXD verbunden. Soweit ja eigentlich richtig... . Das ganze ist mit zwei Brücken realisiert, die auf Pfostenstecker gehen, die an den PIN dran sind... . Das Olimex Board bietet "Schlüsselfertig" die Verbindung auf ein RS232 Stecker (Weibchen) an. Dazwischen hängt ein Kabel mit Stecker und Buchse und das ist mit meinem einzigen RS232 Schnittstellentragenden Rechner verbunden. Strom da, alles da. Wenn ich eine LED Blinken lassen will klappt ja alles bestens... . Das mit den Fuses muss ich nochmals anschauen. Explizit gesetzt habe ich keine - Ich bin davon ausgegangen, dass das ggf. das AVR Studio selbsständig gemacht hat - weil es bei den LED's klappt. Anbei der Screenshot so wie die Entwicklungsumgebung heute aufgestartet ist. Ich habe nichts seit gestern geändert... . Wenn ich beim Reset mit den Fingern auf die Stecker komme, bekomme ich ja auch ein paar Zeichen in meinem Terminal zu sehen. Also ganz falsch scheint es ja nicht zu sein - nur ich bin es nicht so dermassen Hardware-Nahe gewohnt... . Irgendwelchen Kommentar? Ach ja - die Quellen kann ich Posten - 98 Zeilen incl. Kommentare - oder ist das zu lang? Gruss, Axel
Axel Thobaben wrote: > #define OSCSPEED 8000000 /* in Hz */ > Das mit den Fuses muss ich nochmals anschauen. Explizit gesetzt habe ich > keine - Ich bin davon ausgegangen, dass das ggf. das AVR Studio > selbsständig gemacht hat - weil es bei den LED's klappt. Unbedingt ansehen! Bzw. mal eine LED im 1s Takt blinken lassen (Thema Warteschleifen im AVR-GCC-Tutorial). Man sollte rasch sehen, ob das Blinken im 1s Takt (Fuses richtig für 8 MHz) oder im 8s Takt (Fuses falsch bzw. nicht vom AVR Studio selbst gesetzt) passiert. Beim dem mir bekannten, alten AVR Studio wurde die Fuses definitiv nicht von dem AVR Studio selbsttätig gesetzt. Mag sein, dass es sa ein neues AVR Studio gibt. Gib bitte nach deinen Tests Feedback, ob das so ist. > Wenn ich beim Reset mit den Fingern auf die Stecker komme, bekomme ich > ja auch ein paar Zeichen in meinem Terminal zu sehen. Also ganz falsch > scheint es ja nicht zu sein - nur ich bin es nicht so dermassen > Hardware-Nahe gewohnt... Durch dein Gegrapsche ziehst du vielleicht den Signalpegel etwas runter, so dass es für ein zufälliges 0 Bit langt. Lass dir die Schaltung als True Random Generator mit RS232 Ausgabe patentieren ;-) > Ach ja - die Quellen kann ich Posten - 98 Zeilen incl. Kommentare - oder > ist das zu lang? Ggf. Copyright von Olimex beachten! Vielleicht gibt es einen Link zu der Source bei Olimex. Ansonsten ist der Anhang für lange (98 Zeilen ist IMHO bereits lang) Quelltexte da.
Hi Stefan, "Lass dir Schaltung als True Random Generator mit RS232 Ausgabe patentieren ;-)" Mache ich ;-) Ich brauche eh Geld für meine neue Heizung. Das Ganze soll ein Serieller Datenlogger werden... . Der Code (ohne Copyright Note) ist im Anhang. Der Code sollte einfach jedes Zeichen wieder Retour geben, das über RS232 reinkommt. Tut es aber nicht. Um andere Fehlerquellen auszuschliessen - kann man mit HyperTerm unter WinXP einfach so "senden"?? Oder gibt es ein "besseres Terminal"? Putty kenn ich zwar aber nur als VT100 Ersatz unter Windows. Und mit mgetty und stty (config von tty) hatte ich auch keinen Erfolg... . Kannst Du mir noch sagen welches AVR Studio mit welchem WinAVR (GCC) bei Dir am laufen sind? Danke und Gruss, Axel
Axel Thobaben wrote: > Kannst Du mir noch sagen welches AVR Studio mit welchem WinAVR (GCC) bei > Dir am laufen sind? Aus dem Kopp glaub ich das ist WinAVR-20071221, die letzte von 2007 jedenfalls. Da ist schon ein GCC 4.x drin. Mit der Option auf die Vorversion WinAVR-20070225 zu wechseln, die ich noch für Windows98SE extra patchen musste. Jedenfalls habe ich kein WinAVR aus 2008. AVR Studio ist 4.13, ich glaube mit dem 2. Servicepack. Läuft unter meinem Windows98SE aber schon nicht mehr so stabil wie die 4.12er, aber diese WinAVR Versionen brauchen >4.12. Der Code sieht sauber aus. Das Echo ist aber nicht exakt das empfangene Zeichen sondern das um +1 erhöhte Zeichen. Die Funktion steht und fällt mit der richtigen Baudrate und für die richtige Baudrate muss der AVR mit der richtigen Taktrate laufen. Nur das #define im Quellcode reicht da nicht. Der AVR muss physikalisch auf Trab gebracht werden und zwar per Taktquelle und Fuses.
Angehängte Dateien:
-
fuses2.jpg
280 KB
Hi Stefan Du hast recht, es muss an den Fuses liegen und NEIN leider setzt auch die neueste Version von AVR Studio nix automatisch... . Ich tappe nun beim Fuse SUT_CKSEL im Dunkeln. Das Progamierinterface für die Fuses für meinen AVRISP mkII Clone liefert mir keine Anhaltspunkte, wie ich einen externen 8Mhz Quarz (kleiner Blechsarg)korrekt auswähle. Ich habe schon gelernt, dass hier ein Fehler einen neuen Chip nachsich zieht, da ich keine Möglichkeit habe eine extrne Taktquelle anzuschliessen. Olimex schreibt von einem Crystals Q - 8MHz HF crystal on socket der mit passenden Kondesatoren auf XTAL1 und XTAL2 wirkt. Was muss ich nun auswählen????? Das UI ist freundlich ausgedrückt nicht wirklich hilfreich ausser für den Vertrieb.... Ich würde jetzt zu einem "Ext Crystal/Resonator Medium Frequency, Startup Time 1K CK+64ms" tendieren - aber bin mir halt nicht sicher. Was sagst Du? Gruss, Axel
Das UI alleine hilft da nicht. Du musst das Datenblatt des Atmega8 lesen! Mit den 1K bin ich nicht einverstanden. Laut Atmega8 Datenblatt Tabelle 5 sind für die Quarze 16K Startzyklen vorgesehen. Zu den Startzyklen (des anregenden "Quarztreibers", Einschwingzeit) kommt noch eine Wartezeit in ms. Wenn du BOD einschaltest, kannst du die Einstellung ohne weitere Wartezeit in ms nehmen, ansonsten würde ich die konservative Einstellung, also slowly rising power nehmen, d.h. insgesamt 16K + 64ms Bei der Auswahl medium oder fast ist 8 MHz gerade auf der Grenze. Die konservative Einstellung ist dann fast, allerdings braucht der AVR dann mehr Strom. Lies dir auch den Abschnitt zur CKOPT Fuse im Atmega8 Datenblatt durch. Sicherer ist der Betrieb, wenn diese Fuse auch programmiert wird. Das kostet allerdings auch etwas mehr Strom.
ADD: Wichtig! Zuerst Fuses einlesen, dann eingelesene Fuses ändern, dann schreiben. NICHT nur ändern/einstellen und dann schreiben!
Hallo Stefan es funktioniert - Nach nochmaligem lesen des entsprechenden Absatzes über Fuses im Buch und im Datenblatt habe ich so leidlich begriffen wieso ich "Ext Crystal/Resonator Medium Frequency, Startup Time 16K CK +64ms" nehmen muss. Die Aufteilung des Datenblatts ist mir aber noch nicht wirklich sympathisch. Ein Anhang "Fuses" über 2-3 Seiten in Tabellenform wäre wohl keine schlechte Verbesserung. Nebenbei habe ich auch die richtige Terminaleinstellung gefunden und wenn ich ein "X" sende kommt ein "Y" zurück. Bei Beispiel für den TemperaturLogger funktioniert damit zwar noch nicht, aber ich weiss, wo ich graben muss. Du kennst Dich nicht zufällig mit der UART Library von Peter Flury auf ATMega8 aus? Danke nochmals und Gruss, Axel
athobaben wrote: > Hallo Stefan > > es funktioniert - Nach nochmaligem lesen des entsprechenden Absatzes > über Fuses im Buch und im Datenblatt habe ich so leidlich begriffen > wieso ich "Ext Crystal/Resonator Medium Frequency, Startup Time 16K CK > +64ms" nehmen muss. Glückwunsch! Damit bist du ein gutes Stück weiter gekommen. Dieses Wissen ist essentiell. Einige lernen das erst nach dem Verbraten eines AVRs ;-) > Die Aufteilung des Datenblatts ist mir aber noch nicht wirklich > sympathisch. Ein Anhang "Fuses" über 2-3 Seiten in Tabellenform wäre > wohl keine schlechte Verbesserung. Das ist eine Sache von Atmel. Die Chance das zu ändern sehe ich nicht. Du könntest aber deine optimale Lösung in unsere Artikelsammlung einpflegen ;-) > Nebenbei habe ich auch die richtige Terminaleinstellung gefunden und > wenn ich ein "X" sende kommt ein "Y" zurück. Dann klappt das Programm ja. Es erhöht wie im Programmcode vorgesehen das Echozeichen um +1. > Bei Beispiel für den TemperaturLogger funktioniert damit zwar noch > nicht, aber ich weiss, wo ich graben muss. Du kennst Dich nicht zufällig > mit der UART Library von Peter Flury auf ATMega8 aus? Nee sorry, die benutze ich nicht regelmäßig.
Hi Stefan naja meistens lese ich ca 2-3 Wochen lang intensiv Foren und fange dann erst an Zeit zu verbrennen. Sozusagen erst lesen/denk dann tippen - klappt aber auch nicht immer wie UART zeigt. Das mit der Lib von Peter Flury hätte ja sein können. Naja - und das sich ATMEL nicht bewegen wird, ist klar - ich arbeite bei S......s (gross und grün) und da geht auch vieles laaaaaangsam.... . Danke für den Hilfestellung - so langsam gewinne ich der hardwarenahen Programmierung Respekt ab. ;-) Gruss, Axel
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.