- Прототреды это биг-луп вывернутый наизнанку. Или наоборот. То же
самое, что конечные автоматы им. Шалыто, 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)
- "В контексте МК" никаких задач не должно быть! :) Контроллер рассчитан на обслуживание периферии, а потому никаких других событий, помимо тех, что происходят на периферии, в его внутренней среде нет. А такие события, как правило, способны вызывать Ксения(2322 знаков, 20.09.2019 15:15)
- Кооперативную не хотите попробовать? Написана на С, без ассемблера - =AK=(02.09.2019 05:37, ссылка)
- 1) Гм, если размер int не равен разрядности процессора - можно огрести забавных глюков. LightElf(230 знаков, 02.09.2019 17:32)
- Я с 8-битными Ардунками пользовал, глюков не заметил. =AK=(112 знаков, 03.09.2019 00:17)
- 1) просто везло или не заметили. У вас счётчик задержки модифицируется и основной задачей и обработчиком прерывания, без каких-либо средств обеспечения атомарности LightElf(67 знаков, 03.09.2019 01:11)
- Под Ардуиной я даже прерывания не использую, задержки сделаны на основе millis() - =AK=(03.09.2019 02:13, ссылка)
- Если б я еще знал, что такое millis(). Вообще, использовать setjmp/longjmp нужно аккуратно и вдумчиво, там граблей разложено много. Конкретно у вас есть конструкция res = setjmp(bla-bla), которая, ЕМНИП, с точки зрения стандарта есть Undefined LightElf(724 знаков, 03.09.2019 09:54 - 10:20, ссылка)
- millis(0 - стандартная функция Ардуино, возвращает uint32_t, кол-во миллисекунд с момента старта. Об атомарности позаботились в ней. =AK=(2209 знаков, 03.09.2019 11:24 - 11:51)
- Кстати, да. Но допилить вроде бы несложно. - SciFi(03.09.2019 10:39)
- Это да. Но там еще грабли есть со стеком. Суть, кагбэ, в том, что вообще говоря никто не гарантирует, что выпрыгнув однажды из функции по longjmp можно будет в нее потом запрыгнуть назад. Компилятор имеет полное право раскладывать на стеке свои LightElf(249 знаков, 03.09.2019 11:08)
- Вот, кстати, прекрасная цитата. "Оставь надежду, всяк сюда входящий": SciFi(380 знаков, 03.09.2019 11:49)
- Это мне не понятно. Я же не надеюсь на постоянство содержимого стека, при выходе сохраняю контекст, при входе - восстанавливаю. Какая при этом разница, кто там что перезатер в промежутке? - =AK=(03.09.2019 11:30)
- Э-э, так нечестно. Если компилятор любит так безобразничать, пусть отслеживает, что вот тут longjmp, отставить безобразия. - SciFi(03.09.2019 11:28)
- Спасибо, интересно - Vit(02.09.2019 11:28)
- "Написана без ассемблера", а setjmp и longjmp что такое? - Ale3000(02.09.2019 10:37)
- Тогда уж и protothreads от Adam Dunkels посмотрите. - Dingo(02.09.2019 06:12 - 06:17, ссылка, ссылка)
- Ты что-то не то говоришь. В тикле там свой встроенный цикл обработки событий, либо можно свой написать вместо него, смотря как удобнее. Скрипт естественно махом исполняется за раз. Поэтому либо должен быть нашпигован командами after (vwait, fk0(760 знаков, 01.12.2018 14:23)
- Подход, если не нужно реальное вытеснение (т.е. критично время реакции), порочный: сложные системы в "больших компьютерах", наоборот, стараются сделать однопоточными и событийно-управляемыми. Иначе сложность синхронизации параллельных пороков fk0(1890 знаков, 12.09.2015 13:33, ссылка)
- Вот и отличненько. Удалось значит понять суть: императивный стиль программирования повсеместно вдалбливаемый в (не)окрепший мозг -- суть есть тонкая диверсия. Невозможно писать программы в императивном стиле. Особенно, управляющие программы. fk0(2184 знаков, 31.07.2013 16:47)
- "Далее, полезли глюки неопределенных состояний"... и это главная беда. Скрипач(750 знаков, 31.07.2013 17:03)
- Что за глюки "неопределенных состояний"? Может определить эти состояния и глюки пропадут? Apтём(334 знаков, 31.07.2013 17:19)
- "Наизнанку - это как?" Гусары молчать! :) Скрипач(334 знаков, 31.07.2013 17:30 - 17:40)
- Лучше Miro Samek-а читать - Vit(31.07.2013 22:18, ссылка)
- А можно ссылку, чё читать? А то по вашей ссылке яркие краски, бубенчики и крайне мало текста :( - Скрипач(31.07.2013 22:26)
- Переводы некоторых статей там--> - Vit(31.07.2013 22:40, ссылка)
- гуглится Vit(31.07.2013 22:34, ссылка, ссылка)
- ОС для событийного программирования? Проектирование "событийного" автомата радикально менее формализовано, чем проектирование "автомата состояний". И потому более опасно в плане редко возникающих ошибок, примеры которых я привел ранее. - Скрипач(31.07.2013 23:14 - 23:31)
- автомат без явного описания состояний это прототридсы. всё Вам опасно и редко возникающе:) - Vit(01.08.2013 00:15)
- А у вас в программе все ошибки - синтаксические, да? :) Скрипач(164 знаков, 01.08.2013 00:24)
- fk0 в том, что без событийной системы строить мелкожручее, ИМХО, прав. Запускать же адресно автомат (с неформализованным, например, описанием) по событию, которое он ожидает, т.е. описано явно, у Вас почему-то оказывается сложным. Vit(1490 знаков, 01.08.2013 10:06)
- Не так. Модель конечного автомата: Скрипач(294 знаков, 01.08.2013 14:16 - 14:22)
- Возражение не принимается. Работа жесткой логики и программы чуток отличаются. Расставьте всего-лишь 2 входа на разные порты МК и автомат "сам,, в любой момент времени, полностью определить состояние ВСЕХ своих входных сигналов" тупо НЕ СМОЖЕТ и Vit(74 знаков, 01.08.2013 16:55)
- Входами автомата могут быть: собсно дискретные входы, события, таймеры. Что приоритетнее выбирается по условиям задачи. Никакой гонки сигналов тут нет. У нас есть аварийные входы, они идут в первую очередь, очень важные события тоже в первую mazur(643 знаков, 01.08.2013 15:43)
- Для этого предполагатся, что все события могут возникать строго последовательно, и никакой гонки уже быть не может. Порядок возникновения событий во времени придётся сохранить. И вообще не понятно, что мешает автомату самостоятельно проверить fk0(106 знаков, 01.08.2013 14:50)
- я предлагал читать - Vit(01.08.2013 00:10)
- перевожу: "RTOS рулез" - Mahagam(31.07.2013 16:50)
- Давно холиваров не было. Как насчёт 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)
- Топик посвящён программированию микроконтроллеров в условиях необходимости экономии электроэнергии и архитектуре ПО в целом. fk0(5489 знаков, 24.10.2011 02:41)
- Тут очень любят рассуждать о 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)