AVR Studio vs IAR Embedded Workbench vs GCC, К чему привыкать то? Опции

[sigmaN]

Дошли руки и до АВРок.

Смотрю тут люди иногда предпочитают не использовать стандартную среду AVR Studio и ищут иных путей. Почему?
Тот-же IAR - что за зверь?
Ну GCC понятно, гнутый тулчайн, традиционно со своими гнутыми расширениями языка. На сколько он хорош?

Тут же, как я понимаю, "умность" компилятора много значит потому, что тут всё очень Tiny

Пока скачал AVR Studio и жду своего Dragonа..... приедет ориентировочно послезавтра ))))

[SasaVitebsk]

Если для Вас GCC знаком, то особого смысла использовать IAR нет. Есть задачи на которых IAR даёт выигрыш, а есть и наоборот. Кроме того, и сам компилятор имеет немного отличий связанных с мелочами. К примеру объявление прерываний, указания линковщику и т.п. Таким образом перепрыгнуть с одного на другой - существенной разницы нет. Думаю, что зная особенности, возможно сразу писать прогу, которая будет компилится и там и там. Зная особенности компилятора (его преимущества) можно существенно влиять на результат компиляции. Таким образом хорошее знание компилятора, поможет больше, чем его замена.

Ну и AVR, на сегодняшний день, не такие уже и tiny. Скажем под IAR, на данным момент, практически нет необходимости что-то прикручивать на ASM. Программа размером 1к вполне хорошо компилится. Озу, тоже практически всегда хватает. По производительности - лучше выбрать камень с необходимой. Короче - никаких проблем нет.

[sigmaN]

Ну в обем-то понятно, да, спасибо.

Просто больше даже было интересно ПОЧЕМУ люди соскакивают со стандартной и официально предлагаемой Atmel AVR Studio?

В общем я пока на AVR Studio сажусь, а там видно будет )

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

Смотрю тут люди иногда предпочитают не использовать стандартную среду AVR Studio и ищут иных путей. Почему?

А вы попробуйте в ней пописать исходник. А потом попробуйте в эклипсе. Поймете. Кроме жутко неудобного редактора Студия еще недавно (не знаю как сейчас) не позволяла добавлять в проект файлы с расширением .cpp За что и была отложена подальше. Сейчас раз в год достается какой-нибудь заковыристый кусочек просимулировать.

[sigmaN]

Нда. Всё ясно.
Я, кстати, SlickEdit месяц назад скачал...да всё никак не доходят руки. Думаю, GCC туда прикрутить вообще не проблема.
Вопрос только как там все эти отладочные модули/JTAG и т.д. Это ведь всё к AVR студии по идее только цепляется или люди уже давно решили эту проблему(чего только не сделаешь, чтобы отказаться от неудобной среды )

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

отладочные модули/JTAG и т.д.

Avreal + махание ногой + отладочный вывод через uart в терминал. Для ARM сейчас прямо пытаюсь заставить MT-Link работать через OpenOCD - через gdb эклипса работать умеет.

[sigmaN]

Аа, т.е. такую роскошь, как отладка на уровне строк исходного кода с параллельным watch'ем пары-тройки переменных тут действительно только в AVR Studio можно поиметь, да?

Ну я просто привык как-то, всё JTAG да JTAG. В общем я понял, зажрался ))
Но, в принципе то что тут, вроде как может оно и не надо особо...Иногда отладочным выводом в терминал можно даже быстрее локализовать проблему, чем брэйкпоинтами.

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

[SasaVitebsk]

Так ничто не мешает. И IAR, и думаю GCC имеют в качестве выходных файлов UBROF. Подключайте и работайте в студии. С JTAG или в симуляторе.

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

Так ничто не мешает. И IAR, и думаю GCC имеют в качестве выходных файлов UBROF. Подключайте и работайте в студии.

Студия прекрасно понимает gcc-шный elf. А ubrof - закрытый ИАРовский формат, его gcc генерить не может.

[sigmaN]

Даа, действительно эта AVR Studio просто ужасна! Даже не верится, что Атмэл выпускает новые версии не один и не два года......
А ещё удивился, то она без GCC жить не может. Хотя это даже к лучшему. Я GCC уважаю )

[mempfis_]

Вопрос только как там все эти отладочные модули/JTAG и т.д. Это ведь всё к AVR студии по идее только цепляется или люди уже давно решили эту проблему(чего только не сделаешь, чтобы отказаться от неудобной среды )

Плюсы AVRStudio проявляются когда приходится прошивать десятки-сотни плат. Используя AVRISPMKII через студию прошивается один контроллер, выбирается закладка AUTO и одним нажатием кнопки прошиваются остальные, только программатор успевай переставлять

[SasaVitebsk]

Даа, действительно эта AVR Studio просто ужасна! Даже не верится, что Атмэл выпускает новые версии не один и не два года......
А ещё удивился, то она без GCC жить не может. Хотя это даже к лучшему. Я GCC уважаю )

Как это не может??? Это совершенно независимый продукт. Вы можете только в ней работать. Причём продукт весьма приличный, учитывая бесплатность. По крайней мере у меня к ней перетензий нет.

[sigmaN]

Как это не может??? Это совершенно независимый продукт. Вы можете только в ней работать.

Скачал с сайта саму студию плюс два сервис пака. Поставил. По нажатии на кнопку compile мне сказали, что без WinAVR жизни нет. Пошел за WinAVR, с удивлением узнал, что это и есть тот самый AVR GCC собранный под венду. Скачал, поставил. Теперь при нажатии на кнопочку Compile происходит компиляция с использованием того самого GCC

Бесплатна то конечно бесплатна, но как-бы сейчас точно можно лучше. Ну что это такое, я даже не могу щёлкнуть правой кнопкой и открыть файл на котором стоит курсор(Open file at cursor).
Ну это дико вообще! Какая бы там бесплатная она не была, а как минимум код писать нужно в другом редакторе - это факт.

Ну по прошивке и кол-ву поддерживаемых программаторов/отладчиков спору нет.

[SasaVitebsk]

AVR Studio - это оболочка + ассемблер + симулятор. Компилятора Си там никогда не было. Они правда написали плагин для GCC.

[zltigo]

Плюсы AVRStudio проявляются когда приходится прошивать десятки-сотни плат. Используя AVRISPMKII....

Потрясен использованием AVRStudio. Очень. Для этого просто нужен программатор. Любой. Можно и из компоекта этой самой студии. Но сама вся эта "оболочка", ну совсем совсем не нужна.

[sigmaN]

AVR Studio - это оболочка + ассемблер + симулятор. Компилятора Си там никогда не было. Они правда написали плагин для GCC.

Ну я теперь разобрался да, что там ассемблер только. Это объясняет всё Если она под си никогда толком и не затачивалась - тогда всё Ok.
Со своии задачаи справляется )

[haker_fox]

Плюсы AVRStudio проявляются когда приходится прошивать десятки-сотни плат. Используя AVRISPMKII через студию прошивается один контроллер, выбирается закладка AUTO и одним нажатием кнопки прошиваются остальные, только программатор успевай переставлять

Так тут студия не причем) Можно использовать консольную утилиту, только Enter успевай нажимать)

Скачал с сайта саму студию плюс два сервис пака. Поставил. По нажатии на кнопку compile мне сказали, что без WinAVR жизни нет.

Когда проект создаете, выбирайте asm. Чистая студия только ассемблер в себе оной содержит.

Ну это дико вообще! Какая бы там бесплатная она не была, а как минимум код писать нужно в другом редакторе - это факт.

ну это и естественно Над редакторами люди трудятся и достигают конкретных поставленных целей. Цель же студии - симуляция, отладка МК.

Ну по прошивке и кол-ву поддерживаемых программаторов/отладчиков спору нет.

А Вы попробуйте запустить avrdude. Там список программаторов не менее внушительный.

[sigmaN]

В AVR035: Efficient C Coding for AVR написано, что архитектура AVR якобы затачивалась под уже существующий тогда компилятор IAR.
А на сколько сильно на практике gcc проигрывает IAR и проигрывает ли вообще?

[haker_fox]

А на сколько сильно на практике gcc проигрывает IAR и проигрывает ли вообще?

