Make_Pic (25.04.2024 10:16, просмотров: 1107)-
- Обычно, если есть RTOS, то управление функциями делается средствами RTOS. Если есть иерархия автоматов, то RTOS вроде и не нужна. (Необходимость RTOS присутствуют если 1) длительные процессы и 2)готовые пакеты ПО) По теме: управление автоматами осуществляется путем изменения переменной состояния автомата. VLLV(27 знак., 01.05.2024 18:29)
- А выполнение этих функций может быть параллельным? Если да, то проще каждую из этих функций организовать как отдельный поток. Если накладно по ресурсам, то в "потоке-исполнителе" организовать эти ф-ции как протопотоки. В обоих случаях как будто имеется возможность штатного (средствами ОС или protothreads) останова/запуска ф-ций. - Argon(27.04.2024 11:52)
- Ау - гуру? Кто то может еще прокомментировать варианты решения
задачи? - Make_Pic(26.04.2024 06:44)
- Подобные задачи наиболее просто и чисто решаются в ООП парадигме.
Под запуск-останов-пошаговое выполнение пока что (до получения
более подробного описания) подходит Command, Chain of
Responsibility. При этом не знаю к чему упомянут RTOS, но Command
aka "функция" aka "звено цепи" вполне может быть активным, т.е.
представлять экземпляр потока. Про параллельную работу речи не шло,
но могут работать и параллельно, собирая конечные результаты. - RxTx(26.04.2024 14:55)
- С паттернами я на "Вы", но тем не менее, есть примеры аналогичного
использования по теме топика? - Make_Pic(26.04.2024 15:02)
- Примеры есть но без FreeRTOS. Если обязательно FreeRtos, я бы передавал между потоками через xQueue. - RxTx(27.04.2024 08:10)
- С паттернами я на "Вы", но тем не менее, есть примеры аналогичного
использования по теме топика? - Make_Pic(26.04.2024 15:02)
- гуру ртос'ами не пользуются - argus98(26.04.2024 12:04)
- Подобные задачи наиболее просто и чисто решаются в ООП парадигме.
Под запуск-останов-пошаговое выполнение пока что (до получения
более подробного описания) подходит Command, Chain of
Responsibility. При этом не знаю к чему упомянут RTOS, но Command
aka "функция" aka "звено цепи" вполне может быть активным, т.е.
представлять экземпляр потока. Про параллельную работу речи не шло,
но могут работать и параллельно, собирая конечные результаты. - RxTx(26.04.2024 14:55)
- Практически в всех проектах использую подобное. Одна (или
несколько) задача является автоматом состояний, управляемым
событиями. Вся логика работы автомата (режимы, состояния, эвенты,
переходы, действия) описана в таблицах. Неизменяемый движек ждет
события из очереди и парсит таблицы на предмет совпадения.
Остальные задачи накидывают события в очередь. Все под RTOS.
Принцип работы автомата здесь описан. Переписать отправку и
получение события, ну под себя попилить. Andrew_Q(1 знак., 25.04.2024 15:07, ссылка)
- У меня автомат верхнего уровня всего из четырёх-пяти состояний. По сути, режимы работы. И от этих состояний зависит, как отработают другие автоматы и в каких режимах. Ну и некоторые из автоматов нижнего уровня, могут получать команды от линий связи и менять режим. Нельзя сказать, что есть централизованное управление. Хотя, пожалуй, как управление можно выделить переключатель команд в обработчике команд, полученных со стыка с контроллером выше по системе. - Nikolay_Po(25.04.2024 18:16)
- А логика останова автомата состояния, запуска, останова по метке? - Make_Pic(25.04.2024 15:52)
- Дак не корми его событиями, он и стоит. Или события Стоп, Ресет с
соответсвующими обработчиками. - Andrew_Q(25.04.2024 15:56)
- А как с условными переходами быть? - Make_Pic(27.04.2024 06:32)
- Дак не корми его событиями, он и стоит. Или события Стоп, Ресет с
соответсвующими обработчиками. - Andrew_Q(25.04.2024 15:56)
- Продолжаем изобретать интерпретатор? Посмотрите на микровасик,
может навести на интересные мысли: SciFi(1 знак., 25.04.2024 11:22, ссылка)
- Не совсем, но в этом направлении попроще. - Make_Pic(25.04.2024 11:25)
- Меня тут уже поправляли... Конечный автомат... Зависит от того,
может управляющий дать несколько команд быстрее, чем управляемый
исполняет? Требуется ли очередь команд? Делал подобное через флаги.
Делал подобное через прямое вмешательство управляющего кода в
состояние управляемого. И так, и так работает. Был даже вариант с
очередью, но то были транзакции для интерфейса связи. - Nikolay_Po(25.04.2024 10:17)
- Была аналогичная тема? - Make_Pic(25.04.2024 14:33)
- Просто прибор с обработкой данных в ракельном времени, с обменом с несколькими устройствами на нескольких шинах, с фоновым сохранением результатов работы во флэш, с вычиткой данных из флеш по запросу. Очереди использовались, в частности, для флеш и её подсистемы ввода/вывода, с резервированием данных и выравниванием износа, как для самого медленного устройства и самого сложного по требуемому порядку действий. Остальные обмены требовали просто конечных автоматов, без очередей, Nikolay_Po(93 знак., 25.04.2024 18:12)
- Управляющая задача работает быстрее намного, да и приоритет у не более высокий. Насчет очереди вопрос пока открытый скорее потребуется. Что то есть подсмотреть ;)? - Make_Pic(25.04.2024 11:15)
- Была аналогичная тема? - Make_Pic(25.04.2024 14:33)