- LiFePO4 Speicher Test         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 17

Thema: ATTiny13 Timer unregelmäßig

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    20.09.2008
    Ort
    Linz A
    Beiträge
    126

    ATTiny13 Timer unregelmäßig

    Anzeige

    Powerstation Test
    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.
    Angehängte Dateien Angehängte Dateien

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.702
    Blog-Einträge
    133
    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
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    20.09.2008
    Ort
    Linz A
    Beiträge
    126
    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

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.702
    Blog-Einträge
    133
    Zitat Zitat von HeSt Beitrag anzeigen
    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
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  5. #5
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    20.09.2008
    Ort
    Linz A
    Beiträge
    126
    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

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.702
    Blog-Einträge
    133
    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
    Geändert von Searcher (06.02.2013 um 23:14 Uhr) Grund: Name berichtigt
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  7. #7
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    20.09.2008
    Ort
    Linz A
    Beiträge
    126
    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
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken TS_El-Board_V3.jpg  
    Geändert von HeSt (06.02.2013 um 21:59 Uhr)

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.702
    Blog-Einträge
    133
    Hallo Heinz,
    hab mir nochmal in Ruhe die "mov celr,muxr" Versuche angesehen und finde auch keine Erklärung. Nach dem das mit "LDI CELR,2" auch noch Probleme bringt und ich in der SW kein Problem entdecke würd ich auf die HW tippen. Dagegen spricht die zweite Variante mit dem "mov celr,muxr" *ratlos*

    Bei der Platine ist mir erstmal nur der falsch eingezeichnete dicke Elko am 7805 Ausgang aufgefallen (+ und - sind vertauscht). Hoffe, daß der trotzdem richtig eingebaut wurde?

    Eigentlich braucht es keine Pullups an den Reset Pins. Wenn man welche verwendet um die Störanfälligkeit zu verringern nimmt man aber auch wesentlich kleinere - 10k statt 100k. Der obere Tiny (PLF) hat keine. Na ja, wenn die Positionslichter ausfallen ...

    Gehe jetzt mal schlafen. Vielleicht fällt mir oder jemand anderem noch was ein...

    PS: Die Abblockkondensatoren, die 100nF, die mit ihren Beinchen möglichst nah an den VCC und GND der Tinys sitzen sollten, kann ich auch nicht entdecken.

    Gruß
    Searcher
    Geändert von Searcher (07.02.2013 um 08:23 Uhr) Grund: Abblockkondensatoren hinzugefügt
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  9. #9
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    20.09.2008
    Ort
    Linz A
    Beiträge
    126
    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! ).
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Franzis.jpg  
    Geändert von HeSt (07.02.2013 um 09:13 Uhr)

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.702
    Blog-Einträge
    133
    Solche Probleme wecken irgendwie meinen Ehrgeiz. Hätte es zB gerne auf 'nem Steckbrett ausprobiert. Hab leider keinen Tiny13 zur Hand und nutze auch nur BASCOM. Welchen Assembler nutzt Du um das Programm zu assemblieren und Flashen. Welche Fuseeinstellungen? Das Ding soll doch nicht durch unerkannte versteckte Fehler vom Himmel fallen. Oder der Tiny hat doch so einen versteckten Bug. Kann ich aber immer noch nicht glauben. Den gibt es doch schon lange und man hätte schon was davon gehört?

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Timer 1 in zwei 8 bit Timer
    Von Martinius11 im Forum C - Programmierung (GCC u.a.)
    Antworten: 3
    Letzter Beitrag: 26.11.2010, 00:58
  2. Attiny13 als 555er Timer
    Von X1CR im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 11
    Letzter Beitrag: 29.10.2010, 15:56
  3. C167 Drehzahlberechnung mit Timer 3 od. Timer 3 & 4?
    Von cieks0301 im Forum Software, Algorithmen und KI
    Antworten: 5
    Letzter Beitrag: 13.03.2009, 11:37
  4. timer preset bei ATTiny13...
    Von dl1akp im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 1
    Letzter Beitrag: 10.04.2008, 15:14
  5. PWM mit Timer 0 und 2 geht, aber nicht mit Timer 1 (mega64)
    Von popi im Forum C - Programmierung (GCC u.a.)
    Antworten: 3
    Letzter Beitrag: 14.06.2006, 17:00

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test