Реакция на событие может быть не за такое уж и малое время, оно может быть и достаточно большим. Но оно гарантировано.
Т.е. мы гарантируем, что если в момент времени T0 у нас наступило событие, то в момент времени T0+Tevent будет получена реакция на события.
Где Tevent - время реакции, оно документировано и гарантировано.
Плюс системы РВ делятся на системы жесткого и мягкого РВ. В первых Treact должно быть точно выдержано, вплоть до такта процессора. Во вторых допускается некоторое отклонение от точного Treact, но оно так же документировано и не должно превышаться.
Так вот я имел в виду, что в однопроцессорной системе мы можем обеспечить точную выдержку времени (то есть режим жесткого реального времени) только для одного события. Для всех остальных будет задержка реакции, в случае поступления двух событий одновременно.
Получается от физической топологии "шина" они перешли к топологии "звезда"? я вижу только одну причину - безопасность. Если шина повреждена, все, что висит дальше повреждения - отвалилось. А тут хотя-бы отвалится только то, что на поврежденной линии. Но провода да, с чем боролись на то и напоролись...
Интересно, на чем это все закончится. Я в свое время не осилил работу с жестким диском из защищенного режима, на этом мои потуги с написанием OC в x86 закончились))
Начинал с debug. Так уж вышло, что на первом моем IBM PC компе на 386м кто-то в целях оптимизации места выкосил все .hlp файлы и qbasic. Был только debug.exe
А потом мне попала в руки книжка Джордейна. С листингами и реализацией всякого на низком уровне. Оказалось, что в debug можно было кодить, ну и пошел процесс...
У этого способа есть один минус. Если идут помехи, или просто возможно кратковременное случайное нажатие, то можем его (или ее - помеху) зарегистрировать как нажатие на кнопку и пока блокирующий таймер активен, мы считаем, что кнопка нажата.
Вариант с несколькими опросами более устойчив к таким случаям, т.к. шанс, что 5-10 раз подряд попадем в ложный сигнал нажатия достаточно мал.
А автоповтор, срабатывание на нажатие/отпускание можно уже делать, опираясь на вот это отфильтрованное от дребезга значение.
Но с точки зрения простоты, согласен, ваш способ проще.
Спасибо! А ссылка есть у вас на этого продавца на Али? Раз уж проверенный вами
Если можно, опишите, пожалуйста. А может даже мини-статью запилить? Думаю многим пригодится
Под капотом list это обычный динамический массив PyObject-ов
Этот период надо просто пережить, а аккаунты тех, кто постит эту субстанцию, банить нещадно.
Со временем народ поймет, что это бесполезно.
Да, вроде так. в Turbo Pascal ее не было.
И в Borland C еще вроде была.
В Borland C 3.1 она вроде в исходниках что-ли была. В общем я помню, что смотрел ее исходники тоже. Не только юзал
А еще была библиотека
Правда я уже на плюсах ее юзал.
Помнится, она мне намного больше нравилась, чем MFC.
Это, видимо тоже была начальная попытка поддержать разработку под винду.
Еще до delphi/c++ builder
Это была классная библиотека.
Учился окошкостроению и ооп на ней.
Сначала на паскале, потом на си.
До сих пор энтузиасты ее поддерживают
Немного не соглашусь с вами.
Реакция на событие может быть не за такое уж и малое время, оно может быть и достаточно большим. Но оно гарантировано.
Т.е. мы гарантируем, что если в момент времени T0 у нас наступило событие, то в момент времени T0+Tevent будет получена реакция на события.
Где Tevent - время реакции, оно документировано и гарантировано.
Плюс системы РВ делятся на системы жесткого и мягкого РВ. В первых Treact должно быть точно выдержано, вплоть до такта процессора. Во вторых допускается некоторое отклонение от точного Treact, но оно так же документировано и не должно превышаться.
Так вот я имел в виду, что в однопроцессорной системе мы можем обеспечить точную выдержку времени (то есть режим жесткого реального времени) только для одного события. Для всех остальных будет задержка реакции, в случае поступления двух событий одновременно.
В начале 2000х, когда еще в универе учился, брал в университетской библиотеке книгу по Win32 API, не помню автора, к сожалению.
Так вот там именно, что сокеты называли "гнездо"! Они решили перевести все, в том числе и термины!
Читать такое было тяжеловато.
Имхо, понятие "реальное время", распространимо только на один, самый приоритетный процесс.
Все остальные будут - мягкого реального времени, т.к. в любой момент могут быть прерваны тем, самым приоритетным процессом.
Судя по слову Capacitive, он емкостный
Получается от физической топологии "шина" они перешли к топологии "звезда"?
я вижу только одну причину - безопасность.
Если шина повреждена, все, что висит дальше повреждения - отвалилось.
А тут хотя-бы отвалится только то, что на поврежденной линии.
Но провода да, с чем боролись на то и напоролись...
А есть какое-то объяснение, почему убрали терминаторы?
Работал с CAN, правда давненько. Ему без терминаторов очень плохо.
Им резистор жалко?
Интересно, на чем это все закончится.
Я в свое время не осилил работу с жестким диском из защищенного режима, на этом мои потуги с написанием OC в x86 закончились))
О да, Нортон это классика. Тоже не помню название, с темно-синей обложкой мягкой была книга его.
Начинал с debug. Так уж вышло, что на первом моем IBM PC компе на 386м кто-то в целях оптимизации места выкосил все .hlp файлы и qbasic. Был только debug.exe
А потом мне попала в руки книжка Джордейна. С листингами и реализацией всякого на низком уровне. Оказалось, что в debug можно было кодить, ну и пошел процесс...
Результат деления не требует делителя. Вы просто разбиваете произведение на два множителя. Но таких разбиений существует много.
В чем отличие от суммы?
У этого способа есть один минус. Если идут помехи, или просто возможно кратковременное случайное нажатие, то можем его (или ее - помеху) зарегистрировать как нажатие на кнопку и пока блокирующий таймер активен, мы считаем, что кнопка нажата.
Вариант с несколькими опросами более устойчив к таким случаям, т.к. шанс, что 5-10 раз подряд попадем в ложный сигнал нажатия достаточно мал.
А автоповтор, срабатывание на нажатие/отпускание можно уже делать, опираясь на вот это отфильтрованное от дребезга значение.
Но с точки зрения простоты, согласен, ваш способ проще.
Самый простой софтовый вариант имхо:
Заводим счетчик и переменную, куда сохраняем текущее состояние кнопки.
Периодически опрашиваем кнопку, если состояние с предыдущего опроса не изменилось, счетчик инкрементируем, если изменилось - обнуляем.
Если значение счетчика превысило некий порог, фиксируем новое состояние кнопки, уже отфильтрованное.