Это BLINK, который выдаёт бесконечное количество импульсов 0 1 0 1 с указанными длительностями 0 и 1. Если штатный "fast PWM из конфигуратора" не работает, можно сделать свой, рабочий.Сообщение от приборист
Ок, скажу прямо: я без проблем сделаю и могу сделать среду, что "любой, кто смыслит в ST или FBD" сможет сделать свой BLINK.
Но нужно чтобы кто-то выбил это из ОВЕНа.
1) Тут не только "знать секрет" нужно, а получить хоть какое-то подтверждение, что ОВЕН хотя бы "будет стараться не ломать" этот механизм в будущих прошивках.
Да и вообще: случись что со мной. И что? "Секрет дамасской стали" утерян?
Ну, с одной стороны, единожды написанную программу PRU0.prg менять не нужно.
Но, блин, крайне шаткая позиция.
Тут применение "других контроллеров" может быть более оправдано даже с точки зрения "поиска ZIP", "возможности доработки в будущем".
Сейчас всё держится на несущей зубочистке.
2) Тем не менее, Владислав изначально заявлял, что не видит смысла в моём варианте PRU программирования (по разным причинам). Здесь наличие реально работающей программы легко послужит "контрпримером". Т.е. не просто "доказана возможность писать для PRU на нормальном ST / FBD", а прямо реальный проект.
Как-никак, это аргумент, и оспаривать его словами в духе "такая концепция программирования неконцептуальна" крайне тяжело.
Ну, быстрый энкодер-то работает? Он цепляется на быстрые входы, а все быстрые входы разведены на PRU1, значит управление двумя PRU хоть в каком-то виде должно работать.А поддерживается ли сейчас PRU1.prg на уровне прошивки?
Может не думали, что пытливые умы заинтересуются, сделали PRU0.prg и забили.
Возможно, не работает "прямое общение HOST-PRU1", но это можно обойти, если пересылать данные с помощью PRU0.
Ответить с цитированием