Arduino.ru

А неграмотные канают? )) Есть состояния (режимы).  Для каждого состояние есть события (например различные нажатия кнопок) переходов в другие состояния. Стандартный конечный автомат, не?

Что в лоб, что по лбу. Первично таки событие кнопки, а действие уже зависит от текущего режима

ИМХО, первичны как раз состояния. В некоторых состояниях события кнопки вообще могут игнорироваться, а из некоторых возможен переход по таймауту. Ну и код нагляднее

Принял «пару капель» за завершение ремонта первой комнаты у детей. ) Суть вопроса была в том - где больше кода в функции завернуть можно (ну или другим способом сократить).

То есть по событию (нажатиям) обрабатывать режимы, или по «режимам» обрабатывать нажатия. Бррр, сам теряюсь... ((

Одно и то же написал в обоих случаях. От перемены мест слагаемых...

Вот и я теряюсь от чего лучше «исходить»...

Я ж говорю - что в лоб, что по лбу )) Кнопка в любом случае опрашивается, но реакция идет только на нужные события

  // имеем два режима, в обоих используется одна и та же
  // кнопка, но обрабатываются разные события
  byte _state = btn.getButtonState();
  if (mode == 0) // первый режим, обрабатываем одинарный и двойной клик
  {
    switch (_state)
    {
      case BTN_ONECLICK:
        // действия по одиночному клику
        break;
      case BTN_DBLCLICK:
        // действия по двойному клику
        break;
    }
  }
  if (mode == 1) // второй режим, обрабатываем только удержание кнопки
  {
    switch (_state)
    {
      case BTN_LONGCLICK:
        // действия по удержанию кнопки
        break;
    }
  } 

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

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

Но, как я уже говорил, дело хозяйское))

Так и флаги устанешь обрабатывать. Все ровно то же ))

«В лоб» или «по лбу» - все в одну голову. ) Упор больше на удобство программирования и сокращение (повторяющегося в основном) кода. Пять минут и спорная ситуация двух людей на форуме, а у меня в голове пару недель просто «дом советов» из 167 личностей, которые мне не знакомы, но советуют во сне )))

То есть Вы советуете исходить от «режимов», а не от «событий кнопок», я правильно понял?

Дык, программа - это таки режимы, там ведь не только кнопки обрабатываются ))

 Если вопрос мне, то я ничего не советую. Лично МНЕ удобнее, в том случае, если программа/оборудование имеет четко определенные режимы/состояния работы, оперировать именно состояниями. 

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

void loop() {
  auto maybe_input = keypad.scan();
  current_mode->loop(maybe_input);
  screen.update();
}

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

Я всегда говорю - программирование это объяснение задачи тупому, но очень исполнительному подчинённому.

Классы, структуры и прочее - это только инструкции для него, написанные Вами где-то ещё. Хотите упростить - напишите правильно эти инструкции, нет - объясняйте по пунктам чего делать. 

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

Я вопрошал о том, как минимизировать лучше код. То есть "экранизация":

1. Нажата кнопка, смотрим какой режим сейчас установлен и в зависимости от РЕЖИМА выполняем ДЕЙСТВИЕ.

2. Установлен режим "1" (к примеру), смотрим - "а какая кнопка нажата и нажата ли вообще?".

Вот суть темы была. Но я как и выше писали, к первому варианту склоняюсь. Но второй же тоже жизнеспособен? Или нет?

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

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

Итог. Ваш вопрос на бытовом уровне звучит так. Как оптимально взять запчасть от машины и поехать на ней на лето в Крым. Ответ будет банальный. Берите цельную машину и учитесь ее водить. И компьютерные события и состояния это только часть от целого. Само по себе не работает. :))

Более загадочного ответа не слышал. Спасибо и на этом. 

Вопросы на этом форуме задавать - это минус 5к килокалорий в сутки. Поэтому если и задавать вопросы, то только «риторические». Обо#рут много раз и к гадалке не ходи, но среди этого г#вна можно и что то полезное найти. Ради этих полезных «крупиц» можно и вагон го#на прочесть. 
Я человек привычный, гомнонедолюдей каждый день встречал на протяжении половины жизни по работе и после неё, так что мне это все как в магазин сходить. 

Кнопки это всегда вторичное. Это способ взаимодействия с программой. Программа может долго работать, а кнопку нажать один раз в день. Кроме кнопок, параллельно им может быть управление через сом порт, wifi web и прочие интерфейсы. При этом реакция программы должна быть адекватной из любого текущего состояния или режима работы. Поэтому вопрос поставлен не логично. Есть подпрограмма обработки кнопок. Для неё события - нажатие и отпускание кнопок это значимые события и она должна их получать и обрабатывать. Для основной программы эта кухня должна оставаться за кадром. Для текущего режима работы основная программа должна получить команду от подпрограммы обработки кнопок. Ещё раз напомню, что команда может прийти не только от кнопок. Если сейчас для управления используются только кнопки, это не значит, что в будущем не захочется большего, и тогда вариант кнопки главные станет гирей на ногах программирующего.    

