Список переменных проекта Опции

[IJAR]

IAR 4.20
Можно ли из файлов создаваемых компиляторм "вытащить" список имен переменных в RAM,
их начальные адреса и формат?

[Сергей Борщ]

IAR 4.20
Можно ли из файлов создаваемых компиляторм "вытащить" список имен переменных в RAM,
их начальные адреса и формат?

Адреса и список можно вытащить из .map - там они рассортированы по объектным файлам и сегментам. Можно анализировать сегменты, располагаемые в ОЗУ. Но информации о типах там нет. Вся интересующая вас информация хранится в объектном файле для отладчика. Но формат его закрыт. Можно посмотреть другие форматы, которые генерит линкер - coff, elf.

[IJAR]

Адреса и список можно вытащить из .map - там они рассортированы по объектным файлам и сегментам. Можно анализировать сегменты, располагаемые в ОЗУ. Но информации о типах там нет. Вся интересующая вас информация хранится в объектном файле для отладчика. Но формат его закрыт. Можно посмотреть другие форматы, которые генерит линкер - coff, elf.

Да sign и unsign надо различать, да и форма массивов .......
А формат cof где есть открытый

[Сергей Борщ]

А формат cof где есть открытый

Гугля выдает кучу ссылок: http://www.google.com/search?client=opera&...-8&oe=utf-8

[IJAR]

Гугля выдает кучу ссылок: http://www.google.com/search?client=opera&...-8&oe=utf-8

Спасибо, буду ковырять Coff формат.

[-SD-]

Можно воспользоваться Proteus'ом, если ваш контроллер им поддерживается.
Создать в нём простенький проект (один контроллер вставить без всякой обвязки). Сгенерить в IAR'е coff формат и подключить его к процессору в проекте Proteus'а.
Запустить выполнение по шагам и там выведится список всех глобальных переменных с их адресами.

[IJAR]

Можно воспользоваться Proteus'ом, если ваш контроллер им поддерживается.
Создать в нём простенький проект (один контроллер вставить без всякой обвязки). Сгенерить в IAR'е coff формат и подключить его к процессору в проекте Proteus'а.
Запустить выполнение по шагам и там выведится список всех глобальных переменных с их адресами.

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

[-SD-]

Поэтому фокус с coff файлом наиболее подходит.

В принципе это одно и тоже, т.к. Proteus просто "расшифрует" coff файл и покажет это на экране. При этом не надо будет разбираться с coff форматом. Но если не имели дело с Proteus'ом, надо будет его качать, устанавливать, чуть разобраться в нём.
Не известно что легче.

[IJAR]

В принципе это одно и тоже, т.к. Proteus просто "расшифрует" coff файл и покажет это на экране. При этом не надо будет разбираться с coff форматом. Но если не имели дело с Proteus'ом, надо будет его качать, устанавливать, чуть разобраться в нём.
Не известно что легче.

Ну и что с того что на экран можно будет вызвать адреса переменных.
Далее лазить по RAM в разные места? Хорошо если 1-2 переменных типа char,
а обычно их больше. Идея то такая: на экране список переменных с их форматом,
отметил галочками интеремующие - получил список с текущими значениями,
нажал кнопку "Обновить" новые текущие значения.

Правда с Cof файлом оказались проблемы: не хочет IAR 4.20 генерить его для ATmega процессоров
а UBROF 8 пака не нащел описание формата. Так что пока идея в полном развале.

[Сергей Борщ]

а UBROF 8 пака не нащел описание формата.

и не найдете: UBROF - закрытый формат имени ИАРа. А .elf иар умеет генерить для меги?

[IJAR]

и не найдете: UBROF - закрытый формат имени ИАРа. А .elf иар умеет генерить для меги?

В EXTRA OPTION Linker-a ставлю: -Oelf,as=my_Proj.elf
при линковке получаю:
Fatal Error[e92]: Cannot use the 'elf' output format with this cpu
что, как я понимаю, означает что данный формат для такого типа CPU
не поддерживается (у меня mega128)