Подобные вопросы уже обсуждались, можете поискать)
На счет проигрыша: так уж получается, что когда продуктом занимаются профессионалы за деньги, он получается, как правило лучше, чем бесплатный аналог. IAR -не исключение. Однако, это совершенно не мешает мне до сих пор работать с GCC. Привычка, так сказать (примерно 5 лет) и отсутствие необходимости в переходе на более совершенный продукт. В общем это мнение субъективное. Начинать тоже неважно с чего.

[demiurg_spb]

А на сколько сильно на практике gcc проигрывает IAR и проигрывает ли вообще?

Будете смеяться, но в грамотных руках нисколько...
Нужно лишь внимательно изучить ВСЕ (а их ой как не мало) ключи оптимизации и просто грамотно писать исходники.

[SSerge]

В AVR035: Efficient C Coding for AVR написано, что архитектура AVR якобы затачивалась под уже существующий тогда компилятор IAR.

Врут.
И даже что под использование языков высокого уровня вообще - тоже слабо соответствует действительности.
Один только уродский стек чего стоит.

[MrYuran]

А на сколько сильно на практике gcc проигрывает IAR и проигрывает ли вообще?

Ну не скажу про AVR, но для MSP430 получалось по размеру где-то 16к с IAR против 19-20 с MSPGCC.
В общем-то, не набивая под завязку, вполне можно пережить.
Тем более что всё равно флеши 60к, так что больше половины свободно.
При этом, как уже упоминали, правильная манера кодирования позволяет ещё что-либо улучшить.
Хотя, как говорят умные люди, не надо ничего тонко оптимизировать, пока это действительно не будет нужно.
Или другими словами, "не лечи то, что работает"

Ну а насчёт "к чему привыкать"...
Вот на днях директору пришло письмо от заинтересованной конторы, что после 19-го к нам могут прийти внезапно специально обученные люди, которые проверят, действительно ли мы отказались от использования пикада, или продолжаем его нелегально использовать.
Хорошо хоть предупредили...
Узнайте, сколько стоит IAR и оцените, сможете ли вы его себе позволить.

[sigmaN]

В принципе согласен, что при грамотном использовании gcc может оказаться очень хорошим конкурентом IAR.
Однако на WINAVR( как и на всё что GNU) требуется перелопатить достаточно много документации, чтобы понять что к чему и как вообще лучше кодить и какие ключи оптимизации использовать.

Предлагаю собрать тут некий how to или tips and tricks ))

Я потом выложу тут то, что я накопал. Сейчас нет времени.

Пока у меня вопрос:

Код

static volatile    struct{
    uint16_t    timer_ticks;
    uint16_t    timer_ms;
}timer_counters;

uint16_t    timer_get_ticks()
{
    return timer_counters.timer_ticks;
  8a:    20 91 61 00     lds    r18, 0x0061
  8e:    30 91 62 00     lds    r19, 0x0062
}
  92:    c9 01           movw    r24, r18
  94:    08 95           ret

Зачем так тупить? что, нельзя было сразу в r24:r25 загрузить значение?

*код просто для примера. Дело ясное, что в таких случаях нужна структура без static и прямое обращение к ней из других модулей вместо вот таких вот функций-паразитов в микроконтроллеропрограммировании

[sigmaN]

Я вот даже уже почитал авр инструкшн сэт.
Действительно непонятно почему не так?
lds r24, 0x0061
lds r25, 0x0062

[sigmaN]

А ещё забавно, что похоже при любых -О приходится всё равно вручную добавлять -fwhole-program а это хорошая опция, она мне нравится! ))

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

Но всё таки круто! Один компилятор, столько архитектур, столько языков!
Всё таки очень круто, да и бесплатно ещё!

added: ооо, нет. не то. этот -fwhole-program это совсем не то ))

[SasaVitebsk]

Врут.
И даже что под использование языков высокого уровня вообще - тоже слабо соответствует действительности.
Один только уродский стек чего стоит.

Это всё обсуждалось уже.

Всё познаётся в сравнении. По сравнению с PIC16 или с х51, megaAVR лучше "адаптирован". Претензий не больше чем к тому же ARM. Наличие "особенностей" в ядре и системе комманд, обычное явление для любого процессора/ семейства. Всё это результат многочисленных компромисов.

То что вы называете "уродский стэк", вполне можно назвать "крассивое решение по стэку". Причём, ни грамма не покривив душой.

