Скажем, простая ситуация. Следящая схема, в которой МК, например, раз в секунду по прерыванию таймера вырабатывает управляющий сигнал. А в перерывах МК выполняет какую-нибудь программу, где необходима задержка, скажем, на 10 мсек.
Программа управления следящей схемой «заняла» таймер, а во время задержки 10 мсек МК ничего не делает, только ждёт окончания задержки.

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


А если при этом в основном цикле требуется быстрая реакции на события, использование "тупых" задержек тоже вполне допустимо. Только надо использовать задержки с «флагом».
В такой задержке в каждом цикле проверяется флаг, если он установлен — быстрый выход из задержки. На этот случай указал выше прерывание прерывает задержку.
В задержке с флагом время считается, конечно, по другой формуле.
Вообще задержки с циклами – одни из базовых элементов. Просты, удобны, широкий диапазон, простота применения, время легко рассчитывается по готовым формулам. На мой взгляд, должны быть у каждого работающего с МК.

Налицо ошибка проектирования. Ведь никто не мешал таймером всегда считать промежутки по 1мс, обеспечивая каждые тысячу отсчетов (раз в секунду) обработку управляющего сигнала. Зато любой процесс в МК имел бы возможность выполнить паузу любой продолжительностью, кратной 1мс.
Вы бы попробовали на ПК попрограммировать. Там вообще один таймер на весь userspace. Под DOS на IBM XT 4.77МГц RTC шуровал на 10КГц (100мкс). Сейчас частоты, конечно выросли. И ничего, все получается и все работает.


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


Очень упрощенный подход. Кольцевой буфер сообщений гибче и надежней.


Вот именно про это я и говорю! Что точную задержку циклом Вы сделаете только ценой монополии на CPU, что ни в какие ворота не лезет.

опять сферических коней выпасаете?

опять примеры из "больших" задач и программ в разделе про AVR?

вы попробуйте кольцевой буфер сделать на 512 байтах ОЗУ - а это еще много для AVR! и потом поглядим, хорошо ли это будет... сколько раз я ни пробовал делать так, ни разу ничего, кроме геморроя не выигрывал. без кольца получалось в разы проще и понятнее. а чаще всего вообще без буферов обходился.

часто ли в программе для МК требуется точно задержки выдерживать? я только 1-wire могу в пример привести, а остальное решается на задержках плюс-минус лапоть. даже прием RC5-кодов ДУ я делал на программных задержках, и, кстати, не только RC5 даже без кварца на встроенном RC-генераторе тиньки13...

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

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

ошибка или нет - не скажу, но важность проектирования подчеркну. 7 раз подумай - 1 раз напиши. потом подумай еще 1 раз, и 7 раз перепиши написанное

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

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

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Вы без оскорблений умеете? Или Вы считаете что начинать любую дискуссию надо заранее признав собственную неправоту и неспособность общаться без перехода на личности?


Сейчас на STM8S у меня кольцевой буфер всего 16 байт + 1 байт на два четырехбитных смещения в нем. Так что я превзошел Вас уже в 30 раз
Вмещает от 16 до 5 событий. Первые три бита сообщения - длина его в байтах. Следующие 5 код сообщения. Дальше от 0 до 2 байт - аттрибуты, зависящие от кода сообщения.
События от двух таймеров, от прерывания порта ИК и прерываний UART.


Да вот, вроде бы простеший контроллер двух RGB лент с управлением с ИК пульта, а уже целая куча:
1. Два вида задержек при приеме по ИК
2. Два вида задержек для сигнализации светом о приеме команд с МК.
3. Целая система задержек для выполнения программы, меняющей яркость светодиодов.

Так как два таймера STM8 заняты шестью каналами ШИМирования, задержки, длительностью меньше нескольких десятков миллисекунд сделаны на третьем, самом примитивном. ШИМ на 500Гц, так что, заодно и кратные 2мс задержки с него же.


Где я хоть слово написал про опрос? Основная программа по жизни сидит в WFI (Wait for Interrupt) ожидая события. Так что отзовется она совершенно синхронно сразу после завершения обработчика прерывания.


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

P.S. Изивиняюсь, что не про AVR, но я его временно забросил.

ПК != RTOS. Учитывая вытесняющую многозадачность, гарантировать точность временных интервалов в общем случае нельзя. Ну и вы правильно сказали про рост частот - именно огромный запас производительности позволяет выдерживать интервалы с приемлемой точностью. На МК такой роскоши нет.
Пробовал делать кольцевой буфер для UART'а с размером, кратным 2 и задаваемым define'ом. Остановился на 32 байтах вроде, больше не нужно. Особых проблем на было. В чем подвох?
Тем не менее, vusb вполне себе существует. Там период входного сигнала 4 такта контроллера вроде, и ничего, справляется.
Смею надеяться, вы не уподобляетесь некоторым ардуинщикам, лепящим "тупые" задержки везде и всюду, а представляете, когда событие можно повесить на таймер или флаг. Если так, не прибедняйтесь

В данном контексте нельзя сравнивать стм8 и АВР. Для СТМ в большинстве случаев задержки на цикле вообще не нужны. На АВР так не получится.

даже и не знаю... вдруг разочарую?
дело в том, что тупая задержка - далеко не так тупа, как кажется.
вот привожу простой пример: ИК-дистанционное управление. погуглите - практически все используют стандартный подход: прерывания или режим захвата таймера с отработкой автомата состояний в прерывании. оно-то, конечно, в основном цикле время не тратится, но стоит ли оно того? почти во всех приходящих мне на ум случаях такой "асинхронный" подход не требуется вообще. и я взял и написал функцию, которая на тупых задержках тупо принимает коды ДУ с любых пультов. без конечных автоматов - строго линейно: ждем, анализируем, снова ждем... и не вижу причин применять прерывания.

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

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

