ATTiny13 Timer unregelmäßig

[HeSt]

Hallo allerseits

Ich habe ein kleines Progrämmchen geschrieben (funktioniert auch tadellos, bis auf ...), das die einzelnen Zellen eines 3s-LiPo-Packs überwacht und bei Unterschreiten einer definierten Mindestspannung PB0 auf LOW setzt und die Zellennummer ins RAM auf die erste Adresse schreibt.
Um anzuzeigen, welche Zelle Unterspannung hat/hatte wird die RESET-Taste (PB5>GND) gedrückt. Danach wird in der POR-Routine abgefragt, ob eine Zell# im RAM abgespeichert wurde. Wenn ja, so verzweigt das Programm auf "SHOWCELL". Je nach Wert im RAM (=Zell#) blinkt die LED (PB1) 1 bis 3x im Rhytmus des Wertes in TIMR (SubR WAIT und IntR TIMOVF).
Der Timer wird in WAIT immer wieder gestartet und gestoppt, da ich diese Routine auch je einmal in anderen Bereichen des gesamten Programmes mit anderen Zeitwerten (TIMR) verwende.

So weit so gut.
Die LED blinkt (egal welche Zell#) allerdings manchmal unregelmäßig (im Beispiel 2x = Zelle 2) - siehe Video
(http://youtu.be/jJj2TMR_5Q4) bei 29 Sek., 34 Sek. und zum Schluss bei 1:05 nochmal.

Leider komme ich nicht dahinter, wo mein Programmfehler liegt.
Ich kann mir nicht vorstellen, dass der Tiny13 Blödsinn macht.
Kann mir bitte jemand helfen den Fehler zu finden?

Danke im Voraus
Heinz

PS:
Es fehlen im Listing (angehängt: TS_Blinken_List.txt) einige Programmschritte, die beim Blinken allerdings keinen Einfluss haben, somit weggelasen wurden.

[Searcher]

Hallo,
ich kann erstmal kein Problem im Listing erkennen außer, daß ich nicht erkennen kann, wie die erste RAM Adresse mit 2 belegt wird. Im Video scheint aber die 2 drin zu sein. Läuft im Video ein anderer Code als hier gepostet?

Wenn ja, könnte der Fehler auch im übrigen Code stecken.

Gruß
Searcher

[HeSt]

Hi Searcher,

danke für deine Mühe, meinen Code zu lesen!
Das Video zeigt exakt das Resultat des Listings!
Auch ist keine Regelmäßigkeit der Unregelmäßigkeiten festzustellen, sodass man daraus Rückschlüsse ziehen könnte.

Die "2" (Zellennummer im Beispielvideo) wird in einem anderen Programmteil ins RAM geschrieben, wird dort aber nicht angezeigt.
Erst wenn ich wissen will welche Zelle "schwach" war, kann ich mir das dann per "Knopfdruck" (reset > PB5) anzeigen lassen.
Das impliziert aber, dass ein Normalbetrieb erst wieder nach Ab- und Anstecken des/eines Akkus möglich ist, da sonst die Anzeigeroutine nicht mehr verlassen wird/werden kann.

Die Funktionalität ist ja gewissermaßen gegeben. Nur bin ich nun absolut unsicher, ob man sich auf den Timer des Tiny13 verlassen kann.
Denn wenn nicht, kann man das für spezielle und genaue Timerapplikationen vergessen!

LG Heinz

[Searcher]

Nur bin ich nun absolut unsicher, ob man sich auf den Timer des Tiny13 verlassen kann.

Ich würde ihm schon vertrauen

Du könntest das oben gepostete Codestück doch mal ganz allein auf den Tiny flashen.
Das "ld celr,X" nach dem Label SHOWCELL: zuvor mit "ldi celr,2" ersetzen um das Holen der Zellennummer aus dem RAM zu simulieren.

Das würde doch dieses Codestück testen. Falls da immer noch Unregelmäßigkeiten auftauchen muß man dann hier weiter graben.

Gruß
Searcher

[HeSt]

Hi Searcher,

ich hatte eine ähnliche Idee:
Lade den Inhalt des RAMs vorher in ein Register (MUXR - wird ja nur in den ADC-Routinen benötigt, liegt also beim Blinken brach).
MUXR wird in der POR-Routine aus dem RAM geladen (LD MUXR,X). Ich blieb bei 2, damit keine Änderung des Verhaltens dadurch hervorgerufen werden konnte.

Vorweg: Sämtliche Änderungen erfolgten ausschließlich in der Routine SHOWCELL!
Alles andere im gesamten Programm blieb absolut unverändert!

Erste Änderung:
SHOWCELL:
mov celr,muxr
cbi PORTB,0
CELCNT:
sbi PORTB,1
ldi timr,1
rcall wait
cbi PORTB,1
ldi timr,1
rcall wait
dec celr
brne celcnt
PAUSE:
ldi timr,3
rcall wait
rjmp showcell

LD CELR,X (siehe Listing im Anhang am Anfang des Treads) wurde durch MOV CELR,MUXR ersetzt.

Auswirkung: Unregelmäßigkeiten noch immer vorhanden, gefühlsmäßig jedoch seltener!

Dann folgende Änderung:
PB0 wird nur mehr 1x bei Aufruf der Routine durchgeführt, weil
1. die Reihenfolge von MOV und CBI getauscht wurde und
2. die RJMPs nicht mehr per Label durchgeführt werden, sondern per "Rückschritten" (PC-x):

SHOWCELL:
cbi PORTB,0
mov celr,muxr
sbi PORTB,1
ldi timr,1
rcall wait
cbi PORTB,1
ldi timr,1
rcall wait
dec celr
brne pc-7 ; Sprungpunkt > SBI
ldi timr,3
rcall wait
rjmp pc-11 ; Sprungpunkt > MOV

Auswirkung: KURIOS!! Habe ca. 10 Minuten beobachtet - innerhalb dieser Zeit absolut keine Unregelmäßigkeiten mehr!!
Jetzt frage ich mich, was die Änderungen mit dem Timer zu tun haben!???!?

Für mich heißt das im Klartext: man kann sich auf den Tiny13/Timer nur bedingt verlassen!!
Unter ganz bestimmten Konstellationen - weiß der Teufel welche, so scheint es zumindest, werden ohne jede Ersichtlichkeit irgendwelche internen Funktionen beeinflusst!
Wie, wann, warum!? Keine Ahnung!
Zumindest sieht es für mich so aus.
Wenn jemand eine schlüssige Erklärung zum obigen Phänomen hat, möge er sie mir bitte klarlegen.

Gruß
Heinz

[Searcher]

Hallo Heinz,
ich bin jetzt nicht so der Crack und verstehe nicht so richtig wie Dein Programm funktioniert. Der am Anfang gepostete Code steht doch am Anfang des Programms. Wenn der Tiniy eingschaltet wird, ist die Ramadresse 60 auf 0 ? und der gepostete Code macht irgendwas. Irgendwie kommt dann die 2 nach Adresse 60 und wenn dann Reset gedrückt wird beginnt die Blinkerei ???

Um das Codestück, das Du gepostest hast als Fehlerquelle auszuschließen oder zu identifizieren, kannst Du doch nur dieses mit dem "ldi celr,2" laufenlassen. Alles andere weg! Dann hätte das Forum und Du den gleichen Stand - bis auf die HW.

Vielleicht ist ja die HW auch nicht sauber, Stromversorgung, Abblockkondensatoren, ...
Als ich das Video sah, hab ich im ersten Impuls an zufällig ausgeführte Resets gedacht. Was sind das für seltsame Geräusche im Hintergrund?

Unter ganz bestimmten Konstellationen - weiß der Teufel welche, so scheint es zumindest, werden ohne jede Ersichtlichkeit irgendwelche internen Funktionen beeinflusst!

Das würd ich als allerletztes in Betracht ziehen.

Also: NUR den Code laufen lassen, der verdächtigt wird - alles andere löschen.
Platine auf Kurzschlüsse überprüfen?
Wenns geht Schaltplan und Beschreibung Stromversorgung?

Gruß
Searcher

[Adlerherz]

hy heinz, also ich für mich würde en 2. attiny laden un mit dem ersten vergleichen, um die hardware auszuschliesen