Не отрабатывает #define, глюки работы директивы define Опции

[aspID]

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

Код

#ifdef DEBUG
//Генерация импульса синхронизации
DDRD |= 1 << PD1;
PORTD |= 1 << PD1;
_delay_ms( 1 );
PORTD &= ~(1 << PD1);
#endif //DEBUG

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

Код

#ifndef F_CPU
  #define F_CPU 3686400UL
#endif

В используемом далее контексте ругается, что не определено F_CPU

Код

#ifndef F_CPU
# warning "F_CPU not defined for <aspID/delay.h> using 1MHz"
# warning "To define F_CPU go Proj->Opt->C/C++->Defined symbols"
# define F_CPU 1000000UL
#endif

Но и этот # define очень похоже, что не отрабатывает.

Заранее спасибо и всех с наступающим Рождеством!


ЗЫ: до сих пор не могу победить проблему, если пишу с использованием классов и НЕ использую конструктор по умолчанию - кричит "дай!"

[aspID]

Еще придется думать о переполнении

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

Про точность понима, а вот про скорость не понима... Что будет работать быстрее и почему?

[Николай Z]

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

Про точность понима, а вот про скорость не понима... Что будет работать быстрее и почему?

Отнюдь... У Вас там параметр x присутствует... Потому полностью при компиляции не сработает.
Если деление сначала - то это должно сработать при компиляции, а вот умножение при исполнении...
Если наоборот - первым умножение - то все будет работать только при исполнении - отсюда и разница в быстродействии... А переполнение возможно в зависимости от реализации целочисленной арифметики при умножении - я не знаю деталей вашего проца.

Сообщение отредактировал Николай Z - Jan 9 2008, 08:17

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

А вот насчет переполнения сам не уверен: компилятор при константе UL будет считать в 32-разрядных целых или в 64-разрядных?

UL - 32 разрядные. ULL - 64 разряда

Отнюдь... У Вас там параметр x присутствует... Потому полностью при компиляции не сработает.

Отнюдь. Если параметр x в точке использования макроса - константа, то IAR все выражение вычислит на этапе компиляции (а в приведенном в посте №1 коде там именно константа). Если переменная - то да, на этапе исполнения.

[aspID]

Отнюдь. Если параметр x в точке использования макроса - константа, то IAR все выражение вычислит на этапе компиляции (а в приведенном в посте №1 коде там именно константа). Если переменная - то да, на этапе исполнения.

Спасибо! Самый понравившийся ответ
Видимо, именно потому, что не подумал о возможности подстановки вместо x "неконстанты" я и не мог понять, почему так. На всяческий случай подправил "универсально" в своих макросах - чтобы сначала выполнялось деление.