Нужно добавить в прошивку программы, сгенерированную AVR Studio, некий внешний блок данных (имеется в виде HEX-файла), который нужно разместить во FLASH по заданному адресу.

Т.е. нужно объединить два HEX-файла так, чтобы данные второго файла размещались в объединённом файле по некоторому заданному адресу

А почему нельзя просто копированием через буфер обмена объединить? Я всегда так делаю. Или вам надо адреса во втором HEX-файле поменять, а сгенерить HEX с заданными адресами тяжело? Или в чём проблемма?

Есть уже сгенерированный HEX-данных, в котором прописаны адреса, а мне нужно этот HEX объединить с прошивкой программы, чтобы эти данные были размещены по заданному адресу FLASH.

Т.е. нужно переместить этот HEX-данные в адресном пространстве о объединить с прошивкой

Я м.б. не понял сути проблеммы - вам нужно в HEX-файле данных менять адреса или нет?
Если эти HEX-данные имеют в своём HEX-файле не те адреса, которые вам нужны, и вы не можете изменить адреса при генерации HEX-файла (например этот HEX-файл сгенерирован не вами) и хотите изменить эти адреса перед объединением файлов - то в этом случае рекомендую написать простенькую програмку (хоть на бейсике, хоть на пёрле или C - что вам больше нравится), а может такая уже и готовая есть. Но, наверное, написать будет быстрее, чем найти. Я несколько раз такие писал, т.к. предыдущие терял.

как то такое я написал
http://kazus.ru/forum/topics/f_19425.html&...%CD%C8%C5#19425

http://srecord.sourceforge.net/ обычно позволяет справиться с любыми проблемами. Ну а самый простой вариат воспользоватся допотопным и широко распространенным

И преобразовав предварительно в бинарники переклеить, как душе угодно.

Moderator:
Тему перенес, поскольку к AVR она не имеет отношения.

Я пробовал такой способ, но если исходный HEX-файл с "дырками", то, полученный таким методом, - подряд. Хотя "дырки" можно любыми байтами заполнять. Или это у меня руки кривые - не разобрался? Но в любом случае - написать програмку проще и быстрее, чем разбираться.

Проблему решил без всяких утилит благодаря Антону

"Доделал пару "софт под Win32"-"софт под ATMega128" до того, что уже пишет во FLASH в количестве "скока хочешь" слов (по два байта) по адресу "куда следует". И ни разу не ошибается!

И вот, когда уже вроде бы "всё пучком", ещё раз нарываюсь на грабли: в формате iHex НЕТУ никакой возможности адресовывать свыше 64 килобайт!!!

Я даже три книги купил, но там всё честно про формат написано - уже по-русски, чтобы быть уверенным. На адресацию отводится ровно 4 символа в формате HEX.

Анализ файла от ImageCraft выявил наличие в на границе перехода через 64k некоторой неоднородности в файле iHex:
______cut here ___________
:14FFA0009924AA24BB2441D0C1F044D0B1F0E8E2000F111F63
:14FFB400221F331F771C881C991CAA1CBB1C88169906AA0630
:14FFC800BB0628F0881A990AAA0ABB0A0395EA9559F726F40D
:14FFDC00082D192D2A2D3B2D13C07A928A929A92AA92BA9228
:10FFF000CA92EA938A939A93AA93BA938B859C8523
:020000021000EC
:14000000AD85BE85C32E0EF0CB260895C7FC17D0B991A991CC
:1400140099918991E991C990B990A99099908990799024963A
:140028000895E02FE12BE22BE32B0895E82FE92BEA2BEB2BFE
:14003C00089500951095209530950F5F1F4F2F4F3F4F0895DA
:1400500080959095A095B0958F5F9F4FAF4FBF4F0895689467
:1400640001C0E8942A93FA92EA92FF24EE2420E1000FFF1C26
______cut here ___________

Вот такая вот беда...

Видимо он куски памяти подсчитывает и закончив одину 64-килобайтную секцию начинает писать в другую.

