У вас есть возможность просмотреть отладчиком? Я собрал проект в Cub, пробежался по инициализации и обнаружил следующее: Структура заполняется для деления на 4, но! TIM3->CR1 & TIM3->SMCR начиная с 8-го бита задают делитель. TIM3->CR1 - внутреннего сигнала, а TIM3->SMCR - внешнего. В процессе инициализации в кубе происходит запись параметра ClockDivision в регистр TIM3->CR1... Это похоже на косяк куба. Можно попробовать перед включением таймера 3 вставить строку: TIM3->SMCR |= 1
Если вдруг получится обойтись без программного деления на 2 или 4 (в зависимости от настроек) то напишите пожалуйста. Я понимаю что деление на степени двойки для микроконтроллера относительно легко даются за счет сдвигов, но хочется совсем от них избавится
@domstudent7541 , в общем, энкодер из закромов у меня оказался точно такой, как и в видео - 4 отсчёта на щелчёк. К слову, бывает и 2, и сильно редко 1 отсчёт на щелчёк. Делить пришедшие импульсы на 4 у меня микроконтроллер заставить не вышло, а вот на 2 - легко. При инициализации просто нужно выбирать работу не по обоим входам энкодера, а по одному (ENCODERMODE TI1 или TI2). А аппаратный делитель таймера действительно, такое чувство, что не работает от слова совсем. НО!!! Если прескалер таймера после его инициализации установить на 2 ( TIM3->PSC = 0x1UL в моём случае ) - всё работает как нужно, правда с одной оговоркой - после перехода счётчика через ноль (крутнуть энкодер в обратную сторону). До этого, если крутить в плюс, считает по 2 импульса. Творится какая-то магия и ситуация однозначно требует дальнейшего расследования. :) Ах, да, и вторая оговорка тоже есть - после этих манипуляций приходит хана аппартному антидребезгу. В общем, ST-шники в очередной раз где-то набыдлокодили, а расхлёбывать простым пользователям. p.s.: нашёл интересную заметку по этому поводу. efton.sk/STM32/gotcha/g52.html
@@Seriyv0lk Спасибо за исследования! Теперь стало понятно почему и в документации на HAL, да и в самом ХАЛе запрещается выставлять прескейлер отличный от нуля) по поводу ENCODERMODE - это тоже логично и понятно, но деление на 2 и деление на 4 - по сути для процессора одно и то же. Была наивная надежда, что уж в новой то серии микроконтроллеров будет меньше багов. По этому то и отказался от bluePill, она со своим глючным I2C меня в своё время доконала до состояния что забросил на долгое время изучение. Спасибо еще раз, значит привыкаем к новым багам, и двигаемся дальше.
Не знаю что задумали в STM ,но у AVR есть спец бит установка которого при захвате сигнала с ноги, проверяется сигнал 4 такта. Если верны все то истина. Может тут нужно реализовать проверку на все 4 импульса?
К сожалению в офф. комьюнити даже предлагают использовать программное деление. Ну и этот вопрос тянется ещё с 2015 года на одном из форумов. community.st.com/t5/stm32-mcus-products/encoder-mode-counter-division-possibilities/td-p/116644 mcu.cz/forum_m/showthread.php?tid=2354
У вас есть возможность просмотреть отладчиком? Я собрал проект в Cub, пробежался по инициализации и обнаружил следующее:
Структура заполняется для деления на 4, но! TIM3->CR1 & TIM3->SMCR начиная с 8-го бита задают делитель. TIM3->CR1 - внутреннего сигнала, а TIM3->SMCR - внешнего.
В процессе инициализации в кубе происходит запись параметра ClockDivision в регистр TIM3->CR1...
Это похоже на косяк куба. Можно попробовать перед включением таймера 3 вставить строку:
TIM3->SMCR |= 1
Нужно будет проверить поведение энкодера. Как раз есть G030, распаяный на макетке.
Если вдруг получится обойтись без программного деления на 2 или 4 (в зависимости от настроек) то напишите пожалуйста. Я понимаю что деление на степени двойки для микроконтроллера относительно легко даются за счет сдвигов, но хочется совсем от них избавится
@domstudent7541 , в общем, энкодер из закромов у меня оказался точно такой, как и в видео - 4 отсчёта на щелчёк. К слову, бывает и 2, и сильно редко 1 отсчёт на щелчёк. Делить пришедшие импульсы на 4 у меня микроконтроллер заставить не вышло, а вот на 2 - легко. При инициализации просто нужно выбирать работу не по обоим входам энкодера, а по одному (ENCODERMODE TI1 или TI2). А аппаратный делитель таймера действительно, такое чувство, что не работает от слова совсем.
НО!!! Если прескалер таймера после его инициализации установить на 2 ( TIM3->PSC = 0x1UL в моём случае ) - всё работает как нужно, правда с одной оговоркой - после перехода счётчика через ноль (крутнуть энкодер в обратную сторону). До этого, если крутить в плюс, считает по 2 импульса. Творится какая-то магия и ситуация однозначно требует дальнейшего расследования. :) Ах, да, и вторая оговорка тоже есть - после этих манипуляций приходит хана аппартному антидребезгу.
В общем, ST-шники в очередной раз где-то набыдлокодили, а расхлёбывать простым пользователям.
p.s.: нашёл интересную заметку по этому поводу. efton.sk/STM32/gotcha/g52.html
@@Seriyv0lk Спасибо за исследования!
Теперь стало понятно почему и в документации на HAL, да и в самом ХАЛе запрещается выставлять прескейлер отличный от нуля)
по поводу ENCODERMODE - это тоже логично и понятно, но деление на 2 и деление на 4 - по сути для процессора одно и то же.
Была наивная надежда, что уж в новой то серии микроконтроллеров будет меньше багов. По этому то и отказался от bluePill, она со своим глючным I2C меня в своё время доконала до состояния что забросил на долгое время изучение.
Спасибо еще раз, значит привыкаем к новым багам, и двигаемся дальше.
@domstudent7541 в G4 можно сделать, чтобы такой энкодер считал один к одному. Там есть опция ENCODERMODE X1.
Не знаю что задумали в STM ,но у AVR есть спец бит установка которого при захвате сигнала с ноги, проверяется сигнал 4 такта. Если верны все то истина. Может тут нужно реализовать проверку на все 4 импульса?
К сожалению в офф. комьюнити даже предлагают использовать программное деление. Ну и этот вопрос тянется ещё с 2015 года на одном из форумов.
community.st.com/t5/stm32-mcus-products/encoder-mode-counter-division-possibilities/td-p/116644
mcu.cz/forum_m/showthread.php?tid=2354