Текущая версия платы процессорного модуля
Подоспела вторая часть материала про самопально-велосипедную систему управления освещением. Напомню, я решил строить сеть RS-485, в которой находятся управляющие и исполнительные устройства, а мастером является компьютер, на котором крутится реализующая логику программа. Прежде чем перейти к описанию логики системы, расскажу о доработках и сдвигах парадигмы в плане железа, возникших в результате обсуждения и тестирования прототипов из первой части.
Допиливание
Во-первых, железки решено делать модульными, по аналогии с Arduino и рядом других проектов. Я прикинул, что основной (процессорный) модуль у меня содержит больше компонентов, чем модули функциональные, поэтому именно он будет материнским. А в него будут вставляться «шилды». В плане схемотехники произведены следующие изменения:
1) Добавлен стабилизатор питания (AMS1117-5.0).
2) Изменена разводка питания микроконтроллера.
3) Плата основного модуля разведена с учетом промышленного изготовления, но второй слой меди используется по минимуму — можно кустарно изготавливать однослойную плату и ставить перемычки.
4) Добавлен джампер Endpoint для терминирования линии на последнем устройстве.
5) Добавлен джампер RST Lock для блокирования сброса микроконтроллера.
6) Аналогично п.3 разведены дочерние платы энкодера и драйвера светодиодной ленты.
7) Жду первый пробный заказ печатных плат, пока только основные модули (ITEAD Studio).
Дочерняя плата драйвера светодиодной ленты
Суета вокруг RS-485
Теперь перехожу к мастеру сети. В плане железа там все просто — ну, по крайней мере, я так думал. Взял переходник USB-UART, к нему подключил маленькую платку с MAX485 и несколькими резисторами, начал работать. И наступил на отличные грабли, вполне документированные, но для новичка совершенно не очевидные.
MAX485 нужно переключать между приемом (низкий уровень на объединенных пинах ~RE и DE) и передачей (высокий уровень). Руководствуясь простой логикой, я использовал для управления режимом выход DTR преобразователя (на CP2102), дергая его программно. И получил безобразие. Система кое-как работала только при неприемлемо больших задержках между приемом и передачей. А все из-за того, что DTR переключается медленно. Насколько медленно, мне нечем было померять, поэтому просто привожу ссылку на более вменяемое исследование граблей с применением осциллографа.
Из этого же материала я уяснил следующее: наименее болезненным будет использование FT232, поскольку у него есть вывод, при дефолтной настройке чипа как раз предназначенный для переключения режимов RS-485. Попросту говоря, на нем появляется высокий уровень при передаче по UART. Так что, из закромов извлечен китайский клон Arduino Nano, ~RST закорочен на землю, к 13-й ножке FT232 подпаян провод, и все это дело соединено с MAX485. Работает как часы. В «боевой» версии системы, конечно, такая конструкция использоваться не будет — китайская промышленность с удовольствием предлагает аналогичные готовые платы.
Логика системы
Наконец, к тому, как весь процесс выглядит с точки зрения мастера. Он работает с объектами устройств, которые могут быть управляющими или исполнительными. Управляющие подразделяются на реальные («железные»), виртуальные и таймеры. Исполнительные могут быть только реальными.
Виртуальные управляющие устройства понадобятся при реализации более сложного управления системой, в частности, когда к ней будет приделан веб-интерфейс. Также они пригодятся для интеграции с чем-то, что я еще не придумал. Да, тут, наверное, надо сказать о том, что вообще такое «устройство» в рамках системы.
Устройство — это объект класса Device. Минимальный набор атрибутов — имя, тип и флаг использования. Дальше, в зависимости от типа, могут быть добавлены адрес на шине, имя подчиненного устройства, приоритет управления, начальные значения регистров и некоторые другие атрибуты. Основные методы класса касаются работы с реальными устройствами — это чтение и запись регистров.
И вот, более-менее определившись с программной структурой системы, можно приступать к реализации. На текущий момент имеется следующее:
1) модуль Comm485, содержащий описание класса Conn. Методы класса — это открытие и закрытие подключения, передача и прием пакета, проверка контрольной суммы.
2) модуль Device485 содержит описанный выше класс Device.
3) основной программный модуль.
Дочерняя плата энкодера
Собственно, в основном модуле реализованы две вещи. Первая — создание нужных объектов класса Device согласно конфигурационному файлу. Вторая — непосредственно логика работы системы.
В процессе
В настоящее время работает следующее:
1) Составление списка задействованных исполнительных устройств.
2) Для каждого исполнителя составляется список задействованных управляющих устройств.
3) Значения регистров управляющего устройства с максимальным приоритетом записываются в регистры исполнительного устройства и управляющих, обладающих меньшим приоритетом.
То есть, предположим, у нас есть энкодер (железный) с низким приоритетом и виртуальное управляющее устройство — с высоким. В дежурном режиме виртуальное устройство отключено. Когда нужно отрегулировать свет, не поднимая пятой точки с дивана, задействуется виртуальное устройство (на короткий промежуток времени), чтобы выдать новые параметры исполнителю и энкодеру.
Но скорее всего, после небольшой переделки софта основным режимом будет следующий: имеются два управляющих устройства с одинаковым приоритетом. При изменении регистров одного из них происходит запись значений в регистры исполнителя и другого управляющего, у которого изменений не было.
Собственно, пока все. Проект доступен на гитхабе, в папке host можно лицезреть леденящий душу код на Python. Там два модуля (Comm485, Device485), основная программа (host) и папка cfg, в которой конфигурационные файлы: настройка подключения UART и список устройств.
Продолжение непременно последует.
P.S. Будучи жертвой миграции с Хабра, в ряде возможностей ограничен.
