Самодельные часы с Bluetooth интерфейсом на 4-дюймовых индикаторах

Доброго дня всем читателям. Хочу поделиться отчетом по сборке и использованию самодельных часов с огромными индикаторами. Из «плюшек» — полное отсутствие кнопок на корпусе часов – всё управление только с компьютера, через Bluetooth. Заходите, почитайте. Или фото посмотрите.

Зачем всё это?

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

Требования к часам:

• Большие индикаторы (возможно, даже абсурдно большие);
• Точность хода;
• Непропадание настроек времени в случае перебоев с электричеством (фильм «Один Дома» все помнят?);
• Два режима яркости: «дневной» / «ночной»;
• Будильник «для подстраховки» (основным будильником является телефон).

Теперь про каждое из требований поподробнее.

Большие индикаторы. Как я уже писал, надоело всматриваться по ночам в обычные стрелочные часы, пытаясь понять, сколько же сейчас времени. Более того, когда стрелки на часах не сильно отличаются по размеру и расположены близко друг у другу (например, час — десять ночи), сложно понять, какая из стрелок — большая, а какая – маленькая: час – десять ночи может спросонья стать двумя – ноль_пятью). Светящиеся цифры же всегда однозначны. Размер цифр в моём случае выбран с большим запасом «по зрению» — их можно увидеть при любом «раскладе». Что же касается «необычности и внешней привлекательности» — согласен, это весьма субъективно. Но в мою пользу говорит тот факт, что во время разработки интерфейса от часов они некоторое время находились у меня «на работе», прямо на рабочем столе. И все, кто «проходил мимо», задавали одинаковые вопросы: «ОГО, ничего себе, какие огромные часы! Это у нас над проходной повесят? (НИДАЙБОХ©)» и «Ааа, так это ты для себя сделал? Домой? А я такие же хочу. Сколько стоит такое сделать?». За неделю было человек десять. Это даёт основания предполагать, что моё субъективное мнение хоть немного стало объективным :). С этим пунктом – всё.

Точность хода. Согласитесь, «немного неудобно», если вместо времени часы показывают среднюю температуру по больнице в Зимбабве (ну, образно говоря). И ни для кого не секрет, что для поделок есть модули часов, заявленная точность которых составляет 2 ppm (чуть больше минуты в год – Ваш К.О.). Эта цифра приемлема для наших целей.

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

Режимы яркости. Надеюсь, в их необходимости никто не сомневается. И правда, ночью яркость должна быть минимальной, чтобы с просонья не стать «яркой красной бесовщиной, светящей в глаза, боже_мой_где_это_я» и чтобы не получить неожиданный ночник. Я тестировал в темноте полную яркость этих часов – индикаторы освещают всю комнату, даже будучи «притонированными». Днём же полная яркость легко может использоваться.

«Подстраховочный» будильник. Основным для меня, как и для многих других, является будильник в телефоне. Но иногда случается такое, что будильник в телефоне приходится перенастраивать, потому что завтра – выходной, например. Снимаем в телефоне галку с дня недели – и вуаля. Правда, надо не забыть потом её снова поставить, чтобы в этот же день, но на следующей неделе, будильник все-таки сработал. Не забыть! :) Именно для этого и нужен «подстраховочный» будильник – настроить по рабочим дням недели, например, время срабатывания в 6 утра, а по выходным – либо часов на 9, либо вообще не настраивать. «Подстраховочным» будильник я называю также потому, что «пищит» он недолго – выключить его не получится, кнопок ведь нет (нечего раздражать людей по утрам долгим писком). И, следовательно, иногда его можно не услышать, если спать крепко. Безусловно, «удлинить» его можно, исходный код я предоставлю целиком. Но рассказать об этом было необходимо. Ну и последнее. Ввиду того, что будильник – это не основная функция, я предусмотрел по одному будильнику на каждый день недели. Поэтому настроить несколько будильников на один день заранее – не получится. Но место в EEPROM я всё же оставлю :)

Что нужно для сборки часов?

• Блок питания на 12 вольт (я взял на 5 Ампер – это с большим запасом);
• Контроллер Arduino (в моём случае это Pro Mini), на процессоре AtMega168 или AtMega328 – 1 шт;
• Драйверы TLC5940 – 2 шт;
• Индикаторы 4 дюйма с общим анодом – 4 шт;
• Модуль часов реального времени на микросхеме DS3231 с батарейкой – 1 шт;
• Отрезки проводов для соединения TLC-шек с индикаторами и модулей друг с другом – некоторое кол-во;
• Мелочевка из числа радиодеталей (многое опционально)(2 конденсатора по 47 мкФ, 2 конденсатора по 100 нФ, два резистора по 2,2 кОм (можно 2 кОм), 2 резистора по 10 кОм, резистор 100 Ом, «пищалка» от компьютера, модуль DC-DC, пин-хедеры угловые («мамы» и «папы»), пин-хедеры прямые («мамы» и «папы»), панельки для TLC-шек, разъём 5,5 мм для входа питания, клемма на плату KF301-2, наконечники НШВИ для проводов (на входе в KF301), винтики, латунные «стоечки», обжимки для Dupont-коннекторов, «рубашки» для Dupont-коннекторов);
• Модуль датчика освещенности с компаратором (опционально)– 1 шт;
• Модуль Bluetooth, распаянный на breakout board’е (опционально)(я использовал HC-05 с кнопкой) – 1 шт;
• Платы для монтажа всей этой «кухни»;
• Корпус (я заказывал кастомный в рекламном агентстве);
• Желание работать и руки, растущие из предусмотренного природой места.

Технические подробности.

Начнем с индикаторов. В моём проекте используются 4-дюймовые 7-сегментные индикаторы. Давайте рассмотрим фрагмент из datasheet на такие индикаторы.


