Здравствуйте.

Собсно вопрос - в результате компиляции получаю HEX-файл. Его размер реально больше, чем то что потом положится во флеш и будет исполняться.
Хотелось бы, используя какой нить экзешник(ну или вообсче что нибудь ), узнать реальный размер кода ( типа как в AVRStudio писало в конце компиляции -> исходный код - стоколько-то байт..)..
Может у кого в закромах есть такая программка ?
Буду признателен

avr-size, она так в линуксе называется. Есть вроде винавр какой-то там тоже наверное есть

2 LamerMan - у меня NIOSII -
Глобальная идея - хочу посмотреть если хватит места, то сделать загрузчик не РОМ а РАМ и натыкать туда переменных чтоб расширить его кругозор....

Поскольку каждый байт в HEX-файле кодируется 3-мя символами ASCII (2 цифры+пробел), то грубо можно оценить, разделив размер на 3.
При этом не учитывается служебная информация в hex-файле.

2 MrYuran - прога ориентировочно занимает байт 200 с хвостиком, хекс занимает 1608 - итого 536 - при размере памяти 512 байт
Не то...

Скачайте с Phyton.ru их программатор (оболочку). Загрузите в него Ваш HEX-файл и смотрите расположение и т.д. Можно написать скрипт (на языке программатора), который будет расчитывать объем бинарного образа.

2 mdmitry - формат знаю - как раз неохота садится и ваять самому этот размеромерятель - точно должен был уже кто-то сотворить такое...

Ну да, я с TI-Text попутал...
Ну тогда так.
Открываем HEX.
:10110000B240805A20013F40F6473E4000023D4039
Это одна строка.
Красный - адрес, зелёный - данные.
Итого 43 байта идут на кодирование 16 байт прошивки.
43/16=2,6875
То есть коэфф. деления 2,6875
Может, размер файла неправильно определяется?

Да, забыл, ещё 2 байта на перевод строки

Кстати, в соседней теме советуют - hex2bin и bin2hex.
По моим понятиям, hex2bin как раз даст бинарный образ программы.

В обсчем решил проблему(хотя не совсем это и проблема)...

Может кому будет полезно -
НЕХ -
:040000000001703a51
:0400010002c06034a5
:040002005ac52414a3
:040003000019883a1e

Асм- листинг
//
wrctl status, zero
0: 0001703a wrctl status,zero
//
movhi led_addr, %hi(BOOT_LED)
4: 02c06034 movhi r11,384
//
ori led_addr, led_addr, %lo(BOOT_LED)
8: 5ac52414 ori r11,r11,5264
//
mov led_value,r0
c: 0019883a mov r12,zero

В ниосе инструкция кодируется 32 битами - из вышеприведённых данных видно что
в НЕХ-е мы имеем 3 строчки по 32 бита - то есть 3*4*байт - итого 12 байт.

Далее смотрим на последнюю строчку в НЕХ-е -
у меня тут
:04004e008000683a8c

Тоесть (4е+1)*4 <- количество занимаемых байт.
(
Цифра 316 подтверждается так же листингом -
// последняя осмысленна инструкция
jmp return_address
138: 8000683a jmp r16

то есть 138+4 - размер кода -> 13С == 316
)


В итоге получилось 316 байт - жирненький я хвостик дописал

пЫсЫ.
Касательно hex2bin - не нашёл в ниосовском ЕДС..

У Атмела надо искать.

2 Andy Great - пробовал - пишет:

Error - Could not open hex file
Status: HEX to BIN conversion was not successful.

Так что я думаю приведённый мной метод всё же работает лучше - в смысле работает

Значит, надо искать конвертор поновее, с поддержкой новых форматов хекса. Это все имеет смысл в надежде, что адреса в хексе последовательные, а то были крики при конвертировании в бин для AT91SAM

Видимо, проблема в том что форматы хексов у всех разные.
по части количества байт в строке.
Если применить мой метод для вашего хекса, то получим:
:040000000001703a51 - итого 21 байт (вместе с переносом строки) для записи 4-х байт.
Делим 21/4=5,25
Делим размер файла 1608 на 5,25 - получаем 306,28
Почти попал

HEX формат имеет модификации для размера до 64к и более 64к (Extended HEX). Во втором случае задается базовый адрес и далее смещение в нем (в пределах 64к). Разные программы по разному формируют HEX файл: строго 16 байт на строку текста или вариация размера бинарного образа в сторке текста файла, а есть еще незаполненные дырки в ПЗУ, которые не отражены в HEX файле. Считается, что эти дырки заполняются правильным символом при стирании памяти (обычно 0xFF) ИМХО: поправочные множители не дадут точного попадания в размер бинарного образа.

В hex файле может быть разное количество байт в строке. чем больше байт в строке тем меньше отношение объема hex/bin. Вот пример от VisualDSP
:20003A00E41AF9F900E02B1E55F500E04126E7E900001D0137021B01F500EB01F500E30000 итого 79 символов со \n\r из них 32 байта данных. Получаем примерный коэффициент 2,47. Если вам нужно знать точный объем, почему бы в опциях компилятора не выбрать в качестве выходного файла формат bin, а не hex?

Ну тогда там должен бы найтись не avr-size.exe, а просто size.exe или там nios-elf-size.exe
Насколько я знаю, оно ведь тоже на gcc базируется.
Кстати,и avr-size не .hex берёт для "работы", а тот .elf, из которого потом все нужные hex-ы генерируются.

Самое простое - конвертнуть хекс в бин оболочкой какого-нибудь программатора.

Или вот, попробуйте Нажмите для просмотра прикрепленного файла