2 sigmaN. Таких "нюансов" компиляции, будет полно и для IAR и для GCC. Чем больше вы будете отходить от ASM, тем меньше это вас будет волновать. В конечном итоге вас ведь интересует не "оптимальность написания программы в коде", а её принципиальная работоспособность, скорость написания, возможности по заимствованию, хорошая отлаживаемость, хорошая поддерживаемость, лёгкость развития проекта и его "прозрачность". Всё это присутствует в полной мере. Суммарный вклад "нюансов" не велик. Кроме того, как правило, невелика часть программы которая является критически важной по времени. Эту часть программы можно написать на ASM. В последнем IAR для ARM - вроде даже видел какой-то проффилировщик.

Короче идёт развитие программных сред и средств, и надо это принять как должное, а не цепляться за старые мощи.

[sigmaN]

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

А этот вон даже не выкидывает функции, которые ни разу не используются. Чё за ерунда.

[MrYuran]

А этот вон даже не выкидывает функции, которые ни разу не используются. Чё за ерунда.

-ffunction-sections - помещает каждую функцию в отдельную секцию
-fdata-sections - помещает каждую переменную в отдельную секцию

Неиспользованные секции не линкуются

[sigmaN]

Ах вот как оно тут сделано по хитрому.
А в техасе писали, что их компилятор выбрасывает все функции, которые не вызываются main(явно или не явно).

А тут вон какой прикол. Для каждой функции секция ))

[demiurg_spb]

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

added: ооо, нет. не то. этот -fwhole-program это совсем не то ))

Это как раз оно.
Да, да, да.

[AHTOXA]

Неиспользованные секции не линкуются

.. при передаче линкеру ключа --gc-sections.

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

Это как раз оно.
Да, да, да.

Но только для C. С плюсами не работает.

[demiurg_spb]

Но только для C. С плюсами не работает.

Ну тут уж... что уж..

[sigmaN]

Это как раз оно.
Да, да, да.

Нет. Не оно. Это он считает, что каждый модуль это вся программа и ничего больше на свете нет. Для того, чтобы тут всё работало - нужно самому всё запихать в один большой файл и скомпилить. А так, связи с main он не определяет . Но таки да, исправно выбрасывает то, что не используется в пределах модуля.

Эксперимент: timer.c описывает функцию get_timer_ticks() которая возвращает тики таймера. Сама переменная тиков объявлена как static volatile и щёлкает по прерыванию.
Из main.c в main() делаем вызов t = get_timer_ticks(); компилим с -fwhole-program. О ужас, проект не линкуется! main.o хочет символ, которого нет! get_timer_ticks благополучно выбросили, потому что модулю timer.c эта функция не нужна(там то она не используется нигде);

Так что - не то

А в техасовском компиляторе просто сказка! Там ещё есть несколько вариантов на выбор(ну типа чтоб без фанатизма или всё подряд удалял). Даа, хороший компилятор. Только уж оооочень долго он работает если все оптимизации включить. А ещё памяти отхавывает с пол гига(на приличном исходнике разумеется). Но оптимизирует зато чётко.

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

Нет. Не оно. Это он считает, что каждый модуль это вся программа и ничего больше на свете нет. Для того, чтобы тут всё работало - нужно самому всё запихать в один большой файл и скомпилить.

Достаточно передать gcc на вход все исходные файлы сразу (не поодиночке) и на выходе получать сразу .elf, без вызова линкера. Когда разбирался - гугля по -fwhole-program давала достаточно информации. Если память не изменяет - к нему в комплекте предлагался еще какой-то ключик.

[sigmaN]

ааа эээ мм.. как это без линкера? Честно говоря даже не думал что так можно...
А как он определит ну там entry point, я не знаю... все эти дела ведь линкер решает. Погуглю обязательно!

Да, -fwhole-program + -combine + передать все файлы за один раз. На выходе всё-же не .elf по-моему, а .o файл.

[SasaVitebsk]

Честно говоря не совсем понимаю зачем это вам?

Насколько я понимаю, вы можете из нескольких C файлов один и по include сделать. Только зачем всё в одну кучу валить?
Наоборот раздельная компиляция - то что надо. Некоторые даже ошибки выявляются.

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

