Ну я теперь разобрался да, что там ассемблер только. Это объясняет всё Если она под си никогда толком и не затачивалась - тогда всё 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(явно или не явно).

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

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