Новой информации никакой не дает, вы ничего своего не придумали и не написали. Половина статьи это вообще картинки из разряда "мигаем светодиодом на STM32". Техническая ценность данной статьи околонулевая. Нет никакой информации по настройке регуляторов, фильтров и т.д.
Вся статья из разряда "Как нарисовать сову". Поэтому нисколько неудивительно, что это не летает, так как все технические моменты, которые влияют на то, чтобы летало, просто пропущены. Лет 7-8 назад на Хабре писали более полезные статьи и про настройку регуляторов для полетных контроллеров и про фильтр Калмана и про Махони.
Позволю себе процитировать сообщение, на которое вы ответили в самом начале ветки (выделения мои):
создаем программный счетчик, который инкриминируется, если кнопка нажата и декриментируется если кнопка отжата (без переполнения);
создаем флаг, который принимает свое значение в зависимости от пересечения верхнего или нижнего установленного порога (обеспечит гистерезис положения нажато/отжато);
добавляем опрос кнопки в бесконечном цикле.
Что я лично вижу в этом описании:
Учтена возможность переполнения, значит ограничения верхнего и нижнего порога уже есть, без ограничений мы получаем переполнение.
То есть все уже задано в ТЗ. )
Правда, я бы лично бесконечный цикл убрал. Так как есть ведь еще другие задачи, который можно выполнять паралельно.
Что мне не понравилось в вашем конкретном примере, это то, что нижнего порога у вас нет. При поступлении 0, вы также считаете -1. Что ведет к тому, что время между окончанием переходного процесса и выставлением флага всегда будет разным, в зависимости от количества 0, пришедших во время переходного процесса.
Так ведь логично любой счетчик всегда ограничивать максимальным и минимальным значениями, тем более, если это значение является пороговым. Так как нам важен только факт переход через порог, дальше нам этот счетчик уже не нужен, соответственно, нет нужды проводить с ним какие-либо операции, а во от переполнения счетчика можно словить различные плавающие проблемы, когда отказ то есть, то нет и попробуй его найти.
Именно поэтому в вашем примере счетчик должен был быть ограничен как сверху, так и снизу, то есть -1, -2, -3 тоже значений у него быть не должно, по моему мнению, ниже 0 мы считать не должны точно также, как и выше порогового значения.
Т.е. можно продолжить ... 4,5,6,7,8,.. (кнопка же нажата)
А далее переполнение и начинаем считать с нуля.. )))
Ну нет, я конечно понимаю, что студент, который только-только пришел на работу и реализует первый раз, вполне может столкнуться с таким, но в целом, в этом тоже нет ничего такого, получит опыт, что любой счетчик стоит отграничивать сверху тоже. Что в целом не так уж и плохо, для опыта.
Зачем его сбрасывать в 0, ведь его потом можно использовать на отпускание кнопки, чтобы не заводить на отпускание еще один счетчик. Ограничили сверху да и все. При отпускании декремент до 0.
Похоже, что не в этой, так как эта ветка начинается с первого комментария и все начало ветки идет про кнопку.
Похоже подумали, что я на Ваш счет
Я возможно чего-то не понимаю, но если вы отвечаете мне на мое сообщение, значит логично выходит, что ответ именно мне, а не кому-то другому, ведь диалог вы со мной ведете. Я хотя к Ардуино не имею никакого отношения, но в целом было интересно понять, с чего такие выводы на вполне безобидную просьбу пояснить, где именно в примере заканчивается переходный процесс.
Ага, именно поэтому я и задал изначально свой вопрос, так как у вас не совсем корректный пример. Если после ... это отпускание кнопки, то ваш счетчик, перед ... не должен иметь значение -1 (3-я строка).
А нормальный пример, будет выглядеть как-то так (нажатие кнопки):
11000001111100111111111111111111111 - будем считать это реальным сигналом
1__0__0__1__0__1__1__1__1__1 - это то, что считали в цикле с какой-то частотой
1, 0, 0, 1, 0, 1, 2, 3, 4, 5 - значение нашего программного счетчика.
Условно, досчитали до 5, выставили флаг, что кнопка нажата.
У вас же, в вашем примере, перед тем, как кнопку отпустили, счетчик имеет значение -1, хотя переходный процесс уже давно закончился. И еще одно замечание, в нормальной реализации счетчик не должен быть отрицательным, так как нас интересуют только фронты, а не спады.
Но, согласитесь, к текущей ветке она не имеет никакого отношения. Человек привел в пример вполне рабочий алгоритм. На что вас тригернуло.
На все попытки объяснить что такое джиттер
По моему мнению, не стоит тратить время на того, что не хочет включать свою голову. Это часто бесполезно. Показал пример, объяснил, почему так, дальше сам.
Типа у меня экодеры видимо дерьмо и попробую другие
Так многие люди и рассуждают, и дело тут не в Ардуино совсем, а в целом в нежелании разобраться в причинно-следственных связях. Я также слышал от программистов, у которых код не работал, что дело в компиляторе. Через 5 мин просмотра кода, находилась проблема, исправлялась и о чудо, дело не в компиляторе совсем было.
В общем, если подвести итог, первая строка, это аналоговый сигнал, который виртуально переведен в цифровой.
Вторая строка, это то, что уже считывается с порта и используется для расчетов в программе.
Все верно ?
Если да, то тогда что означают .... 01001 вот эти 0 и 1 уже после переходного процесса в первой строке, если "..." это окончание переходного процесса ?
Изначально вы начали отвечать на сообщение, где написано про кнопку. И только про кнопку. Причем, еще в таком тоне, что все дураки, "ардуинщики" делают неправильно и т.д. Откуда столько агрессии ?
То, что кто-то будет что-то куда-то пихать, не подумав, это уже другая история. И это ответственность того, кто будет это использовать в ситуациях, когда использовать это нельзя.
Если мы все же продолжаем обсуждать кнопку, а не что-то другое, то тут время не так важно. Если же это не кнопка, а допустим энкодер, по которому вычисляется еще и скорость, это уже совсем другая история и там алгоритм, предложенный выше будет накапливать ошибки. Но тут больше вопрос к тому, что не стоит использовать тот или иной алгоритм бездумно.
А после ... 01001 это что, переходный процесс при отпускании кнопки ? или дрожание контактов после переходного процесса ?
Но тогда лучше (IMHO):
с этим полностью согласен. К этому вопросов нет совершенно. Но разве не на то же самое вы отвечали:
То есть в моменты дребезга счетчик будет болтаться, но после стабилизации уровня счетчик достигнет какого-то максимума при нажатии и нуля при отпускании
не ясновидец и додумывать не буду что он подразумевал.
так если что-то непонятно, принято спрашивать. Я вот спросил, нахватал минусов, хотя вопрос то был по существу.
Не приходящие, а считываемые с порта (я специально это отметил). А приходит напряжение/ток сложной формы
первая строка значение на входе контроллера (*)
Вы сами себе противоречите.
Меня интересовала ТОЛЬКО первая ваша строка, которую вы называете "значение на входе контроллера". Чтобы вы там на ней показали переходный процесс и его окончание.
Зачем это здесь ?
Новой информации никакой не дает, вы ничего своего не придумали и не написали. Половина статьи это вообще картинки из разряда "мигаем светодиодом на STM32". Техническая ценность данной статьи околонулевая. Нет никакой информации по настройке регуляторов, фильтров и т.д.
Вся статья из разряда "Как нарисовать сову". Поэтому нисколько неудивительно, что это не летает, так как все технические моменты, которые влияют на то, чтобы летало, просто пропущены. Лет 7-8 назад на Хабре писали более полезные статьи и про настройку регуляторов для полетных контроллеров и про фильтр Калмана и про Махони.
Позволю себе процитировать сообщение, на которое вы ответили в самом начале ветки (выделения мои):
Что я лично вижу в этом описании:
Учтена возможность переполнения, значит ограничения верхнего и нижнего порога уже есть, без ограничений мы получаем переполнение.
То есть все уже задано в ТЗ. )
Правда, я бы лично бесконечный цикл убрал. Так как есть ведь еще другие задачи, который можно выполнять паралельно.
Что мне не понравилось в вашем конкретном примере, это то, что нижнего порога у вас нет. При поступлении 0, вы также считаете -1. Что ведет к тому, что время между окончанием переходного процесса и выставлением флага всегда будет разным, в зависимости от количества 0, пришедших во время переходного процесса.
Так ведь логично любой счетчик всегда ограничивать максимальным и минимальным значениями, тем более, если это значение является пороговым. Так как нам важен только факт переход через порог, дальше нам этот счетчик уже не нужен, соответственно, нет нужды проводить с ним какие-либо операции, а во от переполнения счетчика можно словить различные плавающие проблемы, когда отказ то есть, то нет и попробуй его найти.
Именно поэтому в вашем примере счетчик должен был быть ограничен как сверху, так и снизу, то есть -1, -2, -3 тоже значений у него быть не должно, по моему мнению, ниже 0 мы считать не должны точно также, как и выше порогового значения.
Да ничего страшного, бывает! )
А далее переполнение и начинаем считать с нуля.. )))
Ну нет, я конечно понимаю, что студент, который только-только пришел на работу и реализует первый раз, вполне может столкнуться с таким, но в целом, в этом тоже нет ничего такого, получит опыт, что любой счетчик стоит отграничивать сверху тоже. Что в целом не так уж и плохо, для опыта.
Зачем его сбрасывать в 0, ведь его потом можно использовать на отпускание кнопки, чтобы не заводить на отпускание еще один счетчик. Ограничили сверху да и все. При отпускании декремент до 0.
Похоже, что не в этой, так как эта ветка начинается с первого комментария и все начало ветки идет про кнопку.
Я возможно чего-то не понимаю, но если вы отвечаете мне на мое сообщение, значит логично выходит, что ответ именно мне, а не кому-то другому, ведь диалог вы со мной ведете. Я хотя к Ардуино не имею никакого отношения, но в целом было интересно понять, с чего такие выводы на вполне безобидную просьбу пояснить, где именно в примере заканчивается переходный процесс.
Ага, именно поэтому я и задал изначально свой вопрос, так как у вас не совсем корректный пример. Если после ... это отпускание кнопки, то ваш счетчик, перед ... не должен иметь значение -1 (3-я строка).
А нормальный пример, будет выглядеть как-то так (нажатие кнопки):
11000001111100111111111111111111111 - будем считать это реальным сигналом
1__0__0__1__0__1__1__1__1__1 - это то, что считали в цикле с какой-то частотой
1, 0, 0, 1, 0, 1, 2, 3, 4, 5 - значение нашего программного счетчика.
Условно, досчитали до 5, выставили флаг, что кнопка нажата.
У вас же, в вашем примере, перед тем, как кнопку отпустили, счетчик имеет значение -1, хотя переходный процесс уже давно закончился. И еще одно замечание, в нормальной реализации счетчик не должен быть отрицательным, так как нас интересуют только фронты, а не спады.
Но, согласитесь, к текущей ветке она не имеет никакого отношения. Человек привел в пример вполне рабочий алгоритм. На что вас тригернуло.
По моему мнению, не стоит тратить время на того, что не хочет включать свою голову. Это часто бесполезно. Показал пример, объяснил, почему так, дальше сам.
Так многие люди и рассуждают, и дело тут не в Ардуино совсем, а в целом в нежелании разобраться в причинно-следственных связях. Я также слышал от программистов, у которых код не работал, что дело в компиляторе. Через 5 мин просмотра кода, находилась проблема, исправлялась и о чудо, дело не в компиляторе совсем было.
В общем, если подвести итог, первая строка, это аналоговый сигнал, который виртуально переведен в цифровой.
Вторая строка, это то, что уже считывается с порта и используется для расчетов в программе.
Все верно ?
Если да, то тогда что означают .... 01001 вот эти 0 и 1 уже после переходного процесса в первой строке, если "..." это окончание переходного процесса ?
Изначально вы начали отвечать на сообщение, где написано про кнопку. И только про кнопку. Причем, еще в таком тоне, что все дураки, "ардуинщики" делают неправильно и т.д. Откуда столько агрессии ?
То, что кто-то будет что-то куда-то пихать, не подумав, это уже другая история. И это ответственность того, кто будет это использовать в ситуациях, когда использовать это нельзя.
Тогда вторая строчка, это что, если первая, это уже то, что считали в программе ?
Если мы все же продолжаем обсуждать кнопку, а не что-то другое, то тут время не так важно. Если же это не кнопка, а допустим энкодер, по которому вычисляется еще и скорость, это уже совсем другая история и там алгоритм, предложенный выше будет накапливать ошибки. Но тут больше вопрос к тому, что не стоит использовать тот или иной алгоритм бездумно.
А после ... 01001 это что, переходный процесс при отпускании кнопки ? или дрожание контактов после переходного процесса ?
с этим полностью согласен. К этому вопросов нет совершенно. Но разве не на то же самое вы отвечали:
так если что-то непонятно, принято спрашивать. Я вот спросил, нахватал минусов, хотя вопрос то был по существу.
Вы сами себе противоречите.
Меня интересовала ТОЛЬКО первая ваша строка, которую вы называете "значение на входе контроллера". Чтобы вы там на ней показали переходный процесс и его окончание.
Добавил картинку специально для вас, как и просили.
Переходный процесс занимает 2.6 мс. Далее, значение 1. И сравните с тем, что привели вы выше в своем примере (первая ваша строка).
Вы не поняли вопрос.
Я попросил отметить, ГДЕ именно на вашей картинке переходный процесс, который должен с течением времени закончится. Он потому и называется переходный.
То есть, картинка должны быть типа такой: 0110101010101011111111111.
И вот этих вот 111111, на вашей картинке не видно, то есть ваша условная кнопка выдает дребезг ВСЕГДА. Что не является правдой, если кнопка исправна.
А не могли бы пояснить, где на вашей картинке переходный процесс ?
По-моему, там просто случайные 0 и 1, приходящие на порт МК.
Вопрос к автору.
Вот вы по тексту везде ссылаетесь на РРЦ.
А КТО ее устанавливает для вас, производитель ?
То есть, гаечный ключ вы даже не рассматриваете ?
Так почему же на самом деле горят видеокарты ?
Судя по тексту, NVidia не сказали ничего нового, что уже известно как 2 месяца.
Заголовок попахивает желтизной.