Программирование ПЛК110 [М02] для задач реального времени

[Вольд]

У PRU ядра всего один поток команд.
Т.е. В каждый момент времени PRU берет следующую команду и выполняет. Никаких прерываний нет.

До этого я составлял программы, в которых было все-все-все. И чтение входов, и обмен данными и
ожидания, и запись выходов.
Мне, конечно так проще, да и всё равно никто другой черепахой не программировал.

Но есть "незадача". Например, для управления ШД нужно мигать выходом с разной частотой. Например, на разгоне вообще частота с каждым импульсом меняется.

В результате, пока "ждём момент для очередного ШД импульса, опрашивать энкодер все равно нужно".
Напомню: прерываний нет, и единственный вариант "переключить выход ровно через 1мкс" это "выполнить 200 каких-нибудь команд" (на частоте 200МГц как раз так получается, что 200 простых команд занимают 1 мкс".
Опрос входа -- 1 команда. Проверка "менялось ли значение за последнюю микросекунду" -- это ещё штук 5-6 команд.
В итоге, 4 входа с примитивной фильтрацией займут ~ 4*7 == 30 тактов == 30/200 мкс == 3/20 = 0.15мкс.
Ещё может случиться "обмен с HOST'ом" (он, ведь, каждую миллисекунду случаться будет?) Это ещё команды непредвиденные.

В итоге, чтобы всё успеть, нужно делать фарш из опросов входов-выходов, фильтрации, и т.п.

Я вижу как минимум следующие варианты:
1) Оставить как есть и "в первой версии PRU среды" сделать режим, когда программист пишет полную программу (включая while true). Так сказать, отложить решение проблемы. При желании всё равно можно будет и ШД и энкодер в одной программе обслуживать, но придётся в правильные моменты добавлять опрос энкодера.
2) Вынести ожидание из ШД программы, и сделать так, чтобы основной цикл всегда вызывал все действия. Тогда в ШД блоке нужно будет добавить проверку "пора ли уже". Казалось бы, вот решение, но при этом точность упадёт. выход будет не "когда нужно" переключаться, а тогда, когда дойдёт управление до ШД блока. Это может оказаться 50-100 команд, т.е. 0.25...0.5 мкс.
3) При создании PRU программы указывать: "вот этот код нужно вызывать раз в 1мкс, вот этот раз в 20мкс, а у этого расписание плавает и он сам будет говорить когда надо". Вроде, подобное в КДС называется task configuration.
4) Ещё можно подумать над тем, что PRU программы будут не сразу входы изменять, а будут говорить "через какое время вход должен измениться".

В случаях 3 и 4 код "основного цикла" будет формироваться из фрагментов, предоставленных программистом и разбавляться проверками времени.

Возможно, есть ещё варианты.

Не совсем понятно какие проблемы в варианте 1.

В варианте 2 во время генерации импульсов период постоянно будет увеличиваться на 0,25...0,5 мкс ?

[Владимир Ситников]

Не совсем понятно какие проблемы в варианте 1.

В варианте 2 во время генерации импульсов период постоянно будет увеличиваться на 0,25...0,5 мкс ?

Проблемы варианта 1 в том, что "ппограммировать сложнее". Грубо говоря, у многих проблемы с пониманием цикла плк, а тут основной цикл придётся вручную целиком писать. Не домохозяйки, конечно собрались, но все же.

В варианте 2 будет рваный ритм. То туда, то сюда в зависимости от того, сколько каждый блок занял. ШД на разгоне и ШД во время основного хода занимает разное время.
Как разновидность 2го, можно всегда дополнять цикл, скажем, до 1 мкс. Выполнили все блоки, обменялись данными с хостом, и, если 1мкс ещё не прошла, то крутим пустой цикл (но с фильтрацией входов). Тут минус в том, что реакция будет привязана к этой самой "длительности цикла"