спасибо, теперь более или менее ясно.

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


я так понял, служебка в первой строке, а в последней признак конца?

Сообщение отредактировал zheka - Feb 9 2012, 04:00

Честно говоря, не знаю, чего там этот человек понаписал. Документ, описывающий формат intel hex на рассудит.
Вы знаете, хоть я и недавно писал бут по ARM (а там анализ hex тоже был), я просуммировал в калькуляторе приведенные Вами строки. Сумма всех байт равна нулю. Попробуйте сами. Это дело 1 минуты.


Это частный случай. Для AVR может быть всегда так. Вот здесь ничего не скажу. Я просматриваю кадждую строку. Проверяю, что я буду писать в память. Не исключаю, что сделал не совсем правильно. Но работает.
Есть 6 типов записей (или строк) в hex файле. Один из них это данные, один - конец строки. Про остальные лучше почитать. Там с сегментами памяти связано. И похоже, введено для поддержки прошивок объемом более 65 кБ.
На этот вопрос, сам бы хотел услышать мнение уважаемого сообщества...

Я тоже проверял, вы меня просто не поняли. Код бутлодера, который я выложио принимает ТОЛЬКО байты данных, суммирует их и сравнивает с контрольной суммой, приходящей вслед. То есть, по мнению автора бута, контрольная сумма - это просто сумма байтов, а не дополнение до нуля.
Впрочем, пишу для себя, софт пишу свой, так что сделаю как мне удобнее. А на мой взгляд все-же удобнее дополнять до нуля, так как в этом случае, можно просуммировать все байты со всеми контрольными суммами в каждой строке и подтвердить истинность всей страницы.

Покурил документ от Интел.
Не раскуривается следующий момент:


Я так понял, смещение - это когда требуется записать фрагмент не в начале памяти, а где-нить в середине. А смещение должно означать начальный адрес программы. И все последующие строки имеют адрес, тот что в них записан, просуммированный со смещением.
Тогда почему 0x1234 даст реальный адрес 0x12340 ? Я так подумал, что програма начинается с этого адреа, а следующая строка при 16-ти байтах даст 0x1244...

Грубо говоря, если у меня смещение 0x1234, а адрес в одной строке 0x00, а в другой 0xFF, какое действие мне нужно произвести, чтобы сообщить истинный адрес бутлоадеру?

"Тогда почему 0x1234 даст реальный адрес 0x12340"
потому что следующие 16 байт информации будут располагаться начиная с адреса 0х12340 по 0х1234F

ниче не понимаю.
На hex калькуляторе посчитал - 0x1234 +0x01 = 0x1235...



Так ведь для того, чтобы из 0x1234 получить 0x12340 нужно не прибавить 16, а умножить на 16....



Не, я не спорю, я хочу найти ошибку, как говорится, в своей ДНК.

Объясните если у меня смещение 0x1234, а адрес в одной строке 0x00, а в другой 0xFF, какое действие мне нужно произвести, чтобы сообщить истинный адрес этих строк бутлоадеру? Может я тогда пойму.

Сообщение отредактировал zheka - Feb 9 2012, 11:22

Адрес байта будет равен LBA + LINE OFFSET + номер позиции байта в строке.
LBA = ULBA << 16.
Про эти величины читайте в даташите Я этим занимался в начале года. Уже все подзабыл. Помню поверхностно.
В приложении на скорую руку писанный парсер hex-файлов. Для IBM PC. Там исходник и исполняемый файл. Скомпилировано GCC.
Запускаете HexParser.exe, он запрашивает имя файла. Вводите, например c:\temp\1.hex. Он выводит информацию по каждой строке в консоль. Делал для себя. За чистоту и честность не ручаюсь) Очень надеюсь, что он Вам чуть чуть поможет )))
Рекомендую Вам отладить этот алгоритм тоже на компьютере. Он не зависит от железа. Можно даже через виртуальные ком-порты отлаживать два приложения: клиент и сам бут. Затем в релизе допилить аппаратную часть...