А мне так кажется, что BOOM не за event based model спрашивает, а как проще - совой об пень или пнём об сову. В общем смысле разницы нет. В том или ином месте вырастет ветвистый if или раскатится case по всему огороду.

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

Это я к тому, что современное программирование это программирование со взаимодействием с внутренними аппаратными или программными часами. Дернулось нога с кнопкой, надо фиксировать время и уровень на ноге.И так много раз. А потом через некоторое время выставлять соответвующее событие и вызывать пользовательский обработчик события, в зависимости пункта меню и картинки на экране.

Вот это все нормальный говнолюдь нихрена не поймет, и обзовет говном.

Да, видимо ты прав.

Только вопрос смысла не имеет. Не с проста были придуманы драйвера, демоны, службы и прочая хрень в большом программировании. Вот и тут нужно подходить так... Есть модуль, например опроса клавиатуры. Вот пусть он регулярно и опрашивает клавиатуру, фиксирует состояния и события, выставляет флаги. И модуль клавиатуры не должен знать о режиме программы. Это даже логически очевидно, даже если логика не программистская.

Есть модуль режимов, вот и он пусть работает. Делает то же самое но в своей области. Кто мешает ему спрашивать "за кнопки" у модуля клавиатуры ?

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

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

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

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

а потом про нас пишут "Разработчики встраиваемых систем не умеют программировать"  https://habr.com/ru/post/555498/ 

Вот значить, претензии там.

Если взять типичную встраиваемую систему достаточно высокой сложности, можно выделить примерно следующие сгустки логики:

• Класс-бог, отвечающий за всё сущее.

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

• Utils или helpers, без них никуда.

Что в итоге: модульное тестирование невозможно, потому что нет модулей; толковая поддержка невозможна, потому что всё сложно; о гарантиях функциональной корректности трудно рассуждать всерьёз, нам бы для начала научиться выполнять вменяемую декомпозицию задачи, а не решать все проблемы в одном цикле сразу. Это зачастую преподносится как неотвратимая данность, нельзя по-другому, потому что это же не десктоп система с неограниченными ресурсами, вы не понимаете, это другое.

А теперь на примере своем. Имею устройстов сигналящее о своем состоянии внешнему миру миганием светодиода  ws2812. Режимы там сложные, четыре датчика, два исполнительных устройства, тайминги и пр.. Потому ws2812 не просто горит заданным цветом, а моргает разными, прям дискотека.. В коде для этого куча уровней: вывод цвета 24 бита по протоколу ws2812 ; вывод фиксированного набора цветов; формирования длительностей свечения; некая машинка состояний; преобразования состояния устройства в цвета и длительности... Меня тут все устраивает, для отладки я экран OLED подкидываю, но в боевом без него. Не устраивает другое, т.к. устройство на открытом воздухе 24/7 то яркость светодиода ночью - прожектор. Иначе на солнце днем не видно будет.

Вот я сегодня фоторезистор докинул, с замыслом ночью яркости убавить. Но  ws2812 его засвечивает, и это надо принять как данность. К счастью при мигании ws2812 всегда есть паузы на 10-50мсек и можно в паузах мерить освещенность фоторезистором. Но тогда мерить нужно в нижних уровнях кода, на верхних просто не известно, когда ws2812 не светит и можно мерить. На верхнем уровне тоже хорошо бы знать, день или ночь. Вот сижу ща, перебираю варианты: 1. Функция отображения состояния системы, она уже есть,  доработать чтоб возвращала состояние фоторезистора - архитектурный бред, состояние фоторезистор ну никак жеж не должно зависеть от состояния системы, оно от освещенности зависит. 2. завести глобальную переменную, устанавливаемая где то в глубинах функции отображения состояния системы  для сохранения состояния фоторезистора - не явно, не понятно насколько актуальное состояние. 3. возвращать на верхний уровень признак того, что ws2812 именно сейчас не светится,  чтоб можно было мерить состояние фоторезистора - не нравится, но склоняюсь пока к этому. 4. лечь спать, завтра глядишь чего надумаю. 

Ах да, вишенька! Фоторезистор повешен между плюсом и аналоговым пином, к которому заодно подключен затвор мосфета и подтяжка к земле. До сегодня пин просто управлял мосфетом. Эта подтяжка и образует с  фоторезистом делитель. И мерить можно только когда мосфет закрыт по логике программы ))) 

