Hi Leute, habe mein c programm in AVR studio 7 geschrieben und auch mit simulator geprüft. attiny läuft mit internen 8mhz osci. Das Programm macht folgendes: -Ein ausschalten per taster am INT0, dabei wird zwischen power down und active mode gewechselt. Der letzte status wird beim int0 betätigen aus dem eeprom gelesen. Danach folgt ein LED blinken in 50ms schritten in einer while schleife Durch klicken einens zweiten tasters wird eine pin change ISR ausgeführt und eine variable geändert. Anschließend kehrt er zurück zur while schleife. Das ganze funktioniert mit 5V mit debugwire, simulator und ohne debugwire ständig einwandfrei. Nur unter 3,9v will das ganze überhaupt nicht klappen. Mit debugwire ist mir aufgefallen, das nach dem pinchange ISR der int0 ISR aufgerufen wird, aber die power taste(int0) wird nicht betätigt. das c programm tut für mich aber nichts zur sache, da es nur unter 3,9V immer auftritt. Laut datenblatt müssen mit 3,3v die 8mhz möglich sein. habe ich etwas übersehen? oder hat vll. jemand einen tipp wie ich den bug eingrenzen könnte. PS: hab zwischen zeitlich den clkdiv8 aktviert für die 1mhz, aber das problem tritt weiterhin auf.
:
Bearbeitet durch User
Ließt sich für mich wie: Wenn du einen prellenden Taster am INT-Pin per Flanke oder Pin-Change auswertest, ist es Zufall, ob/wann/wie gut es funktioniert. Glückwunsch: Der Simulation ist das egal. Glückwunsch: Bei Zimmertemperatur und 5V Versorgung scheint es irgendwie zu gehen. Pech: Mit anderer Betriebsspannung oder vielleicht im Winter nicht mehr. Und auch eine Hardware-Entprellung per RC-Glied löst das Problem nicht unbedingt, die (realen, nicht min/max-Werte aus dem DB) Schaltschwellen des AVRs sinken nicht unbedingt linear mit der Versorgungsspannung. Also: Richtig machen. Keine Taster an Pin-Change oder Flanken-Interrupts. Zum aufwachen Level-IRQ. Auswertung mit Entprellung in Software. Und warum speicherst du im EEPROM, ob der µC grad läuft oder schläft? Das weiß der auch so, wenn er läuft schläft er nicht, ganz einfach....
Wo kommt denn die Versorgungsspannung her? Ist sie stabil? hast du einen Abblock-Kondensator an VCC und GND (direkt am IC)?
User 7. schrieb: > hat vll. jemand einen tipp wie ich den bug eingrenzen > könnte. Divide et impera Teile das Programm in einzelne Funktionen auf und prüfe die jede für sich. Ich mache es immer so, daß ich zuerst die Funktion implementiere. Das Stromsparen kommt dann erst hinzu, wenn alles andere einwandfrei läuft. Zum Aufwachen nehme ich einen leeren Pin-Change-Interrupt, denn das Tasten entprellen und auswerten macht ja bereits der Timerinterrupt.
1 | EMPTY_INTERRUPT(PCINT_vect); // wake up from power down |
Beitrag "AVR Sleep Mode / Knight Rider"
> Ließt sich für mich wie: > Wenn du einen prellenden Taster am INT-Pin per Flanke oder Pin-Change > auswertest, ist es Zufall, ob/wann/wie gut es funktioniert > Also: Richtig machen. Keine Taster an Pin-Change oder > Flanken-Interrupts. > Zum aufwachen Level-IRQ. Auswertung mit Entprellung in Software. am Int0 hab ich low level auslösung um den power status zu ändern. An pin change aber nur eine flankenauslösung. Dieser wird nur ausgeführt, wenn der uC an ist. Nach beiden tastendrucks erfolgt eine tastenentprellung. > Und warum speicherst du im EEPROM, ob der µC grad läuft oder schläft? > Das weiß der auch so, wenn er läuft schläft er nicht, ganz einfach.... damit er die tastenentprellung beim starten nicht mehrmals durchläuft. prüf ich ob der uC an ist und leite in an die while schleife mit der led. dort bleibt er solange bis wieder int0 gedrückt wird. Ist mir auf die schnelle nichts anderes eingefallen. >Wo kommt denn die Versorgungsspannung her? Ist sie stabil? hast du einen >Abblock-Kondensator an VCC und GND (direkt am IC)? Labornetzteil und 100nF sind am uC. >Fuses / Brown-Out ? ist aus.
Peter D. schrieb: > Teile das Programm in einzelne Funktionen auf und prüfe die jede für > sich. Ich würde erst einmal checken ob es eher ein Softwarefehler oder ein Hardwarefehler ist. Softwarefehler kommt mir auf den ersten Blick recht unwahrscheinlich vor. Man könnte mal eine LED in der Hauptschleife toggeln und eine andere per Timner-Interrupt. Dann mal schauen, ob eine oder beide aufhören, zu blinken.
Stefan ⛄ F. schrieb: > Ich würde erst einmal checken ob es eher ein Softwarefehler oder ein > Hardwarefehler ist. Da beides ja streng geheim ist, läßt sich das nicht feststellen. Meine Glaskugel sagt, daß bei VCC=3,9V an nem IO-Pin immer noch 5V anliegen. Dann hat der MC selbstverständlich das Recht, allen möglichen Unsinn auszuführen.
Peter D. schrieb: > User 7. schrieb: >> hat vll. jemand einen tipp wie ich den bug eingrenzen >> könnte. > > Divide et impera > Teile das Programm in einzelne Funktionen auf und prüfe die jede für > sich. > > Ich mache es immer so, daß ich zuerst die Funktion implementiere. Das > Stromsparen kommt dann erst hinzu, wenn alles andere einwandfrei läuft. > Zum Aufwachen nehme ich einen leeren Pin-Change-Interrupt, denn das > Tasten entprellen und auswerten macht ja bereits der Timerinterrupt. >
1 | > EMPTY_INTERRUPT(PCINT_vect); // wake up from power down |
2 | >
|
> Ohne sleep funktion läuft der uC bei 5V als auch 3V. also musste etwas mit den 3V und sleep funktion zusammenhängen. Peter D. schrieb: > Da beides ja streng geheim ist, läßt sich das nicht feststellen. > Meine Glaskugel sagt, daß bei VCC=3,9V an nem IO-Pin immer noch 5V > anliegen. Dann hat der MC selbstverständlich das Recht, allen möglichen > Unsinn auszuführen. Deine Glaskugel hätte ich gern :). Am Int0 pullup waren bei nicht gedrücktem Taster nur 1,55V messbar. Es war eine LED+10k in reihe geschalten. Nachdem ich 220R + LED in Reihe und den 10K parallel zur LED gemacht hatte, waren es genau 3V Vcc. Und damit hat es perfekt funktioniert. leichtsinns fehler. Danke für eure guten Ratschläge.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.