Hallo *, weiss einer warum der avrdude Intel HEX Files > 64k richtig lesen kann, obwohl in der funktion ihex2b die Adressen als unsigned int und damit doch 16 bittig deklariert sind? AVRDUDE5.5 ... static int ihex2b(char * infile, FILE * inf, unsigned char * outbuf, int bufsize) { char buffer [ MAX_LINE_LEN ]; unsigned char * buf; unsigned int nextaddr, baseaddr, maxaddr; int i; int lineno; int len; struct ihexrec ihex; int rc; ...
Weil es nicht auf einer 8-/16-Bit-Maschine läuft, sondern auf einer 32-Bit-Maschine (oder gar 64-Bit-Maschine).
Das heisst: wenn ich unsigned int schreibe wird mit long oder unsigned long oder noch etwas anderem gerechnet ?
Ludger wrote: > Das heisst: > > wenn ich unsigned int schreibe wird mit long oder unsigned long oder > noch etwas anderem gerechnet ? Per definition ist in C ein int mindestens 16 bit lang, aber auf i386 und anderen 32 bit Prozessoren ist ein int üblicherweise 32 bit lang. Die genauen Limits sind in der Headerdatei <limits.h> für die jeweilige Umgebung zu finden. brgds Thomas
Ludger wrote: > weiss einer warum der avrdude Intel HEX Files > 64k richtig lesen kann, > obwohl in der funktion ihex2b die Adressen als unsigned int und damit > doch 16 bittig deklariert sind? Das liegt am Aufbau des Hex-Files, jeder Record enthält nur eine 16Bit-Adresse. Das Hex-File enthält also die Daten in 64k-Blöcken. Und diesen Blöcken wird ein Segment-Record vorangestellt der den Offset des Blocks enthält. Peter
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.