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?
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.
>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"?
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"
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.
>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!
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.
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.
> 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.
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."
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.
@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.
>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.
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"!!!!!!
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.....??
>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??????????
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! ;-)
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
@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!
>"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.
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)
>> 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!
> _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;)
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!
>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).
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
@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.
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!
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()
main.c:87: warning: operation on 'i' may be undefined
1
i=i++;
main.c:101: warning: operation on 'min' may be undefined
1
min=min++;
main.c:118: warning: operation on 'min' may be undefined
1
min=min++;
main.c:143: warning: operation on 'a' may be undefined
1
a=a--;
main.c:147: warning: operation on 'x' may be undefined
1
x=x--;
main.c:158: warning: operation on 'x' may be undefined
1
x=x--;
main.c: In function '__vector_8':
main.c:181: warning: operation on 'sek' may be undefined
1
sek=sek--;
main.c:185: warning: operation on 'dez' may be undefined
1
dez=dez--;
main.c:189: warning: operation on 'min' may be undefined
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.
Was Gerhard sagen will: schreib einfach "min--;" anstatt "min=min--;"
Mal ins blaue geraten: Servo-Ausschlag geändert, keine Freilaufdiode, µC
geschossen?
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!
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
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.
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!
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.
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:
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!
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.