[AndreyKeil]

IAR 4.20
Можно ли из файлов создаваемых компиляторм "вытащить" список имен переменных в RAM,
их начальные адреса и формат?

Скачайте среду разработки "Project-AVR/ESA" московской фирмы "Фитон" http://www.phyton.ru/cp1251/renevals/avr.shtml.
После установки, там есть опция "загрузить программу для отладки". Грузить нужно в формате UBROF8. Далее, в меню есть опция "Просмотр\Распределение памяти", там есть всё что вас интересует.

[IgorKossak]

Скачайте среду разработки "Project-AVR/ESA" московской фирмы "Фитон" http://www.phyton.ru/cp1251/renevals/avr.shtml.
После установки, там есть опция "загрузить программу для отладки". Грузить нужно в формате UBROF8. Далее, в меню есть опция "Просмотр\Распределение памяти", там есть всё что вас интересует.

С сайта производителя:

Поддерживаются микроконтроллеры:

AT90S1200, AT90S2313, AT90S2323, AT90S2343, AT90S4414 (external SRAM), AT90S4414 (internal SRAM only), AT90S4433, AT90S4434, AT90S8515 (external SRAM), AT90S8515 (internal SRAM only), AT90S8534, AT90S8535, ATmega103, ATmega103 (external SRAM), ATmega161, ATmega161 (external SRAM), ATmega603, ATmega603 (external SRAM), ATtiny 10, ATtiny 11, ATtiny 12, ATtiny 15, ATtiny 22, ATtiny 28.

Не думаю, что это старьё кем-то всерьёз используется (в серийных разработках). А новые МК, судя по всему, не поддерживаются.

[AndreyKeil]

Не знаю, что там говорит производитель - я не читал, но в этой оболочке поддерживаются процессоры: ATmega8,ATmega16,ATmega32,ATmega128.
Эта среда, хоть и старая, но имеет возможности сравнимые с редактором SlickEdit. Из её возможностей мне нравится то, что можно загрузить код для отладки и пройтись по коду. При этом, можно в основном коде на "С" смотреть дизассемблер. Периферию не поддерживает. Просто - ход по коду с дизассемблером.
Новые процы я научился добавлять (худо-бедно).

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

[sergik_vrn]

IAR 4.20
Можно ли из файлов создаваемых компиляторм "вытащить" список имен переменных в RAM,
их начальные адреса и формат?

прошу прощения, что вмешиваюсь, а что, нельзя запустить в самом IAR симулятор, и там в окне watch посмотреть все, что нужно?

[Сергей Борщ]

в самом IAR симулятор, и там в окне watch посмотреть все, что нужно?

Симулятор! А вопрошавшему надо из работающего устройства через какой-то свой монитор считывать участки памяти и представлять их как реальные переменные:

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

[IJAR]

Симулятор! А вопрошавшему надо из работающего устройства через какой-то свой монитор считывать участки памяти и представлять их как реальные переменные:

Именно так и предполагается.
Вообще то, если хорошо поковырять файлы *.map и *.lst , то данные о переменных
можно вытащить (из *.map - имена и начальные адреса, а из *.lst - их типы и структуры)
правда парсинг будет достаточно сложный

[sergik_vrn]

Именно так и предполагается.
Вообще то, если хорошо поковырять файлы *.map и *.lst , то данные о переменных
можно вытащить (из *.map - имена и начальные адреса, а из *.lst - их типы и структуры)
правда парсинг будет достаточно сложный

что-то я, видимо, до конца не понял задачу. в исходном сообщении об этом ни слова

IAR 4.20
Можно ли из файлов создаваемых компиляторм "вытащить" список имен переменных в RAM,
их начальные адреса и формат?

если задача еще актуальна, можно ли тогда ее уточнить? это разовая задача или типовая (то есть, нужен скрипт) ? почему информацию о структуре нельзя взять из исходных файлов?

