Hallo ich simuliere den UART des mega16. Habe den Code aus der Codesammlung in mein Programm eingebaut. Leider geht das "UART ist bereit"-Bit nach zwei bytes aus. Danach hängt das Programm in der "warte-bis-UART-wieder-bereit-ist"-Schleife fest. Das "UART-bereit-Bit" geht nicht wieder an. Habe den Code einmal so getestet, dann geht er. Müsst ihr den kompletten Code durchforsten um überhaupt irgendwas dazu sagen zu können oder gibt´s noch einen RTFM-Tipp? THX Basti
Also meine Frage ist, woher der Simulator "weiß", ob das UDR bereit ist. Nach dem zweiten Bytes geht das simulierte UDR nie mehr leer. Und das, nachdem die Sendung eines Bytes erfolgreich simuliert wurde...
Also ich habe den Code jetzt angehängt. Hab mein komplettes Programm nach und nach rausgelöscht und sogar die Register wieder nach dem Beispiel aus dem mikrocontroller.net benannt. Doch nach wie vor hängt das Programm an der gleichen Stelle fest. Ich erkenne jetzt nicht mehr den Unterschied zu dem Beispiel-Code, der direkt eingetippt funktionierte. Habe zur Überprüfung den Code aus der angehängten Textdatei in ein leeres Projekt geladen - gleiches Phänomen wie vorher...
Hab den Code http://www.mikrocontroller.net/sourcecode/tutorial/uart-mega8.asm nochmal direkt eingetippt und wieder das gleiche Problem! (getestet mit mega8 Simulator) Vorhin als es mal ging (hatte zumindest den Eindruck, dass es einmal nach dem direkten Eintippen ging) hab ich es später wieder überschrieben - wollte nur sicherstellen, das der Code tatsächlich funktioniert. Hätt ich geahnt, was das für ein Drama ist hätt ich das eingetippte Beispiel lieber behalten...
Heißt keine Antwort, daß keiner einen Fehler entdecken kann? Es hätte doch wohl jemand gemeckert, wenn ich was verplant hätte?
Hallo, IMHO ist der Simulator vom AVRStudio nicht dazu geeignet, das UART vollständig zu simulieren. Das heißt, wenn man Daten sendet, dann muss man von Hand immer das UDR-Bit regulieren. ´Ähnliche Probleme gibt es ja auch bei Timern. Ich habe mir da bisher keine großen Gedanken gemacht und einfach das gewünschte bzw. erwartete Verhalten der Hardware per Hand eingestellt. Wenn man vorher das Datenblatt des Controllers beguckt, dann passiert da auch kein Blödsinn. MfG, Daniel.
Hallo Daniel Da ich zum ersten Mal ein UART ansteuere, hat mich das Verhalten des Simulators erstmal verunsichert. Von Dir kommen die besten Anfängertipps (und von Peter die besten Programmier-Hinweise ;). Beim letzten Mal hab ich schon mit Atmel Norway kommuniziert und Du hattest dann die Lösung. Vielen Dank, daß von dir die entscheidenden Tipps kommen, auch wenn sonst keiner was schreibt!
Die Simulation der UART erfolgt schon korrekt. Die Tatsache, dass nach dem 2.Byte das UDRE-Bit nicht gleich wieder gesetzt wird, bedeutet ja nur, dass die UART jetzt ersteinmal noch mit dem Versenden der ersten beiden Bytes beschäftigt ist. Es dauert halt eine ganze Weile (kann man sich ausrechnen, pro Bit 16 Clk), bis das Byte Bit für Bit rausgeschoben ist. Bei mir hat jedenfalls auch die Simulation bisher ordentlich funktioniert (mal von kleinen Problemen mit UART1 beim Mega128 und einem älteren AVR-Studio abgesehen). Jörg
@plitzi: Danke für die Stellungname. Es geht nicht darum, dass "das UDRE-Bit nicht gleich wieder gesetzt wird". Sonst wäre es ja auch vollkommen sinnlos, darauf zu warten! Es geht, wie oben beschrieben darum, dass das UDRE-Bit nach 2 Bytes NIE WIEDER gesetzt wird! Nicht nach 16 Cycles, nicht nach 1000 Cycles sondern absolut nie!!! Wenn der von mir vor einigen Posts angehängte Code mit jenem in der Codesammlung übereinstimmt und wenn dieser korrekt ist, wovon ich mal ausgehe, da er auf der Website ausführlich erklärt wird, offenbar von mehreren Leuten benutzt wurde und offenbar keiner einen Fehler gefunden hat, dann muß wohl der Simulator wohl einen Bug haben.
Also, ich hab' das jetzt mal auf die Schnelle ausprobiert und den Quellcode im Simulator laufen lassen. Die ersten beiden Byte werden wie erwartet ohne Verzögerung in das UDR übernommen (doppelt gepuffert beim ATMega16!). Danach bleibt er EINE WEILE in der Bitabfrage für das UDRE stehen, bis das UDR wieder frei ist (so wie ich es oben erklärt habe). Nach etwas über 5ms (@4MHz) landet er bei "rjmp loop". Da dies bei Dir offensichtlich nicht so ist, würde ich ein Update des AVR-Studio vorschlagen (ich arbeite mit 4.11b406SP2). Wie bereits gesagt, hatte ich ein ähnliches Problem vor längerem mit der UART1 und einem ATMega128 mit einer Studio-Version 4.03 oder so. Jörg
Also ich benutze schon 4.11 build 401, daran liegt´s nicht Wie oben beschrieben ging es auch einmal kurz... Basti
Aber Du benutzt ja auch build 406 - wo gibt´s die denn? bei Atmel ist 401 aktuell... http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725
Ich denke mal, das "build406" entsteht durch das Servicepack (ich hab' noch SP2, aktuelle ist aber schon SP3, noch keine Zeit zum updaten gehabt). Jörg
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.