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

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

Программирование PRU - это прежде всего реальное, детерминированное время выполнения. Трансляция кода с ЯВР никогда не покажет предсказуемого времени выполнения алгоритма, при наличии хотя бы одного ветвления. Для систем реального времени - это фатально.

Подучите теорию. ST это язык низкого уровня. В моих программах используются пока только BYTE/WORD/DWORD, как раз те типы, с которыми PRU процессор работает напрямую. Поэтому, язык на котором я пишу является "языком низкого уровня", хоть в нём и есть "человекопонятные IF/WHILE/CASE/и т.п."
Но, ладно, буду думать, что вы под словами "ЯВР" имели ввиду "не ассемблер".

Вот, уже второй говорит, что "фатально" (первый был Владислав)
Хватит бросаться словами.
Без ветвлений вообще невозможно нормальную программу сделать. Иначе процессор выполнит свои 1024 инструкции и остановится.
Хочешь не хочешь, а ветвление необходимо.

Откройте END_1_1.asm и посмотрите сколько там ветвлений (там есть условные переходы).
Откройте PRU_OUT1.asm и посмотрите сколько там ветвлений (и там есть условные переходы).


Лучше бы показали пример, где ваше "предсказуемое" время прямо так реально нужно.

И, да, не забываем, что у всех моих алгоритмов время работы предсказуемо.

Кроме того не забываем что время выполнения даже чистого С (лучших трансляторов) увеличено в 2 -2.5 раза по сравнению с ассемблерным кодом (не оптимизированным по ухищрениям! там разница еще больше). Для близкого к данной теме примера - код написанный на ST выполняется раза в 3 медленнее описания алгоритма на IL, оптимизировал для быстрого таймера поэтому натрахался с этой темой вволю

Вы сказали, только то, что в КДС плохой компилятор ST. Да, компилятор КДС туп как валенок.
И?

Как "плохой компилятор КДС" влияет на мой компилятор ST?
Правильно, никак.

Если вам нравится "IL вволю" -- я ни коем образом не останавливаю. Но поймите, что "трахаться с IL" равно как "трахаться с PRU ASM" очень мало кому нравится.
Людям нужно реальные задачи решать, а не воевать с ассемблером.

Для контроллеров также весьма критичен размер кода... знает ли господин Ситников что у него в распоряжении всего 1 кслов памяти программ? что-то сомневаюсь, ибо он в код ПРУ загоняет и блоки умножения деления.... и это он еще собственно рабочий алгоритм не начал ....

Во-первых, не "1 кслов памяти", а 4 килобайта, т.е. 1024 команды.

Алгоритм ШД с разгоном и торможением уже реализован.
Графики разгона-торможения получены с реального алгоритма.

Этот самый блок ШД со всеми квадратными корнями занимает 342 команды.
Ещё немного добавится на обмен с HOST'ом, поэтому пока никаких проблем нет. Если реально будут проблемы с размером кода, то поработаю над этим.

даже квадратный корень считает, есть "мамонты" которые сами писали эти алгоритмы и помнят сколько кода они забирают? ))...

Смеётся тот, кто смеётся последним.
SQRT(DWORD): DWORD занимает 16 PRU команд.

Если вы не поняли, то это доказывает, что вы не понимаете то, о чём пишете. 16 команд на блок квадратного корня вполне можно себе позволить.

Среда разработки которую предлагает он лучше всего подойдет для приложений hello_world, и конечно пригодиться в жизни, но сейчас это не самое важное. Разумеется это предложение интересно и безусловно имеет право на жизнь, но не в этой теме.

Моя среда, как минимум, позволяет делать полноценную программу для ШД. С разгоном и торможением. С перемещением на ровно указанное количество импульсов.

Hello_world это или нет -- не важно. Важно то, что мой подход позволяет решать реальные задачи на производстве. Вариант "от ОВЕН" -- не позволяет.

Более того, можно даже энкодер и ПИД управление (этим самым ШД) прикрутить, если есть потребность в таком управлении.

Есть концепция овена, которая предлагает именно РЕАЛЬНОЕ ВРЕМЯ и стыкуется с системами программирования логических контроллеров. Данная тема заведена разработчиками для тестирования предложенной технологии, отладки и доведения до уровня беспроблемного применения. То что происходит - злобный оффтопик ))))

Компания ОВЕН свою технологию предоставила.
И компания получила обратную связь. На этой технологии невозможно ни разрабатывать, ни тестировать, ни отлаживать.
Разумеется, на каждую даже самую ужасную технологию найдётся один-два человека, которому именно она в кайф и будет, но в целом, всем стало понятно, что:

1) Есть реальные задачи на применение 100кГц от ПЛК110. Например, управление ШД
2) Предоставленный ОВЕНом инструмент непригоден для общего применения. Блок ШД на инструменте ОВЕН если и можно сделать, то это займёт уйму времени и нервов
4) Упоминаемого "реального времени" пока никому не нужно. Вместо абстрактных слов "реальное время" лучше бы привели пример, где и как это реальное время пригодится на производстве.
Например, задача "ШД с разгоном" понятна всем. Всем понятно почему на простых выходах ПЛК это сделать не получится. А слова "реальное время" это какой-то миф.

Если кому-то интересно что именно я делаю - решаю вопросы своей работы )) В текущий момент - это и модуль энкодера и шаговый двигатель, синхронизированный с энкодерам по плавающему алгоритму. В настоящий момент с уверенностью могу заявить что PRU это круто и за ним будущее! Будет свободное время - формализую модуль по стандартам модулей овена.

Покажете исходный код?
Я уверен, что если просто переписать его на ST, то будет на порядок понятнее, и наверняка более оптимально (по скорости, количеству использованных регистров и всему что только можно).

Я не говорю, что "мой компилятор генерирует код лучше, чем любой рукописный", но я категорически не согласен с тем, что "переписывание на ST замедлит код в 2-3 раза".

И, да, даже, если вдруг замедлит в эти самые 2-3 раза, то частота PRU закрывает это с лихвой. Например, при управлении ШД, процессор простаивает больше 97% времени.
Поэтому на первый план должна выходить не "оптимальность кода", а "сложность поддержки", "возможность отладки" и т.п. Вот у варианта на ассемблере шансов на "исправление ошибки сторонним человеком" никаких нет.

И, да, если покажете пример хоть какой-нибудь программы для PRU1, то скажу большое спасибо. Я пробовал читать "регистр счётчика выполненных команд по адресу 0x7800+0xC", но почему-то не работает. У PRU0 счётчик команд находится по адресу 0x7000 + 0xC, а у PRU1 должен (вроде как) быть в 0x7800+0xC.