- Очевидно, что без механизма ожидания -- получается полная ерунда, которая ничем не лучше биглупа. Когда
событий станет много (типов событий, происходить им не обязательно)
-- всё время только и будет уходить на такие циклы проверки, как и
в биглупе. Зачем тогда сущность с громким названием "операционка"? fk0(7411 знаков, 06.12.2020 14:41, ссылка, ссылка)
- Прототреды это биг-луп вывернутый наизнанку. Или наоборот. То же
самое, что конечные автоматы им. Шалыто, switch-технология. Удобней
представлять в виде big loop всё-таки. Идея в том, что какой-то
"протопоток", "автомат", отдал управление обратно циклу и он
побежал вызывать остальные "протопотоки" или автоматы... fk0(4542 знаков, 11.06.2020 19:54, ссылка, ссылка)
- >наподобии планировщика libevent lloyd(89 знаков, 11.06.2020 21:15)
- Не соглашусь. В случае оптимальной реализации автомата он входит в
состояние ожидания продолжения работы, и делает только это. Кроме
того, никто не заставляет по одному кругу крутить все автоматы. - VLLV(11.06.2020 20:37)
- В состоянии ожидания он постоянно проверяет некоторую переменную.
Если переменных много, когда параллельных/независимых автоматов
много -- эти проверки оказываются чрезмерно длительными. Вложенные
КА (в терминологии switch-технологии Шалыто) отчасти спасают
ситуацию, но в целом проблема остаётся: сильно параллельные задачи
методом big loop, switch-технологие, с помощью protothreads --
эффективно не решаются. При том, что с ними элементарно справится
планировщик типовой RTOS. - fk0(11.06.2020 20:45)
- Вызов вложенных автоматов можно организовать с разной частотой,
соответсвующей необходимой скорости обработки. Это исключит тупую
проверку. Да, сильно параллельные ДОЛГОВРЕМЕННЫЕ задачи сложно
реализовать методом биглуп, но я за свою жизнь с этим столкнулся
только в одном проекте из десятков. А ресурсы нужно делить в каждом
втором. - VLLV(11.06.2020 21:27)
- А зачем, блядь он ее проверяет?! Пусть не проверяет, пусть выберет десяток,
случайным образом, будет быстро. Мужики, так нельзя. Если технически возможно аппаратное выявление изменения состояния входов автомата (АКА
прерывание), то это можно использовать, а если нет - можно только
то, что можно. Cкpипaч(222 знаков, 11.06.2020 20:52)
- Выскажу ещё раз: FreeRTOS сырая недоделка, смысла особого, без реализации ряда перечисленного (см. ниже) не имеет и, хуже того, наоборот вносит существенные ограничения для программиста. Если бы стояла задача выбрать ОС для МК, то я бы скорей fk0(12815 знаков, 18.10.2019 02:15, ссылка)
- "В контексте МК" никаких задач не должно быть! :) Контроллер рассчитан на обслуживание периферии, а потому никаких других событий, помимо тех, что происходят на периферии, в его внутренней среде нет. А такие события, как правило, способны вызывать Ксения(2322 знаков, 20.09.2019 15:15)
- Смотря какая ОС. В основном ОС делятся по типу: бывают корпоративные ОС и любительские. fk0(13826 знаков, 20.03.2019 02:13)
- Обновлено: трехколесный вялошипет с квадратными колесами (многозадачка на Си). Рожалось в муках, труд всей жизни :) LightElf(1261 знаков, dao, полностью, 13.11.2015 16:08 - 16.11.2015 13:06)
- А что толку? Я там вижу дикие циклы по всем задачам с проверкой условий -- с чем боролись, на то и напоролись. Просто вывернули big loop наизнанку. Нужен планировщик с O(1) сложностью алгоритма. Чтоб если у тебя 100500 задач, то нужная выбиралась fk0(84 знаков, 17.11.2015 12:10)
- Спасибо, положу в загашник :-) Хотя для такой вещи функционал ИМХО избыточен. Достаточно ct_block со значением = 0, чтобы организовать "карусельку" (Если я все правильно понял). - il-2(16.11.2015 12:53)
- нечто похожее писал. но с динамическим списком "задач". - RED_DRAGON(13.11.2015 17:39)
- readme-шку бы ещё какую не плохо бы. Что, куда, зачем. С наскоку непонятно. А то, что рантайм память под задачи резервирует - хорошо. Dingo(166 знаков, 13.11.2015 17:32 - 17:36)
- Конечно интересно - Олдфаг(13.11.2015 16:34,
)
- под что? на каком си? - RED_DRAGON(13.11.2015 16:13)
- Кто-нибудь использует RTOS (не ядра) в своих проектах? Интересует их работа в защищённом режиме, взаимодействие пользовательского кода с периферией (как я понимаю, через вызов функций RTOS, ни один пользовательский код не должен обращаться VVB(1582 знаков, dao, полностью, 15.11.2014 22:29 - 22:40)
- Давно холиваров не было. Как насчёт RTOS vs Main Loop? Поделитесь практическим опытом. Сам RTOS не применял, да и не очень хочется. SciFi(559 знаков, dao, полностью, 24.07.2013 12:24)
- Некоторый вывод из холивара -> - Evgeny_CD(25.07.2013 22:47, ссылка)
- А использовал ли кто-нибудь кайловскую RTX RTOS для кортексов? Что скажете про неё в сравнении с другими RTOS? - бомж(25.07.2013 21:42)
- Не нужно использовать ртос. И тогда мой портфолио будет толще вашего :-) abivan(137 знаков, 25.07.2013 10:24)
- Для ST32 применяю и FreeRTOS и Round-Robin. А для AVR пробегалла соответствующая работенка, было интересно, но не нашел яровского порта под старшие модели. Нашел только для m32. Сам портировать на m1280 убоялся так как и времени не было, и не Юра(64 знаков, 25.07.2013 10:05,
)
- на CM3-TnKernel делаю DTMF-декодирование. Занимает 30% процессорного времени. + обеспечивается PCM-поток по SSP. Как это совместить на MainLoop даже не представляю (если только алгоритм DTMF дробить до 8 байт ). А в RTOS на SSP максимальный MegaJohn(50 знаков, 25.07.2013 01:37)
- Можно ли жить на Main Loop, если какая-то периферия требует долгих таймаутов при обмене? Например: Ксения(830 знаков, 24.07.2013 23:55)
- Берете библиотеку Protothreads и пишете как ни в чем не бывало. Скрипач(308 знаков, 25.07.2013 19:52 - 22:05, ссылка)
- Проблема пробок на автотрассе из-за того, что какие-то участники движения едут, как черепахи, решается не светофорами, а обеспечением возможности ОБГОНА! Поскольку перед черпахами дофига свободной дороги. Main loop подобна этой автотрассе - пробки Ксения(335 знаков, 25.07.2013 13:34 - 13:36)
- Есть такой трюк, как несколько лупов поменьше, в прерываниях таймеров с соответствующими приоритетами и вложениями. Одна беда - на AVR этот трюк не катит ;) - Vladimir Ljaschko(25.07.2013 16:42)
- Малая скорость это не помеха. Ехали бы 50 км/ч за пенсионером - уже хорошо. Помеха - нет разгонных полос при въездах(съездах) на магистрали. - Юра(25.07.2013 16:04,
)
- никогда вообще в своих программах не использовал задержек, и все таймауты прекрасно формируются - AVF(25.07.2013 14:24)
- На нашей автотрассе три дороги: ML и SysTick и другие аппаратные/программные прерывания. Все синхронные задачи надо обрабатывать в SysTick, все асинхронные в обработчике прерываний и/или отдельных потоках. Остальное гуано в Main Loop - Anvar(25.07.2013 13:43)
- Ну о чем и речь. Процедура вывода символов проверяет, истекло ли время ожидания. Если не истекло - сразу выход в Main Loop. Если истекло - выводим символ, выставляем новое значение таймаута и выходим опять же в Main Loop. - LightElf(25.07.2013 13:42)
- Здрасти! Пауза же не в конце процедуры стоит, а после КАЖДОГО выведенного на дисплей символа впадает в ожидание. Если я при первом же ожидании в Main loop вернусь, то следующие цифры никогда не будут прописаны. - Ксения(25.07.2013 15:19)
- Где-то у вас что-то не продумано. Koyodza мне подсказал этот способ. Создается буфер. Скажем, 20x4=80 байт. Пусть раз в 1 мс выводим посимвольно из буфера на дисплей. При 20x4 обновление всего экрана 84 мс. 80 символов, 4 адреса строк. Я мог бы mazur(175 знаков, 25.07.2013 16:03, ссылка)
- И вам не хворать :) LightElf(202 знаков, 25.07.2013 15:48 - 15:55)
- Можно и всю строку выводить, но тогда очиску FIFO можно поручить таймерному прерыванию, которое будет за один вызов писать один символ на экран. - Apтём(25.07.2013 19:46)
- А как быть, если в начале/конце строки есть дополнительная работа (например, на очистку экрана) с особо большой задержкой? Тогда таймирование подравнивать под эту большую задержку, чтобы было поровну, или ту большую задержку разбивать на много Ксения(17 знаков, 25.07.2013 19:11)
- Ну вот как-то примерно так. lcd_put просто складывает строку в буфер fifo. lcd_poll вызывается из main loop. LightElf(1581 знаков, 26.07.2013 13:29 - 13:44)
- Я начинаю понимать, что мне придется просто свой исходник привести, бо косноязычен зело и описать словами не могу. - LightElf(26.07.2013 12:17)
- Про какой дисплей вы говорите? Если взять ЖКИ на HD44780, то команда очистки 1,5 мс. Установили таймер, новое состояние автомата, новую точку входа прототреда, вышли. Делаете свои дела дальше. При следующей итерации проверка таймера. Время вышло? mazur(360 знаков, 25.07.2013 20:16 - 20:19, ссылка)
- Никакого тупика. Решение для обгона есть, но вы его упорно игнорируете -> - SciFi(25.07.2013 13:41, ссылка)
- Я пользую timer.c, честно выкушенный из стека uIP - неблокирующиеся софтверные таймеры. - LightElf(25.07.2013 13:16)
- элементарно (автомат состояний), но оно надо? сделайте один проект под ось, потом будете просто задачи добавлять/менять - AVF(25.07.2013 13:15)
- Странно это слышать от вас. Да запросто это сделать в программе Main Loop. Стараюсь писать свои программы без долгих зацикливаний. Потихоньку перетаскиваю этот принцип на си. К примеру ваш пример. С дисплеем. mazur(3447 знаков, 25.07.2013 05:55 - 06:23, ссылка)
- при нличии свободного счётчика - запросто. Д.ARMоед(478 знаков, 25.07.2013 01:31)
- Как вам таймаут в один год? :) - Скрипач(25.07.2013 00:36)
- Решение возможно: испльзуйте конечные автоматы (так кажется называлось), оно же - автоматное программирование. Apтём(227 знаков, 25.07.2013 00:08)
- Очевидно, вы не в курсе, что существует protothreads. Как и многие из нижеподписавшихся, впрочем. - SciFi(24.07.2013 23:57)
- посмотрите protothreads - Vit(24.07.2013 23:57)
- "Специалист подобен флюсу - полнота его одностороняя". Идеализм с полновытесняющей RTOS доступен только в толстых системах. Подход "без ОСи" достоин сжигания. Evgeny_CD(1332 знаков, 24.07.2013 22:16)
- Использую две крайности: Big-Loop и Linux. Впечатления. Скрипач(392 знаков, 24.07.2013 19:13)
- Кстати, в тему: по ссылке рассказано, как устроен стек в RTOS RTX166 Tiny. В двух словах: все потоки делят общее пространство стека, при переключении контекста стек активной задачи сдвигается, освобождая место для следующей. Креативненько! SciFi(123 знаков, 24.07.2013 16:38, ссылка)
- А чо тут холиварить. На небольших задачах и слабом железе ось нахер не надо и не лезет. А на больших задачах (слабое железо тут не канает автоматом) петля автоматически перерастет в ось. Остается определиться взять готовую или в муках рожать свою. Codavr(140 знаков, 24.07.2013 16:34)
- я не представлюю для себя программирования без ртос. К хорошему быстро привыкаешь. Использую ртос всегда и везде для задачи любой сложности. Кооперативка не требует много ресурсов. abivan(1488 знаков, 24.07.2013 14:38)
- Если надо проектом один программер работает, не используя никакого стороннего кода (а вероятность дальнейшей поддержки другим программером очень низка) - то пофигу. Alex B.(1397 знаков, 24.07.2013 14:26)
- Без RTOS в мигании светодиода на плате появляется заметный на глаз джиттер при более-менее заметной нагрузке другими задачами. - =AlexD=(24.07.2013 14:18)
- Все фигня, RTOS действительно нужна только в одном случае - когда нужно рвать выполнение из чужих пакетов. Например, файловой системы. При наличии навыков все отлично пишется рвано, еще и даром логичное разбиение на модули :) - Vladimir Ljaschko(24.07.2013 13:45)
- со своей колокольни: Mahagam(1257 знаков, 24.07.2013 12:56)
- времянка в вытесняющих RTOS-ах проще удовлетворяется, чужой код берется нахаляву - засунул в низкоприорететную задачу и все само само заработало (можно повторить N раз если есть таймслайсинг), в команде проще программить (и опять же времянку ыыыы(238 знаков, 24.07.2013 12:52)
- под RTOS программить легче. все остальное - от экономии на песке. - Snaky(24.07.2013 12:28)
- правильное использование RTOS - научите уму разуму MegaJohn(987 знаков, dao, полностью, 21.12.2011 13:48)
- Сначала определитесь, должна ли чувствовать Прикладная задача "не мгновенность" отправки СМС. Скрипач(192 знаков, 24.12.2011 19:14)
- Если у Вас получится приличный и, что самое главное, универсальный драйвер со своим потоком, который будет взаимодействовать с вполне конкретным GSM-модулем, да еще если все вызовы RTOS для этого драйвера будут по минимуму обернуты Вашими Alexandr(251 знаков, 23.12.2011 23:00,
)
- Кроме того 99% функций не поддерживают рекурсивное использование.Так-что все еще хуже. - PlainUser(22.12.2011 10:28)
- +1: Если не нужно гарантированное время реакции на событие, не нужно RTOS. При многозадачности или multi-thread, это называется: либо IPC (inter--process-communication), либо синхронизация работы thread внутри одного процесса. ++(419 знаков, 22.12.2011 10:06, ссылка)
- Разбейте сперва на процессы (логические), между ними установите событийную связь и решите процессы по отношению друг к другу будут синхронные или асинхронные и все это безотносительно к rtos. Хитрый Китаец(250 знаков, 21.12.2011 19:57)
- OSью я бы всяку мелочь не называл. чисто таск-шедулер. не более. не важно. шедулер этот уже какой-то конкретный присмотрели? - Mahagam(21.12.2011 18:10)
- Подумай вначале о том, как ты бы сделал на PC. И после недолгих размышлений придёшь к выводу, что: задачи и многозадачность вообще практически не нужны. Скорей нужен механизм событий наподобии очереди событий в GUI Windows. Не обязательно очередь, fk0(1695 знаков, 21.12.2011 17:55)
- Все равно делай на RTOS, осваивать все равно придется. Лучше на простой задаче, а когда GUI / файловая система понадобится, дергаться поздно будет. - Михаил Е.(21.12.2011 16:35)
- 1. Задача М(модем) имеет очередь сообщений она ничего не должна проверять переодически, только обрабатывать приходящие сообщения. abivan(1143 знаков, 21.12.2011 16:34)
- ИМХО, в этой задаче RTOS не помогает. Лучше без неё. - SciFi(21.12.2011 15:04)
- Пару мыслей. DL36(770 знаков, 21.12.2011 14:38)
- Синхронизация работы зависимых блоков ведется через очереди сообщений. Так, по крайней мере, решается в PSOS. Ralex(1280 знаков, 21.12.2011 14:18)
- Вот колеблюсь, какую RTOS использовать для ARM7. Вот приглянулись TN Kernel, ScmRTOS. Советуют AMX и FreeRTOS. Кто что подскажет ? - MegaJohn(ARM, полностью, 28.11.2011 12:33)
- Тут очень любят рассуждать о RTOS и всём таком. Но как-то массово замалчивается, что стандартная C-библиотека для неопределённого ряда своих функций не допускает рекурсивных (вложенных) вызовов. fk0(4442 знаков, dao, полностью, 13.08.2011 15:54)
- Нефиг си пинать за то, что он не хаскель ;) Рэйлвэй Каген(357 знаков, 14.08.2011 15:15)
- IMHO но на удивление все обладают одним фатальным недостатком -- процесс не может ни ожидать более чем одного события одновременно, ни не обладает возможностью асинхронной коммуникации (вроде сигналов в unix) следует напомнить дону, что Vit(245 знаков, 13.08.2011 17:58)
- Да просто использовать надо нормальные инструменты, в которых threadsafe каждой функции оговаривается отдельно. По факту в RealView очень немного функций, который нужно в мютексы оборачивать. Alex B.(183 знаков, 13.08.2011 17:19 - 17:30, ссылка)
- Сильная, нечеловеческая вещь. Ницше плакал. - General(13.08.2011 16:59)
- Интересное наблюдение. - SciFi(13.08.2011 16:33)
- Ось для cortex-M3, в которой декларируется: "Interrupt latency is 0". В документации сказано, что критические секции организованы блокированием планировщика, а не запретом прерываний. Прогрепил исходники - нигде нет запрета прерываний. - alcosar(dao, полностью, 08.12.2009 22:15, ссылка)
- Статья про атомарный доступ к битовым полям. Alex B.(225 знаков, MCU, полностью, 03.03.2009 14:22, ссылка)
- Здорово! Большое спасибо за статью! - Evgeny_CD(07.03.2009 16:44)
- Мелкое замечание по макросам AlexBi(639 знаков, 05.03.2009 18:22)
- Из исходника узнал много нового для себя о препроцессоре Си=) Однако, так и не понял, зачем нужно было городить трехэтажный макрос BFA с переменным числом параметров, в котором действие определяется по значению первого параметра? Не лучше ли сделать 5 M@ik(600 знаков, 05.03.2009 08:39)
- update: по горячим следам добавил макрос с косвенной адресацией и операции установки/сброса/инвертирования по маске. - Alex B.(04.03.2009 17:05, ссылка)
- Максима: "А нечего вообще битовые поля использовать". Сдали огромную часть территории на откуп компилятору, а теперь нужно изобретать, как забрать обратно. - Vladimir Ljaschko(04.03.2009 15:25)
- Введение сумбурное, идеи в макросах интересные. Непонятности во введении: Сергей Борщ(1038 знаков, 04.03.2009 15:22)
- Спасибо, хорошая статья. - vesago(04.03.2009 15:09)
- Очень полезно! Спасибо. - amusin(04.03.2009 13:31)
- Хорошая статья. Аффтар пеши исчо. - she(03.03.2009 19:46)
- Мне очень понравилось, спасибо. На основании этой статьи я откорректировал общеизвестные макросы для работы с портами применительно к С30, может еще кому будет полезно. - DL36(03.03.2009 19:29, ссылка)