Forum: Mikrocontroller und Digitale Elektronik Mega8: möglicher Hardware-Bug in Capture/Timer?


von Jörg H. (idc-dragon)


Lesenswert?

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).

von Karl H. (kbuchegg)


Lesenswert?

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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Die 3 Gebote... ;-)

von Jörg H. (idc-dragon)


Lesenswert?

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.

von marvin m. (Gast)


Lesenswert?

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.

von Jörg H. (idc-dragon)


Lesenswert?

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
Noch kein Account? Hier anmelden.