www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVRStudio simuliert falsch?


Autor: Andi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ;-)

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Frank Linde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.