Nabend.
Wenn ich dabei bin für ein Gerät das erste mal einen Code zu schreiben
kotzt mich nichts mehr an als wenn etwas absolut nicht nachvollziehbar
ist.
Geht um genau zu sein hierrum:
1
lcd_init();// LCD Initialisieren
2
lcd_clear();
3
lcd_home();
4
lcd_string("RFM70 2,4GHz");// Bissle Werbung ausgeben (damit man sieht das er arbeitet)
5
lcd_setcursor(7,2);
6
lcd_string("Funkmodul");
7
_delay_ms(2000);// und 2sec angezeigt lassen
8
lcd_clear();// dann wieder löschen für sinnvollere Dinge
// (SPI bis 2MHz möglich = Einstellungen i.O. bis F_CPU=16MHz)
14
SPCR=1<<SPIE|1<<SPE|1<<MSTR;
15
SPSR=1<<SPI2X;
16
17
// Interrupts aktivieren
18
sei();
19
20
// Variablen mit Werten laden
21
RFM70_getBank();
22
23
// Register Bank0 beschreiben
24
if(Bank){
25
RFM70_switchBank();
26
}
27
/*
28
for(uint8_t i=0; i<=22; i++) {
29
RFM70_write1Byte(i);
30
}
31
*/
Funktioniert aber wunderprächtig. (for schleife auskommentiert)
In der Simlation wird die Routine zum ansteuern des Displays aber in
beiden Fällen aufgerufen.
Desweiteren: Das Programm mit dem Ausgeklammerten Teil zeigt nur mit der
Optimierung Qs was an, ansonsten bleibt das Display unverändert. Wenn
ich auf Q3 optimiere wird das Display gelöscht und das wars.
Versteht irgenwer dieses Verhalten?
Anbei der gesamte Code in der Hoffnung das mir doch nocht igendwie zu
helfen ist.
... der Fehler scheint nicht wie gedacht im AVR-Studio zu liegen sondern
im Bootloader
(http://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung).
Ich vermute nun dass da nach dem Sprung auf 0x0000 noch irgendwas
verstellt ist.
Müsste ich doch umgehen können indem ich beim Start nachschaue wodurch
der Reset ausgelöst wurde und dann zum Sprung auf 0x0000 einmal kurz den
Watchdog zubeißen lasse.
Wenn es funktioniert hat werde ich mich nochmal melden, wenn nicht aber
auch.
Jetzt aber erstmal hinlegen.
unteschiedliches Verhalten in Abhängigkeit der Optimierungsstufen ( O0,
Os .. ) deutet manchmal darauf hin, dass bestimmte Variable "volatile"
sein sollten.
Eventuell wird auch eine Timing-Routine wegoptimiert.
Michael D. schrieb:>> for(uint8_t i=0; i<=22; i++) {>> RFM70_write1Byte(i);>> }>> */
Die i variable in einer For-Schleife zu deklarieren ist mir neu.
Wenn du nicht willst das die Variable wegoptimert wird dann
volatile davor schreiben.
Nach meiner Erfahrung wird der Compiler alles wegoptiemeren was er kann
und Bedingungen die nicht zu erfüllt werden können werden einfach nicht
ausgeführt.
Wenn ein Breakpoint z.b. gesetzt hast und beim Debuggen plötzlich zu
einen
Leeren Kreis wird weiss der Compiler im Vorfeld das Bedinungen nie
erfüllt werden.
Ich hab mich auch schon mit sowas rumgeärgert, weil ich der Meinung war
ich habe recht. Aber der Compiler war schlauer ;-).
Ja, die Compileroptimierung kann teilweise schon nerven. Vor allem dann,
wenn er meint, Bedingungen werden nie erfüllt, es aber doch vorkommen
kann, dass sie erfüllt werden.
Meistens sitzt aber das Problem dann vorm Computer.
Klaus schrieb:> Die i variable in einer For-Schleife zu deklarieren ist mir neu.>> Wenn du nicht willst das die Variable wegoptimert wird dann> volatile davor schreiben.
Unsinn. Das deklarieren der Zählvariable im Schleifenkopf ist das
normalste auf der Welt. Und der Compiler optimiert auch nichts weg, was
noch gebraucht wird! Außnahme: Verzögerungsschleifen, wenn diese
keinerlei Daten des Programms beeinflussen.
... schrieb:> Einen Thread Titel mit einer derartigen Wortwahl kann ich am> Sonntagmorgen gar nicht gut haben, sorry ;-(
Naja, er schreibt, er sei angekotzt. Sich dieses Bild vorzustellen ist
recht amüsant, zumal gestern Samstag war. Noch fern der Realität glaubt
dieser arme Schlucker eine Software wäre für seinen Zustand schuld.
Angesichts solcher Schicksale wünschte man sich, es gäbe nur noch
Werktage.
Wir wissen weder die AVRStudio-Version noch den AVR-Typ.
Daher ist es unmöglich zu helfen.
Wozu also der ganze Wind?
Die Ausgabe des SRAM/Flash-Verbrauchs am Ende des Compilierens wäre ganz
interessant. Du hast ja richtig zugeschlagen mit SRAM.
Am AVRStudio wird es mit Sicherheit nicht liegen.
Peter
Peter Dannegger schrieb:> Die Ausgabe des SRAM/Flash-Verbrauchs am Ende des Compilierens wäre ganz> interessant. Du hast ja richtig zugeschlagen mit SRAM.
Was er mir anzeigt ist Programm mit 15.1% und Data mit 15.3%
Johnny schrieb:> Was genau sendest du denn hier:> for(uint8_t i=0; i<=22; i++) {> RFM70_write1Byte(i);> }>> für i>13 ?>> MfG
Das Register dessen Daten gesendet werden hat 23x2Byte ...
Habe den Fehler nun gefunden.
Lag am Bootloader, der wohl irgendwelche Leichen beim Reset hat liegen
lassen.
Habe nun eingebaut, das er wenn er Reseten soll erstmal einen
WatchdogReset macht und dann auf 0x0000 springt und nun funktioniert
auch das Programm wieder.
Michael D. schrieb:> Habe nun eingebaut, das er wenn er Reseten soll erstmal einen> WatchdogReset macht und dann auf 0x0000 springt und nun funktioniert> auch das Programm wieder.
Ein Würg-Äround ist immer die schlechteste Lösung. Der Fehler kann Dir
dann jederzeit wieder auf den Fuß fallen.
Besser ist es, den Fehler zu finden und zu beseitigen.
Vielleicht läßt der Bootloader einen Interrupt enabled oder die
Vectortabelle verschoben.
Peter
Peter Dannegger schrieb:> Ein Würg-Äround ist immer die schlechteste Lösung. Der Fehler kann Dir> dann jederzeit wieder auf den Fuß fallen.
Meinst Du, der hat noch weiteres Auswurfpotential?
Hätte nicht gedacht, das man sich so über den Titel aufregt, dachte eher
man schmunzelt drüber. Naja war nicht so gemeint.
Daher das der Bootloader (noch) nicht von mir ist kann ich nicht 100%
sagen das dem so ist aber:
Das letzte was er macht ist die Interrupt-Tabelle wieder zurückschieben
(IVSEL), was aber auch nicht 100% funktioniert hat, weswegen mein
Programm das am Anfang nochmal macht.
Bzgl. der Interrupts die noch kommen ist es so das er am Ende nochmal
1sec im _delay läuft, weswegen ich davon ausgehen würde, dass wenn hier
noch ein Interrupt kommt der in dieser Zeit kommen sollte.
Meine Vermutung ist das er noch irgendwas im Stack hat, welcher dann,
sobald ich zuviel benötige (for) überläuft.
Wobei mir dann immer noch nicht klar ist warum der Teil vor der "for"
auchnicht ausgeführt wird.
Habe den Autor des Bootloaders angeschrieben, ggf. weiß der ja Rat um
die "Notlösung" mit dem Wachhund zu umgehen.
Michael D. schrieb:> Hätte nicht gedacht, das man sich so über den Titel aufregt, dachte eher> man schmunzelt drüber.
In der Tat, der Titel regt zum schmunzeln an. Allerdings kann man sich
schon darüber erregen, dass ein Zeitgenosse meint, seine wie auch immer
geartete Kompetenz dem AVR-Studio in die Schuhe schieben zu wollen. Ähm,
auf die Schuhe zu kotzen.
In diesem Sinne hoffe ich, dass das feed back einen Nährwert besitzt.
Klaus schrieb:> Michael D. schrieb:>>>> for(uint8_t i=0; i<=22; i++)>> Die i variable in einer For-Schleife zu deklarieren ist mir neu.
Das ist eine der Erweiterungen in C99.
Thread beobachten
Seitenaufteilung abschalten