@Serg -1980

Вопрос собственно в заголовке, по интересующей теме, не нашёл ни чего из кучи материала и сайтов.
А задача такая : как с помощью Дельфи 7 написать конвертер , который переконвертирует прошиву
из hex в bin . Желательно в потоке.
Если можно пример .

0

@D1973

0

@AzAtom

Это просто отображается по 16 байт для удобства, взглядом воспринимается хорошо и адреса удобно в уме прикинуть. А в самом BIN-файле все эти "строки" идут последовательно друг за другом и нет там никакого разделителя.

Добавлено через 21 минуту
Непонятен один момент. Адреса в HEX файле могут задаваться в произвольном порядке. Значит получается, сначала надо пройтись по всему HEX файлу и выяснить размер конечного BIN файла, приготовить соответствующий буфер и очистить его, и уже затем конвертировать. Так?

0

@Rius

AzAtom, да, об этом намекал ТСу.
Можно не буфер создавать, а сразу файл. В который потом по нужному смещению писать данные. А то на выделении 4 ГБ в ОЗУ можно сфейлиться.

1

@AzAtom

Тоже неплохая идея. Хотя, я как-то сомневаюсь, что в HEX будут хранить гигабайты прошивок. Хотя в этом могу ошибаться, конечно.

0

@Rius

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

0

Verevkin

На дураков не обижаются. Но ты же не дурак, правда? Тебе имя функции "LoadFromFile" ни о чём не намекает?

Добавлено через 1 минуту


Добавлено через 4 минуты
Правильно препод сказал. Было бы быстрее самим разобраться, что такое НЕХ-формат, и написать чёртов конвертер за полдня. У вас там группа лодырей и двоечников. Дай координаты препода, я ему лично выскажу свои респект и уважуху.

Добавлено через 6 минут
Это один из способов. Причём, буфер надо не "очистить", а залить байтом по умолчанию (для ATMEL это 0xFF, насколько мне известно). Второй способ - увеличивать размер буфера динамически по мере записи в него. Но использовать целесообразно именно первый способ по одной простой причине - размер EEPROM известен заранее.

Добавлено через 8 минут
Формат именно для этого и предназначен - для хранения ФРАГМЕНТОВ данных по заданным адресам. На практике я это применяю для заливки в общую микросему памяти микрокодов загружаемых программ, которые потом выполняются контроллером, стоящим на плате. Могу показать примеры, их есть у меня. Скриншоты выше - это виндовая программа управления одним из таких изделий.

Это моя основная работа на заводе - писать такие программы управления для разных интерфейсов. Загружаемые прошивки пишет мой падаван. Естественно, формат Intel-НЕХ я как "отче наш" знаю, это необходимо. Исходник, прицепленный выше, отлаженный и рабочий, но я вижу, что он никого не заинтересовал.

0

@AzAtom

Я это и имел в виду.

Это первое, что пришло мне в голову.

Хорошо, если так. А в общем случае это ведь не так?

Меня заинтересовал, я даже плюсанул. Но всё же, решил сам сообразить свой код.

0

Verevkin

В каком таком общем случае? У нас там нет общих случаев, все параметры указываются в ТЗ в обязательном порядке, исключающем разночтения. Всё по ГОСТу.
Однако вся система заточена не под EEPROM, а именно под оперативную энергоЗАВИСИМУЮ память, в которую код загружается динамически - с компа через интерфейс. Поэтому у меня нет нужды переводить НЕХ-файлы целиком в двоичный вид: я их просто загружаю в память, программа парсит структуру, выделяя на ходу адреса, данные, проверяет контрольные суммы, и, если всё ОК, выдаёт в интерфейс по заданному протоколу эти данные ПОСТРОЧНО прямо в контроллер, который записывает принятое по нужным адресам в общей микросхеме ОЗУ и передаёт управление второму контроллеру, который и выполняет загруженную в ОЗУ программу.

Оптимизация (у меня там в исходнике) сделана для уменьшения количества строк (количества передаваемых пакетов), для ускорения процесса, т.к. интерфейсы у нас медленные (rs232 и производные от него). Но это, скорее, я от любви к искусству сделал, требований таких изначально не было.

Имеешь полное право.

0

@AzAtom

Это у вас там. А вот здесь у ТС получился бинарник 688 байт. А другие проверочные файлы, которыми будут гонять утилиту, неизвестно сколько будет.
А если в HEX будет 2 фрагмента адресов, то что делать? Генерировать один файл с обоими фрагментами и "пустым" местом между ними? А если там между ними гигабайт?

0

Verevkin