Сделать это можно, точно можно,  но вот тому мудаку - автору статьи с хабра точно не понравится...

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

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

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

//К сожалению писанина на хабре, все более и более становится сродни википедии.... Что то написано КЕМ ТО

та ладно! Автор https://habr.com/ru/users/Spym/  Павел Кириенко Spym Архитектор Приглашён 30 мая 2011 в 11:19 по приглашению.... Т.е. десять лет..  В интересах и асм и си и рукоделие.

Нет оснований подозревать в некомпитентности.

А вики, как правило, вызывает раздражение у тех, кто не знает предмет даже в том объеме, что в вики есть. Их туда носом часто тыкают, они и ворчат. Но не о этом.

Автор как минимум опытней 90% тутошних постояльцев. И его критика не без основательна. 

/// Специфика есть, это очевидно.

Так бесспорно!

И явно что физика мира и аппаратная специфика стоят иной раз поперек горла стройной архитектуре,  всей этой "эвентщине и API". И традиционно да, в эмбедеде спгетти-код встречается часто (чаще чем в других направлениях). Даже если все типа жестко по уровням в плане зависимостей, то в плане логики -лихой калбек вытягивает на верхние уровни нечто глубинное, апаратно- и/или платформенно- зависимое (например вызов проверки состояние датчика бумаги в принтере для вывода в UI сообщений о ее кол-ве, причем вызов отрабатывает только при некоторых состояниях принтера )))) Как правило, и в моем примере выше, такое появляется как костыли. Чем старше проект - тем их больше.

В эмбедеде мало людей в команде, часто вообще "самсебережисер", рефакторинг редкость, код старый тянут десятилетиями, а аппаратная часть апдейтится. Конец плача Ярославны ;)  Критерий годности  - работает у конкретного клиента, значить ок. Тоже не в пользу красивому коду. О поддержке в будущем думать некому. И некогда. И даже во вред программеру - он хочет чтоб его ценили выше т.к. другой чел хрен разберется в исходниках. Что тут важней непонятно.. Но как-то привыкли. Однако код становится все сложней и стройность архитектуры все важней.

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

ППС. Во знаю как отвечать! Только отдельные гениальные личности способны в одиночку писать код для встроенных систем. И не выскочкам из серой массы вэбдизайнеров судить гениев!  Стиль эмбадеда - не для забитого шаблонами кодера. Гений должен оставаться не понятым! Признание наступит лет через 20, после смерти светоча  ))))))

Прочитал и почти полностью согласен.

"Старых" эмбеддеров можно узнать по обилию глобалов и неприятию объектов ;)). Тут, на нашем форуме, просто полно таких. Сколько не пиши о том, что сэкономленную память на привозе не продашь, все равно считаем байты и такты. Мало тактов? Нужно не код вылизывать заменяя куски ассемблерными вставками, а перейти на арм-ядро. Опять мало? Взять SoC с 4-мя, с 8-ю ядрами, с большей частотой. Это экономически выгоднее, чем тратить время на "вылизывание", и гораздо лучше по  цене сопровождения и по отказоустойчивости.

-------------------

Недавно делал кусочек кода для "ангельских глазок". На вопрос: "почему для тиньки13?" -  был ответ, что в покупном изделии уже запаяна тинька и не одна (я не вдавался, там вроде еще 2313)! В 21ом веке!!!!! Все режимы с фейдерами, эффектами, всеми типами мигалок, ДХО и чертом лысым  можно сделать на одной СТМ и не считать такты на 8ми битных таймерах, пытаясь засунуть все переменные в 64 байта памяти.

Я сделал человеку эффекты, которые он хотел, на тиньке13. Но в 21-ом веке - это бред, как умение бегать в мешке. Вымрем мы - программисты 20ого века,  и никто не станет возиться с 8ми битными АВРками.

вот гложет сомнение, что для простых задач 8-битная архитектура умрёт

дык все проще бывает - ну вот не умею я их хорошо готовить, а криво делать не люблю. Но в общем конечно все правильно - надо перестраиваться, но то времени нет то желания.
ЗЫ. Вчера буквально: пишу под OrangePI R1, рисую функцию которая будет запрашивать с MQTT сервера по номеру абонента строку SIP вызова, живет эта функция внутри одного модуля, если делать красиво - она должна выдавать char* чтоб потом все это использовать, но нет же - щелкнуло в голове - нахрена я буду лишних 100 байт использовать. В итоге тупо в модуле глобальную переменную строку выделил.
И только сейчас осенило, что ведь памяти у меня просто много и экономить ее нет смысла :(