Mein mini-C-Programm lässt sich trotz fehlerfreier Compilierung nicht
flashen, wenn ich Parameter-Übergabe an eine Funktion und break in
dieser Funktion habe.
Kennt jemand die Ursache?
Wie kann ich dieses Problem vermeiden?
Mein C-Programm:
1
#define F_CPU 8000000 // Frequenz, mit der der uC betrieben wird: 8,0 MHz
2
#include<avr/io.h> // Hardware-Informationen zum Controller
3
4
intfunktion(unsignedintzahl)
5
{
6
intn,ergebnis;
7
floatzahl_dez;
8
9
// zahl = 123; // Zeile 1
10
zahl_dez=(float)zahl/10;// Zeile 2
11
// zahl_dez = 12.3; // Zeile 3
12
13
for(n=2;n>0;n++)// Zeile 11
14
{// Zeile 12
15
if(zahl_dez<10)// Zeile 13
16
{// Zeile 14
17
ergebnis=n;// Zeile 15
18
break;// Zeile 16
19
}// Zeile 17
20
zahl_dez=zahl_dez/10;// Zeile 18
21
}// Zeile 19
22
return(n);
23
}
24
25
intmain(void)
26
{
27
intx;
28
while(1)
29
{
30
x=123;
31
}// Ende while(1)
32
return(0);
33
}// Ende main()
Ohne Zeile 3 und ohne Zeile 1 kommt der folgende Fehler beim Flashen
(compile ist aber ok):
avrdude: ERROR: address 0x0806 out of range at line 129 of main.hex
Make: *** [flash] Error 1
Wenn man das "break;" in Zeile 16 jedoch auskommentiert, tritt der
Fehler nicht auf.
Das "break;" wird aber gebraucht, damit die for-Schleife keine
endlos-Schleife ist.
Übergeben eines Zeigers auf die Variable zahl (also *zahl als
Parameter der Funktion) hilft nicht.
Mit Zeile 1 und ohne Zeile 3 kommt o.g. Fehler "... out of range ..."
nicht.
Ohne Zeile 1 und mit Zeile 3 kommt o.g. Fehler "... out of range ..."
nicht.
Mit Zeile 1 und mit Zeile 3 kommt o.g. Fehler "... out of range ..."
nicht.
Mit Zeile 2 und ohne die Zeilen 1 und 3 und ohne die Zeilen 11 bis 19
kommt o.g. Fehler "... out of range ..." nicht.
Vermutung: Der Fehler hat irgendwie damit zu tun, wo im Flash-Speicher
die Variable zahl abgelegt wird.
Falls ich etwas falsch oder ungeschickt ausdrücke, bitte ich um
Entschuldigung und einen Hinweis. Ich habe auch nach langem Suchen im
www nichts vergleichbares gefunden, deshalb frage ich hier.
Grüße an alle uC-C-Programmier-Fans!
Hast Du beim compilieren auch den ATtiny2313 angegeben?
Es sieht so aus, als ob Du den falschen Prozessortyp angegeben hast.
Kontrolliere das noch einmal.
0x0806 liegt weit ausserhalb vom Flashbereich des 2313.
An Deinem Testprogramm liegt das nicht.
Ingo schrieb:> Ein Float auf nem Tiny???? Passt das> wirklich in den Flash rein???!!!
Ohne Probleme, wenn Deine Tastatur nicht kaputt ist.
Peter M. schrieb:> An Deinem Testprogramm liegt das nicht.
Es fehlt sicherlich die 'libm.a' beim Projekt, die man unter
'Configuration Options'(beim AVR-Studio) einbinden kann.
> Peter M. schrieb:>> An Deinem Testprogramm liegt das nicht.>> Es fehlt sicherlich die 'libm.a' beim Projekt, die man unter> 'Configuration Options'(beim AVR-Studio) einbinden kann.
Erstmal herzlichen Dank an alle, die sich mein (wie ich finde) seltsames
Problem beim Flashen angeschaut und versucht haben, zu helfen.
an Ingo:
Der Typ "float" bei einer Variablen ist sicher kein Problem, weil auch
in der Programm-Variante ohne Fehler diese Variable enthalten ist.
an Peter M.:
Ich habe beim Compilieren den attiny2313 angegeben. Wäre es nicht so,
gäbe es ja auch keine fehlerfrei geflashte Variante des Programms.
an m.n. und neuer PIC Freund:
Vielen Dank für den Tip mit "libm.a", den ich leider nicht ausprobieren
konnte, obwohl ich AVR Studio 6 zum Compilieren benutze. Wie genau
bindet man die libm.a ein? Geht das nur beim Anlegen eines Projektes
oder auch noch nachträglich in ein bestehendes Projekt? Ich habe
"Configuration Options" nicht gefunden, nur "Options", aber dort keinen
Punkt "Configuration".
Beim Compilieren (mit Debug) erhalte ich:
Invoking: AVR/GNU C Compiler : 3.4.2
text data bss dec hex filename
62 0 0 62 3e fehler-tiny2313-03.elf
Program Memory Usage : 62 bytes 3,0 % Full
Data Memory Usage : 0 bytes 0,0 % Full
Kann mein Makefile Schuld sein?
Bernd-Dieter Bernt schrieb:> Program Memory Usage : 62 bytes 3,0 % Full
Nur bei der "funktionierenden" Version, oder auch bei denen, die sich
nicht flashen lassen?
Und, nebenbei, unrelated:
Bernd-Dieter Bernt schrieb:> return(n);
sollte man sich abgewöhnen.
"return" ist ein operator, keine Funktion.
Überleg z.B. mal, was
Bernd-Dieter Bernt schrieb:> Wie genau> bindet man die libm.a ein?
Unter 'toolchain/libraries' libm eingeben, vermute ich.
Für Studio 6 fehlt mir der Sinn; ich benutze Studio 4.
Linksammler schrieb:>> return(n);>> sollte man sich abgewöhnen.
Ich bin auch klammersüchtig und halte den Entzug nie durch. Oft setze
ich auch in if-Abfragen ganz viele Klammern, obwohl die Ausdrücke auch
keine Funktion sind (aber haben) ;-)
m.n. schrieb:> Oft setze> ich auch in if-Abfragen ganz viele Klammern,
Da schaden sie ja nicht, bis auf Sonderfälle, wo man ggfs. sinnige
Kompilerwarnings unterdrückt.
z.B:
> if (a=1) {
vs.
> if ((a=1)) {
machen dasselbe.
Wenn man eigentlich
> if (a==1) {
gemeint hat, ist die zweite Form sch****.
aber
> return(n) + 1;
ist dasselbe wie
> return (n+1);
oder wie
> return n + 1;
aber nie
> (return n) + 1;
d.H. der Kompiler ignoriert sozusagen die Klammer, und baut etwas ganz
anderes daraus, als der optische Eindruck suggeriert.
deshalb: bei return lieber weglassen.
Zweiter, vmtl. gewichtigerer Grund: Man outet sich im Forum als
C-Noobie, der das Sprachkonstrukt "return" nicht verstanden hat.
> Program Memory Usage : 62 bytes 3,0 % Full
kommt bei allen Versionen beim Compilieren in AVR Studio 6, egal, ob mit
oder ohne Fehler beim Flashen-Versuch.
Beim Flashen wird die Byte-Anzahl nur angezeigt, wenn das Flashen
geklappt hat. Dann: "avrdude: 1548 bytes of flash verified"
Ich bin mir nicht sicher, weil ich derartiges nie im Programm
geschrieben habe, aber ich vermute, dass "return(n) + 1;" "n+1" zurück
gibt.
'toolchain/libraries' finde ich in AVR Studio 6 nicht.
Ich habe jetzt mein Makefile um "-lm" erweitert:
COMPILE = avr-gcc -Wall -Os -lm -DF_CPU=$(CLOCK) -mmcu=$(DEVICE)
Das hat auch nicht geholfen.
Aber ich möchte gern zurückkommen auf das eigentliche Problem:
Wie ist dieser Fehler beim Flashen überhaupt möglich?
Linksammler schrieb:> Zweiter, vmtl. gewichtigerer Grund: Man outet sich im Forum als> C-Noobie, der das Sprachkonstrukt "return" nicht verstanden hat.
man schreibt ja auch nicht
1
i=(j);
Die Syntax für return ist in EBNF ganz einfach
1
"return" [ expression ] .
kein Grund für ( ) Klammern.
Interessanterweise ist ja auch
1
returnn;
schneller und leichter zu tippen als
1
return(n);
(Und ja, ich weiss: K&R themself benutzen diese Form. Ist trotzdem kein
Argument. So sieht das return wie ein Funktionsaufruf aus, was es ja
nicht ist.)
Das "-lm" hatte ich nur einmal kurz ins Makefile hinzugefügt,
ausprobiert, kein Erfolg, wieder rausgenommen, hier im Forum davon
berichtet.
Inzwischen weiß ich, dass eine Mathe-Bibliothek mit "-lm" eingebunden
werden soll. Aber ich weiß nicht, wie das den Fehler (Adresse außerhalb
des Flash-Speichers) beheben sollte.
Ich würde ja gerne im AVR Studio debuggen, also das Programm laufen
lassen und ihm "dabei Schritt für Schritt zusehen", weiß aber leider
nicht, wie man AVR Studio dazu bringt.
Linksammler schrieb:> Zweiter, vmtl. gewichtigerer Grund: Man outet sich im Forum als> C-Noobie, der das Sprachkonstrukt "return" nicht verstanden hat.
Gern geschehen!
Karl Heinz schrieb:> Und ja, ich weiss: K&R themself benutzen diese Form.
Danke! Jetzt weiß ich endlich wieder, warum ich es so mache ;-)
Obiges Programm habe ich mit Studio 4 übersetzt und zwar ohne
Optimierung -O0, damit funktion() überhaupt beachtet wird.
1866 Byte ohne und 820 Byte mit 'libm.a'. Beide Versionen passen in
einen Tiny2313. Mit Optimierung -Os werden 82 Byte erzeugt, was noch
viel ist ;-)
Mit make mußte ich auch nicht hantieren und weiß auch nicht, warum Du
dort herumspielst.
Da das C-Programm auch ohne die Zeilen 1 und 3 ok ist (es wird beim
Compilieren auch als ok angezeigt), vermute ich, dass irgendetwas beim
Flashen, also im Makefile, zu dem Fehler führt. Deshalb habe ich jetzt
begonnen, das Makefile teilweise zu ändern. Da ich Anfänger beim
Mikroprozessor-Flashen bin, orientiere ich mich an existierenden
Makefiles. Ich wollte auch das von Studio 6 erstellte Makefile benutzen,
leider kommt dabei immer die Meldung "Make: No rule to make target
'flash'".
Es würde mir sehr helfen, wenn jemand mein Progrämmchen (ohne die Zeilen
1 und 3) mit einem Makefile übersetzen und fehlerfrei auf einen tiny2313
flashen würde und hier sein Makefile notieren würde, damit ich mein
Makefile mit einem korrekten Makefile vergleichen kann. Ich denke,
anders wird der Fehler, den ich mache, nicht zu finden sein.
Bernd-Dieter Bernt schrieb:> Da das C-Programm auch ohne die Zeilen 1 und 3 ok ist (es wird beim> Compilieren auch als ok angezeigt), vermute ich, dass irgendetwas beim> Flashen, also im Makefile, zu dem Fehler führt.
Dein AVRDude informiert dich darüber, dass das HEX-File zu gross für den
Prozessor ist.
Die Fehlermeldung
1
avrdude: ERROR: address 0x0806 out of range at line 129 of main.hex
bezieht sich auf die Adresse 0x806, dezimal 2054
Da ein Tiny2313 über 2K Flash verfügt, reicht der im Flash adressierbare
Bereich von 0 bis zur Adresse 2047. 2054 (oder eben HEX 0x0806) ist
damit definitiv ausserhalb des auf einem Tiny2313 zur verfügung
stehenden Flash- Bereiches.
Die Frage ist jetzt: Warum ist dein übersetztes C-Programm so dermassen
gross?
Und so wie das scheint, kann das hier niemand wirklich nachvollziehen.
> Makefiles. Ich wollte auch das von Studio 6 erstellte Makefile benutzen,
Wenn du sowieso das Studio 6 benutzt, wozu brauchst du dann noch ein
eigenes Makefile?
Lass das Studio 6 den Build fertig machen, setz dein Brennprogramm auf
das Hex-File an und gut ists.
Um den Schritt des Brennens eines HEX-Files per AVRDude durchzuführen,
braucht man auch kein Makefile. Ein stink normaler Batch Job (ein BAT
File), in dem das avrdude Kommando drinn ist, damit man sich nicht
dauernd die Parameter merken muss) und das man doppelklickt wenn man
brennen will, tut es da völlig.
Bernd-Dieter Bernt schrieb:> Inzischen weiß ich, dass eine Mathe-Bibliothek mit "-lm" eingebunden> werden soll. Aber ich weiß nicht, wie das den Fehler (Adresse außerhalb> des Flash-Speichers) beheben sollte.
Wird die Mathe-Bibliothekj eingebunden, wird das Programm normalerweise
kleiner, weil die Routinen aus der Lib kleiner sind, als die die der
Compiler normalerweise benutzt.
Bernd-Dieter Bernt schrieb:> avrdude: ERROR: address 0x0806 out of range at line 129 of main.hex129 Zeilen langes Hex-File für dieses winzige Programm?
Bitte poste doch einfach mal das besagte hex-file, dann können wir es
disassemblieren und sehen was da alles reingepackt wurde.
Bernd-Dieter Bernt schrieb:> Vielen Dank für den Tip mit "libm.a", den ich leider nicht> ausprobieren konnte, obwohl ich AVR Studio 6 zum Compilieren benutze.> Wie genau bindet man die libm.a ein?
Für avr-gcc ab 4.7.2 tut man NICHTS!
Siehe http://gcc.gnu.org/PR54461
Der Compiler(treiber) weiß, wann er welche Standardbibliothek wo wie
linken muss, also libgcc.a, libc.a und libm.a und ab avr-gcc 5 auch
libdev.a.
Und zwar passend für's jeweils angegebene Device automatisch eine der 16
unterschiedlichen Ausprägungen der lib*.a.
Da von Hand irgendwelche Pfade oder Optionen reinzufutscheln fürhrt
bestenfalls dazu, daß die Linkreihenfolge nicht stimmt, die falsche
Multilib-Variante verwendet wird oder eine komplett falsche libm wie
z.B. die für den Host.
Falls irgendwelche überschlauen GUIs oder Makefiles meinen, da Hand
anlegen zu müssen: Raus damit!
avr-gcc 4.7.2+ ist dazu mit --with-avrlibc zu configuren, was jeder, der
sich halbwegs mit avr-gcc auskennt, auch macht. Ab avr-gcc 4.8 is diese
configue-Option per default gesetzt, d.h. man muß explizit mit
--wih-avrlibc=no oder --target=avr-*-rtems configuren, um den Support
der AVR-LibC gemäß PR54461 zu deaktivieren.
Siehe dazu die Einträge zu "AVR" in den GCC Release Notes:
http://gcc.gnu.org/gcc-4.7/changes.htmlhttp://gcc.gnu.org/gcc-4.8/changes.html
sowie die entsprechende Doku in "Installing GCC: Configuration"
http://gcc.gnu.org/install/configure.html#TOC3
Wie gelinkt wird, kann man z.B. anzeigen lassen mit
> avrdude: ERROR: address 0x0806 out of range at line 129 of main.hex
2
>
> bezieht sich auf die Adresse 0x806, dezimal 2054>> Da ein Tiny2313 über 2K Flash verfügt, reicht der im Flash adressierbare> Bereich von 0 bis zur Adresse 2047. 2054 (oder eben HEX 0x0806) ist> damit definitiv ausserhalb des auf einem Tiny2313 zur verfügung> stehenden Flash- Bereiches.>> Die Frage ist jetzt: Warum ist dein übersetztes C-Programm so dermassen> gross?> Und so wie das scheint, kann das hier niemand wirklich nachvollziehen.
Hallo Karl Heinz, erstmal vielen Dank für Deine ausführliche Antwort.
Sie hat mich dazu angeregt, mein Progrämmchen auch mal auf einen tiny13
zu flashen, bzw. das zu versuchen. Der Fehler kam wieder, nur lautete
diesmal die Meldung: "address 0x0410 out of range at line 65 of
main.hex" und "write to file main.hex failed".
Dann habe ich den Code von "int funktion(unsigned int zahl)" zweimal
kopiert und die beiden Kopien umbenannt in funktion1(...) und
funktion2(...) und in main() eingefügt: "x = funktion(123);" und "x =
funktion1(123);" und "x = funktion2(123);". Es kam exakt die gleiche
Fehlermeldung, nämlich "address 0x0410 out of range at line 65 of
main.hex".
Wie ist das möglich? Jetzt hätte doch der Programmcode nicht nur bis
0x0410, sondern viel weiter reichen müssen?!
Die anderen Anregungen (auch dafür herzlichen Dank) werde ich so bald
wie möglich aufgreifen und versuchen umzusetzen.
Bernd-Dieter Bernt schrieb:> Hallo Karl Heinz, erstmal vielen Dank für Deine ausführliche Antwort.
Aber offenbar hast du sie nich verstanden.
> Sie hat mich dazu angeregt, mein Progrämmchen auch mal auf einen tiny13> zu flashen, bzw. das zu versuchen.
Genau. Wenn 20 Liter Wasser nicht in einen 10 Liter Eimer passen,
probiert man, ob sie wohl in einen 5 Liter Eimer passen würden.
> Wie ist das möglich? Jetzt hätte doch der Programmcode nicht nur bis> 0x0410, sondern viel weiter reichen müssen?!
Der Programmcode ist so gross wie er ist.
Aber die unterschiedlichen Tiny haben unterschiedlich viel Speicher!
Nämlich zu wenig. Der Tiny13 hat weniger Flash als der Tiny2313. Ergo
geht dem auch schon früher der Speicher aus, bzw. der Programmer kann
viel weniger in den Flash schreiben, ehe der Platz ausgeht.
Die Adresse, die du vom AvrDude kriegst, ist die des ersten Bytes, das
nicht mehr in den Flash passt!
Bernd K. schrieb:> Bernd-Dieter Bernt schrieb:>> avrdude: ERROR: address 0x0806 out of range at line 129 of main.hex>> 129 Zeilen langes Hex-File für dieses winzige Programm?>> Bitte poste doch einfach mal das besagte hex-file, dann können wir es> disassemblieren und sehen was da alles reingepackt wurde.
Das hex-file habe ich angehängt.
Wo kann ich einen guten Disassembler runterladen?
Karl Heinz schrieb:> Der Programmcode ist so gross wie er ist.> Aber die unterschiedlichen Tiny haben unterschiedlich viel Speicher!> Nämlich zu wenig. Der Tiny13 hat weniger Flash als der Tiny2313. Ergo> geht dem auch schon früher der Speicher aus, bzw. der Programmer kann> viel weniger in den Flash schreiben, ehe der Platz ausgeht.>> Die Adresse, die du vom AvrDude kriegst, ist die des ersten Bytes, das> nicht mehr in den Flash passt!
Mein Gedanke war, dass evtl. irgendetwas mit meinem tiny2313 nicht
stimmt. Schließlich ist mein Progrämmchen so klein, dass es problemlos
auch auf einen tiny13 passen müsste. Und die angemeckerte Speicherstelle
0x0806 im Flash-Speicher steht nicht direkt hinter dem Flash-Ende
0x0801, weshalb ich 0x0806 für das Ende meines Programms im hex-File
hielt. Sorry, war falsch gedacht. So ganz verstehe ich zwar nicht, warum
das erste Byte, das nicht mehr in den Flash passt, ganze 7 Bytes hinter
dem Flash-Ende (und nicht direkt hinter dem Flash-Ende) steht, aber das
ist sicherlich im Hinblick auf mein Problem unwichtig.
Wichtig dürfte sein, was in meinem hex-File außer meinen wenigen aus dem
Programm-Code entstandenen Bytes steht und wie das dahin gelangt ist.
Deshalb bin ich gespannt darauf, was Bernd K. beim Disassemblieren
herausfinden wird.
Mein Beitrag vom 27.03.2015, 13:07 enthält dieses hex-File gleich 3 mal
als Anhang, weil die Anhänge in der Vorschau nicht angezeigt wurden und
nach Anklicken des Buttons "Vorschau" neben dem Button "Durchsuchen..."
die zuvor ausgesuchte Datei (mein hex-File) verschwunden war und
stattdessen dort stand "Keine Datei ausgewählt.". Also habe ich die
Datei nochmal ausgewählt und "Vorschau" gedrückt, weil ich dachte, etwas
falsch gemacht zu haben. Nach dem dritten Versuch habe ich den Beitrag
dann abgeschickt, mit oder ohne Anhang, mal sehen. Nun weiß ich, wie es
geht.
Bernd-Dieter Bernt schrieb:> Das hex-file habe ich angehängt.> Wo kann ich einen guten Disassembler runterladen?
Brauchst Du nicht denn Du hast ihn schon, es geht mit avr-objdump:
1
--(bernd@Saturn)-(/home/bernd/Downloads)--
2
--($)-- avr-objdump -D -m avr5 main.hex
3
4
main.hex: Dateiformat ihex
5
6
7
Disassembly of section .sec1:
8
9
00000000 <.sec1>:
10
0: 12 c0 rjmp .+36 ; 0x26
11
2: 22 c0 rjmp .+68 ; 0x48
12
4: 21 c0 rjmp .+66 ; 0x48
13
6: 20 c0 rjmp .+64 ; 0x48
14
8: 1f c0 rjmp .+62 ; 0x48
15
a: 1e c0 rjmp .+60 ; 0x48
16
c: 1d c0 rjmp .+58 ; 0x48
17
e: 1c c0 rjmp .+56 ; 0x48
18
10: 1b c0 rjmp .+54 ; 0x48
19
12: 1a c0 rjmp .+52 ; 0x48
20
14: 19 c0 rjmp .+50 ; 0x48
21
16: 18 c0 rjmp .+48 ; 0x48
22
18: 17 c0 rjmp .+46 ; 0x48
23
1a: 16 c0 rjmp .+44 ; 0x48
24
1c: 15 c0 rjmp .+42 ; 0x48
25
1e: 14 c0 rjmp .+40 ; 0x48
26
20: 13 c0 rjmp .+38 ; 0x48
27
22: 12 c0 rjmp .+36 ; 0x48
28
24: 11 c0 rjmp .+34 ; 0x48
29
26: 11 24 eor r1, r1
30
28: 1f be out 0x3f, r1 ; 63
31
2a: cf ed ldi r28, 0xDF ; 223
32
2c: cd bf out 0x3d, r28 ; 61
33
2e: 10 e0 ldi r17, 0x00 ; 0
34
30: a0 e6 ldi r26, 0x60 ; 96
35
32: b0 e0 ldi r27, 0x00 ; 0
36
34: e4 e0 ldi r30, 0x04 ; 4
37
36: f6 e0 ldi r31, 0x06 ; 6
38
38: 02 c0 rjmp .+4 ; 0x3e
39
3a: 05 90 lpm r0, Z+
40
3c: 0d 92 st X+, r0
41
3e: a8 36 cpi r26, 0x68 ; 104
42
40: b1 07 cpc r27, r17
43
42: d9 f7 brne .-10 ; 0x3a
44
44: 2d d0 rcall .+90 ; 0xa0
45
46: dc c2 rjmp .+1464 ; 0x600
46
48: db cf rjmp .-74 ; 0x0
47
4a: ef 92 push r14
48
4c: ff 92 push r15
49
4e: 0f 93 push r16
50
50: 1f 93 push r17
51
52: cf 93 push r28
52
54: df 93 push r29
53
56: c2 e0 ldi r28, 0x02 ; 2
54
58: d0 e0 ldi r29, 0x00 ; 0
55
5a: 0f 2e mov r0, r31
56
5c: fd ec ldi r31, 0xCD ; 205
57
5e: ef 2e mov r14, r31
58
60: fc ec ldi r31, 0xCC ; 204
59
62: ff 2e mov r15, r31
60
64: f4 e4 ldi r31, 0x44 ; 68
61
66: 0f 2f mov r16, r31
62
68: f1 e4 ldi r31, 0x41 ; 65
63
6a: 1f 2f mov r17, r31
64
6c: f0 2d mov r31, r0
65
6e: c8 01 movw r24, r16
66
70: b7 01 movw r22, r14
67
72: 20 e0 ldi r18, 0x00 ; 0
68
74: 30 e0 ldi r19, 0x00 ; 0
69
76: 40 e2 ldi r20, 0x20 ; 32
70
78: 51 e4 ldi r21, 0x41 ; 65
71
7a: 13 d0 rcall .+38 ; 0xa2
72
7c: 7b 01 movw r14, r22
73
7e: 8c 01 movw r16, r24
74
80: 21 96 adiw r28, 0x01 ; 1
75
82: 20 e0 ldi r18, 0x00 ; 0
76
84: 30 e0 ldi r19, 0x00 ; 0
77
86: 40 e2 ldi r20, 0x20 ; 32
78
88: 51 e4 ldi r21, 0x41 ; 65
79
8a: b2 d0 rcall .+356 ; 0x1f0
80
8c: 88 23 and r24, r24
81
8e: 7c f7 brge .-34 ; 0x6e
82
90: ce 01 movw r24, r28
83
92: df 91 pop r29
84
94: cf 91 pop r28
85
96: 1f 91 pop r17
86
98: 0f 91 pop r16
87
9a: ff 90 pop r15
88
9c: ef 90 pop r14
89
9e: 08 95 ret
90
a0: ff cf rjmp .-2 ; 0xa0
91
a2: a8 e1 ldi r26, 0x18 ; 24
92
a4: b0 e0 ldi r27, 0x00 ; 0
93
a6: e6 e5 ldi r30, 0x56 ; 86
94
a8: f0 e0 ldi r31, 0x00 ; 0
95
aa: 7b c2 rjmp .+1270 ; 0x5a2
96
ac: 69 83 std Y+1, r22 ; 0x01
97
ae: 7a 83 std Y+2, r23 ; 0x02
98
b0: 8b 83 std Y+3, r24 ; 0x03
99
b2: 9c 83 std Y+4, r25 ; 0x04
100
b4: 2d 83 std Y+5, r18 ; 0x05
101
b6: 3e 83 std Y+6, r19 ; 0x06
102
b8: 4f 83 std Y+7, r20 ; 0x07
103
ba: 58 87 std Y+8, r21 ; 0x08
104
bc: b9 e0 ldi r27, 0x09 ; 9
105
be: eb 2e mov r14, r27
106
c0: f1 2c mov r15, r1
107
c2: ec 0e add r14, r28
108
c4: fd 1e adc r15, r29
109
c6: ce 01 movw r24, r28
110
c8: 01 96 adiw r24, 0x01 ; 1
111
ca: b7 01 movw r22, r14
112
cc: 91 d1 rcall .+802 ; 0x3f0
113
ce: 8e 01 movw r16, r28
114
d0: 0f 5e subi r16, 0xEF ; 239
115
d2: 1f 4f sbci r17, 0xFF ; 255
116
d4: ce 01 movw r24, r28
117
d6: 05 96 adiw r24, 0x05 ; 5
118
d8: b8 01 movw r22, r16
119
da: 8a d1 rcall .+788 ; 0x3f0
120
dc: 29 85 ldd r18, Y+9 ; 0x09
121
de: 22 30 cpi r18, 0x02 ; 2
122
e0: 08 f4 brcc .+2 ; 0xe4
123
e2: 7e c0 rjmp .+252 ; 0x1e0
124
e4: 39 89 ldd r19, Y+17 ; 0x11
125
e6: 32 30 cpi r19, 0x02 ; 2
126
e8: 10 f4 brcc .+4 ; 0xee
127
ea: b8 01 movw r22, r16
128
ec: 7c c0 rjmp .+248 ; 0x1e6
129
ee: 8a 85 ldd r24, Y+10 ; 0x0a
130
f0: 9a 89 ldd r25, Y+18 ; 0x12
131
f2: 89 27 eor r24, r25
132
f4: 8a 87 std Y+10, r24 ; 0x0a
133
f6: 24 30 cpi r18, 0x04 ; 4
134
f8: 11 f0 breq .+4 ; 0xfe
135
fa: 22 30 cpi r18, 0x02 ; 2
136
fc: 31 f4 brne .+12 ; 0x10a
137
fe: 23 17 cp r18, r19
138
100: 09 f0 breq .+2 ; 0x104
139
102: 6e c0 rjmp .+220 ; 0x1e0
140
104: 60 e6 ldi r22, 0x60 ; 96
141
106: 70 e0 ldi r23, 0x00 ; 0
142
108: 6e c0 rjmp .+220 ; 0x1e6
143
10a: 34 30 cpi r19, 0x04 ; 4
144
10c: 39 f4 brne .+14 ; 0x11c
145
10e: 1d 86 std Y+13, r1 ; 0x0d
146
110: 1e 86 std Y+14, r1 ; 0x0e
147
112: 1f 86 std Y+15, r1 ; 0x0f
148
114: 18 8a std Y+16, r1 ; 0x10
149
116: 1c 86 std Y+12, r1 ; 0x0c
150
118: 1b 86 std Y+11, r1 ; 0x0b
151
11a: 04 c0 rjmp .+8 ; 0x124
152
11c: 32 30 cpi r19, 0x02 ; 2
153
11e: 21 f4 brne .+8 ; 0x128
154
120: 84 e0 ldi r24, 0x04 ; 4
155
122: 89 87 std Y+9, r24 ; 0x09
156
124: b7 01 movw r22, r14
157
126: 5f c0 rjmp .+190 ; 0x1e6
158
128: 2b 85 ldd r18, Y+11 ; 0x0b
159
12a: 3c 85 ldd r19, Y+12 ; 0x0c
160
12c: 8b 89 ldd r24, Y+19 ; 0x13
161
12e: 9c 89 ldd r25, Y+20 ; 0x14
162
130: 28 1b sub r18, r24
163
132: 39 0b sbc r19, r25
164
134: 3c 87 std Y+12, r19 ; 0x0c
165
136: 2b 87 std Y+11, r18 ; 0x0b
166
138: ed 84 ldd r14, Y+13 ; 0x0d
167
13a: fe 84 ldd r15, Y+14 ; 0x0e
168
13c: 0f 85 ldd r16, Y+15 ; 0x0f
169
13e: 18 89 ldd r17, Y+16 ; 0x10
170
140: ad 88 ldd r10, Y+21 ; 0x15
171
142: be 88 ldd r11, Y+22 ; 0x16
172
144: cf 88 ldd r12, Y+23 ; 0x17
173
146: d8 8c ldd r13, Y+24 ; 0x18
174
148: ea 14 cp r14, r10
175
14a: fb 04 cpc r15, r11
176
14c: 0c 05 cpc r16, r12
177
14e: 1d 05 cpc r17, r13
178
150: 40 f4 brcc .+16 ; 0x162
179
152: ee 0c add r14, r14
180
154: ff 1c adc r15, r15
181
156: 00 1f adc r16, r16
182
158: 11 1f adc r17, r17
183
15a: 21 50 subi r18, 0x01 ; 1
184
15c: 30 40 sbci r19, 0x00 ; 0
185
15e: 3c 87 std Y+12, r19 ; 0x0c
186
160: 2b 87 std Y+11, r18 ; 0x0b
187
162: 20 e0 ldi r18, 0x00 ; 0
188
164: 30 e0 ldi r19, 0x00 ; 0
189
166: 40 e0 ldi r20, 0x00 ; 0
190
168: 50 e0 ldi r21, 0x00 ; 0
191
16a: 80 e0 ldi r24, 0x00 ; 0
192
16c: 90 e0 ldi r25, 0x00 ; 0
193
16e: a0 e0 ldi r26, 0x00 ; 0
194
170: b0 e4 ldi r27, 0x40 ; 64
195
172: 60 e0 ldi r22, 0x00 ; 0
196
174: 70 e0 ldi r23, 0x00 ; 0
197
176: ea 14 cp r14, r10
198
178: fb 04 cpc r15, r11
199
17a: 0c 05 cpc r16, r12
200
17c: 1d 05 cpc r17, r13
201
17e: 40 f0 brcs .+16 ; 0x190
202
180: 28 2b or r18, r24
203
182: 39 2b or r19, r25
204
184: 4a 2b or r20, r26
205
186: 5b 2b or r21, r27
206
188: ea 18 sub r14, r10
207
18a: fb 08 sbc r15, r11
208
18c: 0c 09 sbc r16, r12
209
18e: 1d 09 sbc r17, r13
210
190: b6 95 lsr r27
211
192: a7 95 ror r26
212
194: 97 95 ror r25
213
196: 87 95 ror r24
214
198: ee 0c add r14, r14
215
19a: ff 1c adc r15, r15
216
19c: 00 1f adc r16, r16
217
19e: 11 1f adc r17, r17
218
1a0: 6f 5f subi r22, 0xFF ; 255
219
1a2: 7f 4f sbci r23, 0xFF ; 255
220
1a4: 6f 31 cpi r22, 0x1F ; 31
221
1a6: 71 05 cpc r23, r1
222
1a8: 31 f7 brne .-52 ; 0x176
223
1aa: da 01 movw r26, r20
224
1ac: c9 01 movw r24, r18
225
1ae: 8f 77 andi r24, 0x7F ; 127
226
1b0: 90 70 andi r25, 0x00 ; 0
227
1b2: a0 70 andi r26, 0x00 ; 0
228
1b4: b0 70 andi r27, 0x00 ; 0
229
1b6: 80 34 cpi r24, 0x40 ; 64
230
1b8: 91 05 cpc r25, r1
231
1ba: a1 05 cpc r26, r1
232
1bc: b1 05 cpc r27, r1
233
1be: 61 f4 brne .+24 ; 0x1d8
234
1c0: 27 fd sbrc r18, 7
235
1c2: 0a c0 rjmp .+20 ; 0x1d8
236
1c4: e1 14 cp r14, r1
237
1c6: f1 04 cpc r15, r1
238
1c8: 01 05 cpc r16, r1
239
1ca: 11 05 cpc r17, r1
240
1cc: 29 f0 breq .+10 ; 0x1d8
241
1ce: 20 5c subi r18, 0xC0 ; 192
242
1d0: 3f 4f sbci r19, 0xFF ; 255
243
1d2: 4f 4f sbci r20, 0xFF ; 255
244
1d4: 5f 4f sbci r21, 0xFF ; 255
245
1d6: 20 78 andi r18, 0x80 ; 128
246
1d8: 2d 87 std Y+13, r18 ; 0x0d
247
1da: 3e 87 std Y+14, r19 ; 0x0e
248
1dc: 4f 87 std Y+15, r20 ; 0x0f
249
1de: 58 8b std Y+16, r21 ; 0x10
250
1e0: be 01 movw r22, r28
251
1e2: 67 5f subi r22, 0xF7 ; 247
252
1e4: 7f 4f sbci r23, 0xFF ; 255
253
1e6: cb 01 movw r24, r22
254
1e8: 2e d0 rcall .+92 ; 0x246
255
1ea: 68 96 adiw r28, 0x18 ; 24
256
1ec: ea e0 ldi r30, 0x0A ; 10
257
1ee: f5 c1 rjmp .+1002 ; 0x5da
258
1f0: a8 e1 ldi r26, 0x18 ; 24
259
1f2: b0 e0 ldi r27, 0x00 ; 0
260
1f4: ed ef ldi r30, 0xFD ; 253
261
1f6: f0 e0 ldi r31, 0x00 ; 0
262
1f8: d8 c1 rjmp .+944 ; 0x5aa
263
1fa: 69 83 std Y+1, r22 ; 0x01
264
1fc: 7a 83 std Y+2, r23 ; 0x02
265
1fe: 8b 83 std Y+3, r24 ; 0x03
266
200: 9c 83 std Y+4, r25 ; 0x04
267
202: 2d 83 std Y+5, r18 ; 0x05
268
204: 3e 83 std Y+6, r19 ; 0x06
269
206: 4f 83 std Y+7, r20 ; 0x07
270
208: 58 87 std Y+8, r21 ; 0x08
271
20a: 89 e0 ldi r24, 0x09 ; 9
272
20c: e8 2e mov r14, r24
273
20e: f1 2c mov r15, r1
274
210: ec 0e add r14, r28
275
212: fd 1e adc r15, r29
276
214: ce 01 movw r24, r28
277
216: 01 96 adiw r24, 0x01 ; 1
278
218: b7 01 movw r22, r14
279
21a: ea d0 rcall .+468 ; 0x3f0
280
21c: 8e 01 movw r16, r28
281
21e: 0f 5e subi r16, 0xEF ; 239
282
220: 1f 4f sbci r17, 0xFF ; 255
283
222: ce 01 movw r24, r28
284
224: 05 96 adiw r24, 0x05 ; 5
285
226: b8 01 movw r22, r16
286
228: e3 d0 rcall .+454 ; 0x3f0
287
22a: 89 85 ldd r24, Y+9 ; 0x09
288
22c: 82 30 cpi r24, 0x02 ; 2
289
22e: 38 f0 brcs .+14 ; 0x23e
290
230: 89 89 ldd r24, Y+17 ; 0x11
291
232: 82 30 cpi r24, 0x02 ; 2
292
234: 20 f0 brcs .+8 ; 0x23e
293
236: c7 01 movw r24, r14
294
238: b8 01 movw r22, r16
295
23a: 52 d1 rcall .+676 ; 0x4e0
296
23c: 01 c0 rjmp .+2 ; 0x240
297
23e: 81 e0 ldi r24, 0x01 ; 1
298
240: 68 96 adiw r28, 0x18 ; 24
299
242: e6 e0 ldi r30, 0x06 ; 6
300
244: ce c1 rjmp .+924 ; 0x5e2
301
246: df 92 push r13
302
248: ef 92 push r14
303
24a: ff 92 push r15
304
24c: 0f 93 push r16
305
24e: 1f 93 push r17
306
250: fc 01 movw r30, r24
307
252: e4 80 ldd r14, Z+4 ; 0x04
308
254: f5 80 ldd r15, Z+5 ; 0x05
309
256: 06 81 ldd r16, Z+6 ; 0x06
310
258: 17 81 ldd r17, Z+7 ; 0x07
311
25a: d1 80 ldd r13, Z+1 ; 0x01
312
25c: 80 81 ld r24, Z
313
25e: 82 30 cpi r24, 0x02 ; 2
314
260: 48 f4 brcc .+18 ; 0x274
315
262: 80 e0 ldi r24, 0x00 ; 0
316
264: 90 e0 ldi r25, 0x00 ; 0
317
266: a0 e1 ldi r26, 0x10 ; 16
318
268: b0 e0 ldi r27, 0x00 ; 0
319
26a: e8 2a or r14, r24
320
26c: f9 2a or r15, r25
321
26e: 0a 2b or r16, r26
322
270: 1b 2b or r17, r27
323
272: a5 c0 rjmp .+330 ; 0x3be
324
274: 84 30 cpi r24, 0x04 ; 4
325
276: 09 f4 brne .+2 ; 0x27a
326
278: 9f c0 rjmp .+318 ; 0x3b8
327
27a: 82 30 cpi r24, 0x02 ; 2
328
27c: 21 f4 brne .+8 ; 0x286
329
27e: ee 24 eor r14, r14
330
280: ff 24 eor r15, r15
331
282: 87 01 movw r16, r14
332
284: 05 c0 rjmp .+10 ; 0x290
333
286: e1 14 cp r14, r1
334
288: f1 04 cpc r15, r1
335
28a: 01 05 cpc r16, r1
336
28c: 11 05 cpc r17, r1
337
28e: 19 f4 brne .+6 ; 0x296
338
290: e0 e0 ldi r30, 0x00 ; 0
339
292: f0 e0 ldi r31, 0x00 ; 0
340
294: 96 c0 rjmp .+300 ; 0x3c2
341
296: 62 81 ldd r22, Z+2 ; 0x02
342
298: 73 81 ldd r23, Z+3 ; 0x03
343
29a: 9f ef ldi r25, 0xFF ; 255
344
29c: 62 38 cpi r22, 0x82 ; 130
345
29e: 79 07 cpc r23, r25
346
2a0: 0c f0 brlt .+2 ; 0x2a4
347
2a2: 5b c0 rjmp .+182 ; 0x35a
348
2a4: 22 e8 ldi r18, 0x82 ; 130
349
2a6: 3f ef ldi r19, 0xFF ; 255
350
2a8: 26 1b sub r18, r22
351
2aa: 37 0b sbc r19, r23
352
2ac: 2a 31 cpi r18, 0x1A ; 26
353
2ae: 31 05 cpc r19, r1
354
2b0: 2c f0 brlt .+10 ; 0x2bc
355
2b2: 20 e0 ldi r18, 0x00 ; 0
356
2b4: 30 e0 ldi r19, 0x00 ; 0
357
2b6: 40 e0 ldi r20, 0x00 ; 0
358
2b8: 50 e0 ldi r21, 0x00 ; 0
359
2ba: 2a c0 rjmp .+84 ; 0x310
360
2bc: b8 01 movw r22, r16
361
2be: a7 01 movw r20, r14
362
2c0: 02 2e mov r0, r18
363
2c2: 04 c0 rjmp .+8 ; 0x2cc
364
2c4: 76 95 lsr r23
365
2c6: 67 95 ror r22
366
2c8: 57 95 ror r21
367
2ca: 47 95 ror r20
368
2cc: 0a 94 dec r0
369
2ce: d2 f7 brpl .-12 ; 0x2c4
370
2d0: 81 e0 ldi r24, 0x01 ; 1
371
2d2: 90 e0 ldi r25, 0x00 ; 0
372
2d4: a0 e0 ldi r26, 0x00 ; 0
373
2d6: b0 e0 ldi r27, 0x00 ; 0
374
2d8: 04 c0 rjmp .+8 ; 0x2e2
375
2da: 88 0f add r24, r24
376
2dc: 99 1f adc r25, r25
377
2de: aa 1f adc r26, r26
378
2e0: bb 1f adc r27, r27
379
2e2: 2a 95 dec r18
380
2e4: d2 f7 brpl .-12 ; 0x2da
381
2e6: 01 97 sbiw r24, 0x01 ; 1
382
2e8: a1 09 sbc r26, r1
383
2ea: b1 09 sbc r27, r1
384
2ec: 8e 21 and r24, r14
385
2ee: 9f 21 and r25, r15
386
2f0: a0 23 and r26, r16
387
2f2: b1 23 and r27, r17
388
2f4: 00 97 sbiw r24, 0x00 ; 0
389
2f6: a1 05 cpc r26, r1
390
2f8: b1 05 cpc r27, r1
391
2fa: 21 f0 breq .+8 ; 0x304
392
2fc: 81 e0 ldi r24, 0x01 ; 1
393
2fe: 90 e0 ldi r25, 0x00 ; 0
394
300: a0 e0 ldi r26, 0x00 ; 0
395
302: b0 e0 ldi r27, 0x00 ; 0
396
304: 9a 01 movw r18, r20
397
306: ab 01 movw r20, r22
398
308: 28 2b or r18, r24
399
30a: 39 2b or r19, r25
400
30c: 4a 2b or r20, r26
401
30e: 5b 2b or r21, r27
402
310: da 01 movw r26, r20
403
312: c9 01 movw r24, r18
404
314: 8f 77 andi r24, 0x7F ; 127
405
316: 90 70 andi r25, 0x00 ; 0
406
318: a0 70 andi r26, 0x00 ; 0
407
31a: b0 70 andi r27, 0x00 ; 0
408
31c: 80 34 cpi r24, 0x40 ; 64
409
31e: 91 05 cpc r25, r1
410
320: a1 05 cpc r26, r1
411
322: b1 05 cpc r27, r1
412
324: 39 f4 brne .+14 ; 0x334
413
326: 27 ff sbrs r18, 7
414
328: 09 c0 rjmp .+18 ; 0x33c
415
32a: 20 5c subi r18, 0xC0 ; 192
416
32c: 3f 4f sbci r19, 0xFF ; 255
417
32e: 4f 4f sbci r20, 0xFF ; 255
418
330: 5f 4f sbci r21, 0xFF ; 255
419
332: 04 c0 rjmp .+8 ; 0x33c
420
334: 21 5c subi r18, 0xC1 ; 193
421
336: 3f 4f sbci r19, 0xFF ; 255
422
338: 4f 4f sbci r20, 0xFF ; 255
423
33a: 5f 4f sbci r21, 0xFF ; 255
424
33c: e0 e0 ldi r30, 0x00 ; 0
425
33e: f0 e0 ldi r31, 0x00 ; 0
426
340: 20 30 cpi r18, 0x00 ; 0
427
342: a0 e0 ldi r26, 0x00 ; 0
428
344: 3a 07 cpc r19, r26
429
346: a0 e0 ldi r26, 0x00 ; 0
430
348: 4a 07 cpc r20, r26
431
34a: a0 e4 ldi r26, 0x40 ; 64
432
34c: 5a 07 cpc r21, r26
433
34e: 10 f0 brcs .+4 ; 0x354
434
350: e1 e0 ldi r30, 0x01 ; 1
435
352: f0 e0 ldi r31, 0x00 ; 0
436
354: 79 01 movw r14, r18
437
356: 8a 01 movw r16, r20
438
358: 27 c0 rjmp .+78 ; 0x3a8
439
35a: 60 38 cpi r22, 0x80 ; 128
440
35c: 71 05 cpc r23, r1
441
35e: 64 f5 brge .+88 ; 0x3b8
442
360: fb 01 movw r30, r22
443
362: e1 58 subi r30, 0x81 ; 129
444
364: ff 4f sbci r31, 0xFF ; 255
445
366: d8 01 movw r26, r16
446
368: c7 01 movw r24, r14
447
36a: 8f 77 andi r24, 0x7F ; 127
448
36c: 90 70 andi r25, 0x00 ; 0
449
36e: a0 70 andi r26, 0x00 ; 0
450
370: b0 70 andi r27, 0x00 ; 0
451
372: 80 34 cpi r24, 0x40 ; 64
452
374: 91 05 cpc r25, r1
453
376: a1 05 cpc r26, r1
454
378: b1 05 cpc r27, r1
455
37a: 39 f4 brne .+14 ; 0x38a
456
37c: e7 fe sbrs r14, 7
457
37e: 0d c0 rjmp .+26 ; 0x39a
458
380: 80 e4 ldi r24, 0x40 ; 64
459
382: 90 e0 ldi r25, 0x00 ; 0
460
384: a0 e0 ldi r26, 0x00 ; 0
461
386: b0 e0 ldi r27, 0x00 ; 0
462
388: 04 c0 rjmp .+8 ; 0x392
463
38a: 8f e3 ldi r24, 0x3F ; 63
464
38c: 90 e0 ldi r25, 0x00 ; 0
465
38e: a0 e0 ldi r26, 0x00 ; 0
466
390: b0 e0 ldi r27, 0x00 ; 0
467
392: e8 0e add r14, r24
468
394: f9 1e adc r15, r25
469
396: 0a 1f adc r16, r26
470
398: 1b 1f adc r17, r27
471
39a: 17 ff sbrs r17, 7
472
39c: 05 c0 rjmp .+10 ; 0x3a8
473
39e: 16 95 lsr r17
474
3a0: 07 95 ror r16
475
3a2: f7 94 ror r15
476
3a4: e7 94 ror r14
477
3a6: 31 96 adiw r30, 0x01 ; 1
478
3a8: 87 e0 ldi r24, 0x07 ; 7
479
3aa: 16 95 lsr r17
480
3ac: 07 95 ror r16
481
3ae: f7 94 ror r15
482
3b0: e7 94 ror r14
483
3b2: 8a 95 dec r24
484
3b4: d1 f7 brne .-12 ; 0x3aa
485
3b6: 05 c0 rjmp .+10 ; 0x3c2
486
3b8: ee 24 eor r14, r14
487
3ba: ff 24 eor r15, r15
488
3bc: 87 01 movw r16, r14
489
3be: ef ef ldi r30, 0xFF ; 255
490
3c0: f0 e0 ldi r31, 0x00 ; 0
491
3c2: 6e 2f mov r22, r30
492
3c4: 67 95 ror r22
493
3c6: 66 27 eor r22, r22
494
3c8: 67 95 ror r22
495
3ca: 90 2f mov r25, r16
496
3cc: 9f 77 andi r25, 0x7F ; 127
497
3ce: d7 94 ror r13
498
3d0: dd 24 eor r13, r13
499
3d2: d7 94 ror r13
500
3d4: 8e 2f mov r24, r30
501
3d6: 86 95 lsr r24
502
3d8: 49 2f mov r20, r25
503
3da: 46 2b or r20, r22
504
3dc: 58 2f mov r21, r24
505
3de: 5d 29 or r21, r13
506
3e0: b7 01 movw r22, r14
507
3e2: ca 01 movw r24, r20
508
3e4: 1f 91 pop r17
509
3e6: 0f 91 pop r16
510
3e8: ff 90 pop r15
511
3ea: ef 90 pop r14
512
3ec: df 90 pop r13
513
3ee: 08 95 ret
514
3f0: fc 01 movw r30, r24
515
3f2: db 01 movw r26, r22
516
3f4: 40 81 ld r20, Z
517
3f6: 51 81 ldd r21, Z+1 ; 0x01
518
3f8: 22 81 ldd r18, Z+2 ; 0x02
519
3fa: 62 2f mov r22, r18
520
3fc: 6f 77 andi r22, 0x7F ; 127
521
3fe: 70 e0 ldi r23, 0x00 ; 0
522
400: 22 1f adc r18, r18
523
402: 22 27 eor r18, r18
524
404: 22 1f adc r18, r18
525
406: 93 81 ldd r25, Z+3 ; 0x03
526
408: 89 2f mov r24, r25
527
40a: 88 0f add r24, r24
528
40c: 82 2b or r24, r18
529
40e: 28 2f mov r18, r24
530
410: 30 e0 ldi r19, 0x00 ; 0
531
412: 99 1f adc r25, r25
532
414: 99 27 eor r25, r25
533
416: 99 1f adc r25, r25
534
418: 11 96 adiw r26, 0x01 ; 1
535
41a: 9c 93 st X, r25
536
41c: 11 97 sbiw r26, 0x01 ; 1
537
41e: 21 15 cp r18, r1
538
420: 31 05 cpc r19, r1
539
422: a9 f5 brne .+106 ; 0x48e
540
424: 41 15 cp r20, r1
541
426: 51 05 cpc r21, r1
542
428: 61 05 cpc r22, r1
543
42a: 71 05 cpc r23, r1
544
42c: 11 f4 brne .+4 ; 0x432
545
42e: 82 e0 ldi r24, 0x02 ; 2
546
430: 37 c0 rjmp .+110 ; 0x4a0
547
432: 82 e8 ldi r24, 0x82 ; 130
548
434: 9f ef ldi r25, 0xFF ; 255
549
436: 13 96 adiw r26, 0x03 ; 3
550
438: 9c 93 st X, r25
551
43a: 8e 93 st -X, r24
552
43c: 12 97 sbiw r26, 0x02 ; 2
553
43e: 9a 01 movw r18, r20
554
440: ab 01 movw r20, r22
555
442: 67 e0 ldi r22, 0x07 ; 7
556
444: 22 0f add r18, r18
557
446: 33 1f adc r19, r19
558
448: 44 1f adc r20, r20
559
44a: 55 1f adc r21, r21
560
44c: 6a 95 dec r22
561
44e: d1 f7 brne .-12 ; 0x444
562
450: 83 e0 ldi r24, 0x03 ; 3
563
452: 8c 93 st X, r24
564
454: 0d c0 rjmp .+26 ; 0x470
565
456: 22 0f add r18, r18
566
458: 33 1f adc r19, r19
567
45a: 44 1f adc r20, r20
568
45c: 55 1f adc r21, r21
569
45e: 12 96 adiw r26, 0x02 ; 2
570
460: 8d 91 ld r24, X+
571
462: 9c 91 ld r25, X
572
464: 13 97 sbiw r26, 0x03 ; 3
573
466: 01 97 sbiw r24, 0x01 ; 1
574
468: 13 96 adiw r26, 0x03 ; 3
575
46a: 9c 93 st X, r25
576
46c: 8e 93 st -X, r24
577
46e: 12 97 sbiw r26, 0x02 ; 2
578
470: 20 30 cpi r18, 0x00 ; 0
579
472: 80 e0 ldi r24, 0x00 ; 0
580
474: 38 07 cpc r19, r24
581
476: 80 e0 ldi r24, 0x00 ; 0
582
478: 48 07 cpc r20, r24
583
47a: 80 e4 ldi r24, 0x40 ; 64
584
47c: 58 07 cpc r21, r24
585
47e: 58 f3 brcs .-42 ; 0x456
586
480: 14 96 adiw r26, 0x04 ; 4
587
482: 2d 93 st X+, r18
588
484: 3d 93 st X+, r19
589
486: 4d 93 st X+, r20
590
488: 5c 93 st X, r21
591
48a: 17 97 sbiw r26, 0x07 ; 7
592
48c: 08 95 ret
593
48e: 2f 3f cpi r18, 0xFF ; 255
594
490: 31 05 cpc r19, r1
595
492: 79 f4 brne .+30 ; 0x4b2
596
494: 41 15 cp r20, r1
597
496: 51 05 cpc r21, r1
598
498: 61 05 cpc r22, r1
599
49a: 71 05 cpc r23, r1
600
49c: 19 f4 brne .+6 ; 0x4a4
601
49e: 84 e0 ldi r24, 0x04 ; 4
602
4a0: 8c 93 st X, r24
603
4a2: 08 95 ret
604
4a4: 64 ff sbrs r22, 4
605
4a6: 03 c0 rjmp .+6 ; 0x4ae
606
4a8: 81 e0 ldi r24, 0x01 ; 1
607
4aa: 8c 93 st X, r24
608
4ac: 12 c0 rjmp .+36 ; 0x4d2
609
4ae: 1c 92 st X, r1
610
4b0: 10 c0 rjmp .+32 ; 0x4d2
611
4b2: 2f 57 subi r18, 0x7F ; 127
612
4b4: 30 40 sbci r19, 0x00 ; 0
613
4b6: 13 96 adiw r26, 0x03 ; 3
614
4b8: 3c 93 st X, r19
615
4ba: 2e 93 st -X, r18
616
4bc: 12 97 sbiw r26, 0x02 ; 2
617
4be: 83 e0 ldi r24, 0x03 ; 3
618
4c0: 8c 93 st X, r24
619
4c2: 87 e0 ldi r24, 0x07 ; 7
620
4c4: 44 0f add r20, r20
621
4c6: 55 1f adc r21, r21
622
4c8: 66 1f adc r22, r22
623
4ca: 77 1f adc r23, r23
624
4cc: 8a 95 dec r24
625
4ce: d1 f7 brne .-12 ; 0x4c4
626
4d0: 70 64 ori r23, 0x40 ; 64
627
4d2: 14 96 adiw r26, 0x04 ; 4
628
4d4: 4d 93 st X+, r20
629
4d6: 5d 93 st X+, r21
630
4d8: 6d 93 st X+, r22
631
4da: 7c 93 st X, r23
632
4dc: 17 97 sbiw r26, 0x07 ; 7
633
4de: 08 95 ret
634
4e0: 1f 93 push r17
635
4e2: dc 01 movw r26, r24
636
4e4: fb 01 movw r30, r22
637
4e6: 9c 91 ld r25, X
638
4e8: 92 30 cpi r25, 0x02 ; 2
639
4ea: 08 f4 brcc .+2 ; 0x4ee
640
4ec: 47 c0 rjmp .+142 ; 0x57c
641
4ee: 80 81 ld r24, Z
642
4f0: 82 30 cpi r24, 0x02 ; 2
643
4f2: 08 f4 brcc .+2 ; 0x4f6
644
4f4: 43 c0 rjmp .+134 ; 0x57c
645
4f6: 94 30 cpi r25, 0x04 ; 4
646
4f8: 51 f4 brne .+20 ; 0x50e
647
4fa: 11 96 adiw r26, 0x01 ; 1
648
4fc: 1c 91 ld r17, X
649
4fe: 84 30 cpi r24, 0x04 ; 4
650
500: 99 f5 brne .+102 ; 0x568
651
502: 81 81 ldd r24, Z+1 ; 0x01
652
504: 68 2f mov r22, r24
653
506: 70 e0 ldi r23, 0x00 ; 0
654
508: 61 1b sub r22, r17
655
50a: 71 09 sbc r23, r1
656
50c: 3f c0 rjmp .+126 ; 0x58c
657
50e: 84 30 cpi r24, 0x04 ; 4
658
510: 21 f0 breq .+8 ; 0x51a
659
512: 92 30 cpi r25, 0x02 ; 2
660
514: 31 f4 brne .+12 ; 0x522
661
516: 82 30 cpi r24, 0x02 ; 2
662
518: b9 f1 breq .+110 ; 0x588
663
51a: 81 81 ldd r24, Z+1 ; 0x01
664
51c: 88 23 and r24, r24
665
51e: 89 f1 breq .+98 ; 0x582
666
520: 2d c0 rjmp .+90 ; 0x57c
667
522: 11 96 adiw r26, 0x01 ; 1
668
524: 1c 91 ld r17, X
669
526: 11 97 sbiw r26, 0x01 ; 1
670
528: 82 30 cpi r24, 0x02 ; 2
671
52a: f1 f0 breq .+60 ; 0x568
672
52c: 81 81 ldd r24, Z+1 ; 0x01
673
52e: 18 17 cp r17, r24
674
530: d9 f4 brne .+54 ; 0x568
675
532: 12 96 adiw r26, 0x02 ; 2
676
534: 2d 91 ld r18, X+
677
536: 3c 91 ld r19, X
678
538: 13 97 sbiw r26, 0x03 ; 3
679
53a: 82 81 ldd r24, Z+2 ; 0x02
680
53c: 93 81 ldd r25, Z+3 ; 0x03
681
53e: 82 17 cp r24, r18
682
540: 93 07 cpc r25, r19
683
542: 94 f0 brlt .+36 ; 0x568
684
544: 28 17 cp r18, r24
685
546: 39 07 cpc r19, r25
686
548: bc f0 brlt .+46 ; 0x578
687
54a: 14 96 adiw r26, 0x04 ; 4
688
54c: 8d 91 ld r24, X+
689
54e: 9d 91 ld r25, X+
690
550: 0d 90 ld r0, X+
691
552: bc 91 ld r27, X
692
554: a0 2d mov r26, r0
693
556: 24 81 ldd r18, Z+4 ; 0x04
694
558: 35 81 ldd r19, Z+5 ; 0x05
695
55a: 46 81 ldd r20, Z+6 ; 0x06
696
55c: 57 81 ldd r21, Z+7 ; 0x07
697
55e: 28 17 cp r18, r24
698
560: 39 07 cpc r19, r25
699
562: 4a 07 cpc r20, r26
700
564: 5b 07 cpc r21, r27
701
566: 18 f4 brcc .+6 ; 0x56e
702
568: 11 23 and r17, r17
703
56a: 41 f0 breq .+16 ; 0x57c
704
56c: 0a c0 rjmp .+20 ; 0x582
705
56e: 82 17 cp r24, r18
706
570: 93 07 cpc r25, r19
707
572: a4 07 cpc r26, r20
708
574: b5 07 cpc r27, r21
709
576: 40 f4 brcc .+16 ; 0x588
710
578: 11 23 and r17, r17
711
57a: 19 f0 breq .+6 ; 0x582
712
57c: 61 e0 ldi r22, 0x01 ; 1
713
57e: 70 e0 ldi r23, 0x00 ; 0
714
580: 05 c0 rjmp .+10 ; 0x58c
715
582: 6f ef ldi r22, 0xFF ; 255
716
584: 7f ef ldi r23, 0xFF ; 255
717
586: 02 c0 rjmp .+4 ; 0x58c
718
588: 60 e0 ldi r22, 0x00 ; 0
719
58a: 70 e0 ldi r23, 0x00 ; 0
720
58c: cb 01 movw r24, r22
721
58e: 1f 91 pop r17
722
590: 08 95 ret
723
592: 2f 92 push r2
724
594: 3f 92 push r3
725
596: 4f 92 push r4
726
598: 5f 92 push r5
727
59a: 6f 92 push r6
728
59c: 7f 92 push r7
729
59e: 8f 92 push r8
730
5a0: 9f 92 push r9
731
5a2: af 92 push r10
732
5a4: bf 92 push r11
733
5a6: cf 92 push r12
734
5a8: df 92 push r13
735
5aa: ef 92 push r14
736
5ac: ff 92 push r15
737
5ae: 0f 93 push r16
738
5b0: 1f 93 push r17
739
5b2: cf 93 push r28
740
5b4: df 93 push r29
741
5b6: cd b7 in r28, 0x3d ; 61
742
5b8: de b7 in r29, 0x3e ; 62
743
5ba: ca 1b sub r28, r26
744
5bc: db 0b sbc r29, r27
745
5be: 0f b6 in r0, 0x3f ; 63
746
5c0: f8 94 cli
747
5c2: de bf out 0x3e, r29 ; 62
748
5c4: 0f be out 0x3f, r0 ; 63
749
5c6: cd bf out 0x3d, r28 ; 61
750
5c8: 09 94 ijmp
751
5ca: 2a 88 ldd r2, Y+18 ; 0x12
752
5cc: 39 88 ldd r3, Y+17 ; 0x11
753
5ce: 48 88 ldd r4, Y+16 ; 0x10
754
5d0: 5f 84 ldd r5, Y+15 ; 0x0f
755
5d2: 6e 84 ldd r6, Y+14 ; 0x0e
756
5d4: 7d 84 ldd r7, Y+13 ; 0x0d
757
5d6: 8c 84 ldd r8, Y+12 ; 0x0c
758
5d8: 9b 84 ldd r9, Y+11 ; 0x0b
759
5da: aa 84 ldd r10, Y+10 ; 0x0a
760
5dc: b9 84 ldd r11, Y+9 ; 0x09
761
5de: c8 84 ldd r12, Y+8 ; 0x08
762
5e0: df 80 ldd r13, Y+7 ; 0x07
763
5e2: ee 80 ldd r14, Y+6 ; 0x06
764
5e4: fd 80 ldd r15, Y+5 ; 0x05
765
5e6: 0c 81 ldd r16, Y+4 ; 0x04
766
5e8: 1b 81 ldd r17, Y+3 ; 0x03
767
5ea: aa 81 ldd r26, Y+2 ; 0x02
768
5ec: b9 81 ldd r27, Y+1 ; 0x01
769
5ee: ce 0f add r28, r30
770
5f0: d1 1d adc r29, r1
771
5f2: 0f b6 in r0, 0x3f ; 63
772
5f4: f8 94 cli
773
5f6: de bf out 0x3e, r29 ; 62
774
5f8: 0f be out 0x3f, r0 ; 63
775
5fa: cd bf out 0x3d, r28 ; 61
776
5fc: ed 01 movw r28, r26
777
5fe: 08 95 ret
778
600: f8 94 cli
779
602: ff cf rjmp .-2 ; 0x602
Vielleicht sollten wir das auch mal mit dem .elf file machen, da werden
zusätzlich noch die Namen der Funktionen mit drinstehen. Ruf doch zum
Spaß mal make disasm auf (in dem oben geposteten Makefile ist das drin)
...wimre hat der ATtiny2313 128 Bytes RAM. Da von diesen offenbar
mindestens 104 statisch belegt werden, bleiben noch ganze 24 Bytes RAM
über. Die tolle ISR braucht z.B. schon 20 Bytes Stack, d.h. es bleiben
maximal 4 Bytes Luft an freiem RAM!
Das führt zwar nicht zu Problemen mit dem Loader, aber der Autor ist
sich nicht ganz über die verwendete Hardware klar.
Johann L. schrieb:> Da kommen dann noch 104 Bytes an Flash-Daten (zum init von .data) hinzu.
Nein, nur 8. R26 startet bei 96 und endet bei 104. Im Hex-File sind
keine 104 zusätzlichen Bytes mehr, nur noch ne kleine Handvoll.
Was mich mehr irritiert ist die Diskrepanz zwischen der Behauptung das
Kompilat wäre nur 92 Bytes groß und dem geposteten Hex-File mit mehr als
1,5 KB.
Dieses Hex-File stammt definitiv nicht aus dem Compilerdurchlauf aus
Posting #6 der mit 92 Bytes endet.
Vielleicht bekommen wir ja auch noch mal das Disassemblat des
zugehörigen .elf zu Gesicht, da stehen wahrscheinlich ein paar
hilfreiche Labels drin so daß man sieht was was ist.
Alternativ könnte ja mal der große AVR-Assembler Guru des Forums hier
auftauchen und uns das bis ins Detail erläutern was der Code da
eigentlich tut (oder besser vielleicht lieber doch nicht).
Ich vermute es kommt von der float-Berechnung und allem was dadurch mit
reingezogen wird und mangels Optimierung und mangels gc-sections auch
nicht mehr rausgeworfen wird.
Weil ich die verschiedenen Hinweise und Ideen mit einigen Änderungen und
Erweiterungen aufzugreifen versucht hatte, habe ich jetzt nochmal das
zum Fehler führende C-Programm im AVR-Studio mit "build" verarbeitet und
etliche dabei erhaltene Dateien angehängt. Ich hoffe, dass z.B. aus dem
*.elf jemand einen Hinweis ableiten kann, warum mein Programm sich nicht
flashen lässt.
Dies ist die Version 5 (fehler-tiny2313-05.c) meines Programms.
Außerdem habe ich das von Studio 6 erzeugte Makefile gestartet, aber nur
die Meldung "Make: No rule to make target 'flash'" erhalten.
Schließlich habe ich noch ein eigenhändig erstelltes Makefile gestartet
und die Meldung erhalten: "avrdude: ERROR: address 0x0806 out of range
at line 129 of main.hex" avrdude: write to file 'main.hex' failed".
Dieses Makefile habe ich unter dem Namen "Makefile_Eigenbau" angehängt.
Beim Starten hieß es selbstverständlich "Makefile".
Hilft es, wenn ich eine Version 6 starte, die keinen Fehler beim
Flash-Versuch bringt, und zum Vergleich einige (welche?) Dateien poste?
Mit dem disassemblierten Code kann ich leider wenig anfangen, weil ich
nur winzige Assembler-Kenntnisse habe. Ich hatte gehofft, dass die
Disassemblierung einen C-Code hervorbringt.
Bernd-Dieter Bernt schrieb:> fehler-tiny2313-05.hex (189 Bytes)
Das ist nicht das Kompilat von vorgestern. Dieses ist winzig klein und
wird ohne Fehler auf den Tiny passen.
Ergebnis siehe Anhang.
Wie vermutet ist es die Verwendung von float. Die zusätzlichen 256 Bytes
im Datensegment in __clz_tab rühren ebenfalls daher und werden verwendet
bei der Umrechnung von int nach float (siehe auch google: __clz_tab zu
dem Thema).
Generell ist es eine gute Idee auf so kleinen 8-Bit Controllern von
jeglicher Verwendung von Fließkomma-Berechnungen abzusehen, es gibt
meist immer eine clevere Möglichkeit das mit Integer-Berechnungen
hinzubekommen und wenn Du es schaffst Dich auf Faktoren 2, 4, 8, etc...
bei Multiplikationen und Divisionen zu beschränken (aus welchen der
Compiler simple bit-shifts machen wird) wird es nochmal effizienter und
oftmals willst Du Dich sogar bei der Verwendung von Integern auch lieber
auf 8 bit beschränken wollen und nicht so oft gleich mit int um Dich
werfen.
Ein Blick ins .lss File oder in die Ausgabe von
1
avr-objdump -d -j .text -j .data -m avr5 main.elf
ist bei relativ kleinen Programmen für so kleine Controller noch meist
recht übersichtlich, man sieht mit etwas Übung schnell wo unnötig oder
unerwartet viel Platz verschwendet wird (und dementsprechend oft auch
Laufzeit bei engen Interrupt-Routinen auf ohnehin nicht besonders
schnellen Controllern)
Ein häufiger Blick in den Assembler-Output sollte zur Routine werden, so
lange bis Du ein Gefühl dafür bekommst was der Compiler da so
fabriziert.
Bei größeren Controllern und dementsprechend evtl später umfangreicheren
Programmen kann das jedoch schnell viel unübersichtlicher werden, da
kann einem angesichts von zig kB Flash auch mal was reinrutschen was man
nicht sofort sieht und anfangs vielleicht auch nicht weiter stört aber
evtl. dennoch vermieden werden sollte, also solltest Du ein Gefühl dafür
entwickeln wie das auszusehen hat solange Deine Programme noch klein und
übersichtlich sind. Das ist alles kein Hexenwerk, das kommt mit der
Zeit.
Hupps, ich sehe gerade: 3.4.2.
Dein Compiler ist von September 2004. Probier doch lieber mal was
aktuelles. Ich könnte mir vorstellen, dass damals float auf den tinys
eher suboptimal implementiert wurde.
Eine umständlich formulierte Endlosschleife: Wenn du zu einer positiven
Zahl 1 hinzuzählst — egal wie oft — wird das Ergebnis natürlich immer
positiv sein.
neuer PIC Freund schrieb im Beitrag #4071791:
> Hupps, ich sehe gerade: 3.4.2.
Das ist nicht die Version des Compilers; es ist die Version die Atmel
dran geklebt hat.
Bernd K. schrieb:> Wie vermutet ist es die Verwendung von float.
Diese Diagnose hat mich erstmal geschockt und frustriert, weil ich von
Programmierung in C auf dem PC Probleme dieser Art überhaupt nicht
kenne. Ich wollte eigentlich nur kleine Programme in meiner
Lieblingssprache C auf verschiedenen Mikroprozessoren laufen lassen. Nun
muss ich mich also mit Problemen wegen geringem Speicherplatz und
ausufernden gcc-internen Routinen rumschlagen. Aber es wird wohl nicht
zu vermeiden sein.
Ich habe jetzt dazu nur noch die Fragen: Warum tritt das überlange
hex-file nicht auf, wenn ich nicht die an funktion() übergebene Zahl (y
= funktion(unsigned int 123), sondern eine erst innerhalb der Funktion
zugewiesene Zahl (zahl = 123; in Zeile 1) in float umwandle?
Warum tritt das überlange hex-file nicht auf, wenn ich nach der
Umwandlung in float "zahl_dez = 12.3;" einfüge?
Und warum tritt das überlange hex-file auch nicht auf, wenn ich Zeile 16
weglasse?
Noch etwas anderes:
>Ich vermute es kommt von der float-Berechnung und allem was dadurch mit>reingezogen wird und mangels Optimierung und mangels gc-sections auch>nicht mehr rausgeworfen wird.
Ich dachte, die Optimierung mittels "-Os" im Makefile veranlasst zu
haben.
Wie sollte ich die Optimierung anfordern?
Meine Version 5:
Bernd-Dieter Bernt schrieb:> Bernd K. schrieb:>> Wie vermutet ist es die Verwendung von float.> Diese Diagnose hat mich erstmal geschockt und frustriert, weil ich von> Programmierung in C auf dem PC Probleme dieser Art überhaupt nicht> kenne.
"Bisher hatte ich auf meinem Flugzeugträger nie Platzprobleme. Ich bin
geschockt und frustriert, wie wenig Platz in meinem neuen Kajak ist!"
Aber selbst mit deiner Nußschale kann man float sinnvoll einsetzen. Ein
Beispiel, was geht ist z.B. im Wiki:
4000 Stellen von Pi mit ATtiny2313
Unabdingbar ist jedoch, daß du ein Verständnis dafür entwickelst, wie
limitiert die eingesetzte Hardware ist, insbesondere im Vergleich mit
einem PC — selbst mit einem 80286.
> Nun muss ich mich also mit Problemen wegen geringem Speicherplatz> und ausufernden gcc-internen Routinen rumschlagen.
Die float Routinen stehen in Assembler und sind von erfahrenen
Entwicklern geschrieben; in diesem Falle von Autoren der avr-libc. Wenn
der µC keine float-Hardware hat, dann muss man das alles eben
ausprogrammieren. Ein GCC kann auch keine FPU herbeizaubern...
> Und warum tritt das überlange hex-file auch nicht auf, wenn ich> Zeile 16 weglasse?
vermutlich irgendwelche Optimerungen. Constant folding, dead code
elimination, etc. Um eine genaue Antwort zu geben, könnte man die
GCC-Dumps lesen. Wenn es dir den Aufwand wert ist: Die Dumps bekommst
du mit -fdump-rtl-all-details -fdump-tree-all-details
> Ich dachte, die Optimierung mittels "-Os" im Makefile veranlasst> zu haben.
Optimierungen ändern nicht den Code in Bibliotheken.
> Meine Version 5:> int funktion(unsigned int zahl)
Diese Funktion wird nicht referenziert. Bei entsprechender Optimierung
wird der komplette Code entsorgt — egal was da alles geschrieben steht.
>
Bernd-Dieter Bernt schrieb:> Diese Diagnose hat mich erstmal geschockt und frustriert, weil ich von> Programmierung in C auf dem PC Probleme dieser Art überhaupt nicht> kenne. Ich wollte eigentlich nur kleine Programme in meiner> Lieblingssprache C auf verschiedenen Mikroprozessoren laufen lassen. Nun> muss ich mich also mit Problemen wegen geringem Speicherplatz und> ausufernden gcc-internen Routinen rumschlagen. Aber es wird wohl nicht> zu vermeiden sein.
wie wärs, wenn du einfach einen aktuellen Compiler benutzt?
Johann L. schrieb:> Bernd K. schrieb:>> Die zusätzlichen 256 Bytes im Datensegment in __clz_tab rühren>> Das Problem hatte ich bereits vor 4 Jahren behoben:>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524#c24
Das lässt doch hoffen, dass es dannach sehr viel besser aussieht.
Desweiteren:
ist diese Funktion wirklich nötig?
Vom groben draufschauen, würde ich sagen, da wird nur die Anzahl der
Stellen ermittelt. Also quasi der Logarithmus zur basis 10. da kann man
zum einen die standardbibliothek fragen (log(zahl)) oder zum anderen
komplett auf Floats verzichten, da dein input argument ja eh ein integer
ist.
Vlad Tepesch schrieb:> wie wärs, wenn du einfach einen aktuellen Compiler benutzt?
Ich benutze AVR Studio 6.1 und dessen Compiler. Ich denke, das ist
aktuell genug. Vergl. "neuer PIC Freund schrieb im Beitrag #4071791:
> Hupps, ich sehe gerade: 3.4.2.
Das ist nicht die Version des Compilers; es ist die Version die Atmel
dran geklebt hat.".
> Desweiteren:> ist diese Funktion wirklich nötig?> Vom groben draufschauen, würde ich sagen, da wird nur die Anzahl der> Stellen ermittelt. Also quasi der Logarithmus zur basis 10. da kann man> zum einen die standardbibliothek fragen (log(zahl)) oder zum anderen> komplett auf Floats verzichten, da dein input argument ja eh ein integer> ist.
Der Zehnerlogarithmus einer Integer-Zahl ist (bis auf log von
Zehnerpotenzen) eine Dezimalzahl, kein Integer. Mit dem
Zehnerlogarithmus würde ich also wieder eine Fließkommazahl benutzen.
Ich habe jetzt die Stellen-Anzahl mittels eines else-if-Konstrukts ohne
floats ermittelt: if(zahl==0)...else if(zahl>=1 && zahl<=9)... etc. Auf
diese Weise kann ich aber nur die Stellen-Anzahl von Zahlen bis 65.535
(mit uint16_t zahl) oder bis 4.294.967.295 (mit uint32_t zahl)
ermitteln. Mein ursprünglich angedachter Algorithmus war für im Prinzip
beliebig viele Stellen geeignet. Allerdings habe ich inzwischen bemerkt,
dass auch dieser Algorithmus auf einem Mikrocontroller den o.g.
Beschränkungen unterliegt und somit auch nur für max. zahl=4.294.967.295
die Stellen-Anzahl ermitteln kann.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Ich habe jetzt die Hinweise und Ratschläge von Bernd K. und Johann L.
befolgt und auf floats verzichtet (s.o.) und meinen Code möglichst kurz
gehalten. Dadurch ist mein main.hex nur noch 628 Bytes groß, obwohl das
C-Coding ca. 100 Zeilen lang ist, und ich kann jetzt mit der
eigentlichen Programm-Entwicklung fortfahren.
Darum schlage ich vor (wenn ich das darf), die Diskussion an dieser
Stelle zu beenden mit dem Ergebnis:
Man sollte float-Zahlen auf Mikrocontrollern möglichst vermeiden, stets
mit möglichst kleinen Integertypen arbeiten und die GCC-internen
Optimierungen in Anspruch nehmen.
Außerdem schlage ich vor, im AVR-GCC-Tutorial ein Kapitel "Tipps für
Anfänger" oder "häufige Fehlerquellen" hinzuzufügen, mit Ratschlägen der
o.g. Art.
Ich bedanke mich ganz herzlich bei Ingo, Peter M., m.n., neuer PIC
Freund, Linksammler, Karl Heinz, Bernd K., Johann L. und Vlad Tepech für
ihre Beiträge und ihre Geduld mit mir AVR-Anfänger.
Bernd-Dieter Bernt schrieb:> Man sollte float-Zahlen auf Mikrocontrollern möglichst vermeiden, stets> mit möglichst kleinen Integertypen arbeiten und die GCC-internen> Optimierungen in Anspruch nehmen.
ein wahres Wort, gerade an AVR habe ich bei AD Wandlungen lieber auf
INTs gesetzt und in der Umrechnung das Komma als Text eingefügt.
Bernd-Dieter Bernt schrieb:> Man sollte float-Zahlen auf Mikrocontrollern möglichst vermeiden,
Da muß ich widersprechen: das ist die falsche Folgerung aus mangelnder
Programmiererfahrung! Leider wird das immer wiederholt und durch die
Weiten des Netzes als Gerücht verbreitet :-(
Joachim B. schrieb:> ein wahres Wort, gerade an AVR habe ich bei AD Wandlungen lieber auf> INTs gesetzt und in der Umrechnung das Komma als Text eingefügt.
Schon vor 15 Jahren habe ich auf dem AT90S2313 'float' verwendet mit
besten Ergebnissen. 'Ints' hätten die Berechnungen nicht so kompakt
geschafft!
Bernd-Dieter Bernt schrieb:> Außerdem schlage ich vor, im AVR-GCC-Tutorial ein Kapitel "Tipps für> Anfänger" oder "häufige Fehlerquellen" hinzuzufügen, mit Ratschlägen der> o.g. Art.
Der einzige sinnvolle Rat lautet:
Nimm einen Tiny mit wenig Speicher nur dann, wenn es absolut unbedingt
erforderlich ist und wenn du genau weisst, was du da tust. Als Anfänger
bitte nicht.
Oliver
m.n. schrieb:> Da muß ich widersprechen: das ist die falsche Folgerung aus mangelnder> Programmiererfahrung! Leider wird das immer wiederholt und durch die> Weiten des Netzes als Gerücht verbreitet :-(
widersprechen ist leicht, dann erzähl doch mal wie man den Flash und Ram
Verbrauch mit Einbindung der float LIB trotzdem kleinhalten kann?
Ich lerne wirklich gerne dazu, auch ein Grund warum ich hier bin.
Bernd-Dieter Bernt schrieb:> Der Zehnerlogarithmus einer Integer-Zahl ist (bis auf log von> Zehnerpotenzen) eine Dezimalzahl, kein Integer.
Richtig.
Du verwendest aber nur den ganzzahligen Anteil davon
Deine Funktion lässt sich daher bei gleichem Endergebnis so schreiben.
1
uint8_tfunktion(uint16_tzahl)
2
{
3
uint8_tergebnis=1;
4
5
while(zahl>10){
6
ergebnis++;
7
zahl/=10;
8
}
9
10
returnergebnis;
11
}
> ermitteln. Mein ursprünglich angedachter Algorithmus war für im Prinzip> beliebig viele Stellen geeignet.
Mit Sicherheit nicht. Denn da gibt es noch so eine Kleinigkeit wie
'Datentypen', die dir einen Strich durch die Rechnung machen. In einen
uint16_t (vulgo unsigned int) passen nun mal keine größeren Zahlen als
solche, die 5 Stellen haben. Wenn das Argument an die Funktion ein
uint16_t ist, dann kann das Ergebnis daher nicht größer als 5 sein. Das
kannst du drehen und wenden wie du willst.
> oder bis 4.294.967.295 (mit uint32_t zahl) ermitteln.
Und?
Gleiches Schema. Solange dich nur der ganzzahlige Anteil interessiert,
schreibst du dir eine entsprechende Funktion für einen uint32_t die nach
dem gleichen Schema funktioniert. Kein Mensch braucht dazu float. Das
Ergebnis kann auch hier nicht größer als 10 sein, d.h. fuer 'ergebnis'
reicht auf jeden Fall ein uint8_t aus (was dem Tiny schon mal bei den
Inkrement hilft). An den Divisionen durch 10 ändert das nichts. wird
eben ein 32 Bit Wert durch 32 Bit - 10 dividiert.
Fazit:
Auch wenn die Theorie sagt, dass der 10-er Logarithmus genau das Ergbnis
enthält, das man haben will, sollte man doch mal darüber nachdenken, ob
man im konkreten Fall den 'vollen' Weg gehen muss, oder ob die
Aufgabenstellung es ermöglicht eine Abkürzung zu gehen.
Gegen Brain 2.0 ist auch der cleverste Compiler nur ein müder Abklatsch.
Berücksichtigt man noch, dass Multiplikationen für einen µC meist
weniger Aufwand sind als Divisionen, dann landet man ganz zwangsläufig
bei
1
uint8_tfunktion(uint16_tzahl)
2
{
3
uint8_tergebnis=0;
4
uint16_tmask=1;
5
6
while(mask<=zahl){
7
ergebnis++;
8
mask*=10;
9
}
10
11
returnergebnis;
12
}
und auch hier wieder: niemand braucht hier Floating Point.
Joachim B. schrieb:> widersprechen ist leicht, dann erzähl doch mal wie man den Flash und Ram> Verbrauch mit Einbindung der float LIB trotzdem kleinhalten kann?
Zahlen hatte ich weiter oben genannt:
Beitrag "Re: flash-Fehler mit ATtiny2313, compile ok"
Die Grundrechenarten in 'float' brauchen < 1K. Wenn man die von 'float'
gebotenen sechs Stellen nebst hoher Dynamik braucht, ist das eine sehr
kompakte Lösung. Rechnereien mit 'long' oder 'long long' brauchen
letztlich genausoviel Programmspeicher und sind zudem unübersichtlich.
Hier geht es um den ATtiny2313. Falls es knapp wird, gibt es auch den
4313 als Ersatz mit mehr Speicher. Selbst bei den tiny Tinys hat man die
Wahl von z.B. 25/45/85 mit acht Beinchen oder Tiny44/84 mit 14 Pins.
Dein ADC-Beispiel mit 10-Bit Auflösung schafft ein 'int' locker. Das ist
keine Aufgabe für 'float'. Aber sobald an anderer Stelle die libm
eingebunden wird, kann man auch im restlichen Programm 'float' rechnen
lassen.
Dennoch habe ich Beispiele für einen ATtiny25 mit ADC-Nutzung, wo ich
unverdrossen 'float' rechnen lasse, das Programm dadurch übersichtlich
bleibt und dennoch Platz in dem (kleinen) 2K Flash bleibt:
http://www.mino-elektronik.de/Generator/takte_impulse.htm#bsp5
und der nachfolgende U2F-Wandler.
Ob der ADC jetzt 10, 16 oder 24 Bit liefert, die Berechnung bleibt
transparent und genau.
Vorbeugend: das nächste Gerücht besagt, daß 'float' Berechnungen langsam
wären. Das trifft ebenfalls nicht zu und wurde hier an vielen Stellen
ausgiebig besprochen (beschimpft) ;-)
m.n. schrieb:> Dein ADC-Beispiel mit 10-Bit Auflösung schafft ein 'int' locker. Das ist> keine Aufgabe für 'float'.
danke das du mir da zustimmst! Dann habe ich ja nix falsch gemacht.
m.n. schrieb:> Aber sobald an anderer Stelle die libm> eingebunden wird,
habe ich aus genannten Gründen vermieden, warum auch? ich bekomme mit
INT und LONG hinreichende Genauigkeit, ob das nun mV oder dezi_mass ist
liegt ja nur in meiner Interpretation und Komma kann ich im Ausgabe
"String" einfügen.
Joachim B. schrieb:> habe ich aus genannten Gründen vermieden,
Ist ja völlig in Ordnung!
Vor langer, langer Zeit habe ich auch Alles mit 16 oder 32 Bit Werten
hin und zurückgerechnet: Meter-Inch, kG, N, lbs, psi, Bratkartoffelquark
hoch 3, usw. Irgendwann gab es brauchbare Float-Bibliothen (Keil 8051)
und ab dann wurde das Leben erheblich leichter.
Ob ein ADC jetzt 2,345 mV/Schritt, 3,79 µV/Schritt oder sonstetwas
ausgibt: die Skalierung ist ein Kinderspiel. Wenn ich heutzutage noch
sehe, daß manch einer Referenzspannung und Teiler am ADC so wählt, daß
es genau 5 mV/Schritt werden, muß ich lächeln. Unnötiger Aufwand an
völlig falscher Stelle.
m.n. schrieb:> Ob ein ADC jetzt 2,345 mV/Schritt, 3,79 µV/Schritt oder sonstetwas> ausgibt: die Skalierung ist ein Kinderspiel. Wenn ich heutzutage noch> sehe, daß manch einer Referenzspannung und Teiler am ADC so wählt, daß> es genau 5 mV/Schritt werden, muß ich lächeln. Unnötiger Aufwand an> völlig falscher Stelle.
floating point math ist aber Faktor 100 - 1000 langsamer.
Manch einen mag das für seine Anwendung stören.
Solange man die hohe Dynamik nicht benötigt, würde ich sie auf so
kleinen µCs auch nicht benutzen.
Auf nem größeren ARM, der VFP oder sogar vielleicht sogar NEON hat - who
cares.
ABer jeder der ernsthafte Berechnungen mit floats macht, sollte sich
vorher das mal zu gemüte führen:
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
Damit er weiß, was tatsächlich passiert, worauf er achten muss und wann
er lieber doch was anderes benutzen sollte. Vor allem wenn nur Single
Precision Floating Point verfügbar ist.
Thread beobachten
Seitenaufteilung abschalten