Pull to refresh
53
0.4
Михаил Кнутарев @mmMike

User

Send message

Сегодня предприятия сталкиваются с комплексным вызовом, когда даже высокие зарплаты не компенсируют тяжелые условия труда в глазах молодых специалистов. Особенно остро проблема стоит в моногородах, где традиционно располагаются горно‑обогатительные комбинаты.

Если корову меньше кормить и больше доить.. то она будет что?
"Конечно больше доиться и меньше кормиться" с точки зрения таких вот генеральных (гениальных менаджеров) как автор статьи.

У меня есть знакомые из Междуреченска.. 150 тыс говорите... ну ну. А сами за 60..70 (по факту) не пробовали смены в забое в аварийных шахтах отрабатывать?
И деваться на кузбасе из этого гребанного Междуреченска некуда и работы никакой другой по слути там нет.

А самое обидное что этот "Дмитрий Лохов" после того как все окончательно накроется уйдет с "портфелио" куда ни будь еще.. руководить.

А я не вижу в этом описание условия ограничения самого счетчика.
Есть только условия на флаг.
А фраза "без переполнения" != "ограничен сверху значеним порога а снизу 0".

Да я нудный. Но слишком часто приходилось тратить на переделку и общение с заказчиками из за "подразумевалось".

Что мне не понравилось в вашем конкретном примере, это то, что нижнего порога у вас нет.

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

И прекрасно осознаю, что если у автора по факту работало, то это просто алгоритм не до конца описан.

Эхх.
Никогда не нужно в ТЗ/описании додумывать за кого то.
"это логично", додуманное за кого то (если четко не описано), ведет в ад.

Это применительно ко всему.

Я не оспариваю ваш вариант.
Классический вариант плавующего окна (счетчик с ограниченим и тригерное значение). Но только в исходном описание детали пропущены, которые уже "додумываются" :)

Ограничили сверху да и все.

Ну так это и есть доп. типа "а мы это подразумевали".
Только что на работе с этим столкнулся (конечно не по столь простому случаю). И жду ответа "а что вы подразумевали?". .
вот поэтому и фигней сейчас страдаю на хабре :)

Перепутал ветки. Читал одновременно.. (в коротком переыве в работе)
бывает.
еще раз извинините.

Условно, досчитали до 5, выставили флаг, что кнопка нажата

Да. флаг выставили. Но нигде не сказано, что счетчик в 0 сбросили или перестали +1 при нажатой кнопке. Фактом выставления флага же все не заканчивается. Т.е. можно продолжить ... 4,5,6,7,8,.. (кнопка же нажата)

Занудничаю..
Но тут и по работе в постановке задачи "а мы это подразумевали" наложилось.

в этой ветку был коммент про "по-хорошему, надо энкодер соответствующий использовать". На него и тригернуло.

Похоже подумали, что я на Ваш счет.. Не.. даже не думал.
Извините именно Вам не хотел.
Да и даже не к исходному комменту.
вообще "про ардуинщиков" было "лирическое отступление" и в не том комменте что нужно.

новый переходной процесс (отпускания).
Для демонстрации поведения счетчика "+1/-1 от сэпла". Что счетчик по формулировке алгоритма продолжает щелкать при нажатой кнопке.

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

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

Последовал вот почти такой же ответ. Типа у меня экодеры видимо дерьмо и попробую другие. Т.е. человек даже не хотел вникать в причины. Все просил дать ему ссылку на работающую ардуино либу.

Так что.. да. Агрессия и клеймо "ардуинщик". Может у меня шаблон в голове на "ардуинщик". Но асоциация такая:

  1. Хочет найти готовую либу.

  2. Не хочет вникать как работает "работает и ладно".

  3. От електронники далек как только можно и не хочет в это вникать.

1-я строка это то, что потенциально можно считать с входа в программе (ну, скажем, если считывать на максимальной частоте проца/входа).
ну не нарисую я же текстом аналоговый сигнал :)
А вторая строчка - то что считали. А "___" во второй строке - это типа dt между считываниями.

Корректной картинкой. Но долго и неохота рисовать.

Для интерактивной кнопки вообще практически все будет работать.

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

не корректно написал. НЕ на входе. А считываемое с входа в программе.

Для иллюстрации.. синие и красное - это ну скажем на 0.01% отличающееся друг от друга частоты семплирования. 100 - типа порговое значение. Просто для иллюстрации/примера. За счет алиасинга пороговое значение будет достигаться в алгоритме "+1/-1 от семпла" фактически в непредскзуемое время.

На синем - больше было не учтенных выбросов 1. А на красном больще не учтенных выбросов 0.
Сделать оверсеплинг для дребезга, где фактическая частота может быть десятки МГц.. это не возможно да и не нужно.

там где "..." - там закончивается.

Я диаграммой показывал именно переходной процесс и то, что семплирование с фикисрованной частотой с непрерывным интегрированием результата какого либо смысла не имеет. Поскольку результаты плавают и ловить какое то определенное место в промежутке переходного процесса все одно не выдет таким способом.
Если требуется ловить именно отсутиве дребезга в течении какого то времени. То так и надо писать.
Но тогда лучше (IMHO):

  1. "счетичк нажатия" += 1, если семп == "1"

  2. "счетичк нажатия" = 0, если семп == "0"

  3. счетичк "нажатия" > порога (устоявшийся процесс) -> сигнал о нажатой кнопке + "счетичк нажатия" = 0.

И пороговое значение понятнее и проще. А если в счетчике учитыватеся и переходной процесс и его окончание считается как пороговое значение счетчика, то вермя "нажата кнопка" будет считаться от начала переходного процесса. И будет случаныйм образом плавать, поскольку в порог включить придется и семплы после переходного и семплы внутри переходного. А они случайны (количестов 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" на опросе кнопки могут встречатся вообще в любых сочетания при попадании на диапазон "дребезга". И период опроса вообще на это не влияет. Поскольку "дребез" это в общем случае "случайный" период (упрощенно изображают на графиках меандром. но это не меандр).

Я так, понимаю, что автор рассматирвал вопрос сложности определения момента "нажатия" на кнопку как фиксации события "нажата". А не просто определения факта "нажата/не нажата"

Ну ну..
Ключевая концептуальная ошибка: "опрос"+"счетчик".

который инкриминируется, если кнопка нажата и декриментируется если кнопка отжата

Получите неопределенное значение. Потому что, момент опроса и момент переходных процессов при нажатии (дребезг) вообще могут не совпасть.

Очень типичная ошибка "опросом" + "счетчик".
Например, так же нельзя опросом энкодер считывать. Если конечно интересует не "качественные" показатели (типа крутилка громкости), а накомительное значение (ось станка и пр.).

1
23 ...

Information

Rating
3,705-th
Location
Новосибирск, Новосибирская обл., Россия
Date of birth
Registered
Activity