NuSen писал(а):
Корректор крутить нужно медленно, чтобы не пролететь через 0,
Вот это новость для меня. Пересмотрел весь код, покрутил с разной скоростью энкодер в данном режиме и пришел к выводу, что сие (переход через 0) невозможен.
Во-первых, в обработчике, что обслуживает поворота энкодера в режиме подстройки корректора режима БП в сторону его уменьшения, не обрабатываются флаги увеличения скорости вращения энкодера (всего существует три признака скорости вращения). Соответственно, бесконтрольного "перелёта" от скорости вращения быть не может никак.
Во-вторых, в том же самом обработчике стоит проверка этого "перелёта" и защита от него:
Код:
if(--Ucompensation<1)Ucompensation=1;
Данная строка одновременно минусует содержимое переменной Ucompensation на единицу и одновременно проверяет её содержимое. И если оно достигло нуля, то поправляет 0 на 1, как раз не давая ему перейти через ноль. Таким образом содержимое Ucompensation никак не может опуститься ниже цифры 1, а если переменная и становится нулём, то всего лишь на считанные такты машинного времени (несколько микросекунд, при тактовой частоте 8мГц - именно на неё настраиваются фьюзы Атмега32). В прерываниях никаких вычислений, на которые бы влияла данная переменная, у меня не ведутся, а других возможностей выполнять задачи
как бы параллельно основному процессу у атмега32 нет. Потому временное нулевое значение переменной Ucompensation не страшно. Тем более, что через несколько микросекунд оно станет равным 1 по условиям.
Вероятно существует совокупность случаев, которая выявляется в странной работе устройства и требует полного сброса EEPROM. Это я признаю, но причин этому я так и не нашел. Возможно, было бы не плохо иметь возможность сбрасывать не все переменные стразу, а лишь некоторые, которые отвечают за конкретный участок.