ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
28 марта
954365 Топик полностью
Связанные сообщения
АвтоматыEvent DrivenАрхитектураSplit Stack
Прототреды это биг-луп вывернутый наизнанку. Или наоборот. То же самое, что конечные автоматы им. Шалыто, switch-технология. Удо...2020-06-11
Железо нужно симулировать не на уровне битов и фронтов сигналов, а на уровне высокоуровневых операций (например, чтение-запись б...2019-11-07
Как запустить параллельную систему КА написано у Шалыто лет 20 тому назад. Впрочем и самому додуматься можно. Тема уже изъезженн...2019-10-22
Ровно наоборот. Конечные автоматы подразумевают ЯВНОЕ выделение всех возможных состояний программы (как множества состояний сист...2019-10-21
Выскажу ещё раз: FreeRTOS сырая недоделка, смысла особого, без реализации ряда перечисленного (см. ниже) не имеет и, хуже того, ...2019-10-18
Смотря какая ОС. В основном ОС делятся по типу: бывают корпоративные ОС и любительские.2019-03-20
Когда ПО прибора запускается на обычном ПК. Для этого обычно ПО разделяется на два слоя, как минимум: платформо-независимый (бол...2018-05-23
Это какое-то твоё определение. И оно не выполнимо, т.к. твои же задачи будут конкурировать и оттягивать на себя процессор, как т...2018-05-18
Подход, если не нужно реальное вытеснение (т.е. критично время реакции), порочный: сложные системы в "больших компьютерах", наоб...2015-09-12
Да, трэш угар и содомия. Иногда абстракции через край, поэтому я имею такое мнение, что иногда и не грех в исходники прямо вписа...2013-12-29
Натолкнуло на интересную мысль применительно к embedded программированию. А именно -fsplit-stack. Будучи допиленным до рабочего ...2013-10-29
Не совсем. Над HAL может быть ещё один слой, уже нужный для совмещения разных программных интерфейсов. Т.е. есть модуль A, котор...2013-10-25
Вот и отличненько. Удалось значит понять суть: императивный стиль программирования повсеместно вдалбливаемый в (не)окрепший мозг...2013-07-31
Топик посвящён программированию микроконтроллеров в условиях необходимости экономии электроэнергии и архитектуре ПО в целом.2011-10-24
Полезны аж 3 прослойки (ассемблеристам дальше лучше не читать):2011-10-13
Тут очень любят рассуждать о RTOS и всём таком. Но как-то массово замалчивается, что стандартная C-библиотека для неопределённог...2011-08-13
fk0, легенда (22.10.2019 11:16, просмотров: 1320) ответил =AlexD= на Не понимаю я вот этого противопоставления потоки vs КА. КА внутри потоков работающие строго по блокируемым системным вызовам - наш путь, не?
Да, примерно об этом я и думаю. Что систему КА можно запускать параллельно, на пуле потоков, по выбирая готовые к запуску по мере наличия интересующих конкретные КА событий (это важный момент, т.к. планировщик избавляет от важной проблемы Big Loop'а -- большой латентности из-за чрезмерно долгого оборачивания цикла). КА при этом обладают своим мьютексом, могут взаимодействовать через систему событий и планировщик, могут напрямую вызывать другие КА, но строго в одну сторону: есть чёткое разделение на модули/классы/автоматы используемые каким-либо другим модулем, и использующие какой-либо другой модуль. Прямой вызов возможен только в сторону используемого модуля, и говорится, что использующий модуль знает о свойствах используемого. В обратную сторону вызов запрещён, включая callbacks -- следует использовать событийную систему для передачи информации в обратную сторону (поверх событийной системы могут быть реализованы контейнеры вроде однонаправленных очередей сообщений, fifo-буферов, Go-каналов, recv-reply "шлюзов" из QNX и т.п.) И используемый модуль не знает ничего об использующих его модулях. Т.е. все зависимости ориентированы строго, условного говоря, сверху вниз, в одну сторону. Это позволяет избежать взаимоблокировок (dead locks) и рекурсий. Выстраивать архитектуру системы нужно с деления на модули (классы, автоматы) и создания диаграммы связей между ними. Потом внутри модулей появляются автоматы (в простейшем случае, модуль -- это автомат). Сами автоматы могут задаваться в упрощённом виде, в виде "сопрограмм", представляемых в виде функций на C (т.е. когда состояние определяется счётчиком программных инструкций и значениями переменных). Это с одной стороны плохой подход, но он увы, ускоряет программирование. Кроме того, верификацию программ в системах типа Promela удобнее выполнять тоже при таком подходе. Суть же "сопрограмм" в том, что они представляют обычные функций, у которых стек разделён как бы на две части: основная часть, на которую указывает регистр FP (и SP в момент входа в функцию) располагается не в стеке, а в блоке памяти выделенном именно для данного экземпляра (вызова) сопрограммы в куче. Вторая часть стека, куда искусственно переносится регистр SP -- в стеке потока, который исполняет сопрограмму в текущий момент. И эта часть стека "исчезает" при любой блокировке сопрограммы. Таким образом, сопрограммы могут вызывать обычные функций, но не могут блокироваться в последних. Могут вызывать другие сопрограммы и могут в них блокироваться. Вызов сопрограммы -- относительно дорогая операция (нужно выделение памяти), а вызов обычной функции -- дешёвая. Сопрограмма сохраняет на момент блокировки все свои локальные переменные, но не может использовать массивы с переменным числом аргументов или функцию alloca (т.к. смещение SP достигается через вызов alloca с рассчитанным значением аргумента). Минимально на каждый экземпляр, на каждую вызванную как отдельную "задачу" сопрограмму, нужен объём памяти стека достаточный для хранения её локальных переменных и обработки прерываний. То есть система начинает иметь смысл только наличии системы прерываний обрабатываемых на отдельном стеке, когда на стеке прерванной задачи не используется более нескольких слов. Последнее технически реализуемо на почти любых архитектурах, если переписывать обработчики прерываний на ассемблере. Но в типичных "рантаймах" обычно подразумевается общий стек, что является препятствием. На ряде архитектур с аппаратным стеком (PIC18) такой подход невозможен, как и многопоточность.
[ZX]