Hi Leute - habe heute mein erstes Progrämmchen für meinen ATTiny2313 aus einem Buch abgeschrieben. Das Kompilieren ist Fehler- und Warnungsfrei, das Builden klappt auch wunderbar. Die Dateien werden erzeugt. Über Connect wähle ich das STK500 aus, wähle meinen MC - Read Signature läuft wunderbar. Wenn ich dann aber im nächsten Reiter "Program" die Flash und EEPROM Dateien auswähle, kommt, wenn ich auf verify klicke bei EEPROM, folgender Fehler: "The Intel Hex input file is empty" Beim Flash - kein Problem. Erbitte Hilfe - hab nach erstem Auftreten des Fehlers die neueste Version (4.17) des AVR Studios installiert. Daran lags leider nicht.
Das liegt vielleicht daran, dass dein Programm gar kein EEPROM benutzt, und deswegen auch nur ein leere File erzeugt?!
>wenn ich auf verify klicke bei >EEPROM, folgender Fehler: >"The Intel Hex input file is empty" Hast du denn Daten für das EEPROM im Programm? Wenn nicht, dann ignoriere die Meldung einfach.
Hallo, das ist kein Fehler. Wenn Dein Programm keien Daten für das EEPROM-Segment erzeugt, weil Du diesen nicht benutzt, bleibt die Datei eben leer. Gruß aus Berlin Michael
hi - danke für die schnellen antworten. wofür wird denn der eeprom gebraucht? ich hab mich nur gewundert, dass eine datei mit endung eep erzeugt wird (und auch was drin steht - also nicht 0byte groß ist) und dann nicht verwendet wird? hm dann müsste es ja eignetlich bereits funktionieren.. die fehlermeldung hab ich angehängt.
Hi
>die fehlermeldung hab ich angehängt.
Wie eine Fehlermeldung aussieht, weiss ich. Es ging um den Reiter
"Program" (Tab).
MfG Spess
aso - sorry - da ist das ding. hab gerade probiert ob es geht - leider nicht, aber vll hat das ja auch andere gründe ...
Hi Wie sind die Dateinamen/Pfade für Flash/EEPROM/ELF in die entsprechenden Felder gekommen? Eingetragen oder ausgewählt? MfG Spess
@Spess >Beim Flash - kein Problem. Die Ursache für die Fehlermeldung ist doch längst geklärt. >ich hab mich nur gewundert, dass eine datei mit endung eep >erzeugt wird (und auch was drin steht - also nicht 0byte groß ist) und >dann nicht verwendet wird? Steht das drin? :00000001FF Dann ist die Intel HEX Datei leer.
die pfade hab ich selbst gewählt. yup :00000001FF steht drin - supi danke. dass es noch nicht geht wird dann wohl einen anderen grund haben.
Hi >Steht das drin? >:00000001FF Normalerweise erstellt das AVRstudio kein *.eep-File (bzw. löscht es wieder), wenn der EEPROM nicht benutzt wird. Dann kann auch nicht ':00000001FF' drin stehen. MfG Spess
>Normalerweise erstellt das AVRstudio kein *.eep-File (bzw. löscht es >wieder), wenn der EEPROM nicht benutzt wird. Dann kann auch nicht >':00000001FF' drin stehen. Was ist schon normal? Das kommt auch auf das makefile an. [Klugscheissermodus] Nur :00000001FF in der Datei könnte man auch so interpretieren: Alle EEPROM Zellen sind 0xFF. Bei Intel HEX dürfen diese 0xFF Zellen unterdrückt/weggelassen werden. Folge: Es steht nur :00000001FF in der Datei. Das ist die Kennung für END OF HEX FIlE. [/Klugscheissermodus]
HI >Was ist schon normal? Das kommt auch auf das makefile an. AVR-Studio kennt kein Make-File. MfG Spess
>AVR-Studio kennt kein Make-File. Ist mir Wurscht. Ich benutze AVR-Studio nicht. Tatsache ist, das ein *.eep File erzeugt wurde das leer ist. Wo das her kommt ist mir auch Wurscht ;)
Hi >Ist mir Wurscht. Ich benutze AVR-Studio nicht. OK. Das langt für eine kompetente Aussage. >hab gerade probiert ob es geht - leider nicht, aber vll hat das ja auch >andere gründe ... Dann poste mal da Programm, und versuch mal zu beschreiben, was du gemacht hast. MfG Spess
@Spess >>Ist mir Wurscht. Ich benutze AVR-Studio nicht. >OK. Das langt für eine kompetente Aussage. In welchem Bezug? Die *.eep Datei ist leer. Das ist Fakt. Du darfst mir gerne glauben das ich da kompetent bin.
hallo - hier ist der quellcode. das ganze soll einen würfel ergeben der zufällig eine zahl ausspuckt - kommt dann auf die ausrichtung der leds an. ja ich könnte mit einem einfacheren beispiel anfangen, aber da ich das ganze ja nur abgeschrieben habe, dachte ich es müsste schon funktionieren. wie gesagt, kompilieren und builden geht wunderbar. dann klicke ich auf das "AVR" kästchen und das fenster geht auf. ich wähle meinen MC und teste auch das read signature. dann lade ich die dateien und klicke auf program. läuft dann wie beschrieben in 2 von 3 fällen prima durch - und das müsste es ja schon gewesen sein oder?
1 | #include <avr/io.h> |
2 | #define TAKT 1000000ul
|
3 | |
4 | void wartex10ms (unsigned char); |
5 | |
6 | int main(void) |
7 | {
|
8 | unsigned char i, zaehler=6; |
9 | unsigned char tab[7]={0x01, 0x02, 0x03, 0x06, 0x07, 0x0e, 0x0f}; |
10 | |
11 | |
12 | DDRB=0x0f; |
13 | |
14 | if(!(PINB & (1<<PB4))) zaehler=7; |
15 | |
16 | for (i=0;i<zaehler; i++) |
17 | {
|
18 | PORTB=~tab[i]; |
19 | wartex10ms(50); |
20 | }
|
21 | |
22 | PORTB=0xff; |
23 | |
24 | while(1) |
25 | {
|
26 | for(i=0; i<zaehler; i++) |
27 | {
|
28 | if(!(PINB & (1<<PB4))) |
29 | {
|
30 | PORTB=~tab[i]; |
31 | wartex10ms(5); |
32 | |
33 | while(!(PINB & (1<<PB4))); |
34 | |
35 | wartex10ms(5); |
36 | |
37 | PORTB=0xff; |
38 | }
|
39 | }
|
40 | }
|
41 | return 0; |
42 | }
|
43 | |
44 | void wartex10ms(unsigned char faktor) |
45 | {
|
46 | for(unsigned char j=0; j<faktor; j++) |
47 | {
|
48 | for(unsigned int p=TAKT/400ul;p>0;p--); |
49 | }
|
50 | }
|
Ich weiss nicht wo das Problem liegt, es gibt keine Daten im *.eep File und daher auch der Hinweis: "The Intel Hex input file is empty" Also ich bin noch nie auf die Idee gekommen, wenn ich keine Daten im EEPROM habe, nachzuschauen ob wirklich keine Daten da sind und mich dann zu wundern das es bestätigt wird.
Hubert G. schrieb: > Ich weiss nicht wo das Problem liegt, es gibt keine Daten im *.eep File > und daher auch der Hinweis: "The Intel Hex input file is empty" yo das problem ist erledigt, hab aber gleich eine neue frage - hab noch ein wenig gebastelt und das programm auf folgende zeilen reduziert:
1 | #define F_CPU 1000000ul
|
2 | #include <avr/io.h> |
3 | #include <util/delay.h> |
4 | |
5 | int main(void) |
6 | {
|
7 | unsigned char i, zaehler=6; |
8 | |
9 | |
10 | unsigned char tab[6]={0x01, 0x02, 0x03, 0x06, 0x07, 0x0e}; |
11 | |
12 | DDRB=0xff; |
13 | |
14 | while(1) |
15 | {
|
16 | for(i=0; i<zaehler; i++) |
17 | {
|
18 | if(!(PIND & (1<<PD4))) |
19 | {
|
20 | PORTB=~tab[i]; |
21 | _delay_ms(50); |
22 | |
23 | while(!(PIND & (1<<PD4))); |
24 | |
25 | _delay_ms(50); |
26 | |
27 | PORTB=0xff; |
28 | }
|
29 | }
|
30 | }
|
31 | return 0; |
32 | }
|
irgendwie scheint das array allerdings nicht so ganz zu funktionieren. die ersten beiden zahlen funtionieren, aber danach nichts mehr. kann mir jemand erklären warum? in dieser version funktioniert es, aber die erste ist offensichtlich viel eleganter:
1 | #define F_CPU 1000000ul
|
2 | #include <avr/io.h> |
3 | #include <util/delay.h> |
4 | |
5 | int main(void) |
6 | {
|
7 | unsigned char i, zaehler=6; |
8 | |
9 | DDRB=0xff; |
10 | |
11 | while(1) |
12 | {
|
13 | for(i=0;i<zaehler;i++) |
14 | {
|
15 | if(!(PIND & (1<<PD4))) |
16 | {
|
17 | switch(i) |
18 | {
|
19 | case 0: PORTB=~0x01; _delay_ms(50); while(!(PIND & (1<<PD4))); _delay_ms(50); break; |
20 | case 1: PORTB=~0x02; _delay_ms(50); while(!(PIND & (1<<PD4))); _delay_ms(50); break; |
21 | case 2: PORTB=~0x03; _delay_ms(50); while(!(PIND & (1<<PD4))); _delay_ms(50); break; |
22 | case 3: PORTB=~0x06; _delay_ms(50); while(!(PIND & (1<<PD4))); _delay_ms(50); break; |
23 | case 4: PORTB=~0x07; _delay_ms(50); while(!(PIND & (1<<PD4))); _delay_ms(50); break; |
24 | case 5: PORTB=~0x0e; _delay_ms(50); while(!(PIND & (1<<PD4))); _delay_ms(50); break; |
25 | }
|
26 | PORTB=0xff; |
27 | }
|
28 | }
|
29 | }
|
30 | |
31 | return 0; |
32 | }
|
Bitte 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.