[MrYuran]

Честно говоря не совсем понимаю зачем это вам?

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

[AHTOXA]

Оптимизация лучше.

Ха! И это говорит человек, у которого осталось свободным пол-флеша?
Я согласен с SasaVitebsk. Топикстартеру надо сначала изучить предмет (компилятор), все ключи, нюансы. А уже потом, если в этом останется необходимость, задумываться о супер-оптимизации.
sigmaN, для выбрасывания неиспользуемого кода/данных в gcc есть ключи компилятора -ffunction-sections -fdata-sections и линкера --gc-sections. Мне показалось, что вы это просмотрели.

[MrYuran]

Ха! И это говорит человек, у которого осталось свободным пол-флеша?

Оптимизация, как известно, палочка о двух концах - размер/быстродействие.
Хотя, я с некоторых пор тоже не особо заморачиваюсь.
Например, в реализации FreeModbus в прерывании УАРТа вызывается функция обработки через указатель
и ничего... на скорости 115200 валит 100 регистров в секунду за милую душу

Но всё равно, когда замечаешь разницу относительно ИАРа, это немного нервирует
Видимо, у ИАРа просто оптимизация более адаптивная и многопроходная, а GCC-шному компилятору надо по месту объяснять, что от него требуется.

[AHTOXA]

и ничего... на скорости 115200 валит 100 регистров в секунду за милую душу

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

Но всё равно, когда замечаешь разницу относительно ИАРа, это немного нервирует

Это не проблема, надо просто снести ИАР

[MrYuran]

Это не проблема, надо просто снести ИАР

Дык, уже
только что попробовал -fwhole-program на mspgcc, обругался насчёт анрекогнайзед опшн
ну и хрен с ним пускай...

[demiurg_spb]

Честно говоря не совсем понимаю зачем это вам?

Когда нужно впихнуть невпихуемое - то это отличный вариант.
Пример из жизни: c 16Кб хорошо оптимизированной программы удалось выиграть ещё около 500Байт - и это было решающим фактором.

Насколько я понимаю, вы можете из нескольких C файлов один и по include сделать. Только зачем всё в одну кучу валить?

Инклюдить всё - это как-то через одно место ИМХО.
Зачем делать через Ж, когда компилятор предоставляет стандартное решение?

Наоборот раздельная компиляция - то что надо. Некоторые даже ошибки выявляются.

Сообщения об ошибках выдаются точно также как и при раздельной компиляции.
Так что никакой разницы здесь нет.
И мне даже кажется что так компиляция происходит быстрее.

Дык, уже

Отлично!

только что попробовал -fwhole-program на mspgcc, обругался насчёт анрекогнайзед опшн

Можете сами попробовать пересобрать msp-gcc с этой функцией или попросить Клёна об этом - он ведь у нас Великий Турук-Макто:-)

[MrYuran]

Можете сами попробовать пересобрать msp-gcc с этой функцией или попросить Клёна об этом - он ведь у нас Великий Турук-Макто:-)

msp в его меню не входит...
я, правда, тоже уже на Cortex M0 заглядываюсь потихоньку
Надо бы ещё глянуть, что в мспжцц4 насочиняли..
Однако, тема про АВР - вот там всё должно быть в ногу со временем.

[sigmaN]

Да и инлайны тоже. Приходится писать код в хидерах. И если это функци инициализации таймера в три строки - то инлайн рулит, т.к. вызывается она один раз и размер кода меньше пролога/эпилога. В тоже время всё красиво: таймер в timer.c, АЦП в adc.c. Конечно можно навалить всё в одну большую кучу в файл аля main.c, но это не наш метод ))

Кстати говоря метод -ffunction-sections -fdata-sections и линкера --gc-sections мне кажется каким-то слегка не правильным.... Должен компилятор без вопросов сам всё выбрасывать. Что это за секции, линкеры.....

[demiurg_spb]

Кстати говоря метод -ffunction-sections -fdata-sections и линкера --gc-sections мне кажется каким-то слегка не правильным.... Должен компилятор без вопросов сам всё выбрасывать. Что это за секции, линкеры.....

Он делает всё правильно и максимально гибко. Случаи бывают разные...