Easyelectronics.ru

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

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

Структура проекта.

ммм... Ну структура проекта то проста и незатейлива:
+- Низкоуровневые драйверы:
. |---- драйвер дисплея
. |---- драйвер клавиатуры и драйверы тумблеров, энкодеров
. |---- драйверы коммуникации (UART, Ethernet или др)
. |---- драйверы всякой лабуды типа термометра или еще какой хрени
+- Middleware:
. |---- Ввод и вывод:
..... |---- модуль этой вашей клавиатуры, распознавание нажатых кнопок, тумблеров, энкодеров, реакция на них
..... |---- модуль графики: текстовая, векторная, формирование шрифтов, линий, кружочков, растровых битмапов, квадратиков
..... |---- модуль связи с внешним миром через тот же Modbus или еще чего
. |---- Управление остальной лабудой
+- Hi-level:
. |---- GUI: содержание менюшек, хуюшек, плюшек и завитушек
. |---- логика работы и взаимодействия
. |---- прочая важная хня

Я к тому, что модуль клавиатуры один. События нажатия, удержания, повтора. Где обрабатывать, как разделить логику. Задание параметров и режимы работы.

Эти события - дело низкоуровневого драйвера. В middleware-уровень он должен передать лишь код распознанного события. В среднем уровне - это типа scanf - распознавание вводимого потока.
Сразу определитесь, какие реально события клавиатуры у вас возможны в приборе. Т.е, если двойного нажатия одной кнопки не используется, то и реализовывать его распознавание - не нужно

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

ммм.. то есть, у вас одна клавиатура безо всяких там дополнительных тумблеров-энкодеров? окей. Пусть у вас будет низкоуровневый драйвер этой клавиатуры, который дергает ножки (если матричная) и читает их состояние. Каждой кнопке присваивается код. Если у кнопки есть вторая функция, то у этой функции - свой код, продолженный дальше по номеру. Задача драйвера клавиатуры - определить, была ли нажата кнопка, как она нажата, сколько их нажато и долго ли она нажата. И выдать всего лишь индивидуальный код. Самое простое - с одинарными простыми нажатиями, с одной ф-цией кнопки. Коды - от 1 до 16, например. или даже в ANSI-формате, если цифры там (30-39 для 0-9, и любые другие для остальных).
Всё. Дальше ф-ция, подобная gets или scanf читает поток и определяет, какое число было введено.

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

Я все-таки напомню - Интерфейс генератора. Вполне себе годный вариант для не слишком сложных интерфейсов. Логика простая, линейная. Добавлять/редактировать функционал легко. Нет ваших нелюбимых диспетчеров!

Следует разделить проект на уровни/абстракции, и ими оперировать. Примерно как расписал BusMaster. Самый низ - аппаратно зависимая штука, которая (на примере клавы) только опрашивает кнопки, определяет различные типы нажатий. И уже наверх в нужный таск выдает эти коды. Идеально видится очередь, в которую клава кладёт свои события. Клаве по барабану, кто именно будет разгребать её события, её дело нехитрое. А уж таск, уровнем повыше ожидает событий из этой очереди. К очереди могут обращаться несколько тасков, смотря кому нужны эти события. GUI должен быть совершенно отвязан от логики, его дело - отображать инфу и передавать воздействия в алгоритм (например нажатия на кнопки/крутилки в GUI если они есть). Поидее, GUI можно вообще отключить и всё должно работать, т.к. GUI не влияет в корне на работу алгоритма. Каждая периферия должна быть максимально автономна и вообще не знать, что рядом есть еще кто-то. Инициализировать только себя и предоставить некое API (extern функции/данные) вовне для взаимодействия с собой уровню выше. Уровень выше не должен заморачиваться как именно периферия работает, какие там аппаратные завязки (не считая особо тонких случаев, когда железо всё же важно).
Самый верхний уровень в каком-нибудь SystemInit() собирает всю периферию в кучу, инициализирует каждую по отдельности, запускает главный алгоритм.
Но в таких штуках уже операционка просится, без неё будет тяжеловато реализовывать все хотелки.

Модуль клавы - вопросов нет. Опрос кнопок, при нажатии, удержании, автоповторе генерируются события и коды кнопок. Модуль откукарекал, дальше трава не расти.
На свежую голову сегодня обдумал. Возможно, что проблемы и нет. Все равно есть состояния прибора, которые позволяют разделить на логику работы и интерфейс. То есть, грубо: после включения прибор в определенном режиме. И в этом режиме "смена режима" и "вход в задание параметров". Соответственно, в этом состоянии отлавливаем только кнопку режим. А дальше все просто.

Народ, затруднение, помогите определиться. Одна и та же кнопка может выполнить разные функции. Скажем, если нажать 1 раз - одна функция. Если 5 раз - другая.
Кто как решал подобное. Буду признателен, если приведете примеры.

От кнопки приходит сообщение "меня нажали" и "меня отпустили". Эти сообщения обрабатывает стейт-машина. Если сейчас состояние по кнопке есть "4 нажатия" и пришло еще одно - то перейти в состояние "5 нажатий" и по нему сделать соответствующие действия.

Конкретика где?

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

рукалицо

Посмотрите, как работает ваша мышка, одинарный и двойной щелчок левой кнопкой мышки. Там различается даже три варианта нажатий: однократное нажатие, двойное нажатие, и однократное нажатие с удержанием. Действие по однократному нажатию начинается сразу же, действие по удержанию - логически связано и является дополнением к предыдущему, действие по двойному нажатию так же логически связано и так же дополняет (продолжает логически) действие по однократному нажатию.

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

А теперь подумайте - а вам действительно реально и непременно стопудово однозначно нужна именно такая комбинация?

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

Пусть противоречие останется в голове клиента, а ты делай, что просят. Одно нажатие - делается одно, если сразу второе - то делается плюс что-то еще. Вот, пожалуйста, как вы и говорили. Клиент скажет - "Но по двум нажатиям должно делаться только второе, а первое не делаться". Ок, сделать по двум нажатиям только второе дело. "А одно нажатие должно делать первое, а чо оно теперь не делает?". - Ок, возвращаем первый вариант :))

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

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

Реакция по нажатию. Если реакция по отпусканию, это неприятно для пользователя. Так как нет видимого отклика на нажатие.

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

В приборе не гуевые приложения. Это семисегментный дисплей.