FlProg

Энкодер на прерываниях можно использовать только на малых скоростях , прерывания останавливают исполнение кода, а если у вас 4 энкодера то это может сказаться на времени цикла с увеличением скоростей перемещения

может тогда специальную микросхему для энкодера?

Наверное это хорошее решение , только я такую микруху не знаю и ведь ее еще нужно считывать по какому то протоколу не реже чем такт расчета.. Скорее всего надо использовать одну СТМ на одну ось.
есть еще ход.... Использовать прошивку GRBL там проблемы с управлением шаговиками решены . и есть парсер G-кода и планировщик движения. осталось только разобраться управлением по Modbus ASCII и можно реализовывать проекты с движениями

В режиме энкодера таймер занят подсчетом импульсов и больше он ничего не делает: ни шимит, ни обрабатывает второй энкодер. Раз он аппаратный, то это значит, он работает автономно, без участия КПУ. А прерывания использует как обычно: при переполнении и наверняка без луп.

Про микруху Я уже думал они дорогие

совершенно верно, при обсчете энкодера таймером все так и происходит. Когда речь идет о прерываниях я говорю о программной реализации обсчета, это там могут быть проблемы с лупом

Попробую завтра подключить энкодер, посмотреть, будет ли он работать в Arduino IDE, но опять же, всех потребителей он не обслужит ваших.

К примеру, даже если на один таймер посадить четыре драйвера, то он не сможет реализовать раздельный плавный пуск и плавное торможение для каждого канала независимо. Там будет одинаковая частота на все каналы идти.

Как вариант, попробовать на Raspberry почитать. Там восьмиблочная система. Про энкодеры не знаю, не интересовался там.

Ещё вариант: у меня валяется СТМ 401, можно на нём попробовать почитать возможности.

В общем, видимо, за столько лет не хватило ума вывести библиотеку из HAL в Arduino. Либо энкодер там совершенно никому не нужен. В общем, не работают STM-библиотеки тут. При попытке вручную прописывать регистры на работу с энкодером вроде бы работает, но жуткие дребезги иногда появляются. Данные не выводил, но вывел на отдельный пин наблюдения срабатывание по смене состояния энкодера для анализатора. И ещё обнаружилась аномалия: по мере вращения энкодера на нём есть небольшой участок длины окружности, в котором пин наблюдения принимает 1 и от неё сбрасывает в 0. Возможно, это особенность конструктивная энкодера, но как то это странно.
Режим выбрал x4, где он считает один полный импульс энкодера:
Передний фронт канала A,
Задний фронт канала A,
Передний фронт канала B,
Задний фронт канала B.
Итого четырёхкратная запись в щётчик.
Тогда придётся строить программное расширение до 32 бит.

А так, у STM пины оказались очень медленными, чем у Arduino. Зациклить получилось на 1143 кГц для подсчёта быстродействия, то есть имеем 875 нс. При добавлении кода энкодера скорость МК просела до 923 кГц, это 1,083 мкс (потому что в лупе добавилось две строчки: чтение счётчика и сравнение условия). И как только появляются фронты, на каждый фронт скорость падает до 800 кГц, это 1,25 мкс (это срабатывает условие, чтобы изменить состояние пина наблюдения). И если не брать во внимание лишние строчки кода в лупе на чтение и дёргание пина наблюдения, то, в общем, делаем выводы, что энкодер действительно никак не влияет на CPU и работает сам по себе аппаратно.
Это тесты на чистовом коде, под флпрог скорость упадёт заметно, но на энкодере это никак не скажется.


Притом первый импульс всегда длиннее второго, независимо от направления вращения.

По поводу помех: есть аппаратная фильтрация, но с расширенным выбором пока нащитал 16 штук вариантов, пока не понятно, разве что методом тыка сравнивать их.

Не знаю, как с механикой, но для оптики он более предпочтителен, судя по таблице скорость у него до 36 МГц распознавания.
Осталось померить, как тормозит программный расширитель счётчика.

А какой энкодер использовали? импульсы должны быть пропорциональны углу поворота
А просадку в скоростях дает программное расширение до 32 бит?
А какой таймер использовали и к каким пинам подключали треки А иВ?

Обычный ручной, на 20 импульсов оборот.
Конечно, просадит там же прерывания. Более того, думаю, на высоких скоростях ещё и потери будут.
Таймер2, А0, А1.

Вот если бы DMA подрубить, то можно создать виртуальный счётчик без прерываний попробовать.
Да и данные его уже не нужно крутить в лупе, а там уже и высокие скорости обрабатывать.

С фильтром пока не понял ещё. Там что-то типа счётчика, который задаёшь импульсы от тактовой частоты. При этом выбираешь несколько делителей, у которых также можно задать количество импульсов на пропуск. Я поставил максимум, но почему-то там в какой-то момент импульс пролазит всё равно, хотя он был меньше фильтра.
То ли он не подрубился, хотя нагрузки на CPU там не было в этот момент. Ну, то есть, там не определил я, потому что он фильтр аппаратный, он что так на CPU не создаёт нагрузки что я прописал ему регистры с битами, тоже не создали нагрузку на CPU?
Да, и буферный счётчик делать на 32 бита я ему там долго буду сидеть, накручивать, чтобы его переполнить.
А если из него делать комплиментарные пары энкодер плюс шаговый, то это получается два энкодера, два шаговых на каждый таймер по одному. Плюс у каждого энкодера будет ещё виртуальный буфер на 32 бита. То есть, там прерывание ещё больше будет. Либо объединять два таймера на 32 бита. Но тогда останется один таймер на шаговый плюс один запасной.
Но в любом случае, это дешевле, чем покупать спецмикросхему, допустим, ту же LS7366 на 32 бита, но частота там до 10 МГц.

а если переполнением одного таймера тактировать второй таймер мы не получим суммарный аппаратный обработчик энкодера на 32 бита?
Конечно в этом случае на один камень больше одной связки шаговик -энкодер не поместится, но как вариант

кстати программный счетчик переполнений не должен создать большое кол-во прерываний . всего одно через 65536 шагов

Я и говорил объединить два таймера в один и тогда никаких прерываний не надо всё работает в фоновом режиме

Ну я на Али встречал энкодер на 5000имп
Но мне пока интересно попробовать вариант с дма
И разобраться с фильтрами ещё
Возможно у блупилки понижены частоты тактирования таймеров потому что я не увидел шума в нс как в прошлый раз когда они были
Объединение таймеров это уже когда ничего не получилось

MM33 писал(а): 10 дек 2025, 17:01 кстати программный счетчик переполнений не должен создать большое кол-во прерываний . всего одно через 65536 шагов

можете потестить его на оптическом энкодере
а то мой механический в пару областей окружности начинает сбоить
тоесть идёт сырое значение кратное 4 = 4 8 12 16 19
немогу резко крутануть да и вообще круг сделать раз он начинает цыфры жувать дребезгом

PA0 PA1

Обязательно потестю , постараюсь сегодня или в понедельник

да я уже подразобрался
до часу ночи сидел регистры менял
оказалось всё таки энкодер отвратительной сборки
допустим вместо того что бы показать 16 фронтов он показывает 17 но если легонечко потянуть ручку по люфту то становится 16 отпускаю становится 17
тоесть там зазоры в энкодере на ширпотреб сделаны
от чего он улавливает фронт следующего первого фронта на другой импульс

почему то проект не компилируется
Arduino: 1.8.19 (Windows 10), Плата:"Generic STM32F1 series, BluePill F103CB (or C8 with 128k), STM32CubeProgrammer (SWD), Enabled (generic 'Serial'), None, Low/Full Speed, Smallest (-Os default), None, Newlib Nano (default)"

C:\Users\ММА\AppData\Local\Temp\flprog\pr3\pr3.ino: In function 'void setup()':

pr3:22:21: error: expected primary-expression before '=' token

pr3:23:21: error: expected primary-expression before '=' token

pr3:24:19: error: expected primary-expression before '=' token

pr3:25:19: error: expected primary-expression before '=' token

pr3:26:19: error: expected primary-expression before '=' token

pr3:30:18: error: expected primary-expression before '=' token

exit status 1

expected primary-expression before '=' token

Версия FLProg 9.5.6

норм было я там блок кинул другой ветке

MM33

А у вас есть энкодер программный Вы чем-то до этого пользовались на какой-то библиотеке хочу сравнить производительность в одинаковых условиях

Хороший программный энкодер выставлял Drundel в теме Энкодер Pro,но он для AVR/ Я делал для себя аппаратный, на регистрах для STM но он более громоздкий чем ваш, ( я не программист, делал по образцу из аппаратного генератора, долго разбирался с регистрами) хотя в пределах 16 бит работал.