Liste der Anhänge anzeigen (Anzahl: 1)
ATTiny13 Timer unregelmäßig
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.
Liste der Anhänge anzeigen (Anzahl: 1)
Die ganze Elektronik (LiPo-Guard und DMC - Dual Motor Contoller, beides Tiny13) ist in einem Flugmodell untergebracht.
Der Guard (um den handelt es sich bei dem Problem) überwacht jede einzelne Zelle eines 3-Zellen-Akkupacks.
Er gibt bei Unterschreiten des Spannungslimits einer Zelle an PB0 "low" aus und schreibt die # jener Zelle ins RAM, die das Limit unterschritten hat.
In unserem Testbeispiel ist es die Zelle "2". Ist aber egal ob 1, 2, oder 3 drin steht. Das Blinkverhalten bleibt gleich!
Der DMC schaltet bei "low" beide Motoren aus, indem er die kürzest je empfangenen Impulse (Gas aus) ausgibt. Erst wenn der Guard wieder "ok" (high) signalisiert und das Gas am Sender auf 0 genommen wurde, laufen die Motoren bei Gas wieder an, bis erneut ein "low" vom Guard kommt - usf ...
Soviel zum gesamten Projekt.
Die HW ist unverändert. Also frage ich mich, warum - nachvollziehbar! - der eine Code Probleme macht und der andere nicht!
Das komische Geräsuch im Hintergrund ist von einem Servo. Das Problem tritt aber auch auf, wenn dieses vom Empfänger getrennt wird.
Nun zum LDI CELR,2:
Das Problem tritt auch damit auf, wenn die SHOWCELL-Variante mit den Labels verwendet wird. Allerdings auch seltener.
Die Platine ist sauber, Stromversorgung auch - mit Osci geprüft.
Schaltplan ist in meinem Kopf. Werde ihn mal bei Gelegenheit zu Papier bringen.
Aber vielleicht kannst dem angehängten Platinenlayout was entnehmen ...
Per unten am Bild gezeichneten Taster wird bei abgespeicherter Zelle die Zell# an der LED ausgegeben.
Ist keine Zelle abgespeichert, wird auf LiFePo-Modus geschaltet (andere Spannungslimits in die Register geladen).
Die Elektronik beherbergt insgesamt 3 Tiny13.
Einer überwacht den Akku (Guard - links unten, der Problemkandidat), einer steuert die Motoren (DMC - rechts unten) und der PLF (PositionLightFlasher - oben) ist für die Beleuchtung zuständig.
LG Heinz
Liste der Anhänge anzeigen (Anzahl: 1)
Servus Searcher,
danke nochmals für deine Mühe und deinen Hinweis auf den falsch eingezeichneten Elko!!!
Habe den Einbau überprüft - er wurde richtig eingelötet ;-)
Habe noch einen Test mit dem PLF-Tiny als Guard gemacht. Gleiches Verhalten mit den unterschiedlichen Codes.
Ein weiterer Test folgte noch mit nur dem Listing-Code aber mit LDI CELR,2 mit der Franzis Lernplatine (siehe Schaltungsbild) und den mit oben angeführten Abänderungen. Ach ja, PB0 und PB1 wurden in dieser Anordnung auf PB4 und PB3 geändert. Gleiches Verhalten. Es scheint, als würde es in dieser Anordnung gefühlsmäßig weniger Unregelmäßigkeiten geben. Bin mir aber nicht sicher, da manchmal bis zu 2 Minuten vergehen, ehe wieder ein "Fehler" passiert.
Somit schließe ich die "Umgebungs-HW" samt Stromversorgung als Auslöser/Verursacher des Problems aus.
Im Prinzip ist es mir egal, ob beim Blinken Unregelmäßigkeiten auftreten. Hat ja keine gravierenden Folgen!
Hätte ich nicht diese Routine eingebaut, wäre ich nie auf dieses Phänomen gestoßen!
Es gibt einem nur zu denken, was passiert, wenn man Applikationen schreibt, die exakte und verlässliche Zeiten erfordern!!
Man sucht sich dann zu einem "Wuserl" ohne etwas zu finden - wenn man überhaupt drauf kommt, dass es Timer-Unregelmäßigkeiten sind/gibt!
LG Heinz
/edit/: Das mit den Abblockkondensatoren wusste ich bislang nicht!!
Deshalb fehlen sie auch. Kann sie aber auf der Lötseite der Platine "nachrüsten".
Wird aber mE keine Auswirkung auf das beschriebene Problem haben, da mit der Franzis-Paltine auch das Problem auftritt (trotz Abblockkondensator! ;-) ).
