Программирование PRU - это прежде всего реальное, детерминированное время выполнения. Трансляция кода с ЯВР никогда не покажет предсказуемого времени выполнения алгоритма, при наличии хотя бы одного ветвления. Для систем реального времени - это фатально.
Кроме того не забываем что время выполнения даже чистого С (лучших трансляторов) увеличено в 2 -2.5 раза по сравнению с ассемблерным кодом (не оптимизированным по ухищрениям! там разница еще больше). Для близкого к данной теме примера - код написанный на ST выполняется раза в 3 медленнее описания алгоритма на IL, оптимизировал для быстрого таймера поэтому натрахался с этой темой вволю.
Для контроллеров также весьма критичен размер кода... знает ли господин Ситников что у него в распоряжении всего 1 кслов памяти программ? что-то сомневаюсь, ибо он в код ПРУ загоняет и блоки умножения деления и даже квадратный корень считает, есть "мамонты" которые сами писали эти алгоритмы и помнят сколько кода они забирают? ))... и это он еще собственно рабочий алгоритм не начал ....
Среда разработки которую предлагает он лучше всего подойдет для приложений hello_world, и конечно пригодиться в жизни, но сейчас это не самое важное. Разумеется это предложение интересно и безусловно имеет право на жизнь, но не в этой теме.
Есть концепция овена, которая предлагает именно РЕАЛЬНОЕ ВРЕМЯ и стыкуется с системами программирования логических контроллеров. Данная тема заведена разработчиками для тестирования предложенной технологии, отладки и доведения до уровня беспроблемного применения. То что происходит - злобный оффтопик ))))
Если кому-то интересно что именно я делаю - решаю вопросы своей работы )) В текущий момент - это и модуль энкодера и шаговый двигатель, синхронизированный с энкодерам по плавающему алгоритму. В настоящий момент с уверенностью могу заявить что PRU это круто и за ним будущее! Будет свободное время - формализую модуль по стандартам модулей овена.




Ответить с цитированием