В связи с возможными изменениями угловой скорости ротора, замыкающего контактные группы от типовой программной обработки антидребезга с фиксированной длительностью задержки опроса линии датчика решено было отказаться.
Вместо этого применен позиционно-привязанный вычисляемый условный переход на ячейку, содержащую вектор перехода на последующий участок программы.
Занудно...
Может графическая картинка пояснее будет...
http://img.radiokot.ru/files/20529/10olmil01x.GIF
Сама программа состоит из стартовой точки и двух ветвей согласно возможному направлению перемещения ротора. В каждой из ветвей последовательно обрабатываются несколько позиций таким образом, чтобы в каждой точке обработки из возможных 4-х состояний входных линий корректными являлись только три. Четвертое состояние при нормально работающих контактных группах является логически невозможным (аварийный статус).
Таким образом предусматривается возможность движения вала как в прямом , так и в обратном направлении из любой позиции в любой из двух ветвей программы. Причем при многократном "ерзании" от стартового для текущего направления (01 или 10 но не до 11!) в рабочее 00 тактовый импульс генерируется только один раз.
Для увеличения быстродействия решено отказаться от применения флагов кроме флажка запрета повторной генерации тактового импульса. Хотя такой подход и породил две независимые ветви для каждого из направлений перемещения вала.
Дополнительно используется участок ожидания нейтрально-исходного положения вала (оба контакта пассивны) для обработки в момент подачи питания и в случае обнаружения сбоя контактной группы (с возможным пропуском одного и/или нескольких позиций перемещения вала). Необходимость такого дополнения вызвана результатом макетных испытаний первого варианта программы ( с блокировкой по обнаружении ошибки) — при некоторых «стечениях обстоятельств» пакеты от индуктивного выброса в соединительных проводах в момент коммутации контактов имеют весьма значительную длительность. При дополнении защитного фрагмента сбои исключаются... НО... автоматически могут быть пропущены от одного до нескольких последовательно идущих импульсов положения ротора.
В принципе... для «рукояток — крутилок» такой пропуск не есть проблема.
На выходе будем наблюдать пульсирующий сигнал направления с присутствующим внутри него счетным импульсом. Ежли чисто теоретически — без учета антидребезга - диаграммы сигналов на выводах предобработчика будут вышлядеть таким образом:
http://img.radiokot.ru/files/20529/10olkrmhx0.GIF
Наиболее удачным для вышеприведенного алгоритма представляется система команд МК семейства PIC. Однако «с оглядкой» - по причине отсутствия переноса из PCL в PCH (можно правда макросом подправить — но «командов много» будет). В других семействах возможна табличная организация с доступом через DPTR(mcs51) и/или Z(AVR). Одначе... такая «пересадка» требует проверки не только по написанию кода, но и по экономической целесообразности (ежли часть ПО устройства — пригодится, ежли автономный преобразователь — даже тинька 13-я «жирновата» будет...).
, тут удобнее применять STM32 - там бесплатного хватает выше крыши.
