всегда умиляюсь, когда на любительском форуме приводятся аргументы из категории "а в ракетной технике надо..."

хмм... в случае БП может и так

энкодеры обычные оптические, на небольшой двигатель похожи, у китайцев много - 200-400 импульсов

http://ru.aliexpress.com/wholesale?catId=0&initiative_id=SB_20150403030722&SearchText=encoder+optical

на 24 если опросом косяков особых не увидел


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


ну вот иногда надо, где еще это надо в любительских поделках я не придумал где скорость и точность нужна и без ШД... фиг знает

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Для долгой безотказной работы и делаются качественные компоненты. Посмотрите в ДШ ресурс контактов Вашего механического энкодера и посчитайте насколько его хватит при повороте хотя-бы на один оборот ежедневно. Конечно, они делаются с запасом, но...

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

судя по продукции этих www.alps.com/ ребят оптические проживут в 2 раза больше , 30 000 против 15 000 полных оборотов , по 1 полному обороту в день это 41 год , учитывая что управление так-же будет осуществляться по радиопульту , со смарта , и автоматически с cubieboard 2 который я избрал в качестве главного мозга системы "умный дом" , то он проживет достаточно долго , и несмотря на это вы заставили меня задуматься над тем что-бы применить оптику, или как я слышал есть еще магнитные на датчиках холла руки дойдут и их пощупаю за мягкое место


ps: довести схему до максимума который я в состоянии выжать все-равно попробую и отпишу сюда

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Сдохнет она, не приведи, лет через шесть-восемь и вместо умного дома у вас будет самый глупый дом в округе. Потому что новую такую кубю будет уже не купить.

Вопрос в том, что они имеют в виду под cycles. В большинстве случаев это цикл единичного замыкания/размыкания контакта, а не поворота на 360. У механических ресурс контактов около 30000 замыканий. Даже у кнопок он бывает редко больше 100000. Иногда отдельно приводится ресурс остальной механики, например detent. Хотите долго и много щелкать - ставьте оптический без (detent) . У них ресурс исчисляется миллионами единиц.

что-же тогда посоветуете вместо нее пилить ?

я выбирал что-либо из опенсорса дабы при случае можно было-бы по-быстрому починить. Как вариант можно не чинить ибо все делаеться под линукс а значит подправить код под любой другой подобный проект - не проблема.

Что тут считать, если на столе куча приборов с механическими энкодерами, живой пример. Некоторым по 10 лет, и ничего, живут.



Тратить деньги на оптические энкодеры - сущая глупость (если это не какой-нибудь трансивер). Наоборот, я в последнее время вместо Bourns PEC-16 стал применять более дешевые китайские no-name:



Они по дребезгу заметно хуже, пришлось даже усложнить программную обработку (ввести временной интервал запрета реверса энкодера и фильтр состояний):

Спойлер

Код:

//----------

//Модуль поддержки энкодера

//---------- Используемые ресурсы: ----------

//Сигналы энкодера F1 и F2 подключены к портам IO.
//Кнопка энкодера обрабатывается в другом модуле (keyboard.cpp).
//Используется программный опрос (поллинг).

//----------

#include "main.h"
#include "encoder.h"
#include "data.h"

//---------- Константы: ----------

#define ENC_MAX_V  14 //пороговая скорость энкодера, шагов в секунду
#define ENC_V_TM  100 //интервал измерения скорости энкодера, mS
#define ENC_R_TM   10 //интервал запрета реверса энкодера, mS

#define ENC_MAX_VC (ENC_MAX_V * 4 / (1000 / ENC_V_TM))

//----------
//---------- Класс TEncoder: ----------
//----------

//---------- Конструктор: ----------

TEncoder::TEncoder(void)
{
  Pin_F1.Init(IN_PULL, PULL_UP);
  Pin_F2.Init(IN_PULL, PULL_UP);
  Message = ENC_NOP;
  EncPrev = STATE_0;
  EncPrevPrev = STATE_0;
#if ENC_FLT > 1
  for(char i = 0; i < ENC_FLT; i++)
    EncF[i] = STATE_0;
  FPtr = 0;
#endif 
  EncV = 0; EncS = 0;
  EncTimer = new TSoftTimer(ENC_V_TM);
  EncTimer->Autoreload = 1;
  RevTimer = new TSoftTimer(ENC_R_TM);
  RevTimer->Force();
  Dir = 0;
  Rev = 0;
}

//---------- Опрос энкодера: ----------

