[Don_Ambrosio 0]

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

 

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

[galjoen 0]

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

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

[Don_Ambrosio 0]

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

 

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

 

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

[galjoen 0]

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

 

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

Я м.б. не понял сути проблеммы - вам нужно в HEX-файле данных менять адреса или нет?

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

[de__ 0]

как то такое я написал

http://kazus.ru/forum/topics/f_19425.html&...%CD%C8%C5#19425

[zltigo 3]

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

BIN2HEX Version 1.06
Copyright (c) 1993-1995 BITWARE.
All rights reserved.

Syntax: BIN2HEX [/option] binfile [hexfile]

<binfile> is the binary input file
<hexfile> is the Intel HEX file to create

<option>  may be any of the following

  /Ln     Bytes to read from binary file
  /In     Binary file starting offset
  /On     Output file address offset (where HEX data starts)
  /M      Merge data into existing HEX file
  /2      Generate HEX file using ext. segment address records (HEX86)
  /4      Generate HEX file using ext. linear address records (HEX386)
  /Q      Quiet mode (no statistics are displayed)
  /T      Exclude EOF record
  /A      Append to end of existing HEX file

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

 

Moderator:

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

[galjoen 0]

Ну а самый простой вариат воспользоватся допотопным и широко распространенным

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

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

[Don_Ambrosio 0]

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

 

"Доделал пару "софт под 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-ти байтного сегмента и вуаля. Ничего конвертить не надо . И смещения в добавленном блоке будут отсчитываться от начала заданного Вами сегмента, а не от начала памяти

[zltigo 3]

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

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

 

 

Т.е. просто перед блоком данных вставляем директиву..

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

[Don_Ambrosio 0]

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

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

 

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

[zltigo 3]

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

[Don_Ambrosio 0]

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

 

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

 

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

[galjoen 0]

написать какую одну строку между блоками HEX-а

С одной строкой не всегда получится. Для этого нужно чтобы:

1. программатор её понимал (если больше 64 кбайт программирует то есс-но понимает, а если меньше?)

2. программатор понимал и верно программировал HEX, не по увеличению адресов выстроенный, т.к. в конец HEX-а добавлятся середина будет. В противном случае 2 строки придётся добавлять (в начало и конец вставляемого блока) и в середину файла блок вставлять - место искать.

 

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

 

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

[Don_Ambrosio 0]

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

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

[galjoen 0]

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

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

.db 0xXX, ....; 16 байт
.db 0xXX, ....; 16 байт
...

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