Сегодня предприятия сталкиваются с комплексным вызовом, когда даже высокие зарплаты не компенсируют тяжелые условия труда в глазах молодых специалистов. Особенно остро проблема стоит в моногородах, где традиционно располагаются горно‑обогатительные комбинаты.
Если корову меньше кормить и больше доить.. то она будет что? "Конечно больше доиться и меньше кормиться" с точки зрения таких вот генеральных (гениальных менаджеров) как автор статьи.
У меня есть знакомые из Междуреченска.. 150 тыс говорите... ну ну. А сами за 60..70 (по факту) не пробовали смены в забое в аварийных шахтах отрабатывать? И деваться на кузбасе из этого гребанного Междуреченска некуда и работы никакой другой по слути там нет.
А самое обидное что этот "Дмитрий Лохов" после того как все окончательно накроется уйдет с "портфелио" куда ни будь еще.. руководить.
А я не вижу в этом описание условия ограничения самого счетчика. Есть только условия на флаг. А фраза "без переполнения" != "ограничен сверху значеним порога а снизу 0".
Да я нудный. Но слишком часто приходилось тратить на переделку и общение с заказчиками из за "подразумевалось".
Что мне не понравилось в вашем конкретном примере, это то, что нижнего порога у вас нет.
Обратите внимание, что я несколько раз говорил в первых постах что специально не буду додумывать за.. Поэтому пример сделал специально утрированыным срого по описанию.
И прекрасно осознаю, что если у автора по факту работало, то это просто алгоритм не до конца описан.
Эхх. Никогда не нужно в ТЗ/описании додумывать за кого то. "это логично", додуманное за кого то (если четко не описано), ведет в ад.
Это применительно ко всему.
Я не оспариваю ваш вариант. Классический вариант плавующего окна (счетчик с ограниченим и тригерное значение). Но только в исходном описание детали пропущены, которые уже "додумываются" :)
Ну так это и есть доп. типа "а мы это подразумевали". Только что на работе с этим столкнулся (конечно не по столь простому случаю). И жду ответа "а что вы подразумевали?". . вот поэтому и фигней сейчас страдаю на хабре :)
Условно, досчитали до 5, выставили флаг, что кнопка нажата
Да. флаг выставили. Но нигде не сказано, что счетчик в 0 сбросили или перестали +1 при нажатой кнопке. Фактом выставления флага же все не заканчивается. Т.е. можно продолжить ... 4,5,6,7,8,.. (кнопка же нажата)
Занудничаю.. Но тут и по работе в постановке задачи "а мы это подразумевали" наложилось.
в этой ветку был коммент про "по-хорошему, надо энкодер соответствующий использовать". На него и тригернуло.
Похоже подумали, что я на Ваш счет.. Не.. даже не думал. Извините именно Вам не хотел. Да и даже не к исходному комменту. вообще "про ардуинщиков" было "лирическое отступление" и в не том комменте что нужно.
новый переходной процесс (отпускания). Для демонстрации поведения счетчика "+1/-1 от сэпла". Что счетчик по формулировке алгоритма продолжает щелкать при нажатой кнопке.
Мне фраза одного из комментаторов "по-хорошему, надо энкодер соответствующий использовать, а не лепить из того есть под рукой." напомнила просьбу помочь с "почему у меня ошибка с энкодера накапливается" (что то там про балансирующего робота, где это было очень важно).
На все попытки объяснить что такое джиттер энкродера и почему нужно использовать аппартные счетчики для квадратурного энкодера вместо программной реализации, и почему не нужно исопльзовать прерывания на сигналы от экодера..
Последовал вот почти такой же ответ. Типа у меня экодеры видимо дерьмо и попробую другие. Т.е. человек даже не хотел вникать в причины. Все просил дать ему ссылку на работающую ардуино либу.
Так что.. да. Агрессия и клеймо "ардуинщик". Может у меня шаблон в голове на "ардуинщик". Но асоциация такая:
Хочет найти готовую либу.
Не хочет вникать как работает "работает и ладно".
От електронники далек как только можно и не хочет в это вникать.
1-я строка это то, что потенциально можно считать с входа в программе (ну, скажем, если считывать на максимальной частоте проца/входа). ну не нарисую я же текстом аналоговый сигнал :) А вторая строчка - то что считали. А "___" во второй строке - это типа dt между считываниями.
Корректной картинкой. Но долго и неохота рисовать.
Для интерактивной кнопки вообще практически все будет работать.
Но сам подход с ингорирование проблем алисаинга.. как бы для кнопки не важно (хотя и избыточно в большинстве случаев). Но это же будут пихать и для других целей!
Для иллюстрации.. синие и красное - это ну скажем на 0.01% отличающееся друг от друга частоты семплирования. 100 - типа порговое значение. Просто для иллюстрации/примера. За счет алиасинга пороговое значение будет достигаться в алгоритме "+1/-1 от семпла" фактически в непредскзуемое время.
На синем - больше было не учтенных выбросов 1. А на красном больще не учтенных выбросов 0. Сделать оверсеплинг для дребезга, где фактическая частота может быть десятки МГц.. это не возможно да и не нужно.
Я диаграммой показывал именно переходной процесс и то, что семплирование с фикисрованной частотой с непрерывным интегрированием результата какого либо смысла не имеет. Поскольку результаты плавают и ловить какое то определенное место в промежутке переходного процесса все одно не выдет таким способом. Если требуется ловить именно отсутиве дребезга в течении какого то времени. То так и надо писать. Но тогда лучше (IMHO):
И пороговое значение понятнее и проще. А если в счетчике учитыватеся и переходной процесс и его окончание считается как пороговое значение счетчика, то вермя "нажата кнопка" будет считаться от начала переходного процесса. И будет случаныйм образом плавать, поскольку в порог включить придется и семплы после переходного и семплы внутри переходного. А они случайны (количестов 0 != количеству 1).
Аналогично можно ловить отжатие кнопки. А если требуется просто ловить "кнопка нажата или нет", то проще просто брать сэмплы (период скажем 500ms) и считать семп за резутьтат "нежата/не нажата" в типичной задаче типа "зажатая кнопка увеличивает громкость".
Ровно как описан алгоритм создаем программный счетчик, который инкриминируется, если кнопка нажата и декриментируется если кнопка отжата счетчик будет возврастать при каждом опросе нажатой кнопки (за 1 секунду семплирования с периодом скажем 20ms это будет +1000/20). И как это неперывно увеличивающееся значние используется в "флаг, который принимает свое значение в зависимости от пересечения верхнего или нижнего установленного порога" = ?.
Ровно как описано в исходном посте. А если автор чего то "подразумевал" (типа порог.. обнуляем.. учитываем и т.д.) так я не ясновидец и додумывать не буду что он подразумевал.
Я могу догадываться что и зачем имелось в виду. Но если описание алгоритма такое каое есть, то ну просто сложно удержаться от..
У вас в примере магическим образом частотад дребезка это константа, совпадающая с частотой опроса. А проблемы алиасинга так же магически "частоту опроса GPIO надо приподнять".
Если снять осцилограмму с кнопки в момент ее нажатия/отпускания (хорошим осцилографом с малой емкостю и большим входным сопростивлением). То будет видна характерная картина. Собствено это и есть "дребез контакта". наберите "дребез контакта осциллограмма" в поиске. Там будут картинки примера дребезка на осцилографе.
В зависимости от физического исполнения "кнопки", емкости на входa, входного сопротивления входа и пр. может быть разной формы.. разной длитетельности (может до 5-10ms).
По-моему, там просто случайные 0 и 1, приходящие на порт МК.
Не приходящие, а считываемые с порта (я специально это отметил). А приходит напряжение/ток сложной формы. "Цировой сигнал" это абстракция. Почему то "писатели под ардуино" про это забывают/не знают. А потому удивляются "а почему не так работает как я думал".
4-й курс (времена динозавов правда).. схемотехника.. лаба посвященная этому. "Что бы запомнили". Для меня электроника и схемотехника - хоби. Но запомнил жжж..
Считывание состояния кнопки по прерываниям таймера, это один из стандартных методов. Минус этого метода только в том, что он требует относительно много процессорного времени.
просто отмечу (на правах рассуждения) Процессорное время в обработке события от нажатия на кнопку (человеком) не самый определяющий критерий. И я критиковал очень конкретный алгоритм со "счетчиком" чего то и измением этого счетчика по опросу. А не способ "опроса" вообще.
Квадратурный энкодер обрабатывается как две кнопки.
К слову, квадратурный энкодер программный то же работать не будет, если задача не "крутилка громкости", а "точная координата оси станка после часа его работы". Для таких целей есть аппартаный режим счетчиков (в STM32 например).
В данном случае речь явно о "крутилке громкости", то есть об органах ручного управления, с низкой скоростью событий.
Для "крутилки громкости", зачастую достаточно в фоновом процессе (прерывание по таймера раз в 50ms) тупо считывать состояние и риск возникновения дребезга в момент считывания не учитывать.. кнопки/энкодеры типа "крутилки громкости" - интерактивны. Щелчком больше/меньше значения не имеет вообще.
первая строка значение на входе контроллера (*) вторая строка - считываение в период опроса. третья строка - типа счетчик 000001010101010101010100111101000101111111111100111011111111111..0100100001110000000 0____1____0____1____1____1____0____1____0____0____1..0____1____1____0____ __ -1____0____-1____0____1____2____1____2___-1____-2___-1__.. 345__346__347__346___
Ну и что конретно даст значение счетчика для анализа по предложенному...
программный счетчик, который инкриминируется, если кнопка нажата и декриментируется если кнопка отжата.
Только давайте на ходу не придумывать доп условия :) Преврашая алгоритм в лапшу и набор заплат :) Не надо изобретать велосипед. програмные алгоритмы (как через прерывания, так и через опрос под разные цели) подавления дребезга - это динозавры, которым много десятилетий. Все придумано до нас. Честно говоря, смысла этой статьи не понимаю.
(*) - условно. значени если бы опрашивали порт в данный момент. Тема для превращения в 0/1, фактически аналогового сигнала дребезка, не проста. Но можно не вдаваться и считать 0/1.
программный счетчик, который инкриминируется, если кнопка нажата и декриментируется если кнопка отжата
Количество "0" и "1" на опросе кнопки могут встречатся вообще в любых сочетания при попадании на диапазон "дребезга". И период опроса вообще на это не влияет. Поскольку "дребез" это в общем случае "случайный" период (упрощенно изображают на графиках меандром. но это не меандр).
Я так, понимаю, что автор рассматирвал вопрос сложности определения момента "нажатия" на кнопку как фиксации события "нажата". А не просто определения факта "нажата/не нажата"
который инкриминируется, если кнопка нажата и декриментируется если кнопка отжата
Получите неопределенное значение. Потому что, момент опроса и момент переходных процессов при нажатии (дребезг) вообще могут не совпасть.
Очень типичная ошибка "опросом" + "счетчик". Например, так же нельзя опросом энкодер считывать. Если конечно интересует не "качественные" показатели (типа крутилка громкости), а накомительное значение (ось станка и пр.).
Если корову меньше кормить и больше доить.. то она будет что?
"Конечно больше доиться и меньше кормиться" с точки зрения таких вот генеральных (гениальных менаджеров) как автор статьи.
У меня есть знакомые из Междуреченска.. 150 тыс говорите... ну ну. А сами за 60..70 (по факту) не пробовали смены в забое в аварийных шахтах отрабатывать?
И деваться на кузбасе из этого гребанного Междуреченска некуда и работы никакой другой по слути там нет.
А самое обидное что этот "Дмитрий Лохов" после того как все окончательно накроется уйдет с "портфелио" куда ни будь еще.. руководить.
А я не вижу в этом описание условия ограничения самого счетчика.
Есть только условия на флаг.
А фраза "без переполнения" != "ограничен сверху значеним порога а снизу 0".
Да я нудный. Но слишком часто приходилось тратить на переделку и общение с заказчиками из за "подразумевалось".
Обратите внимание, что я несколько раз говорил в первых постах что специально не буду додумывать за..
Поэтому пример сделал специально утрированыным срого по описанию.
И прекрасно осознаю, что если у автора по факту работало, то это просто алгоритм не до конца описан.
Эхх.
Никогда не нужно в ТЗ/описании додумывать за кого то.
"это логично", додуманное за кого то (если четко не описано), ведет в ад.
Это применительно ко всему.
Я не оспариваю ваш вариант.
Классический вариант плавующего окна (счетчик с ограниченим и тригерное значение). Но только в исходном описание детали пропущены, которые уже "додумываются" :)
Ну так это и есть доп. типа "а мы это подразумевали".
Только что на работе с этим столкнулся (конечно не по столь простому случаю). И жду ответа "а что вы подразумевали?". .
вот поэтому и фигней сейчас страдаю на хабре :)
Перепутал ветки. Читал одновременно.. (в коротком переыве в работе)
бывает.
еще раз извинините.
Да. флаг выставили. Но нигде не сказано, что счетчик в 0 сбросили или перестали +1 при нажатой кнопке. Фактом выставления флага же все не заканчивается. Т.е. можно продолжить ... 4,5,6,7,8,.. (кнопка же нажата)
Занудничаю..
Но тут и по работе в постановке задачи "а мы это подразумевали" наложилось.
в этой ветку был коммент про "по-хорошему, надо энкодер соответствующий использовать". На него и тригернуло.
Похоже подумали, что я на Ваш счет.. Не.. даже не думал.
Извините именно Вам не хотел.
Да и даже не к исходному комменту.
вообще "про ардуинщиков" было "лирическое отступление" и в не том комменте что нужно.
новый переходной процесс (отпускания).
Для демонстрации поведения счетчика "+1/-1 от сэпла". Что счетчик по формулировке алгоритма продолжает щелкать при нажатой кнопке.
Мне фраза одного из комментаторов
"по-хорошему, надо энкодер соответствующий использовать, а не лепить из того есть под рукой." напомнила просьбу помочь с "почему у меня ошибка с энкодера накапливается" (что то там про балансирующего робота, где это было очень важно).
На все попытки объяснить что такое джиттер энкродера и почему нужно использовать аппартные счетчики для квадратурного энкодера вместо программной реализации, и почему не нужно исопльзовать прерывания на сигналы от экодера..
Последовал вот почти такой же ответ. Типа у меня экодеры видимо дерьмо и попробую другие. Т.е. человек даже не хотел вникать в причины. Все просил дать ему ссылку на работающую ардуино либу.
Так что.. да. Агрессия и клеймо "ардуинщик". Может у меня шаблон в голове на "ардуинщик". Но асоциация такая:
Хочет найти готовую либу.
Не хочет вникать как работает "работает и ладно".
От електронники далек как только можно и не хочет в это вникать.
1-я строка это то, что потенциально можно считать с входа в программе (ну, скажем, если считывать на максимальной частоте проца/входа).
ну не нарисую я же текстом аналоговый сигнал :)
А вторая строчка - то что считали. А "___" во второй строке - это типа dt между считываниями.
Корректной картинкой. Но долго и неохота рисовать.
Для интерактивной кнопки вообще практически все будет работать.
Но сам подход с ингорирование проблем алисаинга..
как бы для кнопки не важно (хотя и избыточно в большинстве случаев). Но это же будут пихать и для других целей!
не корректно написал. НЕ на входе. А считываемое с входа в программе.
Для иллюстрации.. синие и красное - это ну скажем на 0.01% отличающееся друг от друга частоты семплирования. 100 - типа порговое значение. Просто для иллюстрации/примера. За счет алиасинга пороговое значение будет достигаться в алгоритме "+1/-1 от семпла" фактически в непредскзуемое время.
На синем - больше было не учтенных выбросов 1. А на красном больще не учтенных выбросов 0.
Сделать оверсеплинг для дребезга, где фактическая частота может быть десятки МГц.. это не возможно да и не нужно.
там где "..." - там закончивается.
Я диаграммой показывал именно переходной процесс и то, что семплирование с фикисрованной частотой с непрерывным интегрированием результата какого либо смысла не имеет. Поскольку результаты плавают и ловить какое то определенное место в промежутке переходного процесса все одно не выдет таким способом.
Если требуется ловить именно отсутиве дребезга в течении какого то времени. То так и надо писать.
Но тогда лучше (IMHO):
"счетичк нажатия" += 1, если семп == "1"
"счетичк нажатия" = 0, если семп == "0"
счетичк "нажатия" > порога (устоявшийся процесс) -> сигнал о нажатой кнопке + "счетичк нажатия" = 0.
И пороговое значение понятнее и проще. А если в счетчике учитыватеся и переходной процесс и его окончание считается как пороговое значение счетчика, то вермя "нажата кнопка" будет считаться от начала переходного процесса. И будет случаныйм образом плавать, поскольку в порог включить придется и семплы после переходного и семплы внутри переходного. А они случайны (количестов 0 != количеству 1).
Аналогично можно ловить отжатие кнопки.
А если требуется просто ловить "кнопка нажата или нет", то проще просто брать сэмплы (период скажем 500ms) и считать семп за резутьтат "нежата/не нажата" в типичной задаче типа "зажатая кнопка увеличивает громкость".
Ровно как описан алгоритм создаем программный счетчик, который инкриминируется, если кнопка нажата и декриментируется если кнопка отжата
счетчик будет возврастать при каждом опросе нажатой кнопки (за 1 секунду семплирования с периодом скажем 20ms это будет +1000/20).
И как это неперывно увеличивающееся значние используется в "флаг, который принимает свое значение в зависимости от пересечения верхнего или нижнего установленного порога" = ?.
Ровно как описано в исходном посте. А если автор чего то "подразумевал" (типа порог.. обнуляем.. учитываем и т.д.) так я не ясновидец и додумывать не буду что он подразумевал.
Я могу догадываться что и зачем имелось в виду.
Но если описание алгоритма такое каое есть, то ну просто сложно удержаться от..
У вас в примере магическим образом частотад дребезка это константа, совпадающая с
частотой опроса.
А проблемы алиасинга так же магически "частоту опроса GPIO надо приподнять".
Мне больше нечего сказать на это..
Если снять осцилограмму с кнопки в момент ее нажатия/отпускания (хорошим осцилографом с малой емкостю и большим входным сопростивлением). То будет видна характерная картина. Собствено это и есть "дребез контакта".
наберите "дребез контакта осциллограмма" в поиске. Там будут картинки примера дребезка на осцилографе.
В зависимости от физического исполнения "кнопки", емкости на входa, входного сопротивления входа и пр. может быть разной формы.. разной длитетельности (может до 5-10ms).
Не приходящие, а считываемые с порта (я специально это отметил). А приходит напряжение/ток сложной формы.
"Цировой сигнал" это абстракция. Почему то "писатели под ардуино" про это забывают/не знают. А потому удивляются "а почему не так работает как я думал".
4-й курс (времена динозавов правда).. схемотехника.. лаба посвященная этому. "Что бы запомнили".
Для меня электроника и схемотехника - хоби. Но запомнил жжж..
просто отмечу (на правах рассуждения)
Процессорное время в обработке события от нажатия на кнопку (человеком) не самый определяющий критерий.
И я критиковал очень конкретный алгоритм со "счетчиком" чего то и измением этого счетчика по опросу.
А не способ "опроса" вообще.
К слову, квадратурный энкодер программный то же работать не будет, если задача не "крутилка громкости", а "точная координата оси станка после часа его работы". Для таких целей есть аппартаный режим счетчиков (в STM32 например).
Для "крутилки громкости", зачастую достаточно в фоновом процессе (прерывание по таймера раз в 50ms) тупо считывать состояние и риск возникновения дребезга в момент считывания не учитывать.. кнопки/энкодеры типа "крутилки громкости" - интерактивны. Щелчком больше/меньше значения не имеет вообще.
первая строка значение на входе контроллера (*)
вторая строка - считываение в период опроса.
третья строка - типа счетчик
000001010101010101010100111101000101111111111100111011111111111..0100100001110000000
0____1____0____1____1____1____0____1____0____0____1..0____1____1____0____
__ -1____0____-1____0____1____2____1____2___-1____-2___-1__.. 345__346__347__346___
Ну и что конретно даст значение счетчика для анализа по предложенному...
Только давайте на ходу не придумывать доп условия :) Преврашая алгоритм в лапшу и набор заплат :)
Не надо изобретать велосипед. програмные алгоритмы (как через прерывания, так и через опрос под разные цели) подавления дребезга - это динозавры, которым много десятилетий. Все придумано до нас.
Честно говоря, смысла этой статьи не понимаю.
(*) - условно. значени если бы опрашивали порт в данный момент. Тема для превращения в 0/1, фактически аналогового сигнала дребезка, не проста. Но можно не вдаваться и считать 0/1.
тогда зачем фраза
Количество "0" и "1" на опросе кнопки могут встречатся вообще в любых сочетания при попадании на диапазон "дребезга". И период опроса вообще на это не влияет. Поскольку "дребез" это в общем случае "случайный" период (упрощенно изображают на графиках меандром. но это не меандр).
Я так, понимаю, что автор рассматирвал вопрос сложности определения момента "нажатия" на кнопку как фиксации события "нажата". А не просто определения факта "нажата/не нажата"
Ну ну..
Ключевая концептуальная ошибка: "опрос"+"счетчик".
Получите неопределенное значение. Потому что, момент опроса и момент переходных процессов при нажатии (дребезг) вообще могут не совпасть.
Очень типичная ошибка "опросом" + "счетчик".
Например, так же нельзя опросом энкодер считывать. Если конечно интересует не "качественные" показатели (типа крутилка громкости), а накомительное значение (ось станка и пр.).