В Вашей ситуации разумнее : 1) сделать "программный" таймер, считающий системные "тики". В основном цикле его проверять. Досчитали — принимать решение включать или не включать подачу.
2) в промежутках между проверками таймера считывать показания от датчика давления и фильтровать их подходящим образом (медиана во избежание значительных случайных выбросов, сглаживание EMA при "дрожании" сигнала и т.п.).
Код увеличится незначительно, зато возможности при отсутствии блокировки основного потока команд возрастут на порядок.
ADC повесить на прерывание, обработчиком — быстро прочитать результат в буфер, затем в основном (не заблокированном) цикле обработать новое значение в фильтре. Возможно, даже подача давления станет не "1 секунда" и пауза не "10 секунд" благодаря быстрому реагированию на изменение давления. Еще полезно ввести программный "гистерезис" с желательными технологическими порогами, чтобы переключать подачу давления не чересчур часто. Грубо прикинуть частоту переключения можно вручную, зная средний "расход" на тушки и соответствующую возможную "подачу", чтобы модель объекта управления была понятнее.
Вы правы. На дешёвых энкодерах с Ali при непреднамеренном неравномерном вращении именно так и происходит. Требуется программная обработка непредусмотренных состояний (комбинаций сигналов) выходов энкодера.
Это на 50% слова... Все-таки надо рассуждать в плоскости "ценность не железа, а программного обеспечения". Много ли под риск-файв написали софта и чем он объективно эффективнее (т.е. лучше) ??
Перерывчики надо делать на отжимания-приседания-наклоны и др., 20 минут на код, 5 минут на размяться - и всё будет хорошо. Всё равно написание кода разбивается на задачи - подзадачи - функции - ... Да и голову хорошо "проветривает", потому как напрягся (написал) - отдохнул (размялся).
Никакой аргументации, просто набор каких-то заявлений...
С чего бы программистам "исчезнуть"?.. Хотя, если действительно подход к написанию программ изменится, - оптимальность, быстродействие, понятность, - почему бы "миллионам индийских кодеров" не переквалифицироваться на что-нибудь другое? :-)
Вероятно вы не сильно выиграете во всех смыслах, перейдя на новый конфиг, разве что потеряете деньги. Если текущая конфигурация вас по производительности/автономности/эргономике устраивает, то не стоит размениваться...
Самое интересное (для меня) - как у этого аппарата с Линуксом?.. Поддерживает ли его ядро на базе Intel/AMD (x86_64) или требует специальных патчей (и пропатчено ли ядро уже). Удачно ли реализуется мультипоточность и прочие преимущественные при реальной эксплуатации вещи.
Пилотов подготовить долго и затратно. Кроме того, им необходим постоянный "налёт часов" для закрепления и развития практических навыков. Если ещё и "выбросить" из схемы одного пилота, то это спровоцирует уменьшение числа годных пилотов и , в результате, будет ещё больше проблем в будущем...
В Вашей ситуации разумнее :
1) сделать "программный" таймер, считающий системные "тики". В основном цикле его проверять. Досчитали — принимать решение включать или не включать подачу.
2) в промежутках между проверками таймера считывать показания от датчика давления и фильтровать их подходящим образом (медиана во избежание значительных случайных выбросов, сглаживание EMA при "дрожании" сигнала и т.п.).
Код увеличится незначительно, зато возможности при отсутствии блокировки основного потока команд возрастут на порядок.
ADC повесить на прерывание, обработчиком — быстро прочитать результат в буфер, затем в основном (не заблокированном) цикле обработать новое значение в фильтре.
Возможно, даже подача давления станет не "1 секунда" и пауза не "10 секунд" благодаря быстрому реагированию на изменение давления. Еще полезно ввести программный "гистерезис" с желательными технологическими порогами, чтобы переключать подачу давления не чересчур часто. Грубо прикинуть частоту переключения можно вручную, зная средний "расход" на тушки и соответствующую возможную "подачу", чтобы модель объекта управления была понятнее.
+++
Вы правы. На дешёвых энкодерах с Ali при непреднамеренном неравномерном вращении именно так и происходит. Требуется программная обработка непредусмотренных состояний (комбинаций сигналов) выходов энкодера.
Оно не "нормальное", оно "широко распространённое"...
А это не всегда критерий правильности.
Это на 50% слова...
Все-таки надо рассуждать в плоскости "ценность не железа, а программного обеспечения".
Много ли под риск-файв написали софта и чем он объективно эффективнее (т.е. лучше) ??
Перерывчики надо делать на отжимания-приседания-наклоны и др., 20 минут на код, 5 минут на размяться - и всё будет хорошо. Всё равно написание кода разбивается на задачи - подзадачи - функции - ... Да и голову хорошо "проветривает", потому как напрягся (написал) - отдохнул (размялся).
Замечательная статья, комментарии вообще огонь!
"Блажен, кто верует..." (с)
Никакой аргументации, просто набор каких-то заявлений...
С чего бы программистам "исчезнуть"?.. Хотя, если действительно подход к написанию программ изменится, - оптимальность, быстродействие, понятность, - почему бы "миллионам индийских кодеров" не переквалифицироваться на что-нибудь другое? :-)
Вероятно вы не сильно выиграете во всех смыслах, перейдя на новый конфиг, разве что потеряете деньги. Если текущая конфигурация вас по производительности/автономности/эргономике устраивает, то не стоит размениваться...
Не "мерить", а "измерять/измерить", может быть "оценивать/оценить".
Аналогично не "ложить", возможно "положить" или "класть"...
Нормальная ситуация для ремонтников "среднего эшелона" - если компонент соответствует неким параметрам, то его можно пустить в дело.
Самое интересное (для меня) - как у этого аппарата с Линуксом?.. Поддерживает ли его ядро на базе Intel/AMD (x86_64) или требует специальных патчей (и пропатчено ли ядро уже). Удачно ли реализуется мультипоточность и прочие преимущественные при реальной эксплуатации вещи.
что поделаешь, бриттам вот тоже (с запозданием) приспичило
Всё выглядит весьма прискорбно...
Кинулись активно "импортозамещать", а на деле толкаясь локтями интенсивно пилить бюджет (пока дают).
Тот же Дебиан (Убунту) выглядит и то гораздо привлекательней. Да и поддержка сообщества - совсем не "кучка, а в кучке три штучки".
Видимо не все шишки ещё набиты, судя по темпам "анонсирования" и реакции знающих товарищей...
Как говорится, "это всё, что вам нужно знать о криптовалюте!" )))
Обыватель обычно гонится за "трендом", специалист предпочитает баланс производительности/отдачи и цены.
Приятно посмотреть на гаджет из юности!..
Было бы смешно, если бы не было так грустно...
Пилотов подготовить долго и затратно. Кроме того, им необходим постоянный "налёт часов" для закрепления и развития практических навыков. Если ещё и "выбросить" из схемы одного пилота, то это спровоцирует уменьшение числа годных пилотов и , в результате, будет ещё больше проблем в будущем...