ATTiny13 Timer unregelmäßig

[Searcher]

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

[HeSt]

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

[Searcher]

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

[HeSt]

Bzgl. Probleme mit dem Tiny bin ich ganz deiner Meinung!
Hab bislang auch keine gehabt.
Zum Umwandeln/Assemblieren verwende ich noch AVR 4.0.
Zum Flashen (auch Fuses setzen - aus Sicherheitsgründen nur Taktung möglich) LPmikroISP.exe von Franzis (aus dem Lernpaket).
Die Fuses sind außer dem Takt: 1,2MHz = CKDIV8=1 (hexwert: 7A FF) Standard.

LGH

[HeSt]

Das Problem scheint gelöst zu sein.
Egal welche Variante des Codes nun neu umgewandelt wird - es gibt keinerlei Unregelmäßigkeiten mehr.
Auslöser dürfte der PC (Win XP SP3) sein.
Ich fahre den PC fast nie herunter sonder lege ihn in den "Ruhestand": RAM auf Platte und beim Starten wieder laden.
Geht schneller und alles ist wie gehabt offen.
Hatte schon einige kuriose Probleme mit anderen Programmen, die durch herunterfahren und neu starten wieder behoben werden konnten.
Nach einem Update für das Betriebssystem habe ich den PC nieder und wieder hoch gefahren ...
Seither nach neuerlichem assemlieren/umwandeln der Codes keine Probleme mehr mit dem Timer!

Es scheint also, als würde das "nicht Herunterfahren" nicht nur zu Problemen bei diversen Programmen zu führen, sondern auch nicht definierbare Problem beim AVR-Studio (in meinem Fall V4.0) hervorrufen - im konkreten Fall beim Umwandeln eines Assembler-Codes in die .hex-file.

Somit ein Tip: vor Umwandeln eines Programmes den PC nie zu oft in den "Ruhestand" schicken sondern nieder und hoch fahren!!!

Gruß Heinz

[HeXPloreR]

...
Ich fahre den PC fast nie herunter sonder lege ihn in den "Ruhestand": RAM auf Platte und beim Starten wieder laden.
Geht schneller und alles ist wie gehabt offen.
Hatte schon einige kuriose Probleme mit anderen Programmen....

Hallo,

ich sage es mal ganz vorsichtig und diplomatisch: Es ist eigentlich ziemlich unwirtschaftlich den PC NIE auszuschalten sondern NUR in Ruhemodus zu versetzten.

Meiner Meinung nach bietet sich sowas an wenn man wirklich nur für eine Weile (2-3h vielleicht) die arbeit am PC unterbricht. Aber doch nicht für den Dauereinsatz. So schnell braucht man doch nun wirklich keinen Zugriff auf seinen "normalen" Haus-PC *kopfschüttel*.
Und ich hatte immer die Vermutung das ein WinXP-Nutzer vollautomatisch das Problem mit dem "mal neu starten" lernt. Man sollte diese Meldung/Aufforderung auch mal nachkommen, und nicht immer nur aus Bequemlichkeit wegklicken.

Vielleicht mal den PC aufräumen, und wenige Verknüpfungen auf dem Desktop.

Ich habe sämliche Programme die ich zum Programmieren und CAD benötige in einen Ordner .... der natürlich auf dem Desktop liegt
Und nur wenn ich davon welche benötige öffne ich diese, sonst bleiben die zu und verbrauchen keine Ressourcen die ich woanders benötige.
Ich habe auch nicht soviel Strom übrig, das ich nicht wüßte wohin mit dem ganzen Zeug.
Und nur die wenigsten Dinge laufen bei mir "bewußt" ständig... der PC gehört bei mir ganz sicher nicht dazu

Naja, wenigstens läuft es jetzt

Viele Grüße

... "fast" NIE auszuschalten/runterzufahren

[oberallgeier]

... den PC aufräumen ... wenige Verknüpfungen auf dem Desktop ... nicht soviel Strom übrig ...

Wie wahr, wie traurig wahr. Es ist mir, als höre ich die (wöchentliche) Weihnachtsansprache unserers EDV-Leiters. Wöchentlich aber nur an manche ausgewählte Zuhörer. Wobei Verknüpfungen ja noch gehen, ich kenne so manchen Zeitgenossen, der statt Verknüpfungen - warum auch immer - gleich ne Kopie auf den Desktop legt. Bei mir liegen viele Links in einem Link der "Links" heisst. Und dann gibts noch ein Aufräumprogramm gegen Junk-Dateien, mit nem Registry-Cleaner und einem Internet-Restevernichter (System Speedup), heisst bei mir 360amigo. Da startet mein zehn Jahre alter Desktop (Fujitsu Siemens Celsius M 410 Workstation, WXPpro) zwar immer noch mit ner satten Minute, aber gegen den Schnellstart des Notebooks (VAIO SVE171...) aus dem Sleep mit rund 20 sec ist dieser zusätzliche Zeitbedarf sowieso nur ein Klacks.

[Searcher]

Das Problem scheint gelöst zu sein.
Egal welche Variante des Codes nun neu umgewandelt wird - es gibt keinerlei Unregelmäßigkeiten mehr.

Super. Danke für die Info.

Es scheint also, als würde das "nicht Herunterfahren" nicht nur zu Problemen bei diversen Programmen zu führen, sondern auch nicht definierbare Problem beim AVR-Studio (in meinem Fall V4.0) hervorrufen - im konkreten Fall beim Umwandeln eines Assembler-Codes in die .hex-file.

Ein seltener Fall von: Fehler sitzt doch nicht vor der Tastatur

Gruß
Searcher