#define F_CPU _delay_us(); _delay_ms();

[goodspeedmen]

У меня проблемы по отладке программы для mega328 в AVR Studio 4.
При отладке паузы могут длятся _delay_us(500); (максимум что я ждал 5 минут) я так понимаю что эти функции связаны с макроподстановкой константы частоты процессора #define F_CPU 16000000UL - 16 мегагерц.

_delay_us(); - я так понял что эта библиотека работает только с константами? (error: expects an integer constant.)

_delay_ms();

объясните кто использовал эти функции что к чему?
========
Target(s)...: Mega

#define F_CPU 80000000UL ??? 80 мегагерц. Нашёл в одно из проектов на http://chipenable.ru
========

[ARV]

Во-первых, никогда не надо указывать F_CPU внутри исходников. Этот макрос должен задаваться в makefile, или, если вы работаете с IDE типа Atmel Studio или AVR Studio, в настройках проекта. Еще раз: никогда внутри файла!!!
Во-вторых, _delay_us и _delau_ms - это макросы. и устроены они так, что правильно работают они только с константными значениями задержек. если передавать им в качестве параметра переменную, то результат работы будет некорректный. зато константы можно передавать типа float.
В остальном никаких проблем с ними нет.

[Demiurg]

[uquote="ARV",url="/forum/viewtopic.php?p=3237114#p3237114"]Во-первых, никогда не надо указывать F_CPU внутри исходников.[/uquote]
Поясните. Интересуют именно технические подробности.

[technik-1017]

>> Во-первых, никогда не надо указывать F_CPU внутри исходников

Тоже интересуют аргументы.
Для примера перенесите проект из одной среды в другую, например из Atmel Studio в IAR (да даже одной среды разных версий). Если значение F_CPU задано в исходниках я по крайней мере знаю о нём, а если в настройках проекта? Предлагаете установить Atmel Studio чтобы посмотреть параметры проекта. Или разбираться с с форматами данных Atmel Studio?

[ARV]

Поясните.

поясняю.
Никто никогда не запретит вам в проекте из трех файлов задать внутри каждого свою собственную директиву #define F_CPU. И так же никто не избавит вас от возможной ошибки

#define F_CPU 80000000UL ??? 80 мегагерц. Нашёл в одно из проектов на http://chipenable.ru

В итоге после компиляции вашего проекта вы получите некие чудеса в решете: в некоторых случаях _delay_ms(500) будет формировать задержку 0,5 секунд, а в некоторых 0,05 секунд.

когда же ни в одном файле у вас не будет этой директивы, а будет только в параметре компилятора -DF_CPU=8000000UL, то никакой ошибки никогда не возникнет: указанный в параметрах компилятора опцией -D макрос становится "видимым" при компиляции всех файлов автоматически, в итоге все модули собираются одинаково, и ведут себя единообразно.

технически это делается в makefile. но лично я так и не освоил сию премудрость, и пользуюсь возможностями IDE для задания этого...

[technik-1017]

[uquote="ARV",url="/forum/viewtopic.php?p=3237245#p3237245"]поясняю...[/uquote]
Предлагаете ВСЕ определения засовывать в настройки IDE, иначе это может привести к ошибкам? Или у вас есть избранные определения?

[Demiurg]

...

У меня порядок действий таков: в проекте всегда есть файл с основными параметрами. Глобальные объявления, переменные, общие функции. И дефайн F_CPU. Есть что-то пошло не так, то сам и виноват. В makefile залазить - это гуру надо быть, чтобы досконально знать, как его правильно править.
Но, у меня и этой проблемы уже давно нет. Практически не использую delay. У меня программные таймеры. Для мкс и мс задержек в основном самописные задержки. Крайне редко delay_us. Для IAR немного по другому.

[technik-1017]

[uquote="Demiurg",url="/forum/viewtopic.php?p=3237258#p3237258"]У меня порядок действий таков: в проекте всегда есть файл с основными параметрами[/uquote]
Поддерживаю

[ARV]

Предлагаете ВСЕ определения засовывать в настройки IDE, иначе это может привести к ошибкам?

нет, не все. но F_CPU - это как раз тот макрос, которому нечего делать внутри ваших исходников.

В makefile залазить - это гуру надо быть, чтобы досконально знать, как его правильно править.

именно поэтому я и не правлю makefile

Поддерживаю

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

лучше один раз привыкнуть делать правильно, чем постоянно объяснять, почему "так удобнее". ИМХО.

[Demiurg]

Проблема эта может быть с чужими проектами. У меня определение F_CPU всегда в одном файле, у которого всегда название main_def_func.h.

