В ФБ для ШД надо ограничиться максимальной частотой в 200 кГц. Минимальный полупериод следования импульсов будет 2,5 мкс. Этого времени должно хватить для опроса быстрых входов, к которым подключены энкодеры.
В ФБ для ШД надо ограничиться максимальной частотой в 200 кГц. Минимальный полупериод следования импульсов будет 2,5 мкс. Этого времени должно хватить для опроса быстрых входов, к которым подключены энкодеры.
Начну с варианта, когда длина цикла фиксирована.Сообщение от Вольд
В конце концов, это не помешает сделать переменную длину цикла, если в пользовательском коде добавить while true...
Ещё вопрос: безопасные состояния, watchdog, вот это всё, нужно?
Если, вдруг, PRU заклинило, то в основной программе должен флаг аварии взводиться? Или перезапуск PRUграммы?
Я склоняюсь к флагу "авария", а перезапуск PRU уже не автоматический, а по запросу основной программы.
А по какой причине может произойти останов PRU программы и как это выявить ?
Что делать при останове PRU программы надо решать в основной программе.
Последний раз редактировалось Вольд; 13.10.2016 в 18:06.
Например, ионизирующее излучение, удар молнии, проблемы с питанием, ну и "кривой код" в конце концов.
Выявлять можно во время очередного обмена данными. Смысл в том, что для обмена информацией PRU и host в любом случае должны как-то координироваться. Если host будет ждать ответа от PRU бесконечно долго, то к нему самому придёт собака. Поэтому, логично при операциях обмена использовать таймаут. Скажем, 100ms. Если достигнут таймаут, то считаем, что обмен не состоялся, а pru, возможно, заклинило.
Аналогично, на стороне PRU можно следить за частотой обменов и переходить в безопасное состояние, если host давно не общался с PRU.
Вот описание энкодера буржуйского контроллера ЭНКОДЕР.rar
Ваши права
Ответить с цитированием