Даже если гигабайт - всё зависит от постановки задачи: что именно надо получить на выходе. Если надо получить сплошной бинарник (имхо, ТСу именно это нужно), то нужно при парсинге НЕХ-файла вычислить конечный адрес (смещение, по которому будет расположен последний байт данных). Остальное - тривиально: выделяем место, заливаем его байтом по умолчанию (0x00 или 0xFF), затем точечно пишем с нужных смещений нужные данные, которые берём из НЕХ-строк. Максимальный размер бинарника = 4 Гб, что в сегодняшник реалиях можно выделять прям в оперативке, а не на носителе, и сохранять в файл после формирования.

Если не устраивает такой вариант, предложи свой.

1

@AzAtom

Verevkin, примерно так я и подумал. Для не очень больших прошивок это будет самое оптимальное, думаю.

0

Verevkin

Для прошивок это ваще не нужно. EEPROM перед прошивкой стирается (заполняется байтом по умолчанию) АППАРАТНО. Затем его можно перезписать либо сплошняком - бинарником от адреса 0 до (размер файла - 1), либо точечно - данными из HEX (этот формат предназначен, в том числе, и для этого).

Со стороны это выглядит сложно, но стоит этим заняться, как сразу понимаешь, что это гениально и просто.

0

@Serg -1980

Как это верно Вы подметили, добавил бы ещё главное : Не просто этим заняться, а под руководством опытного и действительно профессионала кодера, то даже сложная задача решается на ура !.
Жаль что на этом ресурсе таких профессионалов не оказалось, болтовни на 4 странице, одни теоретики и просто зашедшие поболтать..... как Rius ... за несколько дней не смогли решить не трудную задачу и это профессионалы ? сомнительно..
Время столько потеряно было и всё в пустую, демагогия одна...

В общем все зачёты сданы и сданы на отлично и старые и новые и не благодаря демагогам теоретикам, а благодаря настоящему профи, который смог и объяснить и показать и на учить, так, что все усвоили....
Жалко что не на всех ресурсах находишь таких... Здесь я точно не решил своих задач.
Господа админы позвольте совет : Пусть в разделах для начинающих помощь оказывают действительно профессионалы, а не теоретики и демагоги, которые за не делю не смогли решить не очень сложную задачу.
Людям иногда помощь нужна и профессиональное объяснение и примеры конечно.
А не демагогия отдельных участников.
На этом раскланиваюсь ещё раз благодарю за участие ( не плодотворное к сожалению ) всех кто участвовал !
Тему закрываю , так как задача решена полностью и не только одна, времени больше нет, на участие в теме на данном ресурсе, так как новые задачи и новые уроки требуют много времени и сил.

На этом прощаюсь и ещё раз спасибо за участие ! Тему закрываю .

p/s
Нет плохих учеников, есть плохие учителя ...

Миниатюры

 

0

Verevkin

Единственное, что мне не нравится в НЕХ-формате - это ненадёжная контрольная сумма. Поэтому у нас Я так понимаю, это всё вместо "спасибо"?

0

@Rius

Это как?

0

Verevkin

Она тупо рассчитывается как 0x100 - (сумма байт строки & 0xFF). Даже перестановка байтов внутри строки не влияет на сумму. О какой надёжности может тут ваще идти речь?

1

@Rius

Ну, чисто перестановка случайно - маловероятно.
А от намереной и CRC32 не поможет.

0

Verevkin

Тут согласен.

Добавлено через 5 минут
Ну мало ли, при передаче через кривой самодельный интерфейс наводками от рядом стоящего оборудования сигнал исказится так, что изменятся несколько байт, а их сумма - не изменится. В жизни всякое бывает. Но я работаю на таком производстве, где такие маловероятные факапы НЕДОПУСТИМЫ. Поэтому мы всегда в конце приёмо-передачи считаем общую CRC32 и MD5 (именно "и", а не "или").

Вот такие пироги. Так и пишем в ПД - вероятность некорректной передачи пакета = 0%.

0

@northener

Абсолютно неверное утверждение, кода речь идет о подобных форумах. На них слишком много плохих учеников. Плохих тем, что хотят не учиться, а сдать зачет/курсовую и т.д. и т.п. И плохих учителей тоже хватает, которые готовы дать готовое или почти готовое решение задачи.
Собственно говоря вы это и подтвердили тем, что выложили картинку "своей" программы, а не её код.

Может в таком "производстве" в первую очередь надо избавляться от "кривых самодельных" интерфейсов и от наводок? В конце концов ОРД может и спасёт подсчет и CRC32 и MD5. Но что делать если оба варианта постоянно дают неверный результат?

0

Verevkin

Не знаю. Такого за 20 лет моего стажа не случалось. Наверное,

0