Как видим, структурно каждый из сегментов (кроме «точки») состоит из 5 последовательно соединённых светодиодов. Для включения одного сегмента потребуется напряжение в 9 вольт. При недостаточном напряжении сегмент просто не «загорится». В идеале, каждый сегмент, в том числе и точка, «хочет» ток до 20мА. Но 9 вольт!.. Точка, где один светодиод, явно этому «не порадуется». Встает вопрос, при помощи чего управлять сегментами этого индикатора? Традиционная для таких случаев MAX7219 не подходит – при 5 вольтах не включится ни один сегмент. Только точки :) Ставить кучу ключей? А как же уставки тока? Ключи ведь не идеальны по параметрам – есть разбросы характеристик. Нам ведь не нужна разная яркость сегментов в рамках одного и того же индикатора. 74HC595? Это вообще не драйвер, это просто «несколько дополнительных ног» для контроллера, причём, можно сказать, без ШИМа. И опять же, понадобится куча ключей, разные напряжения для сегментов и «точек» и т.д. А напряжение для «точек» подобрать весьма непросто, поскольку вольт-амперная характеристика светодиода очень крутая: при 2,0 вольтах ток составляет 4 мА, а при 2,1 вольтах – уже 80 мА. Сколько же нужно для 20 мА? Любые флуктуации напряжения очень негативно скажутся на долговечности «точек». Использовать кучу точно подобранных резисторов? И это мы пока не рассматривали тот факт, что нужны 2 уровня яркости, а не 1.


Итак, плавно переходим к микросхеме драйвера. В общем, я нашел только один вариант решения вышеописанной проблемы – TLC5940. Да, та самая, из обзора про лестничный контроллер. Что она может? Давайте смотреть. Это 16-канальный токовый драйвер, с индивидуальной яркостью для каждого сегмента в 4096 шагов, способный «протащить» до 120 мА на канал (нам нужно до 20 мА), допускающий напряжение на выходе до 17 вольт (нам хватит и 9 вольт). И самое главное – позволяет образовывать так называемые daisy chain – последовательные цепочки из TLC5940. Давайте считать, сколько нам понадобится таких микросхем. Сколько у нас будет активных сегментов? В первой цифре – 6 (седьмой не нужен, поскольку кроме цифр 1 и 2 ничего отображать не требуется), во второй цифре, третьей и четвёртой – по 7. Плюс 2 точки (будем делать двоеточие). Итого 6 + 7 + 7 + 7 + 2 = 29. То есть, всего 2 микросхемы. И даже 3 запасных выхода останется :). Однозначно подходит для нашего случая. Хочу обратить внимание на то, что предлагаемый мною вариант – не единственно правильный, но он прекрасно работает. Уверен, существуют и другие достойные реализации.


Модуль часов реального времени. Думаю, ни для кого не секрет, что мы говорим о модуле с микросхемой DS3231. Точнее, «доработанный» модуль DS3231 – нужно избавиться от цепи зарядки батарейки, перерезав дорожку или удалить «оранжевенький» диод.
Модуль этот «легко мыть, легко хранить». Время «держит» точно и долго. А также позволяет генерировать прямоугольные ежесекундные импульсы, чем мы и будем активно пользоваться в проекте. Выход с этими импульсами будет подключён к одному из пинов прерываний Arduino, и по прерыванию будет мигать двоеточие. Это позволяет намного точнее отмерять секунду времени между миганиями, нежели при использовании механизма millis() внутри Arduino, а также сильно облегчить логику работы прошивки, позволяя сосредоточиться на более важных вещах и экономя процессорную «мощь».


Модуль Arduino. В данном случае я использовал клон Arduino Pro Mini – Baite BTE13-010. Почему именно этот модуль? Потому что дёшево, а также есть удобный боковой выход на COM порт. На борту у модуля находится процессор ATMEGA168, чего для наших целей гарантировано хватит.


Модуль Bluetooth. Почему именно Bluetooth? Потому, что для беспроводной передачи небольших порций данных он прекрасно подходит. Более того, он не зависит от интернет подключения. При небольшой цене, для моих целей он — прекрасный вариант. Я использовал модуль HC-05, уже распаянный на breakout-board’е. Перед использованием этот модуль нужно будет один раз настроить, хотя это не обязательно – будет работать и «из коробки». Зачем тогда настраивать? Затем, что, по умолчанию, имя модуля «в сети» будет HC-05. Если часов несколько, либо кроме часов есть другие устройства, которые используют такие же модули, будет непонятно, что из них что. Также без настройки модуля пароль от часов будет 1234, что легко угадывается, и при большом желании кто-то может подключиться к часам и слать команды как минимум через терминал (чисто теоретически). А если ещё и знать, чем управляешь, можно «наделать делов». Далее будем обсуждать протокол обмена данными с часами, и будет понятно, почему, например, «заслав» в часы просто букву «Т» без дальнейших параметров, можно «поломать» время на часах (ну, и «привет, будильники», если что). Про настройку модуля поговорим далее по тексту.


Как реализован будильник в проекте? При наступлении нужного дня недели, нужного часа и нужной минуты (и 00 секунд) генерируется признак «нужен будильник». Значение переменной «счётчик», заранее сброшенное в ноль, передаётся в процедуру «пищания». Процедура «пищания», в свою очередь, «смотрит», что за число ей «прислали». Если число чётное в диапазоне от 0 до 9, то включает «пищалку», если нечётное – выключает. Соответственно, будет 5 «пиков» длиной в секунду и периодом в секунду. Последняя цифра – девятка – выключает «пищание». Все остальные, получаемые процедурой, цифры от 10 по 59 – игнорируются. Ну а после 59 секунды уже наступает другая минута и признак «нужен будильник» сбрасывается, как сбрасывается и переменная «счётчик» (для будущего использования). Почему так мало «пиков»? Нужно помнить, что «заткнуть» его не получится, ибо кнопок на нём нет, да и висеть часы, вероятнее всего, будут где-то на стене. Следовательно, «пищать» будильник должен недолго – буквально 3…5 «пика» и всё, иначе есть риск «прилёта» тапочка (или, что хуже, чего-то потяжелее).

Модуль датчика освещенности. Зная любовь пользователей к датчику освещённости (судя по «лестничному» проекту), я решил заранее предусмотреть возможность его использования. Это лишь один из режимов работы подсветки – по датчику освещенности. Чтобы не «городить огород» с аналоговым датчиком, я решил использовать модуль со встроенным компаратором. Что даёт использование датчика освещённости с компаратором? Во-первых, сигнал с модуля будет цифровым («черное» или «белое», «ноль» или «один» — других вариантов нет). На модуле порог срабатывания устанавливается при помощи подстроечного резистора. Во-вторых, использование цифрового способа передачи позволяет (с большего) пренебречь длиной проводов до модуля в случае, если он должен быть удалён на некоторое расстояние от часов. Возвращаясь к другим режимам работы подсветки, нужно сказать, что, кроме как по датчику освещённости, есть 2 других режима: постоянная яркость и смена яркости по расписанию. Ни один из этих двух режимов не требует наличия датчика освещённости. Подробнее об этих режимах – позже.