Мне это не очень нравится, потому что может стать источником ошибки: а вдруг мне сразу во вторую часть писать нужно?

И вот ведь в чём прикол: я уже и программатор отстроил на максимальную гибкость, а тут...

В общем, я весь в расстройстве. Помогите, кто знает!

Спасибо.

……
Учитывая немаленькое число просмотров, дам ответ...
Ответ крылся в том самом неясном куске.

Если тип строки 00 - это данные. Если 01 - конец файла.
А если 02 - это команда изменения сегмента.

Сегменты дробятся с кратностью 16 байт. За командой идёт адрес сегмента - два байта, старший сначала(!).

При открытии файла, если сегмент не изменялся, пишем в нулевой сегмент. Поэтому в коротких программах эта строка "тип 02" вообще не встречается.

В начале каждой строки данных следует относительный адрес записи - адрес, куда эти данные писать.

Абсолютный адрес записи - нужно учесть текущий сегмент. Достаточно его умножить на 16 и прибавить к относительному адресу.

Всё!

Я записал 70% проца ATMega128 из iHex, считал и всё совпало. Да и прога - тоже работала как часы.

Всем спасибо. С форматом iH вопрос ясен.

Антон."(С)

Т.е. просто перед блоком данных вставляем директиву задания номера 16-ти байтного сегмента и вуаля. Ничего конвертить не надо . И смещения в добавленном блоке будут отсчитываться от начала заданного Вами сегмента, а не от начала памяти

Навеное придется книги выбросить и просто в интернете взять стандарт в том числе описывающий и РАСШИРЕНИЯ первоначального варианта для сегментной и линейной адресации, и добавления стартовых адресов.



Надо было внятно сказать, что согласны руками каждый раз файл редактировать.

Дык "руками" и быстрей и надёжней получиться: написать какую одну строку между блоками HEX-а это ИМХО более быстро и наглядно, чем юзать "вслепую" утилиты командной строки имеющие список из 30 и более параметров командной строки. Почему "вслепую"? Да потому что эти утилиты даже ГУИ человеческого не имеют. А не дай бог ошибёсся в циферке и они тебя наконвертят - век потом глюки будешь выискивать.

А тут всё на виду. И блоки и адреса начальных сегментов этих блоков - ошибиться почти не возможно

Эко Вас носит между ГУЯ-ми и руками в редакторе Вы уж определитесь, чем командная строка сложнее редактирования

А зачем мне методично и скрупулёзно вычислять 30 с хреном параметров командной строки (при слиянии в один например 10-ти HEX-файлов) когда я могу тупо скопипастить их в один файл и тупо указать адрес для каждого блока откуда его размещать..

Короче тема исчерпана. Можно её закрыть. Пусть каждый остаётся при своём мнении насчёт того, что удобней

С одной строкой не всегда получится. Для этого нужно чтобы:
1. программатор её понимал (если больше 64 кбайт программирует то есс-но понимает, а если меньше?)
2. программатор понимал и верно программировал HEX, не по увеличению адресов выстроенный, т.к. в конец HEX-а добавлятся середина будет. В противном случае 2 строки придётся добавлять (в начало и конец вставляемого блока) и в середину файла блок вставлять - место искать.

Но если программатор такой продвинутый, то он обычно и запись нескольких HEX файлов поддерживает в т.ч. со смещением адреса. И пустые блоки в FLASH не пишет.

А вообще, если эту программу вы сами пишите, то всё эти проблеммы решаются директивой include.

Это как это? Насколько мне известно с помощью упомянутой Вами директивы можно только .inc-файлы с текстом исходников вставлять, но никак не HEX-файлы с данными

Так я это и имел ввиду. Откуда у вас HEX файл с данными взялся если вы сами всё пишите? Но даже если он и есть, то в исходный текст вида

элементарно преобразуется, например, макрокомандой в текстовом редакторе. Если в нём дырок нет конечно. А т.к. это данные, то наличие дырок крайне маловероятно и труднообъяснимо.