Чудо-юдо QuantumLeaps или просто QP., Фреймворк для автоматного программирования. Кто что скажет? Опции

[JeDay]

Всех приветствую.
Где-то лет 10 назад я первый раз услышал про QP. Почитав интернет и не найдя ни весомых аргументов для использования ни обсуждений на форумах забил...
Ссылка на QP: https://www.state-machine.com
Недавно довелось занырнуть в проэкт написанный на QP. Данный фреймворк работает поверх известной RTOS. Используется около 15ти состояний в которых есть свои под-состояния. Больше 30ти ивентов и 8ми актив-обьектов(QActive) их обрабатывающих. Каждый QActive работает в отдельном потоке. Пока состояние не закончит работу, другое не стартует(даже в другом потоке). В QP переключатель контекста свой. Приоритетное вытеснение, как я понял, самой RTOS полезной нагрузки не несет ибо не знает о QP работающего поверх нее. В общем парадигма программирования совсем другая.
Мне интерестно, кто нибуть вообще эту штуку применял? Интересует впечатления, удобство написания прошивок под Cortex-M.
Лично я не вижу смысла, имея ОС с приоритетным вытеснением, накатывать непонятный фреймворк и делить код на пару десятков состояний которых априори не планировалось бред. Из плюсов в QP есть возможность подписываться на событие нескольким QActive. Но тоже самое в uc/OS существует в виде "Event Flag Group" да и многими другими объектами синхронизации можно обойтись.
Думаю данный подход может понравиться тем кто еще не освоил RTOS и многопоточное программирование, продолжает по накатанной пилить прошивки на базе while-loop со стейтами.
Вот еще пара ссылок:
http://we.easyelectronics.ru/kovz/ispolzov...vstuplenie.html
https://habr.com/post/114239/

[arhiv6]

Данный фреймворк работает поверх известной RTOS.

Нет, он работает без ОС, но заложена возможность запускать этот фреймворк как сервис в ОС. Вот ещё статья была недавно: http://proiot.ru/blog/posts/2017/05/25/zhi...ktorov-qpc-uml/
Вообще, продукта три: QP/C++, QP/C и QP-nano плюс дополнительный софт (для тестирования, профилирования, визуального UML моделирования). Там же на сайте можно книжки по эти фреймворкам бесплатные скачать.

[JeDay]

Нет, он работает без ОС, но заложена возможность запускать этот фреймворк как сервис в ОС.

Да я знаю. Ему нужна переключалка контекста. Причем QP содержит cooperative и pre-emptive планировщика. Можно использовать любой. В мной упомянутом проекте юзается FreeRTOS+QP/C. Переключения контекста QActive происходит в конце отработки QState. Ну и в итоге мы получили на pre-emptive планировщике cooperative переключение контекста.
Интересует мнение людей которые на деле попробовали QP. Лично я фишку не уловил. Мне лучше нативная многозадачность с приоритетным вытеснением. А стейт-машины где потребуется я на switch-case реализую.

[AlexandrY]

Интересует мнение людей которые на деле попробовали QP.

Обсуждалось здесь десятки раз. Никто здесь реально эту вещь не юзал под нормальный embedded.
Но подход этот широко используется в C#, VB, Java и прочих в виде Async и Await
Вот там их наверняка юзали все. Там и спрашивайте.

[Harbinger]

Мне интерестно, кто нибуть вообще эту штуку применял? Интересует впечатления, удобство написания прошивок под Cortex-M.

Получил недавно исходники одного мелкосерийного изделия - но без UML-модели, только кейловский проект под STM32F103. Мрачновато смотрится.

[Kabdim]

Про качество либы скорее вас спрашивать надо, у вас ведь боевой код и возможность его оценить незашореными глазами непричастного разработчика. А насчет ртос - вполне возможно что изначально проект был без ртос, а потом понадобилось и ртос прикрутили к уже имеющейся кодобазе.

в виде Async и Await

Небо и земля, асин/авейт очень понятная и логично записываемая абстракция. В автоматах же при малейшем сбое самоконтроля можно получить взрыв на фабрике лапши.

[JeDay]

Про качество либы скорее вас спрашивать надо, у вас ведь боевой код и возможность его оценить незашореными глазами непричастного разработчика. sm.gif А насчет ртос - вполне возможно что изначально проект был без ртос, а потом понадобилось и ртос прикрутили к уже имеющейся кодобазе.

В том то и прикол, что изначально была связка FreeRTOS+QP. Причем порт FreeRTOS кривоват, очереди для сигналов он использует свои а не xQueue. Что-то мне подсказывает что люди просто применили то что под руку попалось )