Возможно, имеет смысл «в трёх словах» упомянуть про платы, которые я использовал в этом проекте. Поскольку я заказываю изготовление плат «на стороне» вместо самостоятельного изготовления, могу сказать, что это не очень дёшево. Приемлемо, но не дёшево. И коль скоро платы приходят по десятку одинаковых, было бы расточительно изготавливать уникальные платы лишь для одного конкретного проекта. Значит, платы нужно делать более универсальными. То, что вы увидите, и есть пример попытки сделать плату более универсальной.
Сначала взглянем на плату (интересующие нас части):


Теперь описание словами. Плата позволяет опционально использовать либо Arduino Pro Mini, либо Nano – в зависимости от того, нужен ли в данный момент «набортный» USB-RS232, или нужна очень дешёвая цена в ущерб наличию USB. Предусмотрены опциональные «подтяжки» с использованием резисторных матриц – к «плюсам» и «минусам». Предусмотрено место под DC-DC модуль. Предусмотрено использование I2C с рядом расположенным выводом для прерываний. Предусмотрено использование «набортного» реле с выводом его контактов на клеммы, с местом под ключевой транзистор для реле и местом для светодиода индикации работы реле. Также предусмотрена возможность вместо реле использовать мощный полевой транзистор-ключ, в связи с чем рядом с посадочными местами под клеммы есть «источник земли» для полевого транзистора. Предусмотрено подключение датчиков температуры. Ну и, разумеется, мало какой проект обходится без кнопок – это тоже предусмотрено. Панацея ли это от всех бед? Безусловно, нет. Однако для каждого нового проекта большинство требуемого функционала на плате предусмотрено – берем плату и паяем те компоненты, что нужны в данном случае. Мне – удобно.

Вторая часть платы – это breakout board для «проходного» подключения драйверов TLC5940. Назначение этой платы однозначно – без вариантов.

Итак, технические подробности рассмотрены. Пора двигаться дальше.

Аппаратная часть часов – схема и комментарии.

Давайте посмотрим на общую схему подключения всех устройств «в кучу».


Что имеет смысл прокомментировать? В первую очередь, ситуацию с питанием модуля Bluetooth. Дело в том, что сам модуль питается напряжением 3,3 вольта, и уровни сигналов RX и TX также подразумеваются в 3,3 вольта. А мы подключаем к питанию 5 вольт, равно как уровень сигналов RX и TX также 5 вольт. Как так получилось? Нюанс в том, что, как я уже и упоминал, мы используем не «голый» модуль, а припаянный к breakout-борду, который на борту имеет необходимый преобразователь уровней из 5 вольт в 3,3 и обратно. Это важно, поскольку подключение «голого» модуля к Arduino может закончиться «пичалькой».

Далее, подключение модуля часов реального времени. Кроме стандартных для данного случая SDA и SCL, мы используем выход SQW для получения ежесекундных импульсов на вход прерывания Arduino. Для чего это сделано – я уже писал.

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


«Пищалка» будильника. Я использовал для этой цели «пищалку» PC-спикера из компьютера. Их есть у меня :). Единственная доработка сводится к припаиванию в разрыв одного из проводов, идущих к «пищалке», резистора на 100 Ом. Место доработки я «упаковал» в термоусадочную трубку.

Драйверы TLC5940. К сожалению, без «граблей» не обошлось. Как оказалось, в «интернете кто-то неправ» ©. Суть в том, что если сделать всё так, как пишут «в этих ваших интернетах», то в результате получим на индикаторах цифры, в которых все сегменты светятся с разной (!) яркостью. Зрелище отвратительное. Глядя на типовую схему включения драйвера в quick-guide’ах в интернете, можно заметить, кроме всего прочего, что вывод DCPRG подключён к шине Vcc, в то время как VPRG подключён к GND. Когда печатная плата уже готова, узнавать о проблеме с неравномерностью яркости «очень неудобно», мягко говоря. Что ж, проблема есть, почему так получилось? Отворачиваемся от quick-guide’ов и читаем кусок datasheet’а:

DCPRG: Switch DC data input. When DCPRG = L, DC is connected to EEPROM. When DCPRG = H, DC is connected to the DC register. DCPRG also controls EEPROM writing, when VPRG = V (PRG). EEPROM data = 3Fh (default).

Теперь вольный краткий перевод для тех, кто «не дружит» с английским: когда DCPRG = LOW, DC (Dot Correction, точечная коррекция, нужна в первую очередь для RGB светодиодов, чтобы сбалансировать яркость каждого из цветов друг относительно друга) соединена с EEPROM. В этом EEPROM хранится значение 3F(hex) по умолчанию. А вот когда DCPRG = HIGH, DC соединена с регистром DC. Пока вроде всё понятно, читаем дальше:

VPRG: Multifunction input pin. When VPRG = GND, the device is in GS mode. When VPRG = Vcc, the device is in DC mode. When VPRG = V(vprg), DC register data can programmed into DC EEPROM with DCPRG=HIGH. EEPROM data = 3Fh (default).

Теперь, опять же, вольный краткий перевод: когда VPRG = GND, драйвер находится в GS (GrayScale, монохромном) режиме. Когда VPRG = Vcc, драйвер находится в DC режиме.

Что всё это значит в нашем случае? Следуя схемам из интернета, получаем DCPRG = HIGH при VPRG = GND, что значит, яркость не берётся из EEPROM, а «хочет» данных из регистра DC, запись значений яркости в который «предусмотрительно» запрещена настройками VPRG. К слову, регистр на момент старта заполнен чуть ли не рандомными данными, и его использование предполагает обязательное предварительное заполнение своими, нужными данными. И да, при каждом «передёргивании» питания драйвера данные из регистра теряются, следовательно, записать в регистр свои данные на другой плате с последующим «передонориванием» в основную плату – не вариант. Ну разве не прелесть?

Какие есть выходы из сложившегося «трэша»? Их два: либо DCPRG «скинуть» на GND (предпочтительно), либо VPRG «поднять» на Vcc. Как показала практика, вариант с VPRG, являясь программно чуть более трудоёмким, по непонятной причине к желаемому результату не привёл (китайские микросхемы?). Следовательно, выбираем вариант с DCPRG = GND (брать данные из EEPROM) – этот вариант работает прекрасно.

Небольшое отступление от темы. Почему же я только сейчас столкнулся с проблемами TLC, когда я уже «выпустил» обзор про лестничный контроллер ещё год назад? Потому, что в том проекте TLC’шки использовались не как токовый драйвер, а как источники «земли», причём подтянутые резисторами к линии питания. Поэтому негативный эффект не проявлялся.

Итак, самое важное – одной строкой: DCPRG должен быть на GND, а не на Vcc!

Также стоит обратить внимание на резистор уставки тока для сегментов. Рекомендуется использовать резистор на 2 кОм для уставки тока в 20 мА на каждый сегмент. Однако я решил «поберечь» сегменты и использовать резистор 2,2 кОм, что соответствует уставке около 17 мА на сегмент. Какой вариант использовать вам – решайте самостоятельно: оба варианта безопасны.

Ну и, наконец, индикаторы. Исходя из использования TLC5940, индикаторы должны иметь общий «плюс» (общий анод, Common Anode), потому что «минусами» их «обеспечат» микросхемы TLC5940. Обратите внимание, что третий индикатор подключен «вверх ногами» — это сделано ради получения двоеточия (по одной точке от двух смежных индикаторов)

На этом комментарии к схеме заканчиваем.

Программная часть – скетч и комментарии.

Итак, скетч. К моему глубочайшему сожалению, код скетча не влез в тело обзора:

Поэтому, только ссылка на скачивание.

Скачать ino-файл скетча.

Теперь комментарии. Как видите, в этот раз я пошёл ещё дальше, и попытался собрать много вариантов исполнения кода в один, универсальный. В зависимости от настроек в заголовке будет компилироваться разный код – разный по размеру, использованию памяти и функционалу. Это – условное компилирование, когда каждый пользователь при помощи настроек собирает код под своё «железо». Зачем я так сделал? Мой проект с контроллером лестницы показал, что даже тот функционал, что не нужен лично мне, нужен кому-то другому. Если не плодить разные варианты кода, то в случае необходимости обновления кода можно сделать это один раз для всех «комплектаций». Безусловно, коль скоро я выкладываю все исходники, каждый может поменять код «под себя». Но как показала практика, не все люди хотят вникать в суть кода, а повторить проект хочется. Более того, у каждого человека свои предпочтения – «хотелки» другими словами. Ну что ж, кто, как не автор кода, лучше всего знает, как этот самый код работает? Кому легче всего адаптировать код под конкретные нужды? В этот раз я решил угодить чуть большему количеству читателей и предусмотреть «опции» прямо «с завода».

Итак, давайте поподробнее рассмотрим те самые «настройки» кода.

#define beeperPin 6. Теоретически, можно использовать любой другой пин, но обязательно поддерживающий ШИМ: это D3, D5, D6, D9, D10, D11. Но D3, D9, D10 и D11 заняты TLC-шкой, следовательно, остаётся либо D5, либо D6 – можно использовать любой из этих двух оставшихся.

#define autoBrightnessMode 2. Как следует из названия, это режимАвтоПодсветки. Возможен один из трёх режимов.
При режиме 0 яркость не меняется вообще. Единственной текущей яркостью становится максимальная яркость. Такой режим позволяет полностью отказаться от использования датчика освещения. Если используется удалённый интерфейс, это значение можно будет изменить дистанционно.
При режиме 1 яркость меняется в соответствии с расписанием. То есть на ночь, в указанное время, например, в 10 вечера, яркость переходит в минимальный режим, а утром, например, в 6 утра, возвращается в максимальный режим. Причём расписание яркостей предусмотрено для каждого дня недели независимо. Такой режим позволяет полностью отказаться от использования датчика освещения. Расписание устанавливается 1 раз, на этапе компиляции и прошивки (подробнее – чуть ниже). Дистанционно расписание сменить нельзя. Если используется удалённый интерфейс, то дистанционно можно изменить лишь значения максимальной и минимальной яркостей.
При режиме 2 яркость меняется не чаще 1 раза в секунду автоматически, в соответствии с показаниями датчика освещенности. В этом режиме его использование обязательно. Настроить порог срабатывания датчика можно аппаратно на плате самого датчика – прошивка в этом не участвует. Если используется удалённый интерфейс, значение максимальной и минимальной яркостей можно будет поменять дистанционно.

#define autoBrightnessPin 4. Пин, используемый для получения данных от датчика освещенности. Вместо пина 4 можно использовать любой незанятый пин из числа поддерживающих приём цифровых данных. Теоретически это пины D2…D13 и A0…A5, но многие из них уже заняты. Поскольку используется модуль датчика с компаратором, данные от датчика поступают в цифровом виде, следовательно, пин может быть любым, не обязательно аналоговым. Разумеется, настройка имеет смысл только при использовании режима автоподсветки 2 – с использованием датчика освещенности. Для других режимов настройка игнорируется.

#define minStaticBrightness 150. Экспериментально подобранное значение минимальной яркости. Является постоянным значением, если не используется удалённый интерфейс. При использовании удалённого интерфейса является лишь стартовым значением, которое, тем не менее, будет проигнорировано (заменено на данные из EEPROM) далее по коду. Как правило, в «свежих» модулях Arduino там находится дефолтное значение FFh (255), в связи с чем обязательно потребуется установить новое значение минимальной яркости при помощи удалённого интерфейса.

#define maxStaticBrightness 4095. Экспериментально подобранное значение максимальной яркости. Является постоянным значением, если не используется удалённый интерфейс. При использовании удалённого интерфейса является лишь стартовым значением, которое будет, тем не менее, будет проигнорировано (заменено на данные из EEPROM) далее по коду. В связи с этим обязательно потребуется установить новое значение максимальной яркости при помощи удалённого интерфейса.

#define testModeOnStart false. Эта настройка называется тестовыйРежимПриСтарте. Она имеет 2 значения: true или false. Если установить значение true, то при каждой подаче питания в часы (точнее, инициализации Arduino) будут включены все используемые сегменты каждого индикатора. Включёнными они продолжат оставаться 20 секунд, после чего часы перейдут в нормальный режим работы. Нужно это для того, чтобы на этапе сборки часов при пробных включениях убедиться, что все нужные сегменты в индикаторах подключены и светятся с одинаковой яркостью. Задержка в 20 секунд позволит произвести необходимые корректировки в случае необходимости. Если времени на корректировки окажется мало, можно нажать кнопку «reset» на Arduino, что даст следующие 20 секунд при старте часов. Значение false запрещает использование тестового режима, то есть часы при включении сразу переходят в нормальный режим, минуя включение всех сегментов и задержку в таком состоянии.

