Ich habe ein ganz seltsames Verhalten mit dem Timer 1 und der Capture-Unit. Der gleiche Code auf einem Mega88 oder Mega168 zeigt kein Problem, tritt nur beim Mega8 auf: Timer 1 läuft frei und mit maximaler Äuflösung, zählt also Clock Cycles. Ich benutze das Capture-Feature, um eine Flanke des Analogkomparators auszumessen. Im Capture-Interrupthandler lese ich den zum Zeitpunkt der Flanke durch die Hardware kopierten Zählerstand aus dem Registerpaar ICR. Ferner lese ich nochmal den aktuellen Zählerstand aus TCNT1 (um letztlich Überlauf-Randbedingungen eines in Software auf 32 Bit erweiterten Zählers zu behandeln). Ich beobachte nun in ca. 5% der Fälle, das der spätere, in Software gelesene Timerwert kleiner ist als der Capture-Wert, um wenige Takte, 1...8 beobachtet. Dies ist kein Überlauf, sondern passiert mitten im Zählbereich. Ich lese erst IRC1, dann den aktuellen Wert. Selbst wenn der Capture noch prellt dürfte der aktuelle Wert nicht kleiner sein als der Capture?! Ich habe in den (wenigen) Errata des Mega8-Datenblatts nichts in der Art gefunden. Habe ich was übersehen, hat jemand schonmal mit sowas gekämpft? Ich habe als Workaround einen Plausibilitätscheck in die Software gebaut, hilft mir allerdings nicht wenn diese Situation während eines echten Wraps auftritt (denke ich).
Du sollst deinen Code nicht beschreiben Du sollt deinen Code so posten wie du ihn auf dem Gerät laufen hast Du sollst nicht zweifeln an den Fähigkeiten deines AVR
Aha, die 3 Gebote kannte ich noch nicht. ;-) > Du sollst deinen Code nicht beschreiben > Du sollt deinen Code so posten wie du ihn auf dem Gerät laufen hast Der gesamte Code ist recht umfangreich, u.A. mit Messages zwischen ISR und Mail Loop, Hardware-Zugriffe sind für Portabilität auf einen anderen Controller mit (inline-)Funktionen gekapselt. Das hat für AVR-Fans nicht soviel Wiedererkennungswert. Wollte ich euch nicht zumuten, daher die "Executive Summary". Soll ich das nochmal abgespeckt posten? Ist dann aber nicht genau das, was auf den Controller läuft. Hätte ja sein können, das jemandem spontan ein Fallstrick dazu einfällt. > Du sollst nicht zweifeln an den Fähigkeiten deines AVR In aller Regel sitzt das Problem zwischen Monitor und Stuhllehne, weiß ich. Da suche ich immer zuerst, kann auch hier gut der Fall sein. Was mich aber echt verwirrt ist das der Fehler nur auf dem Mega8 auftritt.
Ein Ansatz wäre das Abspecken auf die notwendigsten Funktionen - meist erledigt sich das Problem dann von ganz alleine ;-) Eine starke Abstrahierung mag bei PCs ja einen Nutzwert haben, bei µC ist es gefährlich. Sehr oft vergisst man z.B., dass 16-Bit Zugriffe nicht atomar sind - und so etwas kann dann sehr nette Seiteneffekte erzeugen.
Der Mega8 ist rehabilitiert: Ich hatte versehentlich doch nicht den Capture-Wert zuerst gelesen, sondern den aktuellen. In der Zwischenzeit konnte die Capture-Unit eventuell noch rumprellen und einen neueren Wert in das Register schreiben. Aus irgendeinem Grunde waren Mega88 und Mega168 wohl schaltungstechnisch weniger anfällig für Noise auf dem Signal. Sorry!
Bitte 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.