Hallo, ich habe ein Programm in C geschrieben und mittels avrdude auf mein ATmega8 geflasht. so weit so gut. das Programm macht wie es soll. Nun kommt es vor das manchmal der Reset betätigt werden muss um mein Program wieder in einen calibrierungsmode zu bringen, wenn ich dies mache, startet es manchmal wie gewollt und manchmal macht es nur misst.Komplett die Versorgungsspannung AN/AUS macht den gleichen fehlertyp. Wenn ich das Programm neu geflasht hab funktioniert es immer sofort(zufall?). An was könnt es liegen? Softwarefehler oder eher ein Problem mit der Spannungsversorgung etc.? Ich habe alle wichtigen leitungen mit Pull-ups/down versehen, und bei der HW handelt es sich um eine Motorsteuerung. Weiterhin benutz ich nur einen Interupt für nen Taster im code. hat jemand eine idee? gruss lars
ergänzend muss ich noch sagen: Wenn das Programm nach den reset "misst" baut erkennt er aber immernoch mein tasterevent und reagiert indem er den motor beliebig schaltet. im anhang der Schaltplan, habe ich ungefähr so nachgebaut(Led gedreht etc.)
danke für die antwort. ich denke es hat alles einen init. als anhang jetz der code;-) ich hoffe ist lesbar.
TLars schrieb: > im anhang der Schaltplan, habe ich ungefähr so nachgebaut(Led gedreht > etc.) ungefähr wertlos... motor entstört? freilaufioden-dioden? reset-C?
um genauer zu sein ich habe, ich habe den zweiten enable vom L298 auf PB0 mit pull down gezogen und die Led an den Ports gedreht gruss Lars
Es wundert mich, dass dein Programm überhaupt (sinnvoll) läuft... Die wichtigste Funktion scheint _delay_ms() zu sein. Du solltest dir unbedingt mal das Thema Zustandsautomaten näher ansehen. Die main-Schleife wird immer mit voller Geschwindigkeit durchlaufen, und darin abhängig vom aktuellen Zustand der Maschine (mit switch+case) in bestimmte Programmteile verzweigt. > GICR |= (1<<INT0); // enable Taster Tastenabfragen gehen üblicherweise anders. Man liest den Taster ein, macht eine Entprellung und verarbeitet das dann weiter. > erkennt er aber immernoch > mein tasterevent und reagiert indem er den motor beliebig schaltet. Ich bin mir ziemlich sicher, dass du selber nicht mehr durchblickst, in welchem der verschachtelten Zustände dein Programm sich verklemmt hat. Mach da doch mal Debugausgaben in Form von LEDs mit rein... Zur Hardware: wie hast du das aufgebaut? Lochraster, Platine (falls ja: wie sieht das Layout aus)? Wie sieht die Masseführung aus? Du solltest jetzt erst mal sicherstellen, dass der Motor nicht irgendwie den uC durcheinanderbringt. Dazu wäre ein simples und überschaubres Testprogramm nötig. BTW: sowas sollte es grundsätzlich nicht geben:
1 | ISR (INT0_vect){ |
2 | :
|
3 | _delay_ms (100); |
4 | :
|
5 | }
|
Ein Delay im ms-Bereich hat in einer ISR nichts zu suchen. BTW2: das ist auch komplett unnötig:
1 | while(1) // drive reverse till on reset position |
2 | {
|
3 | :
|
4 | if(Adc_value>=TRESHOLD) |
5 | {
|
6 | :
|
7 | goto rst_position; |
8 | }
|
9 | }
|
10 | rst_position: |
C != Basic. Statt goto schreibt man das so:
1 | while(1) // drive reverse till on reset position |
2 | {
|
3 | :
|
4 | if(Adc_value>=TRESHOLD) |
5 | {
|
6 | :
|
7 | break; |
8 | }
|
9 | }
|
> oder eher ein Problem mit der > Spannungsversorgung etc.? Der Vcc-Anschluss des Prozessors ist nicht an Vcc angeschlossen. Gruß, Peter
Hallo und danke für die antworten. @Lother zur HW: ja das ganze habe ich auf Lochraster aufgebaut, und die massseführungen sind so kurz wie möglich gehalten.Masse trifft sich beim HEBW und geht dan von da auf seperaten wegen zu ATmega und L298. Allgemein die frage: unabhängig von der schlechten Programmierung des codes, wenn ich weiss das der code geht , und nach einen Reset nicht mehr.Kann das überhaupt dan am Programmierstil/SW liegen( beim reset wird ja wieder alles zurückgesetzt,variablen etc.) oder eher an der Hardware(was ich denke).
TLars schrieb: > Allgemein die frage: unabhängig von der schlechten Programmierung des > codes, wenn ich weiss das der code geht Die Frage ist: geht der Code überhaupt? Das alles ist so dermassen unübersichtlich programmiert, dann sich diese Frage nicht beantworten lässt
1 | ISR (INT0_vect){ |
2 | unsigned char sreg = SREG; |
3 | //transmit_str_USART("Int0 \n ");
|
4 | INT_TASTER=1; // setze Flag |
5 | GICR &= ~(1<<INT0);// disable Int0 |
6 | _delay_ms (100); |
7 | SREG=sreg; |
8 | }
|
lass wenigstens das SREG Register in Ruhe! Woher kommt blos diese Unsitte, sich in C an den Prozessorregistern zu vergreifen? Die gehen dich nichts an! Die stehen unter Verwaltung des Compilers und nur der kümmert sich um diese Register. Sonst niemand
ja der code funktioniert sicher wenn er denn einmal richtig gestartet ist. das mit den sreg war copy und paste aus einen tutorial. und die 100ms delay in der ISR ist meine entprellung, ich weiss ist nicht schick aber da eh keine anderen interrups vorhanden sind, dacht ich mir mach ich es da rein. zu meinen akt Fuses.:ich habe zur zeit lFuse:0xFF und hFuse:0xD9 gesetzt siehe link: http://www.engbedded.com/fusecalc ich werd mal das Boden Fuse setzen und schauen was passiert.
> ja der code funktioniert sicher wenn er denn einmal richtig gestartet > ist. Wer gestartet? Der Code? Oder deine Maschine? Und wie schaffst du einen Start, dass er garantiert geht? Klappt das überhaupt, oder ist jeder Start ein Bangen und Hoffen? >>> das manchmal der Reset betätigt werden muss um mein >>> Program wieder in einen calibrierungsmode zu bringen Ja, sind wir denn bei Windows, dass für eine simple Referenzfahrt schon ein Reboot nötig ist? :-o Ich bin mir ziemlich sicher, dass du ein Softwareproblem hast. Wer hält dagegen? > Masse trifft sich beim > HEBW und geht dan von da auf seperaten wegen zu ATmega und L298. Das mit der Versorung am Pin 7 war noch offen...
Peter Bünger schrieb: > Der Vcc-Anschluss des Prozessors ist nicht an Vcc angeschlossen. Wie stehts damit eigentlich?
TLars schrieb: > ja der code funktioniert sicher wenn er denn einmal > richtig gestartet ist. Also funktioniert er nicht :-) > das mit den sreg war copy und paste aus einen tutorial. und die 100ms > delay in der ISR ist meine entprellung, delays macht man nie leichtfertig rein. Und schon gar nicht in Interrupt Routinen. > ich weiss ist nicht schick aber > da eh keine anderen interrups vorhanden sind, dacht ich mir mach ich es > da rein. Darum gehts eher weniger. Wenn ein Interrupt nur einigermassen häufig genug auftritt, dann macht dir der delay da drinnen den kompletten µC dicht. Und zwar schon weit früher als man das aufgrund der Arbeitsgeschwindigkeit (und ohne delay) annehmen könnte. > ich werd mal das Boden Fuse setzen und schauen was passiert. BODEN ist sicher gut. Aber kümmerer dich erst mal um dein Programm. Das ist ja schauderhaft. Fang wenigstens damit an, die vielen immer gleichen Programmteile in Funktionen auszulagern um die Komplexität runterzubringen und mehr Übersicht reinzubringen.
das setzen von der Boden Fuse hat es gebracht. jetzt geht es einwandfrei;-) gruss Lars
BODEN Anschalten und es läuft? Ich denke der läuft jetzt nur immer wieder von vorn los, wenn es übermäßige Spannungseinbrüche gibt. mf
Habe genau das selbe Problem. Programm läuft seit 2 Monaten ohne Probleme, jetzt habe ich den Reset Pin angedrahtet und nur noch einzelne Teile des uC laufen. BODEN bringt da bei mir leider garnichts. Suche weiter und melde mich wenn ich den Fehler gefunden habe. Funktioniert es bei dir jetzt wirklich ?
Dann fängt sich der Pin Störungen ein. Aber fang jetzt bitte nicht an, den Pin zu entstören...
hallo @tweety ja das Program macht jetzt was es soll, auch nach reset...boden fuse hat also bei mir das Problem gelöst. Ein tipp den ich wegen diesen Problem noch bekommen hatte war doch mal im Program alle Variablen , auch Schleifen index, auf volatile zu setzen.(falls du denkst es ist ein SW-Problem). Gruss Lars
Thread beobachten
Seitenaufteilung abschaltenBitte 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.