[IJAR]

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

Из исходника взять данные конечно можно, но из файлов компилятора проще, легче парсить
строки, поскольку в них информация структуирована, например в .map:

Код

ABSOLUTE
  Relative segment, address: DATA 0000010C - 0000010D (0x2 bytes), align: 0
  Segment part 14. ROOT.
           ENTRY                   ADDRESS         REF BY
           =====                   =======         ======
           bi_Wector_USER          0000010C

    -------------------------------------------------------------------------
NEAR_N
  Relative segment, address: DATA 00000182 - 00000195 (0x14 bytes), align: 0
  Segment part 25.            Intra module refs:   main
           ENTRY                   ADDRESS         REF BY
           =====                   =======         ======
           l_b                     00000182
    -------------------------------------------------------------------------
CODE
  Relative segment, address: CODE 0001E0D8 - 0001E0E3 (0xc bytes), align: 1
  Segment part 26.
           ENTRY                   ADDRESS         REF BY
           =====                   =======         ======
           __low_level_init        0001E0D8        ?call_low_level_init (?C_STARTUP)
               stack 1 = 00000000 ( 00000002 )
    -------------------------------------------------------------------------

Понятно, что строку CODE и все что далее до строки
"--------------------------------"
можно пропустить, а вот NEAR_N или ABSOLUTE - заслуживают внимания - получим ИМЯ, РАЗМЕР,
и НАЧАЛЬНЫЙ адрес переменной, далее по имени в *.lst найдем описание структуры, парсим и ее;
далее обычная прогрммная эквилибристика => делаем файл описания переменных
который будет читать терминальная программа по каждому обновлению ну а далее формирование
списка и размеров смежных областей RAM(EEPROM) для чтения и их размер;
далее запросы к контроллеру и далее форматный
вывод на экран прочитанного из контроллера на экран.

[sergik_vrn]

Из исходника взять данные конечно можно, но из файлов компилятора проще, легче парсить
строки, поскольку в них информация структуирована, например в .map:

[..]

получим ИМЯ, РАЗМЕР,
и НАЧАЛЬНЫЙ адрес переменной, далее по имени в *.lst найдем описание структуры, парсим и ее;
далее обычная прогрммная эквилибристика => делаем файл описания переменных
который будет читать терминальная программа по каждому обновлению ну а далее формирование
списка и размеров смежных областей RAM(EEPROM) для чтения и их размер;
далее запросы к контроллеру и далее форматный
вывод на экран прочитанного из контроллера на экран.

в общем, я не согласен только с утверждением, что .map проще парсить - в с структура не менее структурированная, впрочем, если coff открыть не удается, то все равно без парсинга .map (или .lst) не обойтись. в остальном - Вы вроде и ответили на свой вопрос

[IJAR]

в общем, я не согласен только с утверждением, что .map проще парсить - в с структура не менее структурированная, впрочем, если coff открыть не удается, то все равно без парсинга .map (или .lst) не обойтись. в остальном - Вы вроде и ответили на свой вопрос

Согласен что наметился путь решения, хотя и довольно тернистый. Что касается coff файла, то его
не удается создать, а открыть то как раз получается, например coff файл для pic процессоров
вполне разбираем.

[Сергей Борщ]

Что касается coff файла, то его
не удается создать,

Если проект не на С++, то можно создать файл в формате IEEE-695.

[sergik_vrn]

Если проект не на С++, то можно создать файл в формате IEEE-695.

прошу прощения, если чего пропустил, а UBROF случайно не годится?

[Сергей Борщ]

прошу прощения, если чего пропустил, а UBROF случайно не годится?

Если у вас есть описание этого формата, и вы готовы поделиться этой информацией - то годится.

[sergik_vrn]

Если у вас есть описание этого формата, и вы готовы поделиться этой информацией - то годится.

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