В девайсах ATtiny иногда приходится сильно экономить память программ и использовать макросы. Поначалу все получалось и вдруг наступил затык. Три раза проект компилировался нормально, а с четвертого вдруг началась ругань на один из макросов. Причем его строки однотипны, а ругается только с четвертой. Подскажите в чем причина? Использую IAR EWAVR.

Наверное, в том, что между условием после if и else допустим только один оператор.

Непонятно, как именно вообще макросы могут сэкономить память программ (или вообще какую-нибудь память). И как ваши конкретные макросы её экономят.

1) Макросы - сокращение от макроподстановки. Они могут сэкономить только текст программы. То есть облегчить её написание либо восприятие.
2) Текст программы на Си не то же самое, что результирующий код. Иными словами более короткий текст программы может скомпилироваться в более длинную программу или менее эффективную.
3) Насколько я вижу ваши макросы наоборот сильно расходуют, а не экономят память программ. Хотя - может так задумывалось. Я не уверен, понимаете ли вы разницу в выборе на момент компиляции и на момент исполнения? Дело в том,что независимо от аргумента ваша фича скомпилируется в кучу операторов. Другое дело, что компилятор может часть убрать на этапе оптимизации. Тем не менее можно с помощью тех же макросов сделать запись более наглядной и, препроцессор сгенерит лишь один оператор (или часть).

Ну например:

Очень просто. Можно написать макрос как подпрограмму. Например, подпрограмма выбора Vref в ADC на основе всех возможных сочетаний. Это займет значительный кусок кода. Но потом выяснится, что применяется данная программа только один раз для установки Vref = 1v1. Ясное дело, это неэффективно. Если такую задачу решать с помощью макроса, то экономия памяти налицо. Вот почему для многих установок ADC полезно все же писать макросы, но для установки мультиплексора, возможно, подпрограмму (это зависит уже от конкретики задачи)...
С чего бы это? Какая куча? Скомпилируется только то, что соотв. условию по аргументу...
А посути-то есть что сказать? Если есть желание попробовать, прилагаю код...

1) По сути... где фигурные скобки?!
2) Еще раз по сути ... ИАР имеет очень удобную фичу отладки макросов, которая заключается в выводе в файл текста после препроцессора.
3) И третий раз по сути ... Ваши общие рассуждения о расходе памяти программ в случае оформления фрагмента кода как подпрограммы без оговорок о оптимизации и "инлайнирование" неверны. Программист может (и, пожалуй, обязан) написать так, что в любом случае память программ будет расходоваться одинаково экономно.

По всем трем пунктам большое спасибо. Писал все это под утро, уж на автопилоте. Только это что-то мало помогло. Решил упростить все до безобразия и вот... Что же еще упускаю?


2) если вы про пояснения в листинге, то там то же, что и в окне Build
То есть вы считаете, что программист заранее ОБЯЗАН знать, что лучше применить макросы или подпрограммы? По-моему, это не так тривиально и возможно только когда окончательно устаканится код... Лично меня как-то все время больше "тянет" на подпрограммы и уже позже, начинаю замечать, что вызовов не так много и возможно макросы отработают лучше...

Пример, заменяющий первую половину использованной Вами ахинеи, место которой вот здесь

Вопрос, а нафига оно нужно, плодить новояз, добавляющий еще один уровень понятий между терминами, определенными производителем микросхем и человеком, читающим текст программы, задавать не буду.
Лучше о хорошем поговорим. Например

ни о чем не говорит, а вот с привязкой к F_CPU

получаем некоторую свободу от пересчета делителя.
Такие дела.

Дело не в том, как написано, а в том, что синтаксису это удовлетворяет (теперь), а компилятор выдает ошибку. То, что Вы и прочие специалисты можете написать проще и нагляднее мне совершенно понятно. Могу и я написать. Но почему не работает то, что вроде бы должно?

Потому что перед отмеченной красным строкой символ "\" не является последним в строке.

Да дело не в простоте и наглядности. И не в красоте. Это все вещи субъективные.

Давайте проведите простой эксперимент. Поставьте свой макрос и выключите оптимизацию. После чего - листинг выложите постом ниже. Вот и будет простой и объективный ответ вам.

Пост ведь называется "макросы". Далее вы указываете "что применяется данная программа только один раз для установки Vref = 1v1". Значит задачу я понимаю правильно. Сами указываете, что "с целью экономии кода".
Подытоживая всё это, как я понимаю надо средствами препроцессора сделать текст проги красивым и наглядным, но, как минимум не в ущерб памяти программ. Сами вы ставите более серьёзную задачу - сэкономить.

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

Проверьте сами и выложите здесь. А то ветка для начинающих, и кто-нибудь из таковых, не разобравшись, вооружится вашими макросами. Да ещё вставит их в CV. А тот уже ему наэкономит будь здоров.

Ну нет же! Вы воюете с ветряными мельницами, выискивая несуществующую разницу.
Про pragma inline=forced Вы слышали? Она позволяет сделать так, что содержимое функции будет вставлено в текст программы. Потом, после оптимизации Вы получите код, идентичный написанному с использованием макросов.
Все одно, разница только в синтаксисе.
У Вас SETBIT() - это макрос, а у меня SetPin() - это функция, а компилируются они одинаково.

+1.
Не считаю себя профессионалом в данном вопросе, но также хочу отметить один вопрос. Сам его где-то прочитал на форуме - осмыслил - оценил - и теперь стараюсь неукоснительно следовать. Не то чтобы вам советую, просто отмечаю.
Все макроопределения в программе пишу большими буквами. А ф-ции и переменные малыми или смешанными. Это позволяет сразу понять - что есть ф-ция, а что макрос. Для меня - очень удобно.

Извините, но не поленился сделать простой проект в IAR. Могу я покорнейше узнать, почему эта ошибка все еще присутствует? У вас компилируется нормально или с той же ошибкой?
Хорошо. Спрошу проще: вы оформили SetPin() как функцию сознательно по каким-либо существенным мотивам или "просто так сложилось"? Т. е. для вас есть существенная разница как написать данную функцию для девайса со всего лишь 4к флеша? Вот что в хелпе нашел:

Но инлайнить нужно не всегда. И, тем более, когда "...это компилер решает...". Т.е. управлять этой прагмой все равно должен пользователь и встает вопрос - не проще ли макрос написать? Почему "gives you fine-grained control" пока не догоняю...
Я не спец по С, прошу уж сильно то не пинать )))), учитывая название раздела для данной темы....

Потому что


Уберите пробел в конце строки

Ок, спасибо! Была установлена опция в IAR IDE Tools/Options/Editor/Enable virtual space, т. е. курсор можно было поставить в любое место строки... а я как-то сразу и не сообразил ))) ...