Тут ОС для AVR помещали. Здорово конечно. Но я в последнее время заразился принципиально более другим подходом — автоматным программированием. ОС не нужна. Все «задачи» или «процессы» в терминах ОС реализуются как конечные автоматы. Система параллельных задач — не что иное, как система взаимодействующих параллельных автоматов. Автоматы могут взаимодействовать по вызываемости, по обмену номерами состояний, с помощью бинарных сообщений. Автоматы могут быть вложенными в состояния других автоматов, и таким образом организовывать сложную иерархию в рамках одного автомата.
Нет, на самом деле практически всё позаимствовано из работ А.А. Шалыто (http://www.softcraft.ru).
Технология была опробована на практике, показала свои недостатки и определённые преимущества. В первую очередь — чрезвычайно низкое число логических ошибок, их практически не было. Получилась достаточно надёжная система.
Из недостатков можно отметить относительную сложность программирования и проектирования автоматов с большим числом состояний, сложность программирования вычислительных задач. Ещё из недостатков особенно заметна заметная «тормознутость» системы. Есть и определённые решения, направленные на исправление отмеченных недостатков. В целом, я считаю, подход показал себя удачно и будет, я думаю, развиваться, по крайней мере, мною и дальше.
Важно, что техника программирования применимая к «классическому» программированию применима и к автоматному программированию - всё может описываться в рамках системы автоматов.
Считаю, что многозадачной операционной системой нового поколения могла бы являться ОС, созданная для поддержки работы системы параллельных автоматов-задач. Где любая системная (драйвер, например) или прикладная задача описывается конечным автоматом, динамически встраиваемым в систему. А языки программирования, например язык C или ассемблер, расширен библиотеками для поддержки автоматного программирования. Особенно это важно, возможно, для микропроцессорных устройств с небольшим объёмом памяти, где зачастую практически невозможно разместить в ОЗУ стек для более, чем двух-трёх параллельных задач (против нескольких десятков автоматов — ведь практически вся память, выделяемая для работы автомата на каком-либо шаге освобождается по завершению его работы).
Хотелось бы адаптировать бы switch-технологию, исключить громоздкий оператор switch, заменить его, например, на функции-состояния. Реализовать библиотечную поддержку автоматного программирования часто встречающимися примитивами. Особенно, что касается ввода-вывода — стандартные библиотечные функции явно предусматривают блокировку. Реализовать автомат-планировщик для эффективного запуска функций-состояний согласно приоритетами и только для функций-состояний действительно в этом нуждающихся, чтоб не тратить понапрасну время на проверку заведомо ложных условий. Это, отчасти, может реализоваться с помощью механизма бинарных сообщений и автомата-диспетчера, регистрирующего смену состояний автоматов, переменные состояний которых участвуют в условиях переходов других автоматов.
Интересно, а практикует ли кто тоже такой подход к программированию. Речь не идёт о win-программировании (Я НЕНАВИЖУ БИЛДЕР!), а о программировании встраиваемых микропроцессорных систем, напрямую связанных с реальным железом.
Writer http://www.nedopc.org/forum/viewtopic.php?p=74559&sid=636f04528c6c74303b141b53b76193c1