З.Ы. Парсер под ARM... Поэтому записываемые данные после адреса - 32 бита... Но сути это не меняет...

Ни хрена не понимаю....
ВОт у меня адресное пространство, я хочу зарезервировать первые 256 байт.
Значит смещение у меня будет 0xFF.

Исходя из предложенной арифметикик при смещении 0xFF реальный адрес будет 0xFF0, то есть в десятичном исчислении 4080, и я прокину первые 4 килобайта?


Мне это непонятно. Может кто-нибудь на пальцах объяснить?

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

На Вашем скрине смещением (offset) обозвано то, что я привык считать адресом.... я еще больше запутался..

Так в AVRовской прошивке ULBA, как правило, будет равно нулю...

Для прошивки размером менее 65 кБ, смещение и будет адресом... В общем в документации на формат файла, есть формула для вычисления адреса (см. скрин)

Посмотрите "Косвенная адресация операнда" может прояснит

Файл формата Intel HEX может состоять из любого количества записей. Каждая запись представляет собой ASCII-строку, состоящую из нескольких пар 16-ричных цифр. Строка должна начинаться с символа двоеточия и оканчиваться парой символов CR и LF. Запись состоит из пяти полей следующего формата:
LLAAAATTDD...CC
Каждая группа букв (LL, AAAA, TT и т. д.) представляет собой отдельное поле. Каждая буква — отдельную 16-ричную цифру (4 бита). Каждое поле состоит, как минимум, из двух 16-ричных цифр (байт). Ниже представлена расшифровка полей записи:
Каждая запись в файле Intel HEX должна начинаться с двоеточия.
LL Поле длины – показывает количество байт данных (DD) в записи. AAAA Поле адреса – представляет начальный адрес записи. TT Поле типа. Оно может принимать следующие значения: 00 запись содержит данные 01 запись представляет код конца файла 02 запись представляет адрес сегмента для i8086 04 запись расширения линейного адреса DD Поле данных. Запись может содержать несколько байт данных. Количество байт данных должно соответствовать полю LL. CC Поле контрольной суммы. Поле контрольной суммы вычисляется путем сложения значений всех байт (пар 16-ричных цифр) записи по модулю 256 с последующим переводом в дополнительный формат.
Запись данных

Пример одной записи данных:
10246200464C5549442050524F46494C4500464C33
где 10 Количество байт данных (16 байт) 2462 Адрес памяти, куда будет помещена запись. 00 Тип записи — данные. 464C...464C Данные 33 Контрольная сумма записи
Запись адреса сегмента

Файл формата Intel HEХможет содержать записи для процессоров i8086, которые определяют адрес сегмента (иначе говоря — номер параграфа, один параграф — это 16 байт). Если используется директива H167, то этот тип записи заменяет запись расширенного линейного адреса. Номер параграфа используется как смещение адреса для всех записей данных, следующих за этой записью. Смещение представляет собой сдвиг адреса на четыре бита влево. Например, смещение равное 0x1234 даст реальный адрес 0x12340. Пример записи:
020000021000EC
где: 02 Количество байт данных 0000 В этом типе записи всегда равно 0000 02 Тип записи 02 (запись расширенного линейного адреса). 1000 Номер параграфа (реальный адрес будет равен 0x10000). EC Контрольная сумма
Запись расширенного адреса

