У меня проблемы по отладке программы для 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 ========
Во-первых, никогда не надо указывать F_CPU внутри исходников. Этот макрос должен задаваться в makefile, или, если вы работаете с IDE типа Atmel Studio или AVR Studio, в настройках проекта. Еще раз: никогда внутри файла!!! Во-вторых, _delay_us и _delau_ms - это макросы. и устроены они так, что правильно работают они только с константными значениями задержек. если передавать им в качестве параметра переменную, то результат работы будет некорректный. зато константы можно передавать типа float. В остальном никаких проблем с ними нет.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
>> Во-первых, никогда не надо указывать F_CPU внутри исходников
Тоже интересуют аргументы. Для примера перенесите проект из одной среды в другую, например из Atmel Studio в IAR (да даже одной среды разных версий). Если значение F_CPU задано в исходниках я по крайней мере знаю о нём, а если в настройках проекта? Предлагаете установить Atmel Studio чтобы посмотреть параметры проекта. Или разбираться с с форматами данных Atmel Studio?
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
поясняю. Никто никогда не запретит вам в проекте из трех файлов задать внутри каждого свою собственную директиву #define F_CPU. И так же никто не избавит вас от возможной ошибки
goodspeedmen писал(а):
#define F_CPU 80000000UL ??? 80 мегагерц. Нашёл в одно из проектов на http://chipenable.ru
В итоге после компиляции вашего проекта вы получите некие чудеса в решете: в некоторых случаях _delay_ms(500) будет формировать задержку 0,5 секунд, а в некоторых 0,05 секунд.
когда же ни в одном файле у вас не будет этой директивы, а будет только в параметре компилятора -DF_CPU=8000000UL, то никакой ошибки никогда не возникнет: указанный в параметрах компилятора опцией -D макрос становится "видимым" при компиляции всех файлов автоматически, в итоге все модули собираются одинаково, и ведут себя единообразно.
технически это делается в makefile. но лично я так и не освоил сию премудрость, и пользуюсь возможностями IDE для задания этого...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
У меня порядок действий таков: в проекте всегда есть файл с основными параметрами. Глобальные объявления, переменные, общие функции. И дефайн F_CPU. Есть что-то пошло не так, то сам и виноват. В makefile залазить - это гуру надо быть, чтобы досконально знать, как его правильно править. Но, у меня и этой проблемы уже давно нет. Практически не использую delay. У меня программные таймеры. Для мкс и мс задержек в основном самописные задержки. Крайне редко delay_us. Для IAR немного по другому.
Предлагаете ВСЕ определения засовывать в настройки IDE, иначе это может привести к ошибкам?
нет, не все. но F_CPU - это как раз тот макрос, которому нечего делать внутри ваших исходников.
Demiurg писал(а):
В makefile залазить - это гуру надо быть, чтобы досконально знать, как его правильно править.
именно поэтому я и не правлю makefile
technik-1017 писал(а):
Поддерживаю
ну а теперь смотрите на финт ушами: у вас есть глобальный заголовочник, который вы включаете в каждый исходник... и в каждом исходнике у вполне может оказаться еще одно определение этого макроса... вам оно надо - выискивать все эти упоминания? хорошо, когда вы смотрите на варнинги компилятора (он обычно недоволен, когда макрос переопределяется без #undef), но проект собирается без ошибок в любом случае...
лучше один раз привыкнуть делать правильно, чем постоянно объяснять, почему "так удобнее". ИМХО.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Во-первых, никогда не надо указывать F_CPU внутри исходников. Этот макрос должен задаваться в makefile, или, если вы работаете с IDE типа Atmel Studio или AVR Studio, в настройках проекта. Еще раз: никогда внутри файла!!! Во-вторых, _delay_us и _delau_ms - это макросы. и устроены они так, что правильно работают они только с константными значениями задержек. если передавать им в качестве параметра переменную, то результат работы будет некорректный. зато константы можно передавать типа float. В остальном никаких проблем с ними нет.
но вообще говоря, функции программной задержки должны использоваться для коротких и фиксированных задержек, например, при подавлении дребезга или при формировании коротких импульсов управления внешней периферией. а интервалы времени разной длительности лучше отрабатывать таймерами.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Во-первых, никогда не надо указывать F_CPU внутри исходников. Этот макрос должен задаваться в makefile, или, если вы работаете с IDE типа Atmel Studio или AVR Studio, в настройках проекта. Еще раз: никогда внутри файла!!! Во-вторых, _delay_us и _delau_ms - это макросы. и устроены они так, что правильно работают они только с константными значениями задержек. если передавать им в качестве параметра переменную, то результат работы будет некорректный. зато константы можно передавать типа float. В остальном никаких проблем с ними нет.
я вот всегда в main.h его прописываю. никаких проблем.
а я вот никогда вообще ни в одном заголовочнике его не прописываю - вообще проблем нет! у вас есть, пусть даже гипотетически, возможность где-то среди файлов проекта забыть добавить main.h и поиметь гемору... у меня такой возможности даже в теории нет.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
как говаривали в СА, "можно Машку за ляжку и козу на возу". я ж разве говорю, что нельзя? я говорю "не нужно"
если у вас есть IDE, то в ней обязательно есть раздел "опции проекта", а в них обязаны быть настройки железа, в которых обязательно будет таковая частота. зачем делать одно и то же в разных местах?
если у вас нет IDE, то никто (кроме warning, да и то, не всегда) вам не покажет, где у вас лишнее определение макроса и тем более никто никогда не подскажет, где его не хватает для корректной работы. не раз встречал, например, такие участки "в библиотеках":
Код:
#ifndef F_CPU #define F_CPU 8000000UL #endif
ну и скажите мне, кто или что поможет вам в этом случае, если тактовая частота в проекте у вас задана в заголовочнике, а вот в этом самом файле он не подключен?
хотя, чего это я вас убеждаю делать меньше ошибок? да делайте, мне без разницы! если я кому-то даю советы - это лично моё мнение, каждый сам вправе выбирать путь собственных граблей. а я же советую только избежать те, на которые я сам не раз наступал, пока не нащупал верную тропинку... вот про неё и говорю - не пугаю никого
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
у меня не заголовок подключён, а наоборот, в нём все include после настроек, тоесть все подключённые библиотеки увидят настройки из заголовков, нет там никаких вариантов не увидеть.
Может кто то работает без IDE. Наверно есть и те кто работает не только без IDE но и без компьютера.
_________________ я его в гугл на дрц прогнал, вы знаете, пи-када нет.
у меня не заголовок подключён, а наоборот, в нём все include
применение заголовочников призвано в какой-то мере устранить проблему глобальной видимости объектов в Си. когда вы ВСЕ ЗАГОЛОВОЧНИКИ включаете во ВСЕ ИСХОДНИКИ, вы тем самым отказываетесь от, пусть и не лучшего, но хоть какого-то, решения проблемы.
нормальная практика - это когда в сишном исходнике подключены только НЕОБХОДИМЫЕ ЭТОМУ модулю заголовки. поэтому в вашем случае правильнее было бы в КАЖДЫЙ исходник включать заголовок config.h... о том, чем это не комильфо - я уже говорил.
я снова повторю: каждый вправе сам выбирать себе грабли на пути. я стремлюсь выбирать путь без граблей.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Сейчас этот форум просматривают: Starichok51 и гости: 42
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения