shonty, блин ну я же совсем подругому предлагаю, добавил выше

AlexS4, да, этот код подходит и к моему "неполноценному" енкодеру подходит, а про помехи какие мысли будут?

Добавлено after 2 minutes 59 seconds:
но вопрос: по какому условию сдвигать регистр? если при каждом опросе, то если я буду крутить медленно - то такой паттерн никогда не соберётся...
если по изменению, то даже небольшой дребезг и будут большие пропуски, ведь этот паттерн это даже не 3, а 4 проверки и если система нестабильна - пройти их будет трудно...

я же выше напсал детально viewtopic.php?p=4683673#p4683673

Добавлено after 6 minutes 4 seconds:

думаю надо попробовать, скорее всего при правильном времени таймера семплирования ~5..20mS
будет много попадений, пасаны ж утверждают что антидребезг это ненаучная хрень и КОТельников типа против такого

но если таки нет то можно перед этим применить алгоритм антидребезга проверяющий стабильность 2х последовательных семплов
(еще выше писал) тоесть двигать по 2му одинаковому сэмплу. для этого для таймерного прерывания потребуется выделить еше 1 статическую переменную (регистр) с предыдущим семплом в 2х битах.

я попробую но с 3мя, а не с 4 мя семплами в памяти (заносить буду в 3 и 4 бит, т.е. 2 младших бита не будут использоваться и будут всегда нулями и в рабочем регистре и в маске сравнения)

нене это против концепции!! заноси все
а вот паттерны можно более короткие применять,
нормализовать окно (and/or mask) при этом ненужно, важно только чтоб неиспользуемые биты паттерна были заполнены теми же значениями на которые ресетится EcSeq переменная при совпадении паттерна (удобно 0 заполнять в avr)

оно же наполняет EcSeq по факту до 1го совпадения с паттерном, а дальше веравно ресетит и продолжается набор последовательности

ну конечно важно чтоб цикл проверки паттернов был достаточно быстрым (не перегруженным долгими непрерываемыми алгоритмами) чтоб не пропускать "лишние" семплы в последовательнось от таймера. но для энкодера это 10ки mS, так что врядли с этим могут быть проблемы.

В оригинале были битовые поля, 15 флагов занимали 2 байта, а у вас структура из 12 bool занимает 12 байт.

я принцип не меняю и заношу всё, просто обрезаюне слева, а справа, при этом экономлю и флеш и время (зачем чтото чистить, если можно и не мусорить?) тем более у меня входы на 3 и 4 бит приходят - достаточно на 1 вправо сдвинуть и вуаля...

а чистить же всеравно нужно! сразу после обнаружения совпадения!
иначе последовательность будет продолжать совпадать с паттерном и вызывать процедуру +1 или -1 снова и снова ...пока энкодер еще раз не потрогают и он не даст чтото отличное от паттернов

а вот проверка длины записанной последовательности это ненужное усложнение (довольно критического к избыточностиям) обработчика прерывания

слева и справа - совершенно без разницы, я сначала ж предложил в младшие задвигать, а потом просто заметил что битовое бинарное представление паттерна становится более наглядным при задвигании семплов со старших битов (ror)

struct __attribute__((packed)) ButtonFlags {
bool btn_deb : 1;
bool hold_flag : 1;
bool isHolded_f : 1;
bool isRelease_f : 1;
bool isPress_f : 1;
bool step_flag : 1;
bool oneClick_f : 1;
bool isOne_f : 1;
bool inv_state : 1;
bool type : 1;
bool tickMode : 1;
bool noPin : 1;
};

спс за уточнение. не знал .

AlexS4, да, после обнаружения совпадения - конечно, его (это совпадение) надо разрушить...
длину записанной последовательности я и не проверяю.

в остальном спор ни о чём: для мк без разницы, откуда задвигать...
просто мне нет нужды двигать до края (+2 команды), чтобы потом перед сравнением накладывать маску (ещё +2 команды), ведь там скраю, от которого двигаешь, неоткуда взяться данным и там и так всегда нули пока сам туда ничего не внесёшь, а значит ни маскировать ни чистить ничего не надо.

если я правильно понял, то доп двигать сэмпловый регистр никуда не нужно в любом случае,
просто неполный (короткий) паттерн должен быть дополнен 0ми (точнее дефолтным послесбросовым заполнением) с нужной стороны. это просто вопрос формирования хардкодной константы.

У меня с прерываниями простое правило: где необходимо, прыгаю в прерывания, в остальных случаях обработку флагов прерываний провожу в окнах основного круга программы. В прерывании минимально необходимые действия.
Вот и в моём примере с кнопками не использую таймер с прерываниями, условия задачи это позволяют. Здесь таймер с прерываниями – лишнее усложнение задачи, зачем это нужно.


Может быть, не я это был. В 2017 году всё только начиналось, да и было это несерьёзно.

Какой же это секрет? Всё в конечном итоге сводится к машинным кодам, фактически, к ассемблеру. Только на ЯВУ, которые нехороши, код сильно «раздувается».

Не представляю ситуацию, где можно МК напрямую подключить к сетевой фазе.

Думаете много есть людей в русскоязычном пространстве которые, как минимум раньше, юзали АБ, а сейчас пишут для AVR на хорошем/современном/макро ассемблере которого нет в общем доступе, при этом С они не знают и примеры приводят на бейсике? И в каком там состоянии этот ассемблер был в 2017-м вообще не важно, вы и сейчас популяризируете то, чем другие пользоваться не могут )

А в чем вы видите проблему такого подключения? Намекну, в любой стиральной машине МК подключен напрямую к сетевой фазе. Точнее, может быть подключен с вероятностью 50%.

И не только в стиральной машине. В холодильниках МК зачастую питаются от бестрансформаторного БП.

Давно читаю эту тему и просто опишу что у меня работает. 24 входа обновляются каждую миллисекунду в три байта, в последствии каждый бит проходит через фильтр переменной, устанавливаемой юзером длиной, берётся этот параметр из таблицы 24 + 24 байта, соответственно на 1 и 0 отдельно, Длина настройки байт, то есть 0....250, четверть секунды максимально. На каждый входной бит оперативка используется по два байта, на счётчик единиц и счётчик нулей отдельно. Получается в итоге то чтобы на выходе фильтра установилось значение это нужно насчитать совпадений всех выборок согласно таблицы от 0 - это получается выход в точности копирует вход, и до 250, когда нужно чтобы вход повторился 250 раз. Программа написана на ACM2 в AStudio. Потребляет в самом коротком случае 17us, до самого длинного случая 30us. Главный цикл 1 ms, вот и вызывается эта программа сразу после обмена вход/выход. Можно было конечно количество оперативки необходимой уменьшить, но у меня была главной задачей это скорость, по этому код долго вылизывался. Дополню ещё что для кнопки достаточно выставить 30.30 или 40.40 и уже никто не сможет протрезвонить кнопкой, кнопка чётко отрабатывает нажатие, дал специально стенд человеку чтобы он увидел дребезг, не смог, сдался. Чуть не забыл - ATmega 168 - 20 mgz.

Эх, слабак человек.) То же мне тестировщик.(

Я ему провода для подключения выдал на стенде, так что он мог подключать любые кнопки или концевики, ну светодиод при каждом нажатии просто инвертировал своё состояние.

Ну какой это тест? Это не показатель. А люди, как известно, разные. Один просто шустрый, а другой чемпион и что?)
Вот ARV говорит что люди не могут нажимать быстрее 50 мс (не помню), а Старичок вообще 100 мс (не помню) ставит на нажатие. Это его реакция - значит другие быстрее быть не могут.)

Я сам юзал эту кнопку и нашёл правильный ответ - 30.30 или 40.40, Очень удобно, можно например 250 выставить, тогда получается удерживать надо. А если 0 выставить, то тут кошмар - светодиод остаётся в непредсказуемом состоянии, конечно от кнопки всё зависит, тогда я себе сказал - я программист и знаю как кнопку обмануть, тогда и пришла мысль чтобы кто нибудь другой эту кнопку понажимал.