[technik-1017]

[uquote="ARV",url="/forum/viewtopic.php?p=3237288#p3237288"]и в каждом исходнике у вполне может оказаться еще одно определение этого макроса... вам оно надо[/uquote]не может

не убедили

[ARV]

не убедили

да и бог с вами! ваши проблемы меня не касаются.

[goodspeedmen]

[uquote="ARV",url="/forum/viewtopic.php?p=3237114#p3237114"]Во-первых, никогда не надо указывать F_CPU внутри исходников. Этот макрос должен задаваться в makefile, или, если вы работаете с IDE типа Atmel Studio или AVR Studio, в настройках проекта. Еще раз: никогда внутри файла!!!
Во-вторых, _delay_us и _delau_ms - это макросы. и устроены они так, что правильно работают они только с константными значениями задержек. если передавать им в качестве параметра переменную, то результат работы будет некорректный. зато константы можно передавать типа float.
В остальном никаких проблем с ними нет.[/uquote]

А паузу то по переменной чем делать? Спасибо.

[ARV]

А паузу то по переменной чем делать?

если очень хочется по переменной, то можно, например, так:

Код: Выделить всё

void delay_ms(uint16_t delay){
   for(; delay; delay--)
      _delay_ms(1);
}

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

[Ярослав555]

[uquote="ARV",url="/forum/viewtopic.php?p=3237114#p3237114"]Во-первых, никогда не надо указывать F_CPU внутри исходников. Этот макрос должен задаваться в makefile, или, если вы работаете с IDE типа Atmel Studio или AVR Studio, в настройках проекта. Еще раз: никогда внутри файла!!!
Во-вторых, _delay_us и _delau_ms - это макросы. и устроены они так, что правильно работают они только с константными значениями задержек. если передавать им в качестве параметра переменную, то результат работы будет некорректный. зато константы можно передавать типа float.
В остальном никаких проблем с ними нет.[/uquote]
я вот всегда в main.h его прописываю. никаких проблем.

[ARV]

я вот всегда в main.h его прописываю

а я вот никогда вообще ни в одном заголовочнике его не прописываю - вообще проблем нет!
у вас есть, пусть даже гипотетически, возможность где-то среди файлов проекта забыть добавить main.h и поиметь гемору... у меня такой возможности даже в теории нет.

[mazda]

ARV, можно указывать в заглавном файле, если вы его укажите лишний раз IDE вам покажет где оно повторилось.

Всегда его указываю в conf.h который инклюдится в заголовке компилируемого файла, и всё, никаких проблем, зачем людей пугаете?

[ARV]

можно указывать в заглавном файле

как говаривали в СА, "можно Машку за ляжку и козу на возу".
я ж разве говорю, что нельзя? я говорю "не нужно"

если у вас есть IDE, то в ней обязательно есть раздел "опции проекта", а в них обязаны быть настройки железа, в которых обязательно будет таковая частота. зачем делать одно и то же в разных местах?

если у вас нет IDE, то никто (кроме warning, да и то, не всегда) вам не покажет, где у вас лишнее определение макроса и тем более никто никогда не подскажет, где его не хватает для корректной работы. не раз встречал, например, такие участки "в библиотеках":

Код: Выделить всё

#ifndef F_CPU
#define F_CPU 8000000UL
#endif

ну и скажите мне, кто или что поможет вам в этом случае, если тактовая частота в проекте у вас задана в заголовочнике, а вот в этом самом файле он не подключен?

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

[mazda]

у меня не заголовок подключён, а наоборот, в нём все include после настроек, тоесть все подключённые библиотеки увидят настройки из заголовков, нет там никаких вариантов не увидеть.

Может кто то работает без IDE. Наверно есть и те кто работает не только без IDE но и без компьютера.

[ARV]

у меня не заголовок подключён, а наоборот, в нём все include

применение заголовочников призвано в какой-то мере устранить проблему глобальной видимости объектов в Си. когда вы ВСЕ ЗАГОЛОВОЧНИКИ включаете во ВСЕ ИСХОДНИКИ, вы тем самым отказываетесь от, пусть и не лучшего, но хоть какого-то, решения проблемы.

нормальная практика - это когда в сишном исходнике подключены только НЕОБХОДИМЫЕ ЭТОМУ модулю заголовки. поэтому в вашем случае правильнее было бы в КАЖДЫЙ исходник включать заголовок config.h... о том, чем это не комильфо - я уже говорил.

я снова повторю: каждый вправе сам выбирать себе грабли на пути. я стремлюсь выбирать путь без граблей.