Не отрабатывает #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 очень похоже, что не отрабатывает.

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


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

[Baser]

А что нужно - либо точность, либо скорость - думайте.

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

А вот действительно, наконец-то задумался и тоже не понял, что значит в данном примере СКОРОСТЬ.
Макрос то использует встроенную функцию ИАРа:

__delay_cycles(unsigned long int);
Makes the compiler generate code that takes the given amount of cycles to perform, that is it inserts a time delay that lasts the specified number of cycles.
Note: The specified value must be a constant integer expression and not an expression that is evaluated at runtime.

И если он будет генерить для одной и той-же или для близких по величине констант код, работающий сильно различное время, то это будет явный ляп ИАРа. А его не наблюдается
Так что может коллега zltigo имел в виду не скорость, а размер кода?

[zltigo]

Так что может коллега zltigo имел в виду не скорость, а размер кода?

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

Видимо, именно потому, что не подумал о возможности подстановки вместо x "неконстанты"...

Ну теперь знаете а то, что называется "сюрприз!" может случиться с задержкой.

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

а то, что называется "сюрприз!" может случиться с задержкой.

На этапе компиляции. Baser правильно заметил - аргументом __delay_cycles() может быть только константа, ибо компилятор для каждой конкретной задержки генерит подогнанный по тактам код. Для задержек в 2-4 такта вообще без цикла. Если использовать в качестве аргумента переменную - выдает ошибку на этапе компиляции. Исходя из этого можно посоветовать aspIDу поменять макросы назад - чтобы сначала выполнялось умножение и при прочих равных иметь бОльшую точность. А F_CPU объявить с индексом ULL - чтобы вычисления выполнялись в 64 битах и (при разумных задержках) не происходило переполнения.

[zltigo]

...аргументом __delay_cycles() может быть только константа

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

[Николай Z]

__delay_cycles() - это тяжелое наследие 8-ми разрядной архитектуры? Или что?

Я что-то перерыл все библиотеки в своем IAR-е 4.3 и вообще ее не обнаружил...

Что-то смутно помню подобное из архитектуры 8051... подобное... хотя всего год как бросил этот обломок совместимости...

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

[zltigo]

__delay_cycles() - это тяжелое наследие 8-ми разрядной архитектуры?

Естественно

[dxp]

Естественно

Еще это является с некоторых пор и "тяжелым наследием 16-разрядной архитектуры" - в том же EW430, например, с некоторых пор тоже существует такой интринсик.

Вообще, имхо, к архитектуре это отношения не имеет, местами вполне полезная фишка.

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

Вообще, имхо, к архитектуре это отношения не имеет, местами вполне полезная фишка.

Есть предложение считать правильной такую версию: эта функция реализована в компиляторах ИАРа для процессоров, у которых детерминировано время выполнения команд. Вот, например, у ARM7 время выполнения зависит от места исполнения (ОЗУ/флеш), от настроек ускорителя, у более старших (скорее всего) - от настроек кеша. Поэтому в EWARM такой функции нет.

Причем тут "тяжелое наследие"!?

Это у Николая стиль общения такой - "тяжелое наследие", "обломок совместимости". Не обращай внимания.

[Николай Z]

Есть предложение считать правильной такую версию: эта функция реализована в компиляторах ИАРа для процессоров, у которых детерминировано время выполнения команд. Вот, например, у ARM7 время выполнения зависит от места исполнения (ОЗУ/флеш), от настроек ускорителя, у более старших (скорее всего) - от настроек кеша. Поэтому в EWARM такой функции нет.

Понятно... А то я озадачился отсутствием этой функции в моих библиотеках... специально искал ее и не нашел...

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

Даже на 8051-м процессоре(поискал и нашел-таки в старых залежах) я постарался аналогичную функцию исключить из употребления и необходимые задержки предпочитал вставлять сам в виде 2-3 asm(" nop"); или соответствующих циклов.

Зачем? А вот как раз затем - что аналогичная функция в моем случае позволяла задать пераметром не только константное выражение. В результате - один из наших "сильно умных" практикантов написал кусок кода с операцией деления при рассчете этой задержки. Ну а деление в свою очередь - не имело аппаратной поддержки... Как результат - вот именно то о чем говорил zltigo - вместо задержки на фиксированное количество тактов - получалось черт знает что. Если точнее - функция-то задержку делала правильную, но ей предшествовало вычисление величины этой задержки, которое занимало в несколько раз большее время и это время сильно зависело от заданных значений.

Все свои программные задержки, где забываешь счетчик цикла объявить volatile, оптимизатор безжалостно выкидывает

Одно плохо: функция не стандартная.

Угу... А когда забудешь и влепишь выражение в параметр подобной функции - это лучше?
Я предпочитаю явное указание оптимизатору давать : "а не лезь сюда со своим интеллектом" - volatile это...
А насчет рассчитать величину задержки - а что тут такого суперсложного?

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

Это intrinsic function, описанная в EWAVR_CompilerReference.pdf и обьявленная в intrinsics.h

А у меня не EWAVR_CompilerReference.pdf , у меня EWARM_CompilerReference.pdf

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