Gast
#2261393
Hallo Zusammen, ist das Controllerabhängig, zB Atmega2560 im vgl. zum Atmega128? Besten Dank Karl
Gast
#2261445
Falsch vermulierte Frage und darum keine Hilfe? Also nochmal, ich kompiliere mit AVR-Studio und mir fehlen Informationen, ob ein Hexfile vom atmega128 identisch aufgebaut ist wie einer vom atmega2560. Ich habe gelesen, dass es eine 64kbyte Grenze für den Adressraum gibt? Wie kann man diese Grenze für den atmega2560 umgehen, der ja ein flasch größer 64kbyte hat? Vielen dank im voraus... Karl
Gast
#2261449
Karl schrieb: > Also nochmal, ich kompiliere mit AVR-Studio und mir fehlen > Informationen, ob ein Hexfile vom atmega128 identisch aufgebaut ist warum must du es dafür wissen? Das Studio erzeugt doch die Datei. Mir war es bis jetzt ziemlihc egal wie die Datei aufgebaut ist, denn ich hatte mit der Datei überhaupt nichts zu tun.
Das ist nicht kontrollerabhängig sondern softwareabhängig. Das hexfile(ASCII-Folge zusammen mit Prüfsumme u.A.) wird gelesen und von der Software aufgedröselt in die Signale: Speicheradresse, 8-bit-data ... eventuell als lobyte und hibyte von 16- oder 32-bit-words. Dazu werden die entsprechenden Steuersignale fürs Programmieren erzeugt, je nachdem, ob das target ein Kontroller, ein Eprom oder Anderes ist. Welche Variante von hex-file akzeptiert wird, ist alleinige Sache der Software. Die muss sowohl auf das target passen (ob Kontroller, EPROM, EEPROM, Programmieralgorithmus ) als auch auf die angebotenen .hex-files.
Karl schrieb: > Also nochmal, ich kompiliere mit AVR-Studio und mir fehlen > Informationen, ob ein Hexfile vom atmega128 identisch aufgebaut ist wie > einer vom atmega2560. Ja. Karl schrieb: > Ich habe gelesen, dass es eine 64kbyte Grenze für > den Adressraum gibt? Nein. Siehe in den Intel-HEX Spezifikationen den Type 4 Record.
Für intel-.hex-files gibt es eine allgemeine Norm, leichte Unterschiede könnten darin bestehen, dass die Compiler/Assembler-Software, die das .hex- file erzeugt, längere oder kürzere Zeilen zulässt.
Gast
#2261456
Nein, Du kannst nicht ein Hex-File, das für den ATMega128 kompiliert ist, in den ATMega2560 programmieren oder umgekehrt. An dem Format des HEX-Files liegt das nicht , sondern daran, das die Registerdefinitionen nicht identisch sind (unter Vorbehalt).
Gast
#2261473
Also vielleicht hätte ich noch erwähnen müssen, dass ich einen Bootloader programmieren will, der mit den HEX Files von AVRStudio gefüttert wird. Also nur für den AVR Compiler erstmal... Gibt es da keine Unterschiede bei der Adressierung? Wundert mich eigentlich, da ich da was von einer 64kbyte grenze gelesen hab? DAnke nochmal
Karl schrieb: > Also vielleicht hätte ich noch erwähnen müssen, dass ich einen > Bootloader programmieren will, der mit den HEX Files von AVRStudio > gefüttert wird. Also nur für den AVR Compiler erstmal... Gibt es da > keine Unterschiede bei der Adressierung? Wundert mich eigentlich, da ich > da was von einer 64kbyte grenze gelesen hab? Also nochmal: schau in die Spezifikationen für das Intel-HEX-Format. Wie kannst du ein Programm schreiben, das dieses Format interpretieren soll, ohne dort reinzuschauen? Und bezüglich deiner "64k-Grenze" schaust du dir speziell den Typ 4 Record an.
Karl schrieb: > Also vielleicht hätte ich noch erwähnen müssen, dass ich einen > Bootloader programmieren will, der mit den HEX Files von AVRStudio > gefüttert wird. Also nur für den AVR Compiler erstmal... Gibt es da > keine Unterschiede bei der Adressierung? Wundert mich eigentlich, da ich > da was von einer 64kbyte grenze gelesen hab? > DAnke nochmal gugst du: http://de.wikipedia.org/wiki/Intel_HEX
Stefan Ernst schrieb: > Und bezüglich deiner "64k-Grenze" schaust du > dir speziell den Typ 4 Record an. Nein, den guckst du dir nicht an, sondern Typ2: Extended Segment Address Record siehe: http://de.wikipedia.org/wiki/Intel_HEX Karl schrieb: > Ich habe gelesen, dass es eine 64kbyte Grenze für den Adressraum gibt? Das hast du richtig gelesen. unter 64k wird "normal" mit 16 Bit adressiert. Über 64K muss noch die Segmentadresse gesetzt werden. Das macht der "Extended Segment Address Record" So sieht ein "normales" Hexfile aus: :10FC00000C943E7E0C94507E0C94507E0C94507E4E :10FC10000C94507E0C94507E0C94507E0C94507E2C :10FC20000C94507E0C94507E0C94507E0C94507E1C Hier werden Daten ab "FC00" geschrieben. Bei "Extended..." wird vor so einen Block die Segmentadresse gestellt: :020000023000CC :10F800000D9472FC0D9493FC0D9493FC0D9493FC59 :10F810000D9493FC0D9493FC0D9493FC0D9493FC28 :10F820000D9493FC0D9493FC0D9493FC0D9493FC18 :020000 02 3000 CC Das zweite "02" ist die Kennung "Extended.." "3000" ist die Segmentadresse. Die Daten gehören demzufolge nach 0x3F800. "F800" steht in der zweiten Zeile: (Segmentadresse << 4) + Offset Stammt alles vom 8086-Prozessor. Bei 1 MByte ist bei dem allerdings schon wieder Schluß. Die alten "DOSser" kennen das noch. Darüber hinaus gibt es dann die anderen Modi zu Adressierung. Ist aber beim AVR (noch) kein Thema. mfg.
Hi.. ich weiss das Thema ist schon alt hier. aber ich halte trotzdem das Thema noch Offen . habe eine Frage ! mit allen Typen der Intel-Hex Protokolle habe ich verstanden. Bloß der Type 04. kann mir jemand hilfen es zu verstehen. Es handelt sich um ein ARM-32 Bit. also die Adressierung sollte im Prinzip 32 bit sein. bei jeder Hex File sieht am Anfang so aus ! :020000040000FA :10000000000200106D01000071010000730100008A :100010007501000077010000790100000000000078 :100020000000000000000000000000007B01000054 danach habe ich in die Konfig vom (µVision Keil) die startadresse wo das Programme geschrieben wird geändert vom 0x000 auf 0x1000. dann sieht das Hex File so aus : :020000040000FA :0402FC00FFFFFFFF02 :020000040000FA :1010000068020010691100006D1100006F110000EE :101010007111000073110000751100000000000044 :101020000000000000000000000000007711000038 danke euch im Vorraus
mourad e. schrieb: > Hi.. ich weiss das Thema ist schon alt hier. > aber ich halte trotzdem das Thema noch Offen . > > habe eine Frage ! Was genau ist die Frage? > danach habe ich in die Konfig vom (µVision Keil) die startadresse wo > das Programme geschrieben wird geändert vom 0x000 auf 0x1000. mit dieser Änderung wird mehr verknüpft sein, als nur das Ändern der Startadresse. Zb ändern sich alle Sprungadressen, Daten werden an andere Stellen im Speicher verschoben, wodurch dann auch Ladebefehle andere Adressen verwenden usw. usw. > :020000040000FA > :0402FC00FFFFFFFF02 > :020000040000FA > :1010000068020010691100006D1100006F110000EE Offenbar hat sich dieses Hex-File daher in der Lage verschoben. Dieser Datensatz wird im Speicher ab Adresse 0x00001000 abgelegt. Genauso, wie du es angefordert hast.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.