Макросы в IAR EWAVR, v5.40.1 Опции

[ivainc1789]

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

[_Pasha]

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

Код

#define ADC_REF_VCC 1
#define ADC_REF_EXT  0
#define ADC_REF_1V1  3
#define ADC_REF_2V56 2
#define SET_ADC_CHANNEL(refn, chsel) ADMUX = (refn << REFS0) | (chsel)

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

Код

#define ADPS_DIV2 1

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

Код

#define ADPS_dv(val) ((val >= (F_CPU / 250000)) && (val <= (F_CPU / 50000)))
#if ADPS_dv(2)
#define STD_ADPS 1
#elif ADPS_dv(4)
#define STD_ADPS 2
#elif ADPS_dv(8)
#define STD_ADPS 3
#endif

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

[ivainc1789]

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

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

[_Pasha]

Но почему не работает то, что вроде бы должно?

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

[ivainc1789]

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

Извините, но не поленился сделать простой проект в IAR. Могу я покорнейше узнать, почему эта ошибка все еще присутствует? У вас компилируется нормально или с той же ошибкой?

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

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

The compiler is capable of inlining functions. This means that instead of calling a
function, the compiler inserts the content of the function at the location where the
function was called. The result is a faster, but often larger, application. Also,
inlining may enable further optimizations. The compiler often inlines small
functions declared static. The use of the #pragma inline directive and the C++
keyword inline gives you fine-grained control, and it is the preferred method
compared to the traditional way of using preprocessor macros. This feature can be
disabled using the --no_inline command line option.

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

Прикрепленные файлы

 proj.rar ( 6.38 килобайт ) Кол-во скачиваний: 14

 

[Dog Pawlowa]

вы оформили SetPin() как функцию сознательно по каким-либо существенным мотивам или "просто так сложилось"?
Т. е. для вас есть существенная разница как написать данную функцию для девайса со всего лишь 4к флеша? ...
не проще ли макрос написать?

1) У меня система описания портов посложнее. Поскольку на одной плате реализовано несколько разноплановых проектов, я поставил задачу определять порты в отдельном файле в виде:

Код

  OUTPUT  (   PulseWdt        ,   A  , 0x01    )
  OUTPUT  (   Backlight       ,   A  , 0x02    )
  OUTPUT  (   EmptyError    ,   A  , 0x04    )
  INPUT    (   SdaIn           ,   B  , 0x01    )

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

2) если что макрос, что функция занимают одинаково места, то при чем тут размер памяти? Да, без оптимизации моя программа не поместится в память, но я никогда не компилирую без оптимизации. Компилятору нужно доверять.

3) Может и проще, но не такие, как у Вас
Писал я подобные макросы. Основной их недостаток - плохая читаемость. А будете работать с тремя-четырьмя семействами контроллеров одновременно, крыша съедет. Мое мнение такое - или макросы должны быть простейшие, или уж система макросов должна надежно поддерживать логичную структуру описания объектов.
От проекта к проекту я так и делаю то одно, то другое, не используя Ваши промежуточные подходы, когда нужно помнить всю эту логику "макросизации".

Эта тема обсуждалась на форуме пару раз, может есть смысл поискать.