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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет. Не оно. Это он считает, что каждый модуль это вся программа и ничего больше на свете нет. Для того, чтобы тут всё работало - нужно самому всё запихать в один большой файл и скомпилить. А так, связи с 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 давала достаточно информации. Если память не изменяет - к нему в комплекте предлагался еще какой-то ключик.

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

Отлично!


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

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

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

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

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