Когда используется директива H167, файл формата Intel HEX возможно будет содержать записи расширенного линейного адреса. Этот тип записи определяет значения двух старших байт абсолютного адреса (биты 16-31). Эти два старших байта адреса будут применяться как смещение адреса для всех записей данных, следующих за этой записью. Пример записи:
0200000400FFFB
где: 02 Количество байт данных 0000 Всегда равно 0 04 Тип записи 04 (запись расширенного линейного адреса) 00FF Старшее слово смещения адреса (0x00FF0000) FB Контрольная сумма Запись Конец Файла (EOF) Файлы формата Intel HEX должны иметь запись Конца Файла (EOF). Пример записи:
00000001FF
где: 00 Количество байт записи 0000 Поле игнорируется. Не имеет значения, что там записано, но обычно всегда равно 0 01 Тип записи 01 (Конец Файла) FF Контрольная сумма, вычисленная как 01h + NOT(00h + 00h + 00h + 01h). Пример файла формата Intel HEX
020000021000EC
10C20000E0A5E6F6FDFFE0AEE00FE6FCFDFFE6FD93
10C21000FFFFF6F50EFE4B66F2FA0CFEF2F40EFE90
10C22000F04EF05FF06CF07DCA0050C2F086F097DF
10C23000F04AF054BCF5204830592D02E018BB03F9
020000020000FC
04000000FA00000200
00000001FF

Использование в AVR

Прошивка для AVR микроконтроллеров обычно компилируется в формат Intel Hex. Следует учесть следующие моменты:
Любая команда AVR-контроллера занимает не менее 2-х байт, поэтому размер слова составляет 2 байта. Flash-память AVR адресуется в словах,
поэтому команда вида jmp 0x65 будет указывать на 101-е слово (0x65=101) или 202-й байт (он же 0xCA).
Байты в слове читаются "задом наперёд". Например, если в hex-файле встречается слово "12C0", то интерпретировать его нужно как "C0 12",
что будет означать rjmp 18.

Ура!
Контроллер и софт пришли наконце-то к взимопониманию. Контроллер шьется, CRC совпадает, сам контроллер ошибок не выдает.
Правда пока промашки с адресами. В связи с чем у меня вопрос.

Пересмотрел кучу хекс-файлов, которые выдает CodeVison - везде первай строка содержит не 16, а скажем 4 байта. Причем эта строка не информационная,
а именно с данными. А приведенный код принимает строго по 128 байт для mega16.
И все бы хорошо, я могу переделать программу которая читает строки как надо, тупо набивает буфер 128 байтами, отдельно считает CRC, отдельно высчитывает адрес,
так как в этом случае все страницы будут начинаться не с того адреса, с которого начинается строка. Но вот бемпокоит меня следующее -страницы флеш памяти в
контроллере - это понятие условное, можно ли рассматривать память как непрерывное адресное пространство? Или же страницы имеют физические номера с закрепленными адресами?
Как записывать файл начинающийся строками:

если имеющийся у меня бутлоадер принимает одинаковые пачки по 128 байт? Переделать не проблема, просто я боюсь трогать то, что по идее должно работать.

Гм... здесь проблема, учитывая, что запись страницы в память занимает еще и некоторое время... У Вас софт для прошивки какой? Я имею в виду, самописный? Если да, то можно ввести контроль потока, и передавать данные по 128 байт, ждать пока запишется страница, а затем выдавать очередную порцию данных.
Если для прошивки используется эмулятор терминала, то вводят задержки на символ и передаваемые строки...

Можно организовать буфер и складывать в него данные с запасом...

Родненький, я у вас спрашиваю, как девку подцепить, а вы мне рассказываете как соску сосать. Софт у меня самопальный. Пока я контроль обмена данных не наладил, задержки не оценил, у меня ничего не прошивалось. Сейчас все пашет, но не до конца, так как бутлоадер неуниверсальный, он жрет только пакеты определенных размеров и просит CRC, когда хочет. Данные из файла, прежде чем передавать нужно пережевать, как именно и почему я уже написал.


Организую обязательно. Как сделать буфер и записать в него я не то что знаю, мне спрашивать стыдно.

Каежтся я понял, почему файлы начинаются строками с разной длиной - последняя строка всегда заполнена значащими байтами до последнего символа. А количество символов в первой строке - это остаток от деления на 16, как бы вместо последней короткой строки решили сделать первую. Оригинально.

Полтретьего ночи...
Заработало! Все шьется без проблем.