ладно, это пустяки.

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

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


Еще как мешало! В DOS никогда не использовал scanf(), только sscanf() из строки или fscanf() из файла. Клавиатура - только по сканкодам. Зато можно было и нормальное редактирование пользователю обеспечить и подсказки и после каждой нажатой клавиши что-то менять на экране, если необходимо.
Если интересно, погуглите древнюю библиотеку TCXL. Очень много на ней наваял, впрочем, половину библиотеки, в итоге, под себя переписав.


Опять упрощаете. А если раз в секунду, когда одновременно случаются три подряд асинхронных события программа не успевает, а в остальное время успевает?
А если события требуют совершенно разное время на обработку? Например, по UART приходит текстовая команда. Принять очередной байт команды - быстро. А выполнить всю команду - долго.

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

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

не усложняйте

Это еще с какого перепугу? Под DOS я полно Real-Time приложений писал при тактовой 4.77МГц. Потом на QNX. Ряд, вроде бы явно задач реального времени (управление оборудованием), успешно решал на 386-ой под OS/2. А последнее Real-Time приложение писал для ПК с четырьмя Opteron-ами, кстати, тоже под QNX.

Или Вы перепутали ПК с Windows?

Добавлено after 12 minutes 33 seconds:

Я ровно это и написал - у Вас




Вот и пропустили другое событие. Например, прерывание по GPIO.

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

устройство принимает команды с vusb и передает на UART, причем одна принятая команда может развернуться в десяток байтна выход. Реализовать кольцевой буфер все-таки проще, чем дожидаться опустошения линейного или, тем более, ручной сдвиг.
я не путал ПК с DOSом x86 заточен под многозадачность, в отличие от AVR.

Я так не думаю. Примитивная поддержка мультизадачности появилась только на 386. Полноценная - существенно позднее. Реально мультизадачными x86 стали только с появлением Intel-VT и AMD-V, давшие операционной системе средства для контроля над любым устройством ввода-вывода (IOMMU).
Уверенно могу сказать, что, несмотря на 8-битность, в задачах реального времени AVR способен на большее, чем 8088, с которым я первым столкнулся на ПК. Не забывайте, что если у AVR машинный цикл равен 1 такту, то для 8088 машинный цикл был 5 тактов. А из-за восьмибитной шины одна команда у него выполнялась, в среднем, за три машинных цикла. То есть, если AVR на 16МГц способен перемолоть порядка 10 миллионов команд в секунду, то 8088 на своих 4.77МГц - только чуть более 300 тысяч. То есть, AVR быстрее его в 30 раз!
Даже если взять 32-х битный 386-ой с машинным циклом равным трем тактам и, не менее, чем по 1 машинному циклу на команду, на 33MГц, то и осиливал он не более 10 миллионов команд в секунду. Точно как AVR!

Ну и, в дополнение ко всему, FreeRTOS для AVR есть. Если хочется - демка у них для ATMega323

И тем не менее, ПК на Меге мир так и не увидел.

смотря что считать ПК клон спектрума увидел.
бездоказательный тезис. проще или нет - технология сравнения простоты пока не существует, все субъективно. если вы будете разворачивать слишком долго, то буфер любого размера у вас переполнится. даже кольцевой и даже сферический если будете делать быстро, то выигрыш кольца перед линией вряд ли можно заметить.
у меня ничего не мерцает при приеме команд с ДУ. у вас мерцает. кто не сумел сделать хорошо? конечно я, потому что у меня тупые задержки в коде. а вы слишком умны, чтобы применять тупое - у вас мигать начинает, сигнализирует, что тупо.
не смешите. вы привыкли на время обработки команды из UART запрещать ВСЕ прерывания?
а разве я спорил? только для этого буфер вообще и кольцевой в частности не является необходимым условием.

Я уже не однократно просил, не лгите. Приводите цитаты моих слов, а не вкладывайте свои слова в мои уста.


Опять? Приводите цитаты моих слов, а не вкладывайте свои слова в мои уста.
Я призывал к обратному:



Когда же вы читать научитесь?


Добавлено after 9 minutes 32 seconds:

Зачем Вы опять подменяете понятия, пытаясь превратить эту дискуссию в флейм демагогией?
Я про необходимость или необходимость не говорил вообще ни слова. У остальных участников этого слова тоже не видел.
Утверждалось две вещи:
1. Я кольцевой буфер использую в своих проектах
2. В случае необходимости обработки трех и более асинхронных событий, кольцевой буфер является одним из вариантов решения, причем достаточно эффективным.

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

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

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

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

Писал переходник vusb -> e24 (4-канальный 24-битный АЦП). Устройство примечательно тем, что данные выдает не по запросу, а непрерывно спамит в UART. Для настройки чувствительности, частоты преобразования и прочего нужно как минимум 1-3 байта на каждую настройку. А одна принятая с usb команда (в собственном формате) может развернуться и в десяток байт. Так что хоть какой-то буфер нужен.
Достаточно считывать-писать по индексу массива. А если массив является степенью двойки (идеально - 255 байт), закольцовка осуществляется AND'ом по маске. Например, для 31 байта index &= (1<<5)-1; Потери скорости, конечно будут, но небольшие. Если хотите, могу выложить свою версию кольцевых буферов для UART'а.