#define fastBlink false. Настройка быстрыеМигания (двоеточия). Имеет 2 значения: true или false. Прерывания, генерируемые модулем часов реального времени, можно рассматривать методом «изменение» или «падение». Модуль полсекунды «показывает» высокий уровень на своём выходе, затем полсекунды «показывает» низкий уровень. Следовательно, используя метод «изменение», двоеточие будет полсекунды светиться, полсекунды – нет. Это и есть «быстрые мигания». Если же использовать метод «падение», то он происходит 1 раз в секунду, следовательно, двоеточие будет 1 секунду светиться, одну – нет, то есть, вдвое медленнее. Это – «медленные мигания». Значение true для быстрогоМигания – это и есть «быстрые мигания». Значение false применяет «медленные мигания».

#define enableRemoteUI true. Настройка разрешитьУдалённыйПользовательскийИнтерфейс. Имеет 2 значения: true и false. При значении true разрешается использование удалённого интерфейса. При false – запрещается. Хочу обратить внимание, что использование часов вообще без удалённого интерфейса вполне себе возможно. Пример отсутствия удалённого интерфейса: будильники выставляются по дням недели «навсегда» (точнее, до следующей перепрошивки), значения яркостей подбираются и выставляются «навсегда», регулировка режимов яркости возможна в любом из трёх вариантов. Синхронизацию времени периодически проводить «вручную»: точность модуля часов позволяет не «заморачиваться» этим чаще одного-двух раз в год.

Также важно настроить карту подключения сегментов к модулям TLC5940. Поскольку этот драйвер не имеет явного назначения в качестве драйвера семисегментных индикаторов, а всё, что он может – это управлять отдельными светодиодами. Следовательно, все заботы по комбинированию отдельных сегментов в полноценный модуль-индикатор ложатся на программную часть. Чем нужно руководствоваться при подключении конкретных сегментов к какому-то конкретному выводу модулей TLC? Я руководствовался удобством подключения и минимизацией «ктулху» проводов – главное потом правильно составить карту соответствий. Давайте посмотрим, какова нумерация выводов модулей TLC согласно «логике» Arduino:

Теперь давайте посмотрим, что такое сегмент «А», сегмент «B» и так далее на индикаторах:

И вот теперь можно говорить про карту подключений (таблицу соответствий конкретных сегментов конкретным выводам модулей TLC). Вот кусок кода:

#define seg1A 22    // сегмент А индикатора 1 подключён к выводу TLC5940 #22
#define seg1B 23    // сегмент B индикатора 1 подключён к выводу TLC5940 #23
#define seg1C 20    // сегмент C индикатора 1 подключён к выводу TLC5940 #20
#define seg1D 19    // сегмент D индикатора 1 подключён к выводу TLC5940 #19
#define seg1E 18    // сегмент E индикатора 1 подключён к выводу TLC5940 #18
                    // сегмент F мы не используем (он не нужен)
#define seg1G 21    // сегмент G индикатора 1 подключён к выводу TLC5940 #21

#define seg2A 30    // сегмент А индикатора 2 подключён к выводу TLC5940 #30
#define seg2B 31    // сегмент B индикатора 2 подключён к выводу TLC5940 #31
#define seg2C 26    // сегмент C индикатора 2 подключён к выводу TLC5940 #26
#define seg2D 25    // сегмент D индикатора 2 подключён к выводу TLC5940 #25
#define seg2E 24    // сегмент E индикатора 2 подключён к выводу TLC5940 #24
#define seg2F 29    // сегмент F индикатора 2 подключён к выводу TLC5940 #29
#define seg2G 28    // сегмент G индикатора 2 подключён к выводу TLC5940 #28
#define seg2DP 27   // "точка"  индикатора 2 подключёна к выводу TLC5940 #27

#define seg3A 7     // (ВИРТУАЛЬНЫЙ!) сегмент А индикатора 3 подключён к выводу TLC5940 #7
#define seg3B 8     // (ВИРТУАЛЬНЫЙ!) сегмент B индикатора 3 подключён к выводу TLC5940 #8
#define seg3C 3     // (ВИРТУАЛЬНЫЙ!) сегмент C индикатора 3 подключён к выводу TLC5940 #3
#define seg3D 2     // (ВИРТУАЛЬНЫЙ!) сегмент D индикатора 3 подключён к выводу TLC5940 #2
#define seg3E 1     // (ВИРТУАЛЬНЫЙ!) сегмент E индикатора 3 подключён к выводу TLC5940 #1
#define seg3F 6     // (ВИРТУАЛЬНЫЙ!) сегмент F индикатора 3 подключён к выводу TLC5940 #6
#define seg3G 4     //  сегмент G индикатора 3 подключён к выводу TLC5940 #4
#define seg3DP 5    //  "точка"  индикатора 3 подключёна к выводу TLC5940 #5

#define seg4A 14    // сегмент А индикатора 4 подключён к выводу TLC5940 #14
#define seg4B 15    // сегмент B индикатора 4 подключён к выводу TLC5940 #15
#define seg4C 11    // сегмент C индикатора 4 подключён к выводу TLC5940 #11
#define seg4D 10    // сегмент D индикатора 4 подключён к выводу TLC5940 #10
#define seg4E 9     // сегмент E индикатора 4 подключён к выводу TLC5940 #9
#define seg4F 13    // сегмент F индикатора 4 подключён к выводу TLC5940 #13
#define seg4G 12    // сегмент G индикатора 4 подключён к выводу TLC5940 #12

Надеюсь, здесь всё понятно. Отдельного уточнения требует выражение «виртуальный сегмент». Дело в том, что третий индикатор мы монтируем «вверх ногами» — всё ради получения двоеточия для «мигания секунд». Следовательно, то, что было реальным сегментом «А», станет виртуальным сегментом «D», то, что было реальным сегментом «B», станет виртуальным сегментом «E» и так далее. Реальными остаются лишь «точка»(она всего одна) и сегмент «G» (как не переверни – он всё равно по центру). Настройки в скетче указаны для моего варианта подключения, у вас, вероятнее всего, всё будет иначе. Очевидно, что настройка обязательна – без неё на индикаторах, вместо цифр, будет «какая-то бесовщина».

Теперь более «тонкие» настройки, которые можно менять.

brightnessType brightnessScheduler[7] = { {7,21}, {7,15}, {7,21}, {7,21}, {7,21}, {9,22}, {9,22} }. Это массив, состоящий из 7 дней недели, начиная с понедельника. Первое число в каждом дне – час, в котором нужно переключать яркость из «ночной» в «дневную». Второе число в каждом дне – час, в котором нужно переключать яркость из «дневной» в «ночную». Стартово здесь установлено включение «дневной» подсветки в 7 утра по рабочим дням, в 9 утра – по выходным; включение пониженной, «ночной» подсветки установлено на 9 вечера по рабочим дням, в 10 вечера – по выходным. Любые значения можно менять «под себя». Настройка имеет смысл только при настройке autoBrightnessMode = 1 из заголовка.

byte alarmScheduler[21] = {106,100,90, 106,100,90, 106,100,90, 106,100,90, 106,100,90, 109,100,90, 109,100,90}. Всё аналогично предыдущей настройке, но этот массив содержит расписание будильников. Он состоит из 7 дней недели, начиная с понедельника. Каждый день недели – это группа из 3 цифр последовательно. Первая цифра – час срабатывания будильника, увеличенная на число 100. То есть число 106 = 6 часов. Вторая цифра – минута срабатывания будильника, увеличенная на 100. То есть число 100 = 00 минут. Третья цифра – разрешен будильник или нет, где 90 – не разрешен, а 100 – разрешен. Зачем нужно было увеличивать всё на 100? В связи с тем, что данные будут передаваться по COM-порту, а некоторые символы из первой тридцатки являются управляющими, что может принести потенциальные проблемы при передаче. Сместив диапазон цифр на 100 правее, я подстраховался – так всё работает чётко. Хочу обратить внимание, что эти «плюс 100» имеют отношение только к прошивке. При использовании приложения (удалённого интерфейса) будут использованы привычные, нормальные числа, без всяких «плюс 100». Все необходимые прибавления-убавления будут происходить в автоматическом режиме, прозрачно для пользователя.

Для правильной работы нескольких последовательно соединённых драйверов TLC5940 необходимы «махинации» с одним файлом. Не переживайте, «изготовитель» библиотеки это предусмотрел и ничего нестандартного делать не придётся. Что и где менять? В папке с установленной библиотекой TLC5940 ищем файл tlc_config.h. В этом файле есть строчка #define NUM_TLCS 1. Меняем её на #define NUM_TLCS 2, поскольку у нас 2 микросхемы TLC, соединенные последовательно. После изменения сохраняем файл. На этом «махинации» можно считать законченными.

На этом с настройками – всё. Остальной код имеет смысл менять только в том случае, если вы чётко представляете, что делаете. Благо, код я старался по возможности максимально комментировать – проблем возникнуть не должно.

Теперь пару слов о библиотеках, необходимых для компиляции кода.

DS3231. Взято с https://github.com/jarzebski/Arduino-DS3231
TLC5940. Взято с https://github.com/PaulStoffregen/Tlc5940

Насколько я знаю, две остальные библиотеки – Wire и EEPROM – являются стандартными для Arduino и выискивать их отдельно нет нужды – они идут в комплекте со средой программирования.

Предчувствуя, что кто-то всё равно не сможет установить библиотеки с GitHub, я подготовил два zip-файла с библиотеками (с уже настроенным файлом tlc_config.h). Для их установки скачиваем один zip-файл, затем второй. Запоминаем, куда их сохранили, запускаем среду Arduino, выбираем (Меню) – Скетч – Подключить библиотеку – Добавить ZIP библиотеку – указываем на один из скачанных файлов. Повторяем процедуру со вторым скачанным файлом. По завершении – обязательно перезагружаем среду программирования Arduino.

Итак, со схемой подключения разобрались, с программной частью (часов) разобрались. Что ещё нужно знать при сборке часов? Правильно, нужно подключить модуль Bluetooth и, наконец, настроить соединение часов с компьютером. Говоря о Bluetooth, нужно говорить о двух «сторонах медали»: настройки «со стороны» часов и настройки «со стороны» компьютера.

Начнём с настройки со «стороны» часов. Ранее я обещал остановиться на этом подробнее. Для быстрой и удобной настройки модуля нужны следующие компоненты из «закромов оф родина»:

• Адаптер USB-RS232;
• Провод на 4 жилы для соединения USB-RS232 с модулем Bluetooth.

Также нужна программа-терминал. Поскольку после Windows XP Microsoft предусмотрительно «выпилила» терминал из комплекта стандартных программ, будем использовать стороннюю бесплатную программу Tera Term. Скачивается она здесь.

Подключаем «голый» модуль USB-RS232 к компьютеру. В моём случае это был «феншуйный» FTDI, поэтому драйвера установились сами. У вас может быть не FTDI, например, а широко распространённый CH340 – для него нужны соответствующие драйвера. Так или иначе, нужно, чтобы драйвера установились. После этого станет известно, какому COM-порту соответствует модуль USB-RS232. В моём случае он стал COM13. Далее, соединим модули USB-RS232 (отключённый от компьютера) и Bluetooth.

RX к TX, TX к RX, VCC к VCC, GND к GND. На моём модуле USB-RS232 был выбор: 3,3 вольта или 5 вольт. Я использовал 5 вольт, а не 3,3 – всё прекрасно. Модуль, как мы помним, будучи припаянным к breakout-board’у, нейтрален к 5 вольтам. Далее, внимание, сначала нажимаем кнопку на модуле Bluetooth, и, удерживая кнопку, второй рукой подключаем нашу конструкцию к кабелю MiniUSB. Знаю, очень неудобно. После того, как светодиоды загорелись, отпускаем кнопку. Это позволило нам подключить модуль Bluetooth в режиме AT-команд. Насколько я понимаю, это «ограниченный» режим AT-команд. Чтобы получить «полный» режим, нужно… да кто его знает, что там нужно. Нам хватит и «ограниченного».

Далее, устанавливаем скачанную программу и запускаем её. Выбираем назначенный нашему модулю USB-RS232 COM-порт (в моём случае, напоминаю, это COM13).

Далее, выбираем Setup – Serial port.

Меняем скорость на 38400 (в AT режиме стандартные 9600 «не прокатят»), затем нажимаем ОК.

Далее, Выбираем Setup – Terminal.

Здесь Transmit меняем на «CR+LF», и ставим галку «Local echo», чтобы видеть, что за команды мы собираемся слать в модуль Bluetooth.

Приготовления завершены. Теперь можем слать AT-команды. Проверяем, отправив пробное «AT»

Получаем любезное «ОК». Далее, убеждаемся, что модуль – HC-05. Отправляем AT+VERSION

Получаем в ответ «VERSION:2.0-20100601». Оно :). Далее, меняем имя модуля в «сети», отправив AT+NAME=CLOCK1

В ответ снова «ОК». Обращаю внимание, что вместо CLOCK1 вы вправе написать что-то своё (желательно, цензурное). Теперь меняем пароль, например, на 6461, как в моём случае, отравив AT+PSWD=6461 (разумеется, вместо 6461 вы вольны выбрать свой пароль)

Получаем «ОК». Всё, настройка завершена. Можно закрывать программу. Снимаем нашу конструкцию с MiniUSB кабеля и снова подключаем к нему же, но уже без нажатой кнопки. В этот раз светодиод на модуле Bluetooth мигает намного чаще – это значит, что мы уже не в AT режиме. Берём в руки телефон и проверяем, находится ли модуль Bluetooth телефоном:

Ещё как находится! Всё, с настройкой Bluetooth на «стороне» часов покончили. Настроенный модуль можно подключать к часам: RX к TX, TX к RX, VCC к VCC, GND к GND – всё, как и в предыдущий раз.

Теперь нужно настроить Bluetooth на «стороне» компьютера. Здесь все сложнее и проще одновременно. Проще потому, что нужно найти наш «CLOCK1», создать пару, введя пароль (вы «сто раз так делали»), и узнать номер соответствующего Bluetooth-соединению порта. А сложнее… Если на Bluetooth модуль установлены только стандартные драйвера Microsoft, и даже назначен соответствующий Bluetooth соединению COM-порт, то работать если и будет, то 1 раз через 100. Сюрприз :) Тут просто необходимо рассказать вам «удивительную историю» про Макрософт: без этого – никак. Да простят меня представители Майкрософт, если таковые имеются из числа читателей. Итак, как я понимаю, M$ никогда не верила в перспективы Bluetooth и считала, что его судьба повторит историю с IrDA, ныне скорее мёртвому, чем живому. Следовательно, M$ не посчитала нужным выпустить для своей же операционки реализацию стека протоколов Bluetooth. Точнее, выпустила, но лишь частично, ужасно корявую, и только под «закат» Windows XP. Что-то более или менее «человеческое» появилось только в Windows Vista / Windows 7, потому что внезапно оказалось, что Bluetooth умирать не собирается. Но без «ложки дёгтя» не обошлось: M$ посчитала, что Bluetooth – это лишь часть их мировоззрения под названием Windows Sockets. И для работы с Bluetooth по факту нет адекватной реализации протокола RFCOMM – как раз той части, которая отвечает за работу в качестве COM-порта. Но сам COM-порт пускай в Диспетчере устройств «повисит» :). В общем, простите, но это – рукалицо. Что делать? К счастью, есть такая хорошая и ответственная фирма, как Toshiba: она явила миру свой стек протоколов для Windows, являющемуся, к слову, одной из самых полных реализаций стека. К «граблям» можно отнести тот факт, что стек Toshiba работает (вроде бы) не с любым USB-Bluetooth адаптером. Например, мой встроенный DELL Truemobile 355 bluetooth стал тем, что «не смог». Я покопался в «закромах оф родина» и нашел рядом с глиняными табличками доисторический USB Bluetooth адаптер Surecom года так 2003-его. Он смог :) У наших китайских друзей есть куча адаптеров занедорого, которые легко станут для вас «тошибой». Пример (читайте комментарии купивших). Это только для примера, на самом деле, имея дело с таким маленьким USB Bluetooth адаптером, я уверен, будут проблемы с максимальным радиусом действия. Но, о чём это мы? Итак, установив всю эту «кухню» от Toshiba, стало возможно радоваться жизни.

Так выглядит соединение с часами:

Двойной клик – «насильное» подключение. Картинка становится такой:

Взглянем на подробности соединения:

Как видим, наше соединение с CLOCK1 является COM-портом номер 3. Обращаю внимание, что, в отличие от режима AT-команд, где скорость мы устанавливали в 38400, здесь скорость будет иметь «стандартное» значение 9600. Собственно, это было понятно из установки скорости обмена в скетче Arduino, но, на всякий случай, я решил это ещё раз уточнить.

Итак, про изготовление самих часов — всё. Давайте посмотрим, как же выглядит девайс в реальной жизни.





Часы при минимальной яркости:

И при максимальной:

Итак, железо собрали, прошивку «залили», Bluetooth подключили, соединение настроили. Чего-то не хватает? Да.

Программа для Windows.

Программа (приложение) написана в старой-доброй Delphi. И даже работает :). Я выпустил 2 версии программы: на английском языке и на русском (для тех, у кого проблемы с английским). Есть 2 пути получения приложения: самостоятельно скопировать исполняемый файл (с нужным языком интерфейса) из архива (md5=603b12b1b24b3aba05c8d47ae8e11fe8) в нужное вам место, либо воспользоваться инсталлятором (md5=ebbadd3ceba39e95199a2a34a13b712e). Отличие архива от инсталлятора заключается в том, что инсталлятор способен в случае необходимости установить шрифт Segoe UI, являющийся стандартным для Windows 7, но отсутствующий на компьютере с Windows XP. Уверен, что Windows XP давно уже покинула ваши компьютеры, но всё же я решил предусмотреть даже невозможное. Обращаю внимание, что приложение при первом запуске создаст у себя в папке ini-файл с настройками (хранит номер последнего использовавшегося COM-порта). Поэтому для того, чтобы файл мог беспрепятственно создаваться в той же папке, что и приложение, должна быть разрешена запись в эту папку. Следовательно, если приложение будет установлено в папку Program Files и будет запускаться без прав администратора, запись в эту папку будет запрещена. Вместо этого файл будет создан в папке VirtualStore. Просто для сведения. Не собираюсь делать какие-либо секреты относительно приложения, так как это важно.
Приложение выполняет только возложенную на него задачу и ничего другого. Другими словами, ничего лишнего я в приложение не встраивал. Подозрительные и осторожные люди вправе не верить мне на слово и создать правило в Брандмауэре Windows или другом файрволе на свой вкус для этого приложения – их право. Альтернативно, можно создать своё приложение – протокол для обмена данными я выкладываю (хотя, при желании, его можно узнать из скетча – я предоставил все исходники). Возможно, кто-то из читателей сможет «запилить» аналог приложения, но для Android, и поделиться им — было бы прекрасно. Но, вернёмся к тому, что есть. После запуска приложения появится окно следующего вида:

Что нужно сделать в первую очередь? Правильно, выбрать COM-порт.

В моём случае он уже выбран, отображается его номер и скорость. Как узнать, тот ли это порт? Нажать кнопку «Test connection». Если порт – правильный, вы получите соответствующее сообщение. Если нет – тоже. Но другое :). Ну что ж, давайте прочитаем, какие будильники у меня установлены. Жмём «Load from clock» в разделе будильников и получаем такую картинку:

Как видим, у меня активны 5 будильников – те, что по рабочим дням. И время срабатывания каждого из них – 6:15 утра. Также видим 2 будильника на выходных – в 9:00 утра, но они неактивны: нечего будить людей в выходные. Изменить «активность» можно кликом по изображению будильника: красный – значит активный, серый – неактивный. После перенастройки будильников новые данные следует отправить в часы при помощи кнопки Save to clock.

Давайте теперь попробуем выставить время на часах. Перед этим имеет прямой смысл синхронизировать часы на компьютере с одним из серверов NTP – например, time.nist.gov. Это можно сделать стандартными средствами Windows. После того, как время на компьютере стало точным, можем «слать» его в часы. Для этого нажимаем кнопку Sync now. Время будет тотчас же отправлено в часы, а приложение будет отображать статус «Done». Быстро и просто. Бонусный функционал из недавнего обзора про синхронизацию времени с компьютером :) Уверен, что точности синхронизации для бытовых нужд (в подавляющем большинстве случаев) хватит с большим запасом. Выглядит так:

Поехали дальше. Попробуем получить текущие настройки яркостей из часов. Для этого нажимаем кнопку Load from clock в разделе управления яркостью.

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

На этом с функциями приложения — всё. Что ещё можно сказать про него? Разрабатывая интерфейс приложения, я старался оптимизировать его для управления мышкой, чтобы не пришлось тянуться к клавиатуре. Надеюсь, получилось удобно. Ну и, наконец, видео работы «в бою». Надеюсь, это ответит на оставшиеся вопросы.



Пора «сворачиваться» :) Я почти закончил. Вот обещанный протокол обмена данными с часами на случай, если кто-то захочет написать своё приложение для «общения» с часами. Итак, обменяться с часами можно следующими данными:

Sxxxxxxxxxxxxxxxxxxxxx (большая английская S и следом 21 байт данных). S говорит о том, что компьютер хочет передать в часы 21 байт данных Scheduler’а – «планировщика будильников». 21 байт данных – это 7 дней недели, начиная с понедельника, (по 3 байта на каждый день) в формате ЧАС_БУДИЛЬНИКА+100, МИНУТЫ_БУДИЛЬНИКА+100, АКТИВНОСТЬ_БУДИЛЬНИКА (90 = не активно, 100 = активно). И так все 7 дней недели. В ответ часы ничего не шлют.

s (маленькая английская) без дополнительных данных. Компьютер запрашивает у часов текущие действующие данные шедулера будильников. В ответ часы шлют 23 байта данных: «стартовый» байт (!), затем 21 байт данных в формате, аналогичном описанию на 1 пункт выше, затем «стоповый» байт (#).

Bxxxx (большая английская и 4 байта данных). B (Brightness) говорит о том, что компьютер шлёт в часы 4 байта (две двухбайтных переменных, MSB) – значение минимальной яркости (цифра от 0 до 4095), затем значение максимальной яркости (цифра от 0 до 4095). В ответ часы ничего не шлют.

b (маленькая английская). Компьютер запрашивает у часов текущие значения яркости. В ответ приходит 6 байт: «стартовый» байт (!), затем двухбайтная переменная минимальной яркости (MSB), затем двухбайтная переменная минимальной яркости (MSB), затем «стоповый» байт (#).

R (английская большая). R (Request) говорит о том, что это тестовый запрос, для проверки, «свой» ли это порт. В ответ приходит 4 байта: !OK# (O и K – английские большие, а ! и # — «стартовый» и «стоповый» байты соответственно).

Txxxx (английская большая и 4 байта данных). T (Time) говорит о том, что компьютер хочет передать 4-байтную переменную (MSB), содержащую текущее время в формате UNIX. В ответ часы ничего не шлют.

Теперь, выложив протокол обмена данными, хочу вернуться к разговору о том, что можно «поломать» время в часах, послав, например, через терминал на смартфоне букву T. Часы воспринимают это как команду установить время, но поскольку следующих предполагаемых 4 байт часы не дожидаются и выходят по таймауту, устанавливается «левое» время. Ставьте пароль на часы!

Ну, вот вроде и всё. Пора определиться с достоинствами и недостатками и, наконец, подвести черту.

«Плюсы» и «минусы», как я их вижу.

В плюсы запишу вот что:

• Часы получились симпатичными по дизайну;
• Они яркие и большие – можно смотреть на время ночью и без очков;
• Не нужно корректировать время в течение длительного периода;
• Есть будильники для подстраховки.

В минус запишу вот что:

• Требуется внешний блок питания – никаких батареек не хватит!

Остальные минусы, я уверен, помогут сформулировать читатели :)

---

Итого.

Я добился поставленных целей. Более того, я получил ценный опыт работы с Bluetooth и COM-портами в частности, узнал кое-что новое о драйверах TLC5940, утолил «жажду» проектирования новых устройств (возможно даже сдал «лайтовый» диплом), а также сделал выводы о ценообразовании рекламных агентств при производстве кастомных корпусов. Пользоваться часами мне – удобно. Насколько обзор получился полезным для других – покажет время и комментарии.

Проект — свободный, некоммерческий. Каждый вправе использовать данные из обзора в любых целях, кроме коммерческих.

Извините, что отнял много времени. Всем добра.