Зачем? Я пишу операционную систему. Надо. Для автоматики здания надо, для управления огромными боевыми человекоподобными роботами надо.
Чего не хватает? CMSIS RTOS -- хороше API для встроенных приложений. Но мне пришлось пересмотреть ее чуть ли не полностью, перетрясти. Я стараюсь ничего не менять. Но надо.
1) Нужен "жесткий" реал-тайм для роботов. Но он не нужен для управления зданием. Для управления двигателями хочется иметь таймеры которые выполняются с точностью микросекудна - десяток микросекунд.
2) И вот концепция RTOS сломалась о спецификацию протокола BACnet. BACnet не просто протокол для передачи данных - это концепция "всего". Это объектная модель всех возможных, это очень мощный стандарт, который описывает все уровни и все проявления: терминал, файлы, доступ к объектам и полям данных, представление данных для Web, управление данными, десяток протоколов, маршрутизация поверх различных сетей, энкапсуляция данных при передаче между разными сетями, выборы мастера в сети.
Можно сделать халтуру. Но как сделать по описанию протокола в точности, используя данный инструментарий я не решил.
Потратил месяца два на перевод стандарта в код конроллера, в код пришел к выводам:
1) Кроме "тредов" нужны "службы". В чем разница. Тред - это функция, которая ждет событие в на стеке, стек занимает собой, и ждет с таймаутом. А "служба" это такая функция которая ждет событие и обабатывает данные. Причем, ждет вне функции, стек не занимает. В службе я выставляю чего ждать, и выхожу из функции, а в "треде" я явным образом указываю чего ждать и не продолжаю, пока событие не случится. В спецификации стандарта BACnet обнаружил: драйвер сетевой -- служба протокола MS/TP, IPv4, IPv6, Zigbee -- уровень соединения DataLink -- уровень Network -- APDU прикладной -- устройство Device. -- каждый уровень следит за работоспособностью других уровней и поэтому это отдельные задачи - службы и процессы. Помимо этого есть еще приложение, которое определенно может быть "тредом". НО оно взаимодействует с другими объектами и реагирует на события. Значит тоже не простое. Многие вещи свойственные приложению, могу описать блок схемой, но не могу программой. Программа строится из стандартных объектов, которые взаимодействуют асинхронно.
2) Нужна поддержка блочных схем, функциональных блочных диаграмм. Подходящий механизм запуска множества функций со связями типа wait-list обнаружил в стандарте OpenCL и даже научился компилировать "кернелы" в целевую платформу. Нужен конвейер clEnqueue для запуска блочных диаграмм. Командный объект, если в терминах BACnet. Короче есть механизм ожидания сигналов, в RTOS, а мне нужен для синхронизации функций механизм типа как в OpenCL. Замечание. У нас не числогрыз, у нас контроллер встраиваемый с небольшим количеством памяти. Надо запускать функции в блочной диаграмме последовательно но последовательность определяется связями-событиями готовности. Этот функционал можно реализовать на прикладном уровне. Но какая-то поддержка со стороны ОС должна быть, например "списки ожидания" и события типа "кондишен" - готовность. В отличие от OpenCL нам надо уметь запускать последовательности действий с условиями и таймаутами (задержками) между функциональными блоками. И это не должно занимать стек. Если никакая функция в блочной диаграмме не выполняется, стек свободен.
3) Модель драйвера. Пока что у меня получается, что драйвер - это такая служба. У меня не получается его сделать в точности как в традиционной ОС, POSIX. Не могу с драйвером работать как с файловой системой. Каждый драйвер - это несколько типов событий и каждому событию соответсвует свой формат данных. Можно реализовать на обратных вызовах, но не хочу. Хочу на событиях, флагах и асинхронных очередях. Чтобы это укладывалось в концепцию описания служб.
4) Я заглядываю в стандарт C11. Привожу в соответствие со стандартом атомарные операции и пишу реализацию тредов С11, по сути разница не значительная. Хотелось бы придти к системе, которая не зависит от платформы, чтобы отлаживать приложения на ПК.
5) В концепции CMSIS RTOS позитивная идея - пулы памяти - выделение памяти из массива. Идея хорошая, но от нее немного отойти хочется в сторону "слайсов", выделение памяти слайсами, как в GLib.
6) Нужна полная переносимость на Линукс и Виндовс и обратно. При выборе механизмов синхронизации и API служб и тредов, надо их поддержать и на этих двух платформах.
7) В основу подкладываю идеи типа DeviceTree и RCU - база данных устройства типа дерево, в котором живет конфигурация устройства, периферии, связи между объектами, и настройки прикладных программ. Все обращения к объектам и полям объектов происходят через эту базу. База данных должна поддерживать неблокирующий доступ к данным на чтение и запись.
Чего не хватает? CMSIS RTOS -- хороше API для встроенных приложений. Но мне пришлось пересмотреть ее чуть ли не полностью, перетрясти. Я стараюсь ничего не менять. Но надо.
1) Нужен "жесткий" реал-тайм для роботов. Но он не нужен для управления зданием. Для управления двигателями хочется иметь таймеры которые выполняются с точностью микросекудна - десяток микросекунд.
2) И вот концепция RTOS сломалась о спецификацию протокола BACnet. BACnet не просто протокол для передачи данных - это концепция "всего". Это объектная модель всех возможных, это очень мощный стандарт, который описывает все уровни и все проявления: терминал, файлы, доступ к объектам и полям данных, представление данных для Web, управление данными, десяток протоколов, маршрутизация поверх различных сетей, энкапсуляция данных при передаче между разными сетями, выборы мастера в сети.
Можно сделать халтуру. Но как сделать по описанию протокола в точности, используя данный инструментарий я не решил.
Потратил месяца два на перевод стандарта в код конроллера, в код пришел к выводам:
1) Кроме "тредов" нужны "службы". В чем разница. Тред - это функция, которая ждет событие в на стеке, стек занимает собой, и ждет с таймаутом. А "служба" это такая функция которая ждет событие и обабатывает данные. Причем, ждет вне функции, стек не занимает. В службе я выставляю чего ждать, и выхожу из функции, а в "треде" я явным образом указываю чего ждать и не продолжаю, пока событие не случится. В спецификации стандарта BACnet обнаружил: драйвер сетевой -- служба протокола MS/TP, IPv4, IPv6, Zigbee -- уровень соединения DataLink -- уровень Network -- APDU прикладной -- устройство Device. -- каждый уровень следит за работоспособностью других уровней и поэтому это отдельные задачи - службы и процессы. Помимо этого есть еще приложение, которое определенно может быть "тредом". НО оно взаимодействует с другими объектами и реагирует на события. Значит тоже не простое. Многие вещи свойственные приложению, могу описать блок схемой, но не могу программой. Программа строится из стандартных объектов, которые взаимодействуют асинхронно.
2) Нужна поддержка блочных схем, функциональных блочных диаграмм. Подходящий механизм запуска множества функций со связями типа wait-list обнаружил в стандарте OpenCL и даже научился компилировать "кернелы" в целевую платформу. Нужен конвейер clEnqueue для запуска блочных диаграмм. Командный объект, если в терминах BACnet. Короче есть механизм ожидания сигналов, в RTOS, а мне нужен для синхронизации функций механизм типа как в OpenCL. Замечание. У нас не числогрыз, у нас контроллер встраиваемый с небольшим количеством памяти. Надо запускать функции в блочной диаграмме последовательно но последовательность определяется связями-событиями готовности. Этот функционал можно реализовать на прикладном уровне. Но какая-то поддержка со стороны ОС должна быть, например "списки ожидания" и события типа "кондишен" - готовность. В отличие от OpenCL нам надо уметь запускать последовательности действий с условиями и таймаутами (задержками) между функциональными блоками. И это не должно занимать стек. Если никакая функция в блочной диаграмме не выполняется, стек свободен.
3) Модель драйвера. Пока что у меня получается, что драйвер - это такая служба. У меня не получается его сделать в точности как в традиционной ОС, POSIX. Не могу с драйвером работать как с файловой системой. Каждый драйвер - это несколько типов событий и каждому событию соответсвует свой формат данных. Можно реализовать на обратных вызовах, но не хочу. Хочу на событиях, флагах и асинхронных очередях. Чтобы это укладывалось в концепцию описания служб.
4) Я заглядываю в стандарт C11. Привожу в соответствие со стандартом атомарные операции и пишу реализацию тредов С11, по сути разница не значительная. Хотелось бы придти к системе, которая не зависит от платформы, чтобы отлаживать приложения на ПК.
5) В концепции CMSIS RTOS позитивная идея - пулы памяти - выделение памяти из массива. Идея хорошая, но от нее немного отойти хочется в сторону "слайсов", выделение памяти слайсами, как в GLib.
6) Нужна полная переносимость на Линукс и Виндовс и обратно. При выборе механизмов синхронизации и API служб и тредов, надо их поддержать и на этих двух платформах.
7) В основу подкладываю идеи типа DeviceTree и RCU - база данных устройства типа дерево, в котором живет конфигурация устройства, периферии, связи между объектами, и настройки прикладных программ. Все обращения к объектам и полям объектов происходят через эту базу. База данных должна поддерживать неблокирующий доступ к данным на чтение и запись.
Комментариев нет:
Отправить комментарий