А учитываются только 4 младших, в хексе больше и не отведено под адрес, все что перед DEAD(взято просто для наглядности) игнорируется. Поэкспериментировал - результат тот же.
DEAD:
:10DEAD00DDF2EE20E4EEEBE6EDEE20E6E8F2FC200E
:10DEBD00EFEE20E0E4F0E5F1F32030784445414405
:01DECD000054
10DEAD:
:10DEAD00DDF2EE20E4EEEBE6EDEE20E6E8F2FC200E
:10DEBD00EFEE20E0E4F0E5F1F32030784445414405
:01DECD000054
Полная версия этой страницы: Мой первый блин)
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > MCS51, AVR, PIC, STM8, 8bit
Цитата(novlev @ Dec 14 2009, 08:13) 
А учитываются только 4 младших, в хексе больше и не отведено под адрес
Вообще-то в Intel-HEX под адрес отведено 32 бита. 16 бит отведено под смещение.Цитата(novlev @ Dec 14 2009, 08:13)
, все что перед DEAD(взято просто для наглядности) игнорируется.
Вами - возможно и игнорируется. Но любая программа, корректно читающая IntelHEX не должна игнорировать записи типа "Extended segment address" и "Extended linear address". Именно в эти записи и попадают старшие биты.
Я просто пользовался описанием из pdf на контроллер ADuC, видимо там просто упрощенно была описана структура. Просто обозначена последовательность и под адрес загрузки было выделено 2 байта. Хм.. вот в файле map указано верно - Address of section .myInfo set to 0x10dead
(я и указывал 0х10dead), и далее
.myInfo 0x0010dead 0x21
.myInfo 0x0010dead 0x21 gcc_tst.o
0x0010dead bar
Так а почему в самом хексе всегда одинаково? Просто мне важен сам факт наличия информации по конкретному адресу ,просто для технических целей. Мой прошивальщик может ее и не записывать, но хочется по человечески уже сделать все.
(я и указывал 0х10dead), и далее
.myInfo 0x0010dead 0x21
.myInfo 0x0010dead 0x21 gcc_tst.o
0x0010dead bar
Так а почему в самом хексе всегда одинаково? Просто мне важен сам факт наличия информации по конкретному адресу ,просто для технических целей. Мой прошивальщик может ее и не записывать, но хочется по человечески уже сделать все.
Цитата(novlev @ Dec 14 2009, 13:49)
Так а почему в самом хексе всегда одинаково?
А в нем точно нет строчек, начинающихся с :02000004 или :02000002?Тогда показывайте команду, которой avr-objcopy делает из вашего .elf этот .hex
Цитата(Сергей Борщ @ Dec 14 2009, 16:08)
А в нем точно нет строчек, начинающихся с :02000004 или :02000002?
есть строчки, протупил я серьезно...
:0A070E00101234567890000000002D
:020000040010EA
:10DEAD00DDF2EE20E4EEEBE6EDEE20E6E8F2FC200E
:10DEBD00EFEE20E0E4F0E5F1F32030784445414405
:01DECD000054
:00000001FF
Нашел норм документацию на интел хекс формат, спасибо что надоумили)
Цитата(novlev @ Dec 14 2009, 15:46)
А можете поделиться полной спецификацией формата интел хекс, чтоб впредь я так не лажал...
google.com -> Intel hex format
Столкнулся со следующей особенностью программы PONYPROG2000, она не понимает формат хекса типа
:02000004AAAAA6 - тут максимум то 1 для 64К
:10DEAD00DDF2EE20E4EEEBE6EDEE20E6E8F2FC200E
:10DEBD00EFEE20E0E4F0E5F1F3203078414141410F
:05DECD00444541440042
Программа действительно не понимает записи расширенного линейного адреса, или это я чот не то сделал? Она рассчитана только на запись адреса сегмента?
Решено.
То я туплю)))жестко... сложно на разных языках для разных платформ одновременно ваять))))
:02000004AAAAA6 - тут максимум то 1 для 64К
:10DEAD00DDF2EE20E4EEEBE6EDEE20E6E8F2FC200E
:10DEBD00EFEE20E0E4F0E5F1F3203078414141410F
:05DECD00444541440042
Программа действительно не понимает записи расширенного линейного адреса, или это я чот не то сделал? Она рассчитана только на запись адреса сегмента?
Решено.
То я туплю)))жестко... сложно на разных языках для разных платформ одновременно ваять))))
Хоть бы написали как это проявляется
Проявлялось забавно - 
Это если вбить -Wl,--section-start=.myInfo=0xAF700. Код должен начинаться с 0хЕ000, т к -Wl,-section-start=.text=0xE000 (бутлоадер).
Это если вбить -Wl,--section-start=.myInfo=0xAF700. Код должен начинаться с 0хЕ000, т к -Wl,-section-start=.text=0xE000 (бутлоадер).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.