Ich bin etwas verzweifelt: Keines meiner Programme die ich geschrieben habe läuft mehr richtig. -Ich habe die qC ausgetauscht. -Ich habe die Applikation getauscht. (Andere Anwendung) -Fuse bits natürlich gecheckt Somit schliesse ich aus: - qC defekt - Elektrischer Fehler in der Anwendung oder anderes Bauteil defekt. - Fehler im Programm bleibt: STK500 oder AVR Studio 4, sehe ich das richtig? Beschreibung des Symptoms am Beispiel einer Eieruhr die funktioniert hat(!): Bei den 7 Segment anzeigen werden die falschen Segmente angefahren. Und es werden beide Stellen der Sekunden gleichzeitig heruntergezählt. Akkustischer Alarm und abschalten der Uhr mit Distanzsensor funtioniert aber! Ich kann damit garnichts anfangen! Vielleicht hat jemand von euch schonmal sowas erlebt? Und weiss Rat?
Gast
#2087867
...oh, da muss ich mich aber SEHR tief über meine glaskugel beugen und... ...nein, sehe immer noch nichts ! sourcecode ? schaltung ?
Gast
#2087869
Attila Ciftci schrieb: > Somit schliesse ich aus: > - Fehler im Programm das ist mutig, das ist das währe das erste programm was fehlerfrei ist. Hast du noch das alte HEX-File da, wenn ja dann übertrage es doch mal in den neuen µC? Wenn es dann geht, kannst du ja das alte mit den neuen vergleichen.
Gast
#2087880
>Keines meiner Programme ... läuft mehr richtig
Vermutung:
1. Es hat irgendeine Veränderung stattgefunden. Woran? Neuer PC, neues
STK, neues AVRStudio, neu installiert? Was?
2. Das AVRStudio 4 oder STK500 sind nicht fehlerhaft.
Situation:
1. Art der Veränderung ist unbekannt.
2. Beispielcode und Schaltung die nun nicht mehr gehen sind unbekannt.
Schlussfolgerung:
1. Mehr Informationen vom Fragesteller einholen.
Neugierig:
"qC" soll ein "uC" sein? Was heisst das "q"?
Gast
#2087881
Hi >Somit schliesse ich aus: >- qC defekt >- Elektrischer Fehler in der Anwendung oder anderes Bauteil defekt. >- Fehler im Programm >bleibt: STK500 oder AVR Studio 4, sehe ich das richtig? In 99% aller Fälle ist es umgedreht. Und die größte Fehlerquelle sitzt immer vor dem Bildschirm. MfG Spess
Ok: Ich habe heute kleine veränderungen an einem Programm gemacht die ein Boot steuert. Es hat ein Display was urplötzlich nur noch initialisiert wird aber sonst nichts zeigt. Ich habe an den Ausschlägen des Servos gearbeitet habe also nichts grossartig verändert! Nach probieren eines anderen Atmega 8 (der auch nicht ging) habe ich den Atmega von der Eieruhr genommen. Der ging auch nicht. Daraufhin habe ich das Eieruhrprogramm wieder aufgespielt und siehe da: Die Eieruhr spinnt jetzt auch. Ich gebe zu ich habe die 3te möglichkeit übersehen: Nämlich den Atmega 8 geschossen in der Schaltung für das Boot. Kann dies der Fall sein? Macht ein geschossener Atmega so "halbe Sachen" wie ich sie beschreibe? Mit "q" meine ich "Mikro" wie es z.B. auf Kondensatoren steht. Ich dachte mann schreibt es deswegen"qC"
Da steht doch µ drauf und nicht q? Ein kaputter Mega 8 kann grundsätzlich alles machen.
Nico Sch. schrieb: > Da steht doch µ drauf und nicht q? > > Ein kaputter Mega 8 kann grundsätzlich alles machen. Mann muss aber auch sagen, dass die Dinger robust sind. Solange du die nicht an 230V direkt anschliesst, überleben sie das meiste. Wie Spess schon sagte: Meistens sitzt das Problem vor dem Bildschirm, bzw ist ein Fehler im Programm. Das kann durchaus sein, dass sich ein Fehler erst in der nächsten Compilerversion zeigt, weil zb sich der Optimizer verändert hat. Die alte Version hat etwas nicht ausgenutzt, was die neue sehr wohl ausnutzt. Und schon wirkt sich ein Programmfehler aus.
Grundsätzlich: Wenn ich mir die Fehler die ich sonst so mache ansehe, stimme ich Spess und Karl Heinz zu: Die Quelle sehe ich sobald ich vor einen Spiegel trete! ;-) Die Schaltung sowie das Programm der Eieruhr habe ich nicht verändert! Das ist ja das verrückte: Ich habe nichts verändert! Und es fällt mir schwer zu glauben dass ich mit einem 12 Volt Akku einen Atmega schiessen kann. Ich habe allerdings den Atmega SEHR oft heute in den STK500 gesteckt und wieder herausgenommen. @Nico: Wo hast Du denn das Zeichen her? Das umgedrehte "q"?
Mein Tipp: Ein im Entwicklungsstudio zu klein eingestellter Stack oder Heap (falls du new oder malloc verwendest). Da bekommt man die schönsten Fehler, nichts ist mehr vorhersehbar und mitmal gehen Segmente an, die du noch gar nicht kanntest.
Gast
#2087940
Hi > Und es fällt mir schwer zu glauben dass ich mit einem 12 Volt Akku einen > Atmega schiessen kann. Wie ist das jetzt gemeint? MfG Spess
Gast
#2087949
>Und es fällt mir schwer zu glauben dass ich mit einem 12 Volt Akku einen >Atmega
schiessen kann.
Bewertung: Unbegründete Annahmen sind schädlich.
Empfehlung:
Um Dir die Sicherheit wiederzugeben: nimm einen frischen uC,
programmiere den mit dem Hex-File der Uhr, prüfe penibel nach ob Du das
richtige Hex-File hast. Diesen uC kannst Du dann für das Boot nehmen.
Vermutung: Veränderter Code des Boots fehlerhaft.
@Spess: Das Boot ist ein Modell und wird mit einem sogenanten "3S" Akku betrieben. Daraus folgt das meine Schaltung mit 11,nochwas Volt betrieben wird. Ich regel natürlich die Spannung (wie im Tutorial beschrieben) auf 5 Volt runter. Nicht effizient,ja, aber im Moment nicht so wichtig. Wie auch immer wäre ja das "Schlimmste" mit dem ich meinen Atmega quälen könnte folglich 11,irgendwas Volt. So war das gemeint.
Schonmal gecheckt, ob auch ein ATMega8 in der Konfiguration ausgewählt ist ? Hat bei mir mal lustige Effekte gemacht - z.B. wenn plötzlich andere Register beschrieben werden. ZigZeg
@Glaskugel: Das Programm des Boots liest ein GPS aus,steuert ein 2x16 Display, berechnet aus 2 Koordinaten den zu fahrenden Kurs, und steuert ein Modelbauservo. Das letzte was ich geändert habe war die Zahl "30" (Auschlag des Ruders nach voll rechts) zu "-30" (Auschlag des Ruders voll links) zu ändern. Dabei hatte ich die Berechnung des aktuellen Kurses ausgesetzt mit /* und */ Ich wollte die Vollauschläge justieren. (Mechanisch!) Rechts konnte ich noch machen. Und plötzlich zeigt mein Display nichts mehr??? Das Boot ist übrigens schon gefahren. Es hat nur übersteuert,daher kann ich mir nicht einen Fehler in der Schaltung oder im Programm mit DIESER Symptomatik vorstellen!
@Kai: Ja ich habe das verifiziert!
Attila Ciftci schrieb: > @Nico: Wo hast Du denn das Zeichen her? Das umgedrehte "q"? Aufm Mac ist das Alt + M (ist das griechische Mü), auf Windows ist das Alt Gr + M.
@Nico: Gefunden! Danke!
Sowas kann alles mögliche sein. Ein sauber nach innen umgebogener Pin am Controller, dem man auch bei noch so genauem Hinsehen nicht ansieht, daß er gar im Sockel steckt. Dgl. verbogene Sockelfeder, wenn's kein gedrehter Sockel ist. RAM-Grenze überschritten, Stack läuft in die Variablen. Netzteil defekt. Kurzschluss durch Lötspritzer, heruntergefallene Drahtreste. Nur um ein paar Sachen zu nennen, weswegen es bei mir irgendwann plötzlich nicht mehr funktionierte. mfg.
Gast
#2087997
> Das letzte was ich geändert habe war die Zahl "30" (Auschlag des Ruders > nach voll rechts) zu "-30" (Auschlag des Ruders voll links) zu ändern. > Dabei hatte ich die Berechnung des aktuellen Kurses ausgesetzt mit /* >und */ >Ich wollte die Vollauschläge justieren. (Mechanisch!) Rechts konnte ich >noch machen. >Und plötzlich zeigt mein Display nichts mehr??? Vermutung: 1. Der Code funktioniert, die machst die oben beschriebene Änderung und der Code funktioniert nicht mehr. Richtig? Information: 1. Irgendwelche Vermutungen darüber welcher Code mit welchem wechselwirkt oder nicht, sollte man nicht zur Basis der weiteren Vermutung machen, dass die Hardware oder AVRStudio oder das STK500 urplötzlich kaputtgegangen sind. Den Rest haben spess und Karl Heinz dazu schon gesagt. Empfehlung: Code wieder zurück ändern und erneut testen.
Gast
#2087999
Sorry, Rechtschreib-Sub-Glaskugel hatte Stromausfall: Es sollte heissen: "1. Der Code funktioniert, Du machst die oben beschriebene Änderung und der Code funktioniert nicht mehr."
Gast
#2088021
Exkurs: Ich weiss ja nicht wieviel Erfahrung Du schon hast, aber bei etwas grösseren Projekten sind "absurde" Wechselwirkungen durchaus nicht ungewöhnlich, wenn sie auch den Erfahreneren eher etwas seltener passieren. Auch der Schluss: "es muss die Hardware sein" aber "es kann nicht an der gerade erfolgten Änderung liegen" ist unter Erfahrenen nicht wirklich ungewöhnlich, wenn sie auch dazu tendieren dies sofort und vor allem direkt nachzuprüfen, in dem sie die Änderung erstmal wieder rückgängig machen. Dieser Umweg über ein weiteres Programm UND andere Hardware den Du gegangen bist, birgt wiederum Fehlerquellen die völlig in die Irre führen können, weil sie mit der Ursache oft garnichts zu tun haben, Dich also garnicht weiterbringen.
Nimm Dir ein Bier oder zwei oder ein Glas Rotwein, geh schlafen und schau Dir das morgen noch mal an. fchk
Gast
#2088038
>Nimm Dir ein Bier oder zwei oder ein Glas Rotwein, ...
Vermutung:
1. Ayran oder çay werden wohl eher passen.
@Glaskugel: Ich ändere in einem Code "30" zu "-30" und plötzlich geht etwas (Display) was mit der Zahl (für ein Servo!) nichts zu tun hat(!) nicht mehr! Ich ändere zurück zu "30", geht trotzdem nicht mehr. µC getauscht. Es geht nicht. µC aus einer anderen Anwendung (die seit Wochen funktioniert!) benutzt: geht nicht. Ursprüngliches Programm der anderen Anwendung wieder (!)auf den µC gespielt: Das geht auch nicht????? Folglich: Entweder alle µC bei Anwendung 1 "gegrillt" oder Avr Studio kaputt oder STK500 kaputt.
@Frank: Sehr weise Worte die ich natürlich beherzigen werde! @Glaskugel: Hahahahahahaha! Der war wirklich gut!
Gast
#2088063
>Ich ändere zurück zu "30", geht trotzdem nicht mehr. >Folglich: >Entweder alle µC bei Anwendung 1 "gegrillt" >oder Avr Studio kaputt >oder STK500 kaputt. Vermutung: 1. Schaltung wurde geändert 2. Schaltung wurde nicht geändert. Welche ist richtig? Bewertung: 1. Nicht wirklich unsinnig, Dein Schluss, aber eher unwahrscheinlich, was das AVRStudio oder das STK500 betrifft. Empfehlung: 1. Änderungen weiter zurücknehmen. bis es wieder geht. Falls viele Versionen vorliegen erstmal die Hälfte der Änderungen zurücknehmen und sich herantasten.
Gast
#2088064
>@Glaskugel: Hahahahahahaha! Der war wirklich gut!
Ich wollte bloss höflich sein. :-)
Gast
#2088070
Vermutung: 1. Falls es wirklich einmal mit dem Stand vor der Änderung auf -30 ging spricht das für ein Hardwareproblem. Empfehlung: 1. Pins des uC auf Form prüfen. 2. Schaltung komplett prüfen. Vermutung: 1. Du verwendest nicht die Möglichkeit den uC in der Schaltung per ISP zu programmieren? Richtig?
Ach Glaskugel! Wieso sollte ich eine funktionierende Schaltung ändern wenn ich doch nur die Ausschläge eines Servos mechanisch(!) ändern will? Das Einzige was geändert wurde war das Vorzeichen vor der "30"!!!!!!
Gast
#2088088
ich tippe auf was ganz anderes: du hast Code XXX_1 genommen und verändert zu Code XXX_2. Dann auf den ATmega geladen. -> Ging nicht mehr :( ->Änderungen zurück genommen -> Ging ebenfalls nicht mehr. :( Mein Tipp: Ursprünglich war NICHT Code XXX_1 auf dem µC sondern ein ganz annderer: CODE YYY Du hast also den falschen Code genommen(der nie lauffähig war) und diesen dann verändert. Das passiert recht schnell wenn man sich keine gute Projektstruktur schafft. Check mal obs daran liegt.....??
Gast
#2088094
>Wieso sollte ich eine funktionierende Schaltung ändern wenn ich doch nur >die Ausschläge eines Servos mechanisch(!) ändern will? Ich setze nichts voraus. Das "Ach Glaskugel!" verstehe ich so, dass Dir meine Denkart und Vorgehensweise nicht nützlich erscheinen. Ich halte mich also 'raus.
@Tobis: Ich habe "Bootfahren1" (ging schon ganz gut!) zu "Bootfahren2" verändert(geht plötzlich nicht!) Zurück zu "Bootfahren1" geht nicht mehr! Daher zum testen des µC "Bootfahren1" auf den µC der schon seit Wochen "Eieruhr1"macht gespielt: Geht nicht! "Eieruhr1"wieder in den µC der schon seit Wochen "Eieruhr1" macht gespielt (will schliesslich morgens Eier essen!) Geht nicht??????????
Gast
#2088116
bist du dir sicher, dass das "bootfahren1" und "eieruhr1" auch die software war die auf den µC war??
Gast
#2088119
ich meine damit...kannst du ein vertauschen der (vermeintlich) richtigen software ausschließen?
Nun bei "Eieruhr1" hat ja der Alarm, das Runterzählen so wie auch der Sensor funktioniert! Nur nicht die 7 Segment Anzeige! Es müssen also grössere Teile von "Eieruhr1" auf dem µC sein ;-) Wie bescheuert das klingt! ;-)
Gast
#2088127
das ist ja das gefährliche....man erstellt ein projekt 1.dieses ist nicht ganz zufriedenstellend..außerdem hat man eine idee wie das ganze besser aufgezogen werden kann. -> man lässt es und erstellt eine software 2. 3 jahre später kann es durchaus mal passieren dass man dann anstatt projekt 2 das projekt 1 lädt und denkt es ist das auf dem µC befindeliche. Aber wenn du dies auschließen kannst...gut! :) war nur eine idee...:D
Hast du eventuell an einer Library rumgefingert, welche von allen betroffenen Programmen gemeinsam genutzt wird? Gruß, Magnetus
@tobis: Durchaus! :-) Ich denke ich mache es für heute wie Frank es vorgeschlagen hat, und freue mich schon auf den Moment wenn ich die Lösung von dieser Sch.... hier posten kann!
Gast
#2088141
>"Eieruhr1"wieder in den µC der schon seit Wochen "Eieruhr1" macht >gespielt (will schliesslich morgens Eier essen!) >Geht nicht?????????? Das HEX File was schon fertig rumlag oder Programm neu compiliert? Alleine da kann schon der Fehler liegen. Neues Programm mit Optimierung compiliert kann ein anderes Ergebnis bringen wenn ohne Optimierung gerade noch so funktioniert. Programm "Eieruhr1" posten. Dann finden wir den Fehler schon.
@Magnus: Ich weiss überhaupt nicht wie man an einer Library rumfingert!
@Holger: AVR Studio und dann "load" Wenn ich "Eieruhr1" hier poste werde ich sicherlich komplett demontiert!
Attila Ciftci schrieb: > Wenn ich "Eieruhr1" hier poste werde ich sicherlich komplett demontiert! Wenn du den Code nicht postest, wirst du erst recht demontiert und (wenn du viel Glück hast) als was ganz anderes wieder zusammengesetzt ;o)
Gast
#2088179
Hand langsam runterschieben... die behaarte Gegend suchen... und mit den fingern rumspielen.... und schon funzt die lib net mehr :/
Gast
#2088186
>> Wenn ich "Eieruhr1" hier poste werde ich sicherlich komplett demontiert! >Wenn du den Code nicht postest, wirst du erst recht demontiert und (wenn >du viel Glück hast) als was ganz anderes wieder zusammengesetzt ;o) Er ist ja schon darauf aufmerksam gemacht worden, das der Code nicht da ist. Beitrag "Re: Programme haben plötzlich bugs. AVR Studio 4 und STK500" Hat er ignoriert.
@MPL: Aua aua, ganz armselig! @Glaskugel: Ich bleibe dabei dass der Code überhaupt keine Rolle spielt da er bereits WOCHENLANG zum Eierkochen diente und funktioniert (e)! Aber bitteschön, anbei der Code!
Gast
#2088200
> _delay_us(x); Schon das erste AUA. Das geht so nicht. _delay_us() nimmt nur Konstante als Parameter. > _delay_ms(2000); Ob das dein Compiler kann ist auch fraglich. Früher gab es da mal Einschränkungen. Und die ganzen cli() sei() bereiten mir Bauchschmerzen;)
Gast
#2088202
> float i=0
Oh ha, noch son Ding. Wozu float?
Du solltest dir auch dringend angewöhnen deinen Code zu kommentieren.
Eben das meinte ich: Jetzt wird hier meine Eieruhr demontiert statt auf mein Problem einzugehen! Nochmal zum MITSCHREIBEN: Die Eieruhr hat WOCHENLANG funktioniert! Ich will nicht wissen (zumindest nicht im Moment und in diesem Thread) was euch an meinem (ursprünglich FUNKTIONIERENDEN Program) nicht gefällt! Sondern warum es nicht mehr geht! Und das hat NICHTS aber auch GARNICHTS mit dem angefügten listing zu tun! Mir sind die "Unzulänglichkeiten" des listings bewusst (Ja ich lese viel und dankbar bei mikrokontroller.net) Und: es ist mein 2tes je geschriebenes Programm in C. Es könnte besch......ener sein!
Gast
#2088222
>Eben das meinte ich: Jetzt wird hier meine Eieruhr demontiert statt auf >mein Problem einzugehen! Das Programm ist dein Problem. Anders kann man es nicht sagen. >Sondern warum es nicht mehr geht! Neuen Compiler benutzt? Optimierung eingeschaltet? Der spuckt dir jetzt kräftig in die Suppe;)
Genau so mache ich es: 1) Hand nach unten! 2) Nicht mehr float verwenden! 3) Code kommentieren! (Ironie an!)Dann geht meine Eieruhr auch wieder! (Ironie aus!)
@Holger: Nein, nichts dergleichen. Nur viel µC raus und wieder einstecken. Weder neuen Compiler benutzt, noch weiss ich wie man die Optimierung verändert!
Kannst du bitte kurz die (beabsichtigte) Funktion deines Programms beschreiben? Bitte sag jetzt nicht "das ist eine Eieruhr"! Ich würde gerne wissen, wofür du den ADC verwendest. Vielleicht können wir ja den Code mal bei uns compilieren und auf unserer Hardware testen. Hierfür wäre es aber notwendig zu wissen, wie die Peripherie aussehen muss (und wozu der Analogwert dient).
Gast
#2088238
Aus meiner Erfahrung noch zusätzlich: Flahst Du das richtige hex-file? Ich hatte mich schon gewundert, dass keine Codeänderung Wirkung zeigte, bis ich gesehen habe, dass ich immer das gleiche aber nicht aktuelle hex-file geflasht habe. Ergänzung zu Holger: Wenn eine Software nicht sauber geschrieben ist, kann sie mit einer Optimierungseinstellung funktionieren, mit einer anderen aber nicht mehr. z.B. bei Flags, die im Interrupt gesetzt werden und in der Hauptschleife ausgewertet werden. Ohne Optimierung läufts, mit läufts nicht mehr. volatile hilft Michael
Michael R. schrieb: > volatile hilft Volatile hadda drinn.
@Magnus: Nochmal: Die Eieruhr lief und muss eigentlich nicht getestet werden! Das ADC wertet einen Abstandssensor aus. Hand vor die Eieruhr halten macht: - Koch-Zeit in 30 Sekunden-Schritten erhöhen oder - Alarm aus Hand näher an die Eieruhr halten: Zeit schneller in 30 Sekunden- Schritten erhöhen -Mehr als 9:30 geht nicht -Uhr fängt so wie jetzt programiert bei 3 Sekunden an (Demo -Zweck) Idee dahinter: Wer kocht sein Ei 4:53? Hat aber alles nichts mit meinem ursprünglichen post zu tun finde ich !
Attila Ciftci schrieb: > Nochmal: Die Eieruhr lief und muss eigentlich nicht getestet werden! Wenn es nicht am Programm liegt, dann wird es ja wohl auch bei uns funktionieren, oder? > Idee dahinter: Wer kocht sein Ei 4:53? Hast du ne Ahnung ;) [Edit] Gegenfrage: Wer kocht sein Ei 9:30 oder 0:30? [/Edit] > Hat aber alles nichts mit meinem ursprünglichen post zu tun finde ich ! Das wird sich noch zeigen...
@Magnus: Es sollte bei euch funktionieren. Der Abstands-Sensor macht irgendws zwischen 0 und 3 Volt. Es ist ein GP2Y0 usw irgendwas. Es gibt Irre aber ich glaube die meisten Menschen kochen ihre Eier in 30 Sekunden Schritten:4:30, 5:00, 5:30, usw und eben NICHT 4:56 oder sowas.
Noch was: Was soll bei 0:00 passieren?
Ok! Der Einwand 0:30 und 9:30 ist berechtigt! Die Uhr ist nicht nur ausschliesslich für Eier da! Sondern auch um die "Auszeit" für einen kleinen manchmal sehr ungezogenen 3 jährigen zu bestimmen! Und: Wer hier in Windhoek in fast 2000 Meter Höhe ein hartes Ei möchte sollte es 9 Minuten kochen! Die Weichen kochen wir hier 6:30!
Bei 0:00 geht der Alarm los. ;-)
Attila Ciftci schrieb: > Nochmal: Die Eieruhr lief und muss eigentlich nicht getestet werden! > Hat aber alles nichts mit meinem ursprünglichen post zu tun finde ich ! Bin jetzt endlich mal dazu gekommen deinen Code durch den Compiler zu jagen [vr-gcc (WinAVR 20090313) 4.3.2]. main.c:65: warning: return type defaults to 'int' main.c:65: warning: function declaration isn't a prototype
1 | |
main.c:87: warning: operation on 'i' may be undefined
1 | |
main.c:101: warning: operation on 'min' may be undefined
1 | |
main.c:118: warning: operation on 'min' may be undefined
1 | |
main.c:143: warning: operation on 'a' may be undefined
1 | |
main.c:147: warning: operation on 'x' may be undefined
1 | |
main.c:158: warning: operation on 'x' may be undefined
1 | |
main.c: In function '__vector_8': main.c:181: warning: operation on 'sek' may be undefined
1 | |
main.c:185: warning: operation on 'dez' may be undefined
1 | |
main.c:189: warning: operation on 'min' may be undefined
1 | |
Gast
#2088357
Oh Mann, schönes Beispiel! Da hat jemand irgendwann mal etwas falsch abgeschrieben oder nicht verstanden, sich das so eingeprägt, und wendet das nun konsequent an. Und zwar in allen Programmen, die er schreibt. Der Fehler nutzt eine Eigenschaft des Menschen beim Lesen eines Textes oder Quellcodes perfide aus - man schaut eigentlich nur die ersten und letzten Zeichen eines "Wortes" (also eine Gruppe Buchstaben ohne Leerzeichen) an und ergänzt den Rest im Kopf. Beispiel: Gmäeß eneir Sutide eneir elgnihcesn Uvinisterät, ist es nchit witihcg in wlecehr Rneflogheie die Bstachuebn in eneim Wrot snid, das ezniige was wcthiig ist, ist daß der estre und der leztte Bstabchue an der ritihcegn Pstoiion snid. Der Rset knan ein ttoaelr Bsinöldn sien, tedztorm knan man ihn onhe Pemoblre lseen. Deshalb können 40 erfahrene Mikrocontroller-Foren-Mitleser den Quelltext herunterladen und an Details herummäkeln, ohne dass jemandem diese "unübliche" Schreibweise der Inkrementation auffällt. Der Compiler spuckt nun die entsprechende Warnung aus: x=x++ ist undefiniert! Und damit ist meiner Meinung nach klar, dass der Fehler an einem unbemerkten Update des Compilers oder der Änderung der Einstellungen (Optimierung) zurückzuführen ist.
Gast
#2088369
Was Gerhard sagen will: schreib einfach "min--;" anstatt "min=min--;" Mal ins blaue geraten: Servo-Ausschlag geändert, keine Freilaufdiode, µC geschossen?
Gast
#2088384
Gerade mal durchgetestet: Ob "test = test++;" oder "test++;" ist egal, trotz der Compilerwarnung. Mit und ohne Optimierung wird derselbe Code erzeugt. (avr-gcc 4.3.5)
In meinen C Büchern steht dass es wurscht ist ob man "min--" oder "min=min--" schreibt! Genau SO habe ich es verstanden, abgeschrieben und wende es auch an: "min=min--" gefällt mir besser da ich es verständlicher und übersichtlicher finde. Es kann natürlich sein dass Herr Jürgen Wolf und Herr Helmut Erlenkötter Idioten sind die Mist in ihren Büchern erzählen. Das glaube ich aber schlichtweg nicht. Ich habe lediglich ein vormals laufendes Programm auf einen µC gespielt um zu testen ob der µC in Ordnung ist. Nochmal: -Keines meiner vormals laufenden Programme läuft mehr. -Ein update von AVR Studio habe ich aktiv nicht vorgenommen. -Wie man die Optimierung ändert weiss ich überhaupt nicht. Ich habe jetzt mehrfach beschrieben was, wie, wann passierte und finde es traurig dass es nur dazu gedient hat mir zu erklären dass manche hier C besser können als ich (Weiss ich schon!) statt das Problem anzugehen. Nun haben wir also diskutiert: -Wo die Hand hin muss um Behaartes zu finden -Jemand hat ein "float" gestört -Jemand hat ein delay_ms(2000) gestört -Jemand hat gestört das ich mein listing nicht kommentiert habe -Wie meine Eieruhr funktionert -Wie lange man ein Ei kocht -Ob man "min--" statt"min=min--" schreibt -ob jemandem irgendwelche Bauchschmerzen hat. usw...... Eine Änderung der oben genannten Punkte wird sicherlich nicht dazu führen das meine Programme plötzlich wieder laufen! Schade!Wirklich schade! Aber: Vielen Dank an diejenigen die konstruktive Kommentare gemacht haben (Checken ob der richtige µC gewählt ist, Lötspritzer,Bier oder Wein trinken und ähnliches) Ich poste sobald ich den Fehler gefunden habe!
Gast
#2088414
Wenn ein Compiler lauter warnings spuckt, hat das seinen Grund. Auch warning sollte man tunlichst beheben. Was die Lesbarkeit Deines i=i-- angeht: Entweder: i--; oder i=i-1; Letzteres ist die richtige lesbare Variante und der Compiler spuckt dann auch keine warnings mehr. Und sei nicht enttäuscht, dass hier nur Tipps kommen, die Dir noch nicht weitergeholfen habe. Wir können alle nicht hellsehen und sei froh, dass überhaupt versucht wird, Dir zu helfen. Vielleicht ist dert rettende Tipp mal dabei. Ich habe mir den code nicht angeschaut, aber sonstige übliche Kandidaten bei mir waren noch: - Über das Ende eines Arrays hinausgeschrieben - Pointer verhauen - Stack overflow Diese Fehler äußern sich je nach Compilerversion und Optimierungsgrad mit ganz unterschiedlichen oder keinen Fehlerbildern Dann noch: - "if a=1" statt "if a==1" geschrieben - Semikolon direkt hinter die "if"-Abfrage gesetzt. Michael
Gast
#2088418
Attila Ciftci schrieb: > In meinen C Büchern steht dass es wurscht ist ob man "min--" oder > "min=min--" schreibt! Ohje, die solltest du dringend entsorgen. > Genau SO habe ich es verstanden, abgeschrieben und wende es auch an: > > "min=min--" gefällt mir besser da ich es verständlicher und > übersichtlicher finde. Es ist einfach falsch, da undefiniert! Siehe auch http://c-faq.com/expr/ieqiplusplus.html > Es kann natürlich sein dass Herr Jürgen Wolf und Herr Helmut Erlenkötter > Idioten sind die Mist in ihren Büchern erzählen. Das glaube ich aber > schlichtweg nicht. Entweder du erzählst Mist, oder die Herren Wolf und Erlenkötter. > -Keines meiner vormals laufenden Programme läuft mehr. Bei deiner Einstellung wundert das hier vermutlich niemanden. > -Ein update von AVR Studio habe ich aktiv nicht vorgenommen. Aber so richtg weisst du auch nicht was du getan hast? > -Wie man die Optimierung ändert weiss ich überhaupt nicht. Aber dich damit beschäftigt (trotz Hinweis) hast du auch nicht? > -Jemand hat ein "float" gestört > -Jemand hat ein delay_ms(2000) gestört > -Jemand hat gestört das ich mein listing nicht kommentiert habe > -Ob man "min--" statt"min=min--" schreibt > > usw...... > > Eine Änderung der oben genannten Punkte wird sicherlich nicht dazu > führen das meine Programme plötzlich wieder laufen! Du weisst alles besser, willst nicht lernen und auch nichts korrigieren. Und Tschüss > Schade!Wirklich schade! Ach nicht weiter schlimm, ist ja nur dein Problem. > Ich poste sobald ich den Fehler gefunden habe! Das glaube ich nicht.
Gast
#2088440
Hast du noch ein altes Hex zum testen ? Compileroptions noch richtig eingestellt in AVR ?
Sorry! Ja "min= min-1!" Oder eben "min--" aber nicht "min=min-- Sorry! Mein Fehler! Das meine Codes nicht gut sind weiss ich. Ich gab es bereits zu und versuche es stetig zu verbessern! Ich habe nichts gegen den Rat von Profis. Ich nehme ihn sehr gerne an sonst würde ich hier nicht fragen!!! Wenn ich wüsste welchen Bockmist ich gebaut habe würde ich nicht fragen sondern es einfach korrigieren und gut ist. Daher beschreibe ich das ich eben NICHT ein update wissentlich(!!!) durchgeführt habe. Oder eben NICHT and der Optimierung gedreht habe. Ich mag nur nicht , im übertragenen Sinne, über den Reifendruck meines Fahrzeuges diskutieren wenn das Problem ist dass der Motor nicht anspringt. Die Tatsache das in diesem Forum sehr gerne Anfänger demontiert werden indem man einfach am Thema vorbeiredet um sich selber zu profilieren ist nicht nur Schade sondern auch: 1) nicht nur mein Problem. 2) von anderen kritisiert worden. Ich habe mich bei allen meinen Posts bemüht die Lösung des Problems zu posten alleine schon weil ich es selber beim durchforsten des Forums oft vermisst habe! Daher: @Michael: Vielen Dank für deine sachliche und konstruktiven Hinweise @marcus6100: Hochmut kommt vor dem Fall!
Gast
#2088464
noch ne idee, beim Flashen nicht das richtige hex ausgewählt, das stellt sich leider nicht automatisch mit um beim Projektwechsel. Beim Autoflash falsche Haken gesetzt ?
Wie versprochen hier die , wie ich finde unbefriedigende, Lösung: AVR Studio gelöscht, über Nacht downgeloaded, neu installiert und siehe da: Alles geht wieder! Unbefriedigend weil es demnach das AVR Studio gewesen sein muss. Ich halte es aber für sehr unwahrscheinlich das Programme auf Rechnern einfach mal eben so kaputt gehen. Tut mir leid ich wünschte ich könnte Konkreteres anbieten!
Servus Atilla. Du hast so sehr mit Informationen gegeizt, dass es in der Tat sehr schwierig ist, etwas Produktives beizusteuern. 1. An Deiner Stelle würde ich versuchen, zuerst das Eierprogramm erneut zum Leben zu erwecken. Denn das andere Programm scheint etwas komplexer zu sein. 2. Alle Warnungen eliminieren. 3. Als naechstes würde ich von float auf integer umstellen. Ich bin seit ein paar Jahrzehnten in diesem Beruf und kann mich nicht erinnern, jemals float benutzt zu haben. 4. Last but not least: _delay_ms(2000) http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html Dort heisst es: The maximal possible delay is 262.14 ms / F_CPU in MHz.
Hallo Mehmet! 1) Das Eierprogramm lebt wieder und läuft unverändert!Auch das Boot funktioniert wieder und gleich geht es an den See :-) 2) Ich werde versuchen alle Warnungen zu eliminieren das Programm zu kommentieren und dann jemanden hier bitten es zu überprüfen. Ich wusste genau das genau das passieren würde was hier passiert ist: Nämlich das auf einem unvollkommenen Programm eines Anfängers herumgehackt wird. 3)Ich hatte float benutzt in der (falschen) Annahme das int nur bis 255 kann. 4)Das delay_ms_(2000) funktioniert so. Ich hatte zwischendurch auch mal 3000. Das ging auch. Vielleicht deswegen: When the user request delay which exceed the maximum possible one, _delay_ms() provides a decreased resolution functionality. In this mode _delay_ms() will work with a resolution of 1/10 ms, providing delays up to 6.5535 seconds (independent from CPU frequency). The user will not be informed about decreased resolution.
Gast
#2088527
Hi >AVR Studio gelöscht, über Nacht downgeloaded, neu installiert und siehe >da: >Alles geht wieder! Und was schließt du daraus? Persönlich würde ich davon ausgehen, das du lediglich eine verkorkste Einstellung im AVR-Studio wieder in ihren jungfräulichen Zustand versetzt hast. MfG Spess
Hallo Spess! Ja ich befürchte ähnliches! Darum bin ich ja auch unzufrieden und zweifele selber daran das die Aktion sinnvoll war. Ich habe auch mal überlegt ob ich vielleicht gestern statisch geladen war und die µC beim herumtragen angeditscht habe? Es ist mir ein Rätsel. Ich hasse sowas!
Attila Ciftci schrieb: > Ich wusste genau das genau das passieren würde was hier passiert ist: > Nämlich das auf einem unvollkommenen Programm eines Anfängers > herumgehackt wird. Ich würde sagen: Was besser kann doch einem gar nicht passieren. Verausgesetzt natürlich, man will was Lernen und nicht nur seine vorgefasste Meinung bestaetigt sehen. :)
Attila Ciftci schrieb: > Hallo Spess! > > Ja ich befürchte ähnliches! Darum bin ich ja auch unzufrieden und > zweifele selber daran das die Aktion sinnvoll war. > > Ich habe auch mal überlegt ob ich vielleicht gestern statisch geladen > war und die µC beim herumtragen angeditscht habe? > > Es ist mir ein Rätsel. Ich hasse sowas! Ich wette, dass das Problem das von Thomas Eckmann/mir genannte war: >> Mein Tipp: >> >> Ein im Entwicklungsstudio zu klein eingestellter Stack oder Heap (falls >> du new oder malloc verwendest). Da bekommt man die schönsten Fehler, >> nichts ist mehr vorhersehbar und mitmal gehen Segmente an, die du noch >> gar nicht kanntest. >> RAM-Grenze überschritten, Stack läuft in die Variablen. Aber dazu hattest du dich irgendwie gar nicht geäußert?!
@Mehmet: Gerne! Sehr gerne! Wenn ich das Programm korrigiert habe werde ich ja auch nochmal fragen! Das Problem war aber nicht das Programm scheint es,oder? @Pl Lp: Ich weiss nicht wo man im Entwicklungstudio den Stack einstellt und habe daher nie die Größe des Stacks bestimmt oder verändert. Ich weiss nicht was ein heap ist. Ich habe noch nie new oder malloc benutzt. Bin bis zu diesen Befehlen noch nicht vorgedrungen bei meinem Selbstudium. Ist denn das Überschreiten der RAM-Grenze nicht immer gleich? Im Sinne von sollte ich meine Eieruhr jetzt nocheinmal flashen dass der Fehler dann auch wieder auftacht und nicht, so wie vor einer Stunde, plötzlich verschwindet?
Attila Ciftci schrieb: > Das Problem war aber nicht das Programm scheint es,oder? Meine persönliche Erfahrung mit meinen persönlichen Problemem: Mit einer einzigen Ausnahme lag die Ursache des Fehlers stets bei mir. An Deiner Stelle würde ich versuchen den Fehler zu reproduzieren und nicht, weil es jetzt funktioniert, zur Tagesordnung zurückzukehren.
@Mehmet: Ich habe heute morgen 5 Programme die ich geschrieben habe hoch gefahren: 1) Simuliert Strobes und Beacon eines Flugzeuges mit 3 Led's 2) Testet ein Modelbauservo 3) Initialisert und beschreibt ein 2x16 Zeilen Display 4) besagte Eieruhr 5) Eine Steuerung for ein Modelboot per GPS Alle diese Programme sind gelaufen! Gestern liefen alle diese Programme nicht oder nur teilweise. Was ist der Unterschied zwischen heute und gestern? Ich habe AVR Studio gelöscht und neu installiert. Wie kam es gestern zu dem Fehler: Ich habe die Endausschläge für das Servo vom Boot justieren wollen µC in das STK500, im Program "30" (Für Vollauschlag nach rechts) geschrieben und geflasht,µC aus dem STK raus und ins Boot...geht! µC wieder in STK500 gesteckt ,"-30"(Links) ins Programm geschrieben, geflasht, µC ins Boot gesteckt.......geht NICHT! Anderen µC genommen...geht nicht. Anderes Programm auf µC geflasht ....geht nicht. Aber seit einer halben Stunde arbeite ich an den Ruderausschlägen und wiederhole somit was ich gestern gemacht habe. Wenn ich Glück habe geht ja gleich wieder keines meiner Programme? ;-) Und: Natürlich liegt der Fehler bei mir. Wo denn sonst? Das habe ich schon gelernt das es im seltensten Fall Bauteile oder andere äussere Einflüsse sind!
Schau mal bei den Umgebungsvariablen nach, wie lang Dein PATH ist. Manche Programme können ihn nur bis zu ner bestimmten Länge parsen. Und manche Programme tragen sich vor den anderen ein, dadurch können dann Tools des falschen Compilers benutzt werden (Hast Du noch andere Compiler installiert?). Ansich ist der PATH für Windowsprogramme nicht mehr nötig, aber viele müllen trotzdem den PATH zu. Ich räume da immer radikal auf und lasse nur die Windows-Einträge drin:
1 | |
Und AVRStudio weiß trotzdem, wo der WINAVR steht. Peter
Ich habs! Boot flash size! Von 128 auf einen der anderen Werte gesprungen und wahrscheinlich beim setzen der Einstellung für ext. Osc/int Osc mitgefused worden. Vielen Dank für eure Hilfe und ich hoffe das dieser post anderen hilft!
Gast
#2091009
Das ist keine Erklärung für die beschriebenen Phänomene. Es sei denn, du hättest zusätzlich auch BOOTRST aktiviert. Der Atmega 8 hat kein JTAG, sonst wäre das eine beliebte Fehlerursache. Ich glaube also nicht, dass die Ursache schon gefunden ist.
Hallo! Sorry es hat ein wenig gedauert aber ich habe es heute nochmal probiert: Bei Boot flash size=128 läuft die Eieruhr Bei Boot flash size=256 spinnt die Eieruhr rum wie am Anfang des posts beschrieben. Warum das so ist überlasse ich den Profis und hoffe, wie immer, das dieser Beitrag jemandem hilft. PS: Ich habe alles was mal z.B. x=x++ war korrigiert zu z.B. x=x+1 und habe jetzt keine Warnings mehr. War aber sowieso nicht die Ursache des Problems.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.