void TEncoder::Execute(void)
{
  if(EncTimer->Over())                //проверка таймера энкодера
  {
    EncV = EncS;                      //сохранение текущей скорости
    EncS = 0;
  }
  EncCur = STATE_0;
  if(Rev)
  {
    if(!Pin_F1) EncCur  = STATE_A;    //чтение фазы 1
    if(!Pin_F2) EncCur |= STATE_B;    //чтение фазы 2
  }
  else
  {
    if(!Pin_F1) EncCur  = STATE_B;    //чтение фазы 1
    if(!Pin_F2) EncCur |= STATE_A;    //чтение фазы 2
  }
#if ENC_FLT > 1
  EncF[FPtr] = EncCur;                //заполнение массива фильтра
  if(++FPtr == ENC_FLT) FPtr = 0;     //обновление указателя
  for(char i = 0; i < ENC_FLT; i++)
    if(EncF[i] != EncCur)             //если в массиве есть флуктуации,
      EncCur = EncPrev;               //запрещение обработки состояния
#endif
  if(EncCur != EncPrev)               //если состояние изменилось,
  {
    if(EncCur != EncPrevPrev)
      EncS++;                         //счет шагов для измерения скорости
    if(EncPrev == STATE_AB)
    {
      if(EncCur == STATE_A &&
         EncPrevPrev == STATE_B)
      {
        if(Dir || RevTimer->Over())
        {
          if(EncV >= ENC_MAX_V)       //если порог скорости достигнут, то
            Message = ENC_FAST_STEP;  //сообщение быстрого инкремента
              else                    //иначе
                Message = ENC_STEP;   //сообщение инкремента
          Dir = 1;
        }
        RevTimer->Start();
      }
      if(EncCur == STATE_B &&
         EncPrevPrev == STATE_A)
      {
        if(!Dir || RevTimer->Over())
        {
          if(EncV >= ENC_MAX_V)       //если порог скорости достигнут, то
            Message = -ENC_FAST_STEP; //сообщение быстрого декремента,
              else                    //иначе
                Message = -ENC_STEP;  //сообщение декремента
          Dir = 0;
        }
        RevTimer->Start();
      }
    }
    EncPrevPrev = EncPrev;            //сохранение пред-предыдущего сотояния
    EncPrev = EncCur;                 //сохранение предыдущего сотояния
  }
}

//----------
//----------
//----------

Но тоже ничего, работают. Радиолюбительство и так отъедает непозволительно много денег, а тут про какие-то дорогие оптические энкодеры. Бред.

Ну можно сколхозить Любая подходящая механика, диск и оптопары на просвет или отражение ( на отражение типа таких http://www.chipdip.ru/product/ktir0821ds/ тогда диск можно даже на бумаге нарисовать, я с такими веревку в зебру разрисовал и протягивал через трубочку мимо двух оптопар, обрабатывал как энкодер - работает четко http://www.youtube.com/watch?v=9rN-O_V32q0 ). Разбирал свой оптический - там диск металлический с прорезями, оптопары и какой то усилитель-формирователь с ОК.
Или из ШД сделать, тут на радиокоте есть статья. Кто нибудь пробовал так ?

Механические энкодеры довольно часто можно встретить в стиральных машинах. Если в приборах режим эксплуатации относительно щадящий, то в стиралке более на экстремальный похож. Влага, химия, пыль, вибрации, температура. Пару лет назад как-то встречаю соседа, выворачивающего стиральную машину из квартиры. Купил новую, а эту на помойку тащил. Мащина из тех, что в девяностых население массово закупало на волне ажиотажного спроса. Стой, говорю, уно моменто. Сдернул электронику из соображений "авось на что сгодится". Так вот контроллер там нарядный оказался. Видно, что и заливали его когда-то. Запомнились светодиоды, которые стояли на длинных ногах, чтобы до морды дотянуться. Вот эти ноги от окислов были абсолютно черного цвета. Окислено все, что только могло окислиться, забито грязью, что номиналов не прочитать. Тем не менее, электроника была жива до самого момента принятия решения об отправке на выброс. Сдохла механика, проржавел корпус, но аппарат еще подавал какие-то признаки угасающей жизни. В числе прочего с платы был снят и энкодер, который после очистки и изучения диковинной конструкции (в стиралках энкодеры не такие, какие мы привыкли видеть), отправился в загашник с расчетом, что мож когда-нибудь на что-то сгодится.

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


Поддерживаю.



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

Давно хотел спросить насчет софтовых таймеров. Они у вас отдельными объектами сделаны, которые потом динамическим списком собираются? Как-то громоздко выглядит. Я счетчики статическим массивом храню и понимаю, что решение какое-то совсем уж деревянное, но лучше ничего в голову пока не приходит.

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



Мое мнение, что поллинг - самое то, что должно применяться к таким органам управления, как кнопки и энкодеры. Конечно, скоростные энкодеры с тысячами импульсов на оборот не в счет. Сам поллинг занимает исчезающе мало времени. К тому же, процессору обычно нечего делать, когда пользователь ничего не крутит и не нажимает.



Работа по прерываниям может быть оправдана только в одном случае - если требуется организовать очередь событий. Обработка событий все равно ведется задачами основного цикла, поэтому поллинг остается - вместо портов IO опрашиваются флаги, сформированные обработчиком прерывания. Вообще, плодить в системе лишние прерывания крайне нежелательно, так как они увеличивают латентность по-настоящему нужных прерываний.



В данном случае все можно сделать программно, лишние аппаратные затраты - это чистой воды вредительство.



Я стал жить заметно лучше, когда перестал думать о громоздкости и медлительности кода. Особенно на таких избыточных для радиолюбительства контроллерах, как STM32. Главное - читабельность и простота поддержки. У меня программные таймеры представляют собой объекты, которые я создаю динамически.

Спойлер

Код:

//----------
//---------- Класс TSoftTimer (h): ----------
//----------

class TSoftTimer : public TSysTimer
{
private:
  uint32_t Interval;
  uint32_t StartCount;
  bool Event;
protected:
public:
  TSoftTimer(uint32_t = 0);
  bool Autoreload;
  bool Oneshot;
  void Start();
  void Start(uint32_t t);
  void SetInterval_ms(uint32_t t);
  void SetInterval_sec(uint32_t t);
  void SetInterval_min(uint32_t t);
  void SetInterval_hrs(uint32_t t);
  void Force(void);
  bool Over(void);
};

//----------
//---------- Класс TSoftTimer (cpp): ----------
//----------

//---------- Конструктор: ----------

TSoftTimer::TSoftTimer(uint32_t t)
{
  Autoreload = 0;
  Oneshot = 0;
  Event = (t == 0)? 1 : 0;
  Interval = t;
  StartCount = TSysTimer::Counter;
}

//---------- Старт: ----------

void TSoftTimer::Start()
{
  Event = 0;
  StartCount = TSysTimer::Counter;
}

void TSoftTimer::Start(uint32_t t)
{
  Interval = t;
  Event = (t == 0)? 1 : 0;
  StartCount = TSysTimer::Counter;
}

//---------- Установка интервала: ----------

void TSoftTimer::SetInterval_ms(uint32_t t)
{
  Interval = t;
}

void TSoftTimer::SetInterval_sec(uint32_t t)
{
  Interval = t * 1000;
}

void TSoftTimer::SetInterval_min(uint32_t t)
{
  Interval = t * 60000;
}

void TSoftTimer::SetInterval_hrs(uint32_t t)
{
  Interval = t * 3600000;
}

//---------- Принудительное переполнение: ----------

void TSoftTimer::Force(void)
{
  StartCount = TSysTimer::Counter - Interval;
}

//---------- Чтение переполнения: ----------

bool TSoftTimer::Over(void)
{
  bool event = TSysTimer::Counter - StartCount >= Interval;
  if(event)
  {
    if(Oneshot && Event) event = 0;
    Event = 1; 
    if(Autoreload)
    {
      StartCount = TSysTimer::Counter; //перезапуск
      Event = 0; 
    }
  }
  if(!Oneshot && !Autoreload) event = Event;
  return(event);
}

//----------

Бред... тупость... Класс! Вы выразили свою точку зрения очень доходчиво и профессионально. Спасибо!

Согласен, что в дешевой промышленной электронике часто о ресурсе компонентов говорить нет смысла. Создаётся впечатление, что большинство её, словно, и делается с рассчётом, чтобы сломалось через несколько лет. Хорошо, если ваши устройства работают (пока). У меня за последние пару лет было несколько отрицательных опытов с механическими контактами, которые я использовал долгое время. Например, с кнопрой открывателя гаража, которую я нажимаю по нескольку раз в день и энкодер регулировки радио в старой машине. В устройствах, которые не крутят интенсивно каждый день - те-же стиральные машины - ресурс кнопок не успевает выработаться по сравнению с другими частями. С регулятором освещения в этом плане дело может обстоять иначе (а может и нет).

Радиолюбители, в отличии от промышленности, могут позволить себе поставить более дорогие и качественные компоненты в свои единичные поделки. Понимаю, что если кто-то живёт, скажем, на 5 баксов в день, то заплатить 20 за деталь может быть препятствием. Но такие не все, пусть даже их и большинство здесь на форуме (можер быть). Для кого тогда выпускается масса моделей оптических энкодеров? Вопрос "зачем" если и на дешёвых сделать можно здесь неуместен, т.к. однозначного ответа на него нет. Каждый решает его индивидуально и по-своему, принимая во внимание массу субъективных факторов. Зачем ездить на дорогой машине, если и на дешевой можно. Можно только посоветовать что-то, например, в плане удобства. Для кого-то это непозволительная роскошь, а кому-то покажется разумным и приемлимым.

Я живу на 2.7$ в день, моя зарплата по курсу на сегодня чуть больше 80$ в месяц.

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


Если такие радиолюбители видят смысл жизни исключительно в радиолюбительстве, то они могут тратить не только все зарабатываемое на высококачественные компоненты, но и залезать еще при этом в долги или продавать имущество. Можно осуждать такую позицию, но не больше, чем любые другие безобидные чудачества. Если же мы не говорим о радиолюбителях-ортодоксах, то в жизни обнаруживается еще куча способов потратить деньги не менее интересным и приятным способом. Когда я иногда говорю, что не могу себе позволить купить то-то или то-то, то мне отчего то начинают советовать поменять работу и начать больше зарабатывать. Зарабатывать больше -- это априори хорошо, но в тех случаях, о которых шла речь, данный вопрос обычно совершенно не при чем. Важная деталь, на которую никто в описываемых случаях почему-то не обращает внимания, заключена в том, что обычно я могу немедленно отправиться покупать всю ту хрень, о которой шла речь, если только сочту это действие для себя рациональным. А вот с последним обычно все не так просто. Обладая ограниченным финансовым ресурсом при хорошей фантазии в плане, как потратить деньги самыми разнообразными способами, обычно приходится выбирать, что купить в первую очередь. Далее потребительский алгоритм ветвится на конструкции, что покупать, а что не покупать и выкрутиться иным образом. Дальше-больше, дальше-больше. Задача в конечном счете вырождается не в вопрос, "как и что купить", а "что и как не купить" потому, что в рамках финансовых возможностей остаются только планируемые покупки, избежать которых решительно невозможно. И вот когда я мысленно представляю список необходимых покупок на пол-года вперед, а кто-то мне предлагает купить какой-то совершенно забубенный оптический энкодер, чтобы решить какую-то совершенно дурацкую недопроблему, то я испытываю очень сильное разочарование от того, как люди считают допустимым распоряжаться деньгами.



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


Есть очень хороший ориентир -- массовый сегмент. В массовом сегменте не выживают товары, потребительские свойства которых неудовлетворительны. Понятно, что в рамках радиолюбительства массовый сегмент это не дешевые крупы или бюджетные телефоны. Все вышесказанное говорится с поправкой на конкретную специфику. Так вот, наличие дешевых энкодеров в массовом сегменте, как раз и говорит о том, что их потребительские свойства, как минимум, приемлемы и нашли одобрение рынка. От советов в данных условиях купить оптический энкодер неуловимо веет запахом каких-то перламутровых пуговиц.


И то верно. Объяснить, зачем непременно нужно ездить на дорогой машине, намного сложнее, чем объяснить, зачем нужно ездить вообще.



Как-то вы лишь с одной стороны пытаетесь смотреть на проблему. Вот взять алгоритм непрерывного регулирования без обратной связи. Что мы там регулируем? Звук, свет, обороты кухонной вытяжки? Алгоритм смотрит значение задающей переменной, вычисляет величину управляющего воздействия и выдает ее на исполнительное устройство. Для простоты будем считать, что больше он ничего не делает. Если в этот момент случается внешнее прерывание, то обработчик меняет значение переменной, но для основного алгоритма это никак не меняет порядок его действий. Он как считал, так и считает. Он выполняет только действия, касающиеся непосредственно управления, не отвлекаясь на сервисные функции. Почему вы считаете, что нагрузив его еще обязанностью смотреть за кнопками и движками, вы получите какие-то выгоды? Латентность? Ну, может. Только это опять не бесплатно. Повесив сервис на основной алгоритм, вы повышаете нагрузку на него, причем, часто без особой на то причины.

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


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


Покрутил я их покрутил, попробовал как-то приткнуть к своим задумкам, но не ощутил ровным счетом никаких выгод. Либо у меня задачки совсем туфтовые, либо я их готовить не умею.

Что интересно, мне попадались отраслевые исследования, где описывались своего рода пристрастия разработчиков к разного типа МК (начиная от четырехбитных, спрос на которые существует и сегодня, и заканчивая А20 и выше), так там отдельно выделялся факт, что при наличии довольно массовой миграции с малоразрядных платформ на 32 бита, существует и обратный поток, хотя и заметно меньшим числом. И вот в этой связи мне почему-то не кажется, что такой "обратный ход" организовался целиком из неудачников, дурней и прочих бестолочей. Видимо существует достаточно веские причины, почему разработчики познакомившись с новой платформой, пожелали впоследствии все же вернуться на старую. Предполагать, что выбор целиком определяется решением каких-то конкретных задач, где требования насчет используемой платформы изменить нельзя, не представляется возможным, т.к. выводы делались на основании ответов на вопрос: "На какой платформе вы бы предпочли реализовать свой следующий проект."

В общем, пока мне не попадется задачка, где потребуются ресурсы арма, так и будут эти представители 32-битных МК у меня лежать в заводской упаковке. Совсем простые задачки сподручнее на атмеге делать, а нужна забористая периферия, тут stm8s сгодится. Совершенно шикарный камень -- STM8L152. У него периферия -- не у каждого STM32 отыщется. Че все за этими STM32 подорвались, не пойму.


Какая может быть читабельность у десятков регистров с непроизносимыми названиями и сотен битов к ним? Я их никогда и не запоминаю. Вообще считаю, что генератор кода инициализации -- наше все. А общие алгоритмы, они без разницы на каких камнях крутятся.


Хорошо. Правильно. Но громоздко.

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

И Леонид Иванович и Ser60 мыслят абсолютно логично. Но вы, Леонид Иванович не можете примерить "чужую" шкуру на себе. Но не забываем, что Ser60 живет в богатой стране, и наверняка имеет доход больше, чем 2000$/месяц. И соответственно потратить 10% дохода на радиолюбительство скорее всего не проблемма. Поэтому выбор очевиден - лучше купить более дорогие энкодеры, а не тратить лишних 3-4 часа на написание устойчивого к дребезгу алгоритма.

Я вот например живу в "промежуточном" месте. Могу потратить где-то 50-100$ в месяц на радиолюбительство, и этого даже никто не заметит в финансовом плане.

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

Не важно, где он живет, важно - что он делает. Речь о качественных комплектующих можно начинать вести лишь тогда, когда сам проект является качественным. Покажите мне такие, допустим, на примере этого сайта - проекты, которые находятся в стадии разработки и заслуживают внимания. Я пока могу привести только один пример проекта, за которым с интересом слежу. Возможно, я пропустил что-то интересное, тогда поправьте.



Интересно, а как с ними реализовать навигацию по меню? Крупный шаг и "трещетка" механических энкодеров здесь являются жизненно необходимыми.

Перефразируя: мне энкодеры не нужны, но я бы их купил. Как сказал кто-то из юмористов, "Компьютер построен на элементах женской логики: "НЕТ", "НИКОГДА" и "НЕ МОЖЕТ БЫТЬ".

Кроме публичных "проектов" у радиолюбителей ведь есть еще неисчислимое количество, скажем так, уникальных поделок, критерием применимости деталей в которых может и не являться рациональность. Я скорее выберу деталь, которую лично мне применять удобнее, которая компактнее при прочих равных, которая может пригодиться в будущем и ее стоит "пощупать" и которая просто чем то больше нравится (ну или которая уже в тумбочке есть). Мне, например, OLED дисплеи нравятся, а LCD, да еще если это стандартные символьные 16x2 - очень не нравятся и даже если LCD 16x2 достаточно я его использовать не буду и, поскольку это мое хобби в любом случае убыточно, потрачу на деталюшки сколько не жалко. Компактные оптические энкодеры со щелчком попадались какие то $5- $10 что ли, но вот сейчас не нашел почему то. Год назад я много чего на али заказал в соответствии с логикой "не очень то и нужно, но я бы купил", а сейчас уже не купил бы так что и "где кто живет" имеет значение.