Как написать конечный автомат, используя примитивы RTOS?

Question

[Сергей]

Как выглядит конечный автомат с использованием очереди сообщений (event/dispatch queue) с поддержкой перехода между состояниями по таймеру (отложенная обработка события), написанный с помощью примитивов RTOS?
Если писать традиционно, как для AVR, проще всего, как мне кажется, использовать две очереди: одна для сообщений с таймером, другая - сообщений без задержек; первую обрабатываем в таймере, тикающему с заданной частотой (например, 1 мс), вторую - в бесконечном цикле. Т.е. помимо самого КА надо написать две очереди, два обработчика-диспетчера. Я предполагаю, что в RTOS такие вещи должны идти из коробки вместе с планировщиком, но я только начинаю разбираться, и поэтому не понимаю как сделать КА лаконично и красиво.

Зачем нужен КА? Мне так проще формализовывать мысли и согласовывать поведение с конечным пользователями, так что этот архитектурный приём мне просто нравится. Если он совсем противоречит идеологии RTOS, как Вы её понимаете. с удовольствием выслушаю другие предложения.

Answer 1

[tugo]

Погуглите по словам

"RTOS name" state machine

.
Например, "freertos state machine"
Из того, что понравилось:
https://www.sinelabore.de/doku.php/wiki/howto/rtos
https://stackoverflow.com/questions/46927097/state...

Comments

[Сергей]

Спасибо. Первую ссылку я как-то пропустил, вроде там достаточно идиоматично: используем предоставляемый системой софтварный таймерный пул, очередь сообщений и планировщик. Создаётся одна Task, в которой непрерывно (когда системный планировщик разрешит) опрашивается очередь и запускается извлеченное событие. Если КА или прерывание генерируют событие, то пихают в ту же очередь без всяких мьютексов.

Насколько я успел осмыслить документацию freertos, для обработки entry/exit и мгновенных callbacks transition мы их просто кладём в очередь, а для вызова отложенного transition callback немного сложнее: перед запуском vTaskStartScheduler создаём несколько таймеров, а когда надо обработать transition callback, перебираем созданные таймеры xTimerIsTimerActive, чтобы найти неактивный, и вызываем xTaskStart с callback вида "пихнуть в очередь transition callback". Чтобы запихнуть аргументы к callback, делаем примерно так.

Answer 2

[Александр Скуснов]

Если брать Stateflow (граф состояний) из MatLab/Simulink, то там всё идёт по таймеру. Есть переходы между состояниями как по логическому условию, так и по событию.

То же самое заложено в ПЛК, называется сканом: опрос входов, расчёты, сработка выходов, сетевые взаимодействия.
Хотя в ПЛК можно включить и асинхронные обработки прерываний, но, насколько я знаю, это только для быстрых счётчиков, да и то, нужно представлять последствия.

Comments

[Александр Скуснов]

Или почитайте синхронизацию CPU и GPU с помощью флагов и событий в DirectX 12. Там, конечно, на низком уровне распоряжается ОС, но на уровне программирования всё описывается событиями.

// Advance the fence value to mark commands up to this fence point.
    mCurrentFence++;

    // Add an instruction to the command queue to set a new fence point.  Because we 
    // are on the GPU timeline, the new fence point won't be set until the GPU finishes
    // processing all the commands prior to this Signal().
    ThrowIfFailed(mCommandQueue->Signal(mFence.Get(), mCurrentFence));

    // Wait until the GPU has completed commands up to this fence point.
    if(mFence->GetCompletedValue() < mCurrentFence)
    {
        HANDLE eventHandle = CreateEventEx(nullptr, false, false, EVENT_ALL_ACCESS);

        // Fire event when GPU hits current fence.  
        ThrowIfFailed(mFence->SetEventOnCompletion(mCurrentFence, eventHandle));

        // Wait until the GPU hits current fence event is fired.
        WaitForSingleObject(eventHandle, INFINITE); // в реальном приложении INFINITE лучше не писать
        CloseHandle(eventHandle);
    }

(хотя и тут есть вариант - привязаться к вертикальной синхронизации (напр., 60 fps) и не мучаться, т.е. работать по таймеру)