Hallo, bei meinen Schwierigkeiten, alte C-Quellcodes von 2004 mit dem aktuellen WInAVR/gcc 2008-04-02 zu kompilieren, ist mir jetzt der Verdacht gekommen, daß die Programmabarbeitung vielleicht mit dem beginnt, was ganz oben steht? In dem betreffenden Programm sind zuoberst die Abläufe programmiert, die bei verschiedenen Errors geschehen sollen, danach kommen andere Funktionen und zuallerletzt main. Das in den ATmega geschriebene Programm führt nur die oberste Errorroutine aus; wenn ich diese deaktiviere und neu kompiliere, dann die neue oberste usw.. Bis zu main kommt man nicht. Vielleicht möchte das neue WinAVR/gcc das main jetzt am Anfang haben? Also habe ich es dahin kopiert. Aber da wurde erwartungsgemäß bemängelt, daß nichts definiert sei. Jetzt stehe ich wieder auf dem Schlauch. Irgendwo oberhalb von main müssen die Funktionen doch beschrieben sein, aber wenn der Compiler sie so "lecker" findet und gleich ausführen läßt??? Ein Beispiel für solch eine Funktion füge ich an. Wenn sie zuoberst steht, wird sie ausgeführt - und sonst nichts. Ist mit der Definition etwas nicht in Ordnung? Oder muß man jetzt die Funktionen oberhalb von main nur deklarieren und dann unterhalb genauer programmieren? Vielen Dank schon mal! Gruß Peter void error_pcf(void) // LED's 1-4 aufsteigend, mehrmals { n=4; while(n-- >1) { DDRD |=15; PORTD |=1; _delay_ms(30); PORTD |=3; _delay_ms(30); PORTD |=7; _delay_ms(30); PORTD |=15; _delay_ms(30); PORTD &=240; _delay_ms(80); }; return; } // Ende error_pcf()
Sofern du ordentlich über den C-Compiler linkst, sollte der Ablauf mit dem crtXXX.o beginnen, das anschließend main() aufruft (und falls main() jemals zurückkehrt, geht es damit nach exit()).
Gast
#832207
>Vielleicht möchte das neue WinAVR/gcc das main jetzt am Anfang haben? Das wäre ungefähr so, als ob das Alphabet ab sofort mit Z anfängt. Nein, es wird als allererstes main aufgerufen. Allerdings ist deine WinAVR-Version noch so neu, vielleicht falsch installiert, oder noch der Wurm drin. In der Regel liegts aber nicht am Compiler, sondern am Programm. Zeig mal Sourcecode und makefile. Oliver
Oliver wrote: >>Vielleicht möchte das neue WinAVR/gcc das main jetzt am Anfang haben? > > Das wäre ungefähr so, als ob das Alphabet ab sofort mit Z anfängt. Nein, > es wird als allererstes main aufgerufen. Allerdings ist deine > WinAVR-Version noch so neu, vielleicht falsch installiert, oder noch der > Wurm drin. > > In der Regel liegts aber nicht am Compiler, sondern am Programm. Zeig > mal Sourcecode und makefile. > > Oliver Beides anbei. Das Programm ist nur eine unfertige Arbeitsversion! Gruß Peter
Anbei noch makefile Peter
Nur mal so, hast du das mit der noch nicht bug-gefixten Betaversion von WinAVR 20080402 compiliert? Da war noch ein heftiger Bug drin, wie du sicher der Diskussion bei avrfreaks.net entnommen hast.
Ich habe WinAVR .... rc1 benutzt und leider nicht zuvor bei avrfreaks nachgeschaut. Sollte man die Vorgängerversion nehmen oder ist die Bug-Eliminierung schon abzusehen? mfg Peter
Gast
#832294
Ich hab mal eben die aktuelle Version installiert. Leider meckert die
gleich in Zeile 1:
>warning: <avr/io.h>: no such file or directory
(oder so ähnlich)
arghh...
Also wieder runter geschmissen, und die 20071221 wieder installiert.
Damit kann ich leider das Problem nicht testen, und warum die aktuelle
20080402 nicht will, weiss ich auch nicht.
Oliver
Oliver wrote: > Also wieder runter geschmissen, und die 20071221 wieder installiert. > > Damit kann ich leider das Problem nicht testen, Ich habs auch probiert mit WinAVR20071221 - geht auch nicht. mfg Peter
Gast
#832546
Version 20071221 erzeugt folgenden Code:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Da wird ziemlich eindeutig (und wenig überraschend) main aufgerufen. Oliver
Oliver wrote: > Version 20071221 erzeugt folgenden Code: >
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
> > Da wird ziemlich eindeutig (und wenig überraschend) main aufgerufen. > > Oliver Meine Version 20071221 erzeugt: 000000bc <.do_clear_bss_start>: bc: a0 31 cpi r26, 0x10 ; 16 be: b1 07 cpc r27, r17 c0: e1 f7 brne .-8 ; 0xba <.do_clear_bss_loop> c2: 0e 94 81 01 call 0x302 ; 0x302 <main> c6: 0c 94 a9 02 jmp 0x552 ; 0x552 <_exit> Leider muß ich gestehen, daß ich damit nicht viel anfangen kann. Ich habe gerade erstmalig versucht, mich bei AVRStudio 4.13 nach Debug-Methoden umzusehen (soll es auch bei gcc geben). Vielleicht kann ich damit etwas herausfinden. Ich habe hilfsweise an verschiedenen Programmpunkten Errorroutinen eingefügt, danach scheint das Programm alle Funktionen zu durchlaufen. Wahrscheinlich funktioniert die I2C-Ansteuerung mit den neueren WinAVR-Versionen nicht mehr (das derzeit benutzte ...20071221 kann es auch nicht!). Peter
Peter Leistikow wrote: > Meine Version 20071221 erzeugt: ... > c2: 0e 94 81 01 call 0x302 ; 0x302 <main> Ist doch aber eindeutig, oder?
Jörg Wunsch wrote: > Peter Leistikow wrote: > >> Meine Version 20071221 erzeugt: > ... >> c2: 0e 94 81 01 call 0x302 ; 0x302 <main> > > Ist doch aber eindeutig, oder? Ja, sieht gut aus - was den Ablauf des Programms betrifft! Aber nun beginnt die Ochsentour durch die twi-/ I2C-Problematik, wo die verschiedenen WinAVR-Versionen wahrscheinlich voneinander abweichen. Jedenfalls funktionieren die LCD-Anzeigen mit den alten Hex-files gut und die neu kompilierten nicht - vom weggelassenen Rattenschwanz der Sensorabfragen, Datenaufbereitung usw. ganz zu schweigen. Viele Grüße Peter
Hast du selbst gezimmerte Verzögerungsschleifen da drin? Wenn ja: benutze <util/delay.h> statt dessen.
> Aber nun beginnt die Ochsentour durch die twi-/ I2C-Problematik, wo die > verschiedenen WinAVR-Versionen wahrscheinlich voneinander abweichen. > Jedenfalls funktionieren die LCD-Anzeigen mit den alten Hex-files gut > und die neu kompilierten nicht - vom weggelassenen Rattenschwanz der > Sensorabfragen, Datenaufbereitung usw. ganz zu schweigen. Nachtrag: einer der vielen PCF8574 läßt sich über twi/I2C wieder ansprechen, also bin ich guten Mutes. Aber nur mit WinAVR20071221! Vielen Dank für Eure Hilfe! Peter
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.