По проблеме набегающей ошибки счётчика, при переходе из 'Rew' в 'Play':
Тут понятно, что направление хода ленты меняется и в этот самый момент система должна получить "сигнал", что пора считать в другую сторону. Но!... Если проследить как работает "исполнитель" (КР(А)) и "управляющий" (ПУ(А)), то становится понятно, что лента уже начала движение в другую сторону и только спустя какое-то время "исполнитель" даёт об этом знать "управляющему" - набегает ошибка и заметная. Что делать?
В идеале "управляющий" сам должен постоянно определять направление движения и моментально реагировать на изменение. Для этого обычно вводится двойная оптопара на подкассетник. Т.о. надо добавить ещё одну линию к МК. А есть ли у нас эта свободная линия? Проведена? Нет! У меня применена система получения импульсов, от магнитного датчика "MT6701", в режиме "ABZ" (есть 5 разных) и с него получаю квадратурные данные 'A' и 'B', как с энкодера, но беру только один из них. С оптики было бы так же, брал бы только один сигнал - дефицит свободных ножек МК. Т.ч. всё, проект можно закрывать, т.к. снова ничего не получилось?
Ваши варианты?
Для справки: вывод 'Z' "MT6701", в режиме 'ABZ' - показывает 0 градусов положения магнита, это удобно для регулятора громкости. Цитата из даташита: "После запуска "MT6701" может передавать несколько импульсов 'AB', которые соответствуют фактическому значению абсолютного угла, как показано на рисунке 8 (2). Таким образом, микроконтроллер получает информацию об абсолютном положении."
На самом деле не всё так безнадёжно. Сначала подумалось, что надо изменить протокол общения и в момент остановки ленты, со стороны "исполнителя" сразу дать знать, что лента остановлена т.к. "исполнителю" на месте виднее, что произошло событие. Но тогда придётся менять весь формат протокола общения по шине, т.к. факт изменения состояния ЛПМ присваивается переменной только после того, как протекут все переходные процессы (паузы для ЭМ, запуск и раскрутка мотора подмотки и тонвала, отключение 'Mute' и т.п.) и лента уже начала движение! Т.е. уже будет поздно.
Может можно что-то посылать в ответ сразу, а что-то после? Это сложнее для реализации, но в рамках протокола реально. Однако... Есть другой выход и только на стороне "управляющего".
Т.к. автостоп следит за движением ленты, то ему не составит особого труда дополнительно определить момент остановки ленты, недостаточный по времени для срабатывания самого автостопа и достаточно продолжительный, что бы его отличить от самых длинных промежутков реальных импульсов. Для этого "исполнитель" должен обеспечить паузу остановки ленты достаточной продолжительности. Если автостоп длится 1000 мСек, то самый длинный импульс имеем - 210 мСек. Это для скорости 4.76, при D=51 мм полного рулона и для 16 импульсов на оборот. Берём с запасом 300 мСек, т.е. 6 единиц (по 50мСек) переменной счётчика автостопа. Этот период надо обеспечить со стороны "исполнителя" и считать со стороны "управляющего". А что бы ему лишний раз этого не делать, то этот период простоя ленты будем ловить только когда новый режим ещё не объявился текущим. Т.е. когда есть разница между двумя переменными 'CurMode' - текущий режим аппарата и 'NewState' - заявка на новый. Переменная 'NewState' определяет в какую сторону нужно будет считать импульсы. Это должно чисто программно решить проблему. Лучшего решения не нашёл, но д.б. приемлемо. Так-с, шпору себе накатал, ухожу в процесс... Любопытно, нормально ли сработает теория?
З.Ы. Вот на чём себя на досуге поймал. КР - Коммутатор
Режимов, а у меня он оперирует
состояниями ЛПМ! Вроде как не состыковочка! Но! Думаю, что несоответствия тут не будет, если принять за логику работы такое поведение: коммутатор снаружи оперирует
режимами аппарата, т.с. исполняет или нет и отчитывается, вроде как высокий уровень. А изнутри оперирует низким уровнем - переводит бездушное железо в нужное
состояние. Хотя для исполнения он принимает команду на изменение
состояния из переменной 'NewState' за то, то что он возвращает, устанавливается в качестве текущего
режима в переменной 'CurMode'.
