Как стать автором
Обновить

Комментарии 24

Считаю, что с точки зрения UserInterface «тыыык и тыыыык» неудобны. Более удобны были-бы длинные или сдвоенные нажатия, меняющие отклик всех или остальных кнопок.
Это мотоцикл. Руки в перчатках, время есть тк все тыки идут на стоящем моте.
В проекте пока что так:
Два экрана: нормальный и спортивный. Переключаются сликом по кнопке режим (1).
В спортивном кнопка ввода (4) даёт старт/стоп круга по клику. Удержание сбрасявыет всю статистику гонки.
В нормальном режиме клики вверх/вниз (2/3) преключают одометры. Долгое удержание ввода (4) сбрасывает текущий одометр. Удержание ввода (4) переводит экран в меню и можно ходить по полям: одометр, моточасы, часы. Ходить кнопками вверх/вниз. Клик на ввод приводит к редактированию поля, если можно. Можно только часы портить. Клик ввода завершает редактирование и выходит из меню. Долгое удержание выводит из меню. Очень долгое обнуляет поле.

Думаю добавить в протокол класса флаг для слишком долгого удержания на замену его многокликом. Достаточно внутри просто вызвать переход к toIdle. Это полезно для настройки часиков.
Vapor, вроде, всего 3мя кнопками обходится.
Для спортивного режима кнопку старт/стопа удобнее на руль тогда выводить. Если круги короткие и без остановки — погрешность с запуском с приборки будет приличная.
Но вообще идея интересная. По размерам большая получилась? Ну и корпус стоит делать не убиваемый. С таким катанием при приземлении на руль приборку можно в кашу превратить.
Офтоп: Чтобы так не летать рекомендую держать палец на сцеплении. Иногда реально спасает.
На руль обязательно. Но это будет параллельно — на руле и на приборке.
На КТМ, более того, это штатная фича и разъёмы уже есть.
Вот из-за излишнего ООП в либах я так и не смог сделать погодную станцию на уно. Тупо оперативки не хватило, слишком жирно откушано переменными в либах RTC и SD. Остается свободными 300 байт и их не хватает. Либо надо оптимизировать чужие либы, выкусывая ненужный мне код и переменные, либо разносить на 2 микроконтроллера.
SD толстая либа весьма.
ООП позволяет как раз одной строкой создать и настроить объект. Если их много, это удобно, конечно же. Ну и спрятать логику глубоко можно. Я проверил, вот этот код занимает совсем мало памяти что на ООП, что так.
Я бы на твоём месте подумал о втором контроллере с SD и связал бы их по I2C. Например, Pro Mini размером сам с карточку SD.
Я хотел сделать все на голом 328, с уходом в спячку и питанием от батареек АА (4 шт). Но с таким раскладом придется делать станцию из двух частей — часть висящая за окном и следящая за погодой за окном, с отправкой по 433 RF, и часть в квартире (не требовательную к питанию), с логгером и RTC. Два рядом вешать смысла не вижу.
Есть такая штуковина: State Map Compiler — на специальном языке описываются состояния машины и переходы, и компилятор генерирует код — на C, C++, Java и т.д.
Может так проще будет?
Спасибо, почитаю сейчас. Для следующего шага мне как раз что-то подобное надо.
Не увидел обработку дребезга кнопки, это где-то глубже?
Нет, на самом виду. Там от нажатия кнопки (PreClick) до события Click 10мс, это как раз дребезг.
а почему не отработать ее RC фильтром, обойдясь без кода?

Контрастность у дешевого дисплея lcd 1602, как по мне, отвратительная. Для outdoor я бы не использовал.
Ну, и кодировать таблицу состояний можно разными способами, ваш оригинальный.

Спасибо.
У меня несколько разных дисплеев, я неспешно подбираю поконтрастнее.
автомат очень удобно делается с помощью xmacros.
Подскажи кто-нибудь пример, как грамотно реализовать работу с «шифтами» как на геймпаде к PS3: нажатие кнопки — одно действие, кнопка+шифт — другое, кнопка+оба шифта — третье. Если проверять состояние шифтов перед обработкой, код уж очень некрасиво обрастает if/switch'аим
Там много кнопок и есть специфика своя, я бы сделал для шифт класс управляющий кнопок, а их состояние менял в классе onClick/offClick. ставя / убирая бит соответствующий в некой глобальной переменной shiftState.
На тему xmacros. Там надо много писать.
Чем плоха запись, как у меня>
Вроде столько же или чуть меньше, особенно если кнопки начнут плодиться или зависеть друг от друга. Опять же, ФП, метапрограмирование, пафос :)
Да, я тут видел, что впихали ноду в МК. Жесть.
Ну, если упихать и попрыгать сверху… Но вообще я имел в виду вот эту милую наркоманию: 1 2 3 4
Жуть какая…
Жуть — это вот это: 1 2 3
Если Вы думаете, что нельзя написать ещё более мерзкий, непонятный и неподдерживаемый код с использование сишных макросов, то Вы ошибаетесь. На крайний случай всегда есть М4
После senmail.cf меня уже не удивить.
В печали пребываю.

С++ говно.

Размер объекта 157 байтов. На кнопку! Это перебор уж. Указатель на метод класса — 4 байта, на просто функцию — 2. Переписал в итоге внутри на Цэ плоском старом добром саму МКА. Интерфейс оставил старый, так что, всё прошло незаметно. В итоге 13 байтов на объект, уже ничего.
Эх, таблицей, конечно же, красиво, но в ембедеде… Жрёт память таблица, да и вообще оопность негуманно её расходует.

Закоммитил.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории