Hallo, bei dem kleinen Testprogramm im Anhang bin ich auf ein mekwürdiges Verhalten des AVR Studio 4.08 Simulators gestossen. Das Programm erzeugt ein interruptgesteuertes, jitterfreies 25kHz-Signal am Pin PB1. Das macht es tatsächlich wenn man es in einen ATtiny15L hineinlädt. Nicht so im Simulator. Der erzeugt gar keine Frequenz. Er setzt das "output compare interrupt flag" OCF1A im "timer interrupt flag register" TIFR beim Ausführen des Interrupts nicht automatisch zurück. Das sollte er aber laut Datenblatt machen und der ATtiny15 machts ja auch so. Im Simulator funktionierts aber erst richtig, wenn das Interrupt-flag explizit durch Programmcode zurückgestzt wird. Ohne diese Massnahme springt der Simulator nach Beenden der Interrupt-Routine gleich wieder hinein. Für mich sieht das ganz nach einem Fehler im Simulator aus. Oder mach ich was falsch? Noch eine weitere Auffälligkeit: Wird PB1 nicht als Ausgang initialisiert, zeigt der Simulator dennoch den Pegelwechsel am eigentlichen Portpin an. Der ATtiny15 machts wie im Datenblatt beschrieben, wenn der Pin nicht als Ausgang initialisiert ist kommt dort auch nichts raus. Würde mich freuen wenn jemand meinen Versuch wiederholen könnte, oder eine Idee hat was ich falsch mache. Eigentlich kann kaum glauben dass der Simulator so voller Bugs ist, aber ich schlag mich jetzt schon ein paar Tage damit herum. Andi
Hallo! Kann dir leider nicht helfen, kann aber sagen, dass ich mit dem Simulieren von Interrupts auch nicht wirklich zufrieden bin. Habe aber bis heute nicht herausgefunden weshalb das nicht so läuft wie ich will und bin auch an Tipps interessiert.... Grüsse
Hallo... Das bei Tiny15 das Timer-Int-Flag nicht zurückgesetzt wird, kann ich bestätigen. Da bin ich auch schon drüber gestolpert. Allerdings sehe ich das nicht so verbissen, denn ein so uralter Typ wie z.B. der 1200 wurde von Versionen vor 4.08 garnicht simuliert. Man sollte also nicht zu viel verlangen... Das Schreiben auf die Port-Bits (portx) bei ddrx=0 ist ok. Damit schaltet man doch die internen Pull-Up-Widerstände. Das Portregister bekommt also diesen Wert, schaltet ihn aber nicht (niederohmig) zu den Pins durch... Bit- & Bytebruch... ...HanneS...
Wo wir einmal dabei sind, beim Tiny12 reagiert der Simulator auf den falschen Pin für INT0... Ich bin sicher, dass es noch mehr solche Bugs gibt... Bit- & Bytebruch... - ...HanneS...
@Hannes Richtig, ein Schreiben auf ein Port-Bit im Register PORTB schaltet den internen pull-up auf den Pin wenn dieser laut dem Datenrichtungsregister DDRB ein Eingang ist. Das Testprogramm schreibt aber gar nicht auf die Port-Bits im Register PORTB. Dort zeigt der Simulator auch nichts an. Das Ändern des Pegelzustands am Port-Pin (nicht im Register PORTB) macht der Output Compare Interrupt anscheinend an diesem vorbei. Im Simulator ändert sich am Inhalt von PORTB nichts, auch wenn der eigentliche Pin toggelt und es der Simulator auch so anzeigt. Interressant wäre ob PORTB wirklich nicht durch den Output Compare Interrupt geändert wird oder ob das auch so ein Bug im Simulator ist. Darüber wie sich der ATtiny15L nun tatsächlich verhält hab ich im Datenblatt nichts gelesen. Werde das bei Gelegenheit mal ausprobieren. Gibt es eigentlich so was wie eine Bugsammlung irgendwo?. Habe beim googeln nichts gefunden. Wäre vielleicht hier für das Forum nicht schlecht wenn verifizierte Bugs irgendwo gesammelt werden könnten. Andi
Hallo Andi... Man könnte ja ATMEL über die Bugs informieren (als Frage getarnt). Aber ich werde das nicht tun, denn mein Englisch ist zu schlecht und die Gefahr, mich lächerlich zu machen ist irgendwie auch vorhanden, ich bin noch zu unerfahren... Beantworte dir mal diese (sarkastisch gemeinten) Fragen: - Was hast du für ASTUDIO bezahlt? - Meinst du, dass du/wir bei diesem Preis Anspruch auf ein fehlerfreies Programm hast/haben? - Wird der Simulator von Profis genutzt, wo die (mit teurer Hardware) ganz andere Debug-Methoden (ICE) nutzen können? - Wie wichtig sind wir Hobbybastler der Firma? - Wollen die Software verkaufen oder AVRs? Also ich werde da nix unternehmen, ich versuche einfach, damit zu leben. Eine Bugsammlung wäre nicht schlecht, Frag doch mal den Forumbetreiber Andreas, welche Möglichkeiten er für sinnvoll hält (Wiki, ein Thread, Beitrag im Tutorial usw.). Bit- & Bytebruch... - ...HanneS...
@Hannes Die Anfrage an ATMEL hatte ich bereits auf den Weg gebracht, bin mal gespannt auf die Antwort. Ich gehe einfach davon aus dass Atmel für jeden Hinweis auf Produktfehler dankbar sein sollte. Vielleicht fliesst ein Bugfix ja in die nächste Version ein? Dann hätten alle was davon. Natürlich ist AVRStudio kostenlos :-) und Atmel möchte damit ja neue Kunden für ihr Produkt begeistern und den Bekanntheitsgrad steigern. Viele Bastler die einfach mal was ausprobieren wollen aber auch professionelle Entwickler die sich nicht mit wochenlanger Produktsuche nach 3rd Party Entwicklungsumgebungen und möglicherweise in den Sand gesetzten Kosten auseinandersetzten wollen werden im Laufe ihres Lebens so wahrscheinlich häufiger bei Atmel-Produkten hängenbleiben als sonst. Kostenlose Entwicklungsumgebungen zur Verfügung zu stellen ist eine strategische Unternehmensenscheidung die sich meiner Meinung nach rechnet. Die Strategie scheint aufzugehen, nicht zuletzt deswegen gibts ja auch dieses Forum. Was bezahlte Software angeht, und da gehören auch superteure Spezialanwendungen im EDA-Bereich dazu, schaut es ja auch nicht so gut aus wenn es um Fehlerfreiheit geht. Da lob ich mir Linux, ist zwar auch nicht fehlerfrei aber dafür garantiert kostenlos ;-)
Hallo Andi... Was du schreibst ist völlig richtig. Auch ich finde es richtig, kostenlos Software und Datenblätter bereitzustellen, um Jedem die Arbeit mit den Produkten zu ermöglichen. Das rechne ich ATMEL auch hoch an. Doch da ich auch schon einige kleinere PC-Software-Projekte "verbrochen" habe, kann ich den Aufwand nachvollziehen, der in einer so komplexen Software wie AVR-Studio steckt. Ich erwarte daher keine unbedingte Fehlerfreiheit. Selbstverständlich bin ich auch dafür, dass man ATMEL über die gefundenen Bugs informiert. Nur ich selbst halte mich nicht für kompetent genug, mit denen einen Dialog zu führen. Dazu ist mein Englisch und mein Mikrocontroller-Fachwissen zu schlecht. Außerdem habe ich mit meinen vierundfünfzig Jahren meine Aktivitäten als "Weltverbesserer" schon hinter mir... ;-)) Achja, was mich am Simulator auch noch stört, ist die Tatsache, dass bei Auto-Step-Betrieb die Breakpoints nicht beachtet werden... Schade eigentlich... Alles Gute, viel Spaß beim Hobby... Bit- & Bytebruch... - ...HanneS...
Es gibt nun einmal keine fehlerfreie Software. Software wird von Menschen gemacht und Menschen machen Fehler. Grundsätzlich habe ich schon den Eindruck, dass ATMEL um die Beseitigung von Fehlern bemüht ist, insofern macht eine Meldung an ATMEL Sinn, aber man hat offensichtlich keine allzu großen Resourcen für die Programmierung. Deshalb vergeht immer recht viel Zeit bis zur nächsten Version und mit jeder Neuerung (neue Chips müssen unterstützt werden) steigt natürlich auch wieder die Gefahr von neuen Fehlern. Und außerdem: Simulation zählt nicht - im wirklichen Leben ist ohnehin alles anders. ;-) Gruß, Frank
@Hannes Im AVR Studio 4.08 gibts eine Einstellung unter Tools - Options... - Breakpoint - Stop on breakpoint when autostepping. Dann sollte der Simulator auch im Autostep-Betrieb an Breakpoints anhalten. @Frank Atmel ist offenbar wirklich sehr bemüht, hat auch schon geantwortet. Ich werde noch die Beispieldatei hinmailen und euch auf dem Laufenden halten. Andi
Moin... Ups... Das ist die Schattenseite hochkomplexer Software: Man findet die wichtigen Dinge nicht (weil man nicht auf die Idee kommt, danach zu suchen)... Danke, Andi... Dass Atmel sich meldete, finde ich gut... Bit- & Bytebruch... ...HanneS...
Also hier nun die Antwort von Atmel. Bin äusserst positiv überrascht über die schnelle Erledigung durch Atmel: Dear customer I have tested your code, and there is a bug in AVR Studio simulator causing the OCF1A flag not to be automatically cleared after interrupt. For now I think you will have to manually clear the flag when simulating your code. This should not be necessary on your real device. regarding question (2) it also looks like a bug changes the value of port pin regardless of the DDRB value. Thank you very much for reporting these findings to us. The bug is reported.
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.