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



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



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

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

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


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

А как вы определяете, что не отрабатывает?
Примеры ваши учебные, должны работать. Я у себя проверил - работает

Не работать не может. Нет, конечно, если в огороде бузина а дядька в Киеве, то тогода будут проблемы...
Надо понимать, что
#define F_CPU 3686400UL
это не есть нечно вроде "глобальной переменной". Это просто простейшая подстановка препроцесора которая должна встретиться до ее использования именно в текущем файле или прямо описанная, или описанная в другом файле, но включенном в текуший через #include.

P.S.
Писать в стиле "#<пробелы>directive" не стоит, хоть это препроцессор и понимает.

Ну, хотя бы по "ругательствам"...
Или по тому, что если прописываю эти же дефайны в опциях, то работает "как хочу", а не "что это?!"

Если main.cpp начинается с


А в delay.h стоит

То это по-моему, за ошибку "раньше-позже" не проканывает - ряд должен "сходиться", а он "расходится"



Ага, понимает! учту замечание на будущее

Я понимаю, что Вы чего-то хотите, только из приведенных кусочков лично я не могу понять что Вы "хочу". Определения F_CPU в текстах нет в принципе. Соответственно имеет место "ругань", если, конечно не подсунуть определение препроцессору в командной строке через -DF_CPU, что Вы и делаете и что, естественно, работает.

Макросы КРАЙНЕ небрежны . Рихтуем:

Только о наносекундах речь не пойдет Надо выбирать:

Вы меня извините, но почему-то то, что говорит вам zltigo я прекрасно понимаю, а то что говорите вы, нет! Не могли бы вы понятней объяснить, что вы хотите получить и что у вас в результате получается.

p.s. Приведенные вами выдержки из файлов main.cpp и delay.h, расположенные друг за другом, в ИАРе не дают никаких "ругательств". А если убрать #define F_CPU, то исправно выдаются ваши warning-и

называется "почувствуй себя..." завтра(сегодня) попробую проект прицепить с работы


Ок, учтем-с, спасибо! Правда, пока не понял глубокой разницы :-/ Прошу пока не подсказывать


main.cpp строки 9-11 гласят

Или "оно" за директиву не канает уже?

Есть. Местами разительная.

Канает, но исключительно для одного файла main.cpp. Что-то мне подсказывает, что у Вас delay.h не в одном файле по #include включен.

Как для одного? Это же директива препроцессора, он ее должен обработать на начальном этапе... А до этой директивы никаких #include не обозначено...


А! Кажется, понял, что Вы имеете в виду. Тогда полез изучать документацию на предмет порядка обработки файлов компилятором... Я почему-то считал, что тот, в котором main() будет обработан первым

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

Практическая рекомендация к теоретическим объяснениям zltigo:
Я обычно делаю хедер файл, в котором описываю все глобальные для всего проекта define, описания регистровых флагов (если они используются), extern-ы глобальных переменных и функций, называя его, например defines.h

Далее этот файл добавляется через #include "defines.h" ВО ВСЕ другие файлы проекта, где встречаются эти определения. Можно делать и вложенные #include "defines.h" в другие свои локальные хедер файлы, но я обычно для наглядности вложения не делаю, а описываю в файлах с кодом все входящие хедеры в явном виде.

текущего компилируемого (и включенных в него заголовочных) файла.

для aspID: ключевое словосочетание для поисков в книгах и гугле - "раздельная компиляция"

zltigo сказал:

Сергей Борщ возразил на это:

А я прочел и решил спросить - а в чем суть возражения? По-моему zltigo и как раз и говорил о текущем файле - т.е. как раз о компилируемом?

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

Пересмотрел и вышеозвученной "разительной" разницы не нашел. Разве что недостаток закрывающих скобок Я сдаюсь разъясните, пожалуйста, почему надо сначала делить, а потом умножать.


понЯл, отстал. Спасибо

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

Сергей, Вовсе даже нет! Просто этого оказалось достаточно. И спасибо было вполне отдушевное.

Неправильно поняли - я никого ловить не собирался. И противоречия в ответах я не наблюдаю.
Я только пытаюсь понять - а зачем это уточнение.
Я видите ли в том случае, если что-то не понял имею обыкновение переспросить.

Я конечно успел понять, что здесь (на этом форуме) большая часть участников как-то ревностно и неприязненно относятся к дополнительным вопросам, но не до такой же степени нужно их бояться... В данном случае - я просто решил, что возможно я чего-то не понял - вот отсюда и вопрос. И никаких наездов или попыток подловить...

Или задавать вопросы - это большой грех?

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

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

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

У вас в макросах все константы - целые числа. Поэтому и все промежуточные результаты будут целыми. Все дробные части отбрасываются. Для точности нужно сначала УМНОЖИТЬ, а потом ПОДЕЛИТЬ.

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

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

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

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

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

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

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




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

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

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

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

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

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

Естественно

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

Причем тут "тяжелое наследие"!? Это удобное расширение Си, реализованное в ИАРовских компиляторах в виде intrinsic function. Выше я уже приводил кусок хелпа, а Сергей Борщ кратко про нее рассказал.

Могу повториться: встретив эту функцию, компилятор заменяет её кодом минимальной длины (циклами), который выполняется заданное число тактов конкретного процессора. Большое преимущество этой фичи в том, что во-первых не нужно в ручную подбирать циклы, а во-вторых, этот кусок кода не трогает оптимизатор. Все свои программные задержки, где забываешь счетчик цикла объявить volatile, оптимизатор безжалостно выкидывает

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

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

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

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


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

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

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

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

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


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

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


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

Да ничего, но ее надо рассчитать. Для чего надо знать про оптимизацию. Или вставлять код на асме. А __delay_cycles(X) делает это автоматом, наиболее корректно и затем при чтении кода не возникает вопросов о том, что это такое.
Так что в ситуациях, когда нужны небольшие задержки - по моему, самое оно.
Насчет переносимости - она обычно используется где-то глубоко внизу, а при переносе на другую платформу "низ" обычно приходится так или иначе переписывать...




В данном случае компилятор не позволит использовать неконстантное выражение.

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

Ну а было бы - допустим - прозрачным, самоочевидным и ясным определение это функции - то и не было бы тут этого обсуждения. Кстати...

Вот по такому определению функции мне совершенно неясно - что параметр должен быть константным выражением (eго Baser привел и видимо оно в *.h и забито):
...
Значит это ограничение забито где-то еще... Ну а часто ли мы по каждому поводу лазаем по мануалам?
Вот и делайте выводы.

Чесно говоря я не могу придумать более самоочевидного и ясного определения:
__delay_cycles(k); - подождать k циклов (вставить k виртуальных NOPов).
А если параметр будет некорректным - компилятор ругнется. ПосмОтрите в хелп (один раз) и далее будете применять правильно. А посколько функция нестандартная, скорее перед ее применением посмотрите в хелп (также один раз).

А приведенный вами пример с задержкой для 8051 только подтверждает мои слова, там у вас компилятор не ругался, а что получилось?
Вот и делайте выводы.

Да ради бога - нравится используйте...

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

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

Вот вам еще один довод против вашего метода:
Даже если ваша функция задержки обложена volatile, __root и т.д., в ней напрочь отключена оптимизация, то где гарантия, что новая версия компилятора не станет по другому генерить код и все задержки поплывут!?

Гарантия в НЕИСПОЛЬЗОВАНИИ софтовых задержек . Заодно не будет удивления от отсутствия у других компиляторов и компиляторов для других платформ не сколь полезных, сколь провоцирующих функций задержек.

Интересно, а что вы можете предложить другое для коротких задержек. Таймеров у небольших МК мало и они как правило заняты под другие, более важные задачи.

А разве трудно сделать простейшую функцию опроса таймера? Кто сказал, что один таймер это мало?
Процесс простейший:
1) Узнать текущий отсчет таймера...
2) Посчитать требуемый...
3) Пока значение меньше требуемого - вертеть цикл с операций NOP...

Ну а если Вам нужна задержка на 1-2-3-5 тактов - обкладывайте это место volatil-ом сколько хотите и никакой оптимизатор туда не полезет... Особенно если там вставлен ассемблерный код прямо в C-шную функцию...

А для длинных задержек - не грех и семафоры устроить и ждать их(call-back или любой другой механизм)...

Ну а если Вы заглянете в коды FreeRTOS - для STR912 - то вообще обнаружите, что там весь тайминг построен вообще не на таймерах... А на сторожевом таймере - watchdog-е... Мне это было немного странно - при наличии целых 3-х таймеров и одном RTC, но вот так есть...

Согласен, можно и так

Дэк - классика это... К тому же - Вы сами сказали - для очень коротких - лучше на ASM написать функцию, которую никакой оптимизатор не тронет - C-шный... И сомнений не будет - относительно правильности-неправильности определения нестандартной функции... Индусы, которые их лепят - далеко не всегда думают о всех возможных последствиях опрел\деления функций подобных delay_cycle(n)...