Ср дек 21, 2016 19:46:09
ptr128 писал(а):AQ29 писал(а):Таймер может быть занят другими подпрограммами.
Если МК во время задержки ничего не делает, лучше сделать задержку на цикле.
Таймер не может быть "занят подпрограммой", особенно если МК при этом "ничего не делает".
ptr128 писал(а):А с точки зрения написания прерывания таймера, никто не запрещает в этом прерывании, например, считать время в какой-то переменной и в каких-то попугаях. А во всем остальном коде, использовать это время для длительных задержек.
По крайней мере, Вы сможете действительно тогда измерять промежутки времени относительно точно, а не как в цикле, плюс минус лапоть, не зная, сколько времени ушло на обработку прерываний во время выполнения Вашего цикла.
COKPOWEHEU писал(а):Если при этом в основном цикле не требуется быстрой реакции на события, использование "тупых" задержек вполне допустимо.
Ср дек 21, 2016 20:19:18
AQ29 писал(а):Следящая схема, в которой МК, например, раз в секунду по прерыванию таймера вырабатывает управляющий сигнал. А в перерывах МК выполняет какую-нибудь программу, где необходима задержка, скажем, на 10 мсек.
AQ29 писал(а):Для себя считаю выполнение сложных действий в прерывании нехорошим методом программирования.
AQ29 писал(а):В большинстве случаев в программе обработки прерывания только устанавливаю программный флаг.
AQ29 писал(а):Для точной задержки прерывание можно запретить, тогда задержка с циклами будет выполняться с точностью до одного такта.
Ср дек 21, 2016 20:49:12
ошибка или нет - не скажу, но важность проектирования подчеркну. 7 раз подумай - 1 раз напиши. потом подумай еще 1 раз, и 7 раз перепиши написанноеptr128 писал(а):Налицо ошибка проектирования
Ср дек 21, 2016 21:06:00
Ср дек 21, 2016 21:09:20
мне, конечно, лестно... но справедливость требует уточнить: вы меня верно поняли? дело в том, что лично я 80% своих проектов делаю на задержках из циклов ну, не самописных циклов, конечно, а "библиотечных", что сути не меняет.scorpi_0n писал(а):Соглашусь с АРВ
Ср дек 21, 2016 21:24:08
ARV писал(а):опять сферических коней выпасаете?
ARV писал(а):вы попробуйте кольцевой буфер сделать на 512 байтах ОЗУ
ARV писал(а):часто ли в программе для МК требуется точно задержки выдерживать?
ARV писал(а):точно ли отработает задержка по таймеру, если флаг по таймеру опрашиваться будет с неизвестным периодом?
ARV писал(а):зачем придумывать себе сложные, зато "универсальные" решения на все случаи жизни?
Ср дек 21, 2016 21:28:17
ПК != RTOS. Учитывая вытесняющую многозадачность, гарантировать точность временных интервалов в общем случае нельзя. Ну и вы правильно сказали про рост частот - именно огромный запас производительности позволяет выдерживать интервалы с приемлемой точностью. На МК такой роскоши нет.Вы бы попробовали на ПК попрограммировать. Там вообще один таймер на весь userspace. Под DOS на IBM XT 4.77МГц RTC шуровал на 10КГц (100мкс). Сейчас частоты, конечно выросли. И ничего, все получается и все работает.
Пробовал делать кольцевой буфер для UART'а с размером, кратным 2 и задаваемым define'ом. Остановился на 32 байтах вроде, больше не нужно. Особых проблем на было. В чем подвох?вы попробуйте кольцевой буфер сделать на 512 байтах ОЗУ - а это еще много для AVR! и потом поглядим, хорошо ли это будет... сколько раз я ни пробовал делать так, ни разу ничего, кроме геморроя не выигрывал. без кольца получалось в разы проще и понятнее. а чаще всего вообще без буферов обходился.
Тем не менее, vusb вполне себе существует. Там период входного сигнала 4 такта контроллера вроде, и ничего, справляется.Если нужны мгновенные реакции на внешние события или задержки с точностью до такта, то АВР действительно не та платформа.
Смею надеяться, вы не уподобляетесь некоторым ардуинщикам, лепящим "тупые" задержки везде и всюду, а представляете, когда событие можно повесить на таймер или флаг. Если так, не прибедняйтесьдело в том, что лично я 80% своих проектов делаю на задержках из циклов ну, не самописных циклов, конечно, а "библиотечных", что сути не меняет.
Ср дек 21, 2016 21:40:35
Ср дек 21, 2016 21:43:17
даже и не знаю... вдруг разочарую?COKPOWEHEU писал(а):Смею надеяться, вы не уподобляетесь некоторым ардуинщикам, лепящим "тупые" задержки везде и всюду, а представляете, когда событие можно повесить на таймер или флаг.
подвох в том, что если ваша программа не успевает извлекать данные из буфера быстрее, чем он наполняется, ваш кольцевой буфер не решает никаких проблем в принципе. а если успевает - то кольцевой буфер не требуется, достаточно линейного, который реализуется проще в разы. а еще подвох в том, что опять-таки, буфер не так уж и необходим, если тупое ожидание символа (в общем случае - события, хотя я сейчас только об UART) не является для вас проблемой тем более что по большому счету все к ожиданию и сводится - вы же ждете, пока установится какой-то флаг наличия в буфере данных/событий? вот и выходит, что буфер - лишняя субстанция (не всегда, но довольно часто - по моей оценке)COKPOWEHEU писал(а):В чем подвох?
Ср дек 21, 2016 22:11:55
ARV писал(а):вот привожу простой пример: ИК-дистанционное управление. почти во всех приходящих мне на ум случаях такой "асинхронный" подход не требуется вообще. и я взял и написал функцию, которая на тупых задержках тупо принимает коды ДУ с любых пультов.
ARV писал(а):берем "эталон" - командная строка какого-нибудь терминала (ох, не в свою стихию лезу...) я не поручусь головой, но изначально она работала исключительно на scanf - функции, которая получила управление и тупо ждет, пока не получит поток ввода по своему формату. тупо ждет. ждет, не возвращая управления. и ведь это никому не мешало!
ARV писал(а):а если успевает - то кольцевой буфер не требуется
Ср дек 21, 2016 22:22:30
налицо ошибки в проектированииptr128 писал(а):При нажатии любой кнопки на пульте, цвета в светодиодной ленте замирают (перестают меняться по программе) на время приема. На глаз видно
а вы усложняете. я и не говорю, что всегда буфер лишний. я говорю - в большинстве любительских проектов. большинство начинается с 51 процента, если вы вдруг не в курсеptr128 писал(а):Опять упрощаете.
Ср дек 21, 2016 23:06:55
COKPOWEHEU писал(а):ПК != RTOS.Вы бы попробовали на ПК попрограммировать. Там вообще один таймер на весь userspace. Под DOS на IBM XT 4.77МГц RTC шуровал на 10КГц (100мкс). Сейчас частоты, конечно выросли. И ничего, все получается и все работает.
ARV писал(а):вот привожу простой пример: ИК-дистанционное управление. почти во всех приходящих мне на ум случаях такой "асинхронный" подход не требуется вообще. и я взял и написал функцию, которая на тупых задержках тупо принимает коды ДУ с любых пультов.ptr128 писал(а):Пробовал. Некрасиво получается. При нажатии любой кнопки на пульте, цвета в светодиодной ленте замирают (перестают меняться по программе) на время приема. На глаз видно (
налицо ошибки в проектировании
ARV писал(а):но приведите пример из реальной жизни, когда вдруг текстовые строки приходят в устройство так часто, что команда не успевает отработать?
ptr128 писал(а):Например, по UART приходит текстовая команда. Принять очередной байт команды - быстро. А выполнить всю команду - долго.
ARV писал(а):глюпый юзер шлет команду
Ср дек 21, 2016 23:36:04
устройство принимает команды с vusb и передает на UART, причем одна принятая команда может развернуться в десяток байтна выход. Реализовать кольцевой буфер все-таки проще, чем дожидаться опустошения линейного или, тем более, ручной сдвиг.подвох в том, что если ваша программа не успевает извлекать данные из буфера быстрее, чем он наполняется, ваш кольцевой буфер не решает никаких проблем в принципе. а если успевает - то кольцевой буфер не требуется, достаточно линейного, который реализуется проще в разы.
я не путал ПК с DOSом x86 заточен под многозадачность, в отличие от AVR.Или Вы перепутали ПК с Windows?
Чт дек 22, 2016 00:38:16
COKPOWEHEU писал(а):x86 заточен под многозадачность, в отличие от AVR.
Чт дек 22, 2016 06:35:55
Чт дек 22, 2016 06:58:27
смотря что считать ПК клон спектрума увидел.scorpi_0n писал(а):И тем не менее, ПК на Меге мир так и не увидел
бездоказательный тезис. проще или нет - технология сравнения простоты пока не существует, все субъективно. если вы будете разворачивать слишком долго, то буфер любого размера у вас переполнится. даже кольцевой и даже сферический если будете делать быстро, то выигрыш кольца перед линией вряд ли можно заметить.COKPOWEHEU писал(а):устройство принимает команды с vusb и передает на UART, причем одна принятая команда может развернуться в десяток байтна выход. Реализовать кольцевой буфер все-таки проще, чем дожидаться опустошения линейного или, тем более, ручной сдвиг.
у меня ничего не мерцает при приеме команд с ДУ. у вас мерцает. кто не сумел сделать хорошо? конечно я, потому что у меня тупые задержки в коде. а вы слишком умны, чтобы применять тупое - у вас мигать начинает, сигнализирует, что тупо.ptr128 писал(а):Я ровно это и написал - у Вас
не смешите. вы привыкли на время обработки команды из UART запрещать ВСЕ прерывания?ptr128 писал(а):Вот и пропустили другое событие. Например, прерывание по GPIO.
а разве я спорил? только для этого буфер вообще и кольцевой в частности не является необходимым условием.ptr128 писал(а):И даже в этом случае, хорошо написанная программа, сообщит юзеру, что его команду обработать не смогла.
Чт дек 22, 2016 12:47:49
ARV писал(а): у вас мерцает. кто не сумел сделать хорошо?
ARV писал(а):не смешите. вы привыкли на время обработки команды из UART запрещать ВСЕ прерывания?ptr128 писал(а):Вот и пропустили другое событие. Например, прерывание по GPIO.
ptr128 писал(а):Прерывание должно быстро отработать событие, поместить в кольцевой буфер, убедившись, что он не переполнен, сообщение фоновой прогамме, и мирно завершиться. А фоновая программа пусть уже в бесконечном цикле разгребает эту очередь сообщений, останавливая процессор, когда сообщений в кольцевом буфере нет.
ARV писал(а):а разве я спорил? только для этого буфер вообще и кольцевой в частности не является необходимым условием.ptr128 писал(а):И даже в этом случае, хорошо написанная программа, сообщит юзеру, что его команду обработать не смогла.
ptr128 писал(а):А если раз в секунду, когда одновременно случаются три подряд асинхронных события программа не успевает, а в остальное время успевает?
ARV писал(а):буфер вообще и кольцевой в частности не является необходимым условием.
Чт дек 22, 2016 17:44:48
Непонятно, зачем вы постоянно пытаетесь увести дискуссию в сторону. Если скорости передатчика не хватает, никакой буфер и никакие другие ухищрения не помогут, это и так очевидно.бездоказательный тезис. проще или нет - технология сравнения простоты пока не существует, все субъективно. если вы будете разворачивать слишком долго, то буфер любого размера у вас переполнится. даже кольцевой и даже сферический если будете делать быстро, то выигрыш кольца перед линией вряд ли можно заметить.
Чт дек 22, 2016 19:49:01
ничего интересного. дело в том, что я не сталкивался с задачами, когда новые данные приходят до того, как считаны предыдущие. а о сферических конях мне не интересно думать. повторяю: я пока что в 80% случаев обходился без кольцевого буфера, а в оставшихся 20% - и без буфера вообще. не повезло, наверное.COKPOWEHEU писал(а):Было бы интересно посмотреть на вашу версию решения. Учитывая, что новые данные могут прийти пока не считаны все старые.
Чт дек 22, 2016 21:31:43
Достаточно считывать-писать по индексу массива. А если массив является степенью двойки (идеально - 255 байт), закольцовка осуществляется AND'ом по маске. Например, для 31 байта index &= (1<<5)-1; Потери скорости, конечно будут, но небольшие. Если хотите, могу выложить свою версию кольцевых буферов для UART'а.сама идея кольца лично мне не очень нравится по той причине, что считывание/запись из/в него не может осуществляться просто по указателю, обязательно требуются дополнительные вычисления для закольцовки. т.е. на каждом байте теряются такты на всякие проверки и т.п.