Timeweb.Cloud

❯ Небольшая предыстория

Больше года назад я нашел в своих закромах одноплатный компьютер Raspberry Pi 4 Model B 8 ГБ. Устройство было куплено за небольшую цену в то время, когда человечество ещё не сошло с ума. Без долгих размышлений, я принял решение создать голосового ассистента на базе этого одноплатного компьютера, чтобы управлять своей системой домашней автоматизации. Бонусом к этой идее шли приватность и автономность. В итоге у меня «родилось» устройство под кодовым именем «Мария».

Но в этой статье не пойдет речь об использовании Raspberry Pi 4 Model B, так как в современных реалиях использование данного одноплатного компьютера стоимостью более $190, трудно назвать бюджетным решением.

❯ Давайте изобретать

Недавно компания Xunlong Software, которая занимается выпуском одноплатных компьютеров под маркой Orange Pi, представила интересное решение — плату Orange Pi Zero 2W с 4 ГБ оперативной памяти, стоимостью $27.

Данное решение вполне подходит для нашего проекта, как в техническом, так и в экономическом плане.

Итак, определимся с конструкцией устройства. Изучив спецификацию Orange Pi Zero 2W, у нас формируется следующий список дополнительных компонентов:

1. Динамик 52мм (просто он у меня уже был $1,3)

2. Усилитель низкой частоты (буду использовать PAM8403 $0,9 за 10 шт)

3. USB микрофон (xingzhaotong $1,5)

4. Шлейф FFC FPC 24pin тип B ($1)

5. RGB светодиод

❯ Разработка звуковой платы

Согласно документации, аудиовыходы реализованы на боковом разъеме FPC, а интерфейс I2S отсутствует. По крайней мере, мне не удалось его реализовать на этой плате. Таким образом, в качестве аудиовхода мы будем использовать USB-микрофон. В версии «Мария» я использовал I2S-микрофон, который продемонстрировал отличные результаты. Ниже предоставлена распиновка бокового разъёма.

Исходя из вышесказанного, в процессе разработки у нас получается следующая схема «звуковой платы»:

Так могла бы выглядеть плата при производстве на китайской фабрике:

❯ Изготовление звуковой платы

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

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

Ниже показано тестовое подключение звуковой платы к одноплатному компьютеру с помощью шлейфа FFC FPC:

❯ Настало время творчества! Проектируем корпус

Обычно в своих разработках я использую естественный интеллект. Поэтому пришлось придумывать дизайн корпуса самостоятельно, учитывая особенности печати 3D принтера. Разработку модели корпуса выполнял с помощью FreeCAD, результат моделирования вы можете видеть ниже.

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

❯ Сборка умной колонки

Подключение элементов устройства выполняется по следующей схеме:

Как видно из схемы, для управления усилителем используется выход 28 (wPi 18) RPI разъёма, данный выход подключается к контакту звуковой платы с обозначением «SOUND EN». К выходам 26, 24, 22 подключается управление RGB светодиода, который выполняет функцию индикатора при выполнения запросов.

Как я упоминал ранее, в качестве микрофона используется USB микрофон марки xingzhaotong, который выглядит так:

Для установки в корпус колонки, нам необходимо его полностью разобрать и оставить только плату. Данная плата подключается согласно распиновки к соответствующим контактам на звуковой плате GND, DP, DM, VCC.

Давайте приступим к сборке устройства. Предварительная примерка платы Orange Pi Zero 2W:

Вид сверху без верхней крышки, на верхней поверхности резонатора виден прикрепленный USB микрофон в центре будет размещен RGB светодиод.

❯ Немного программной части

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

Операционная система:

В качестве операционной системы я использовал Debian Bullseye c версией ядра 6.1.31, скачать можно на официальном сайте Orange Pi.

Управление GPIO:

Для управления GPIO используется официальная библиотека Orange Pi wiringPi.

Установка wiringPi:

apt-get update
apt-get install -y git
git clone https://github.com/orangepi-xunlong/wiringOP.git
cd wiringOP
sudo ./build clean
sudo ./build

После успешной установки Orange Pi wiringPi, мы можем вывести таблицу GPIO:

gpio readall

В итоге мы увидим следующее:

Обратите внимание, что в колонке «V» указано текущее состояние пина RPI.
Чтобы изменить состояние, мы можем воспользоваться следующими командами:

gpio mode 18 out # Изменение типа пина вход/выход (in/out)
gpio write 18 0 # Изменение уровня пина низкий/высокий (0/1)
gpio read 18 # Чтение состояние пина

Пример одного из вариантов управления GPIO из Python скрипта:

import os
os.system("gpio mode 18 out") # Изменение типа пина вход/выход (in/out)
os.system("gpio write 18 0") # Изменение уровня пина низкий уровень
os.system("gpio write 18 1") # Изменение уровня пина высокий уровень
os.system("gpio read 18") # Чтение состояние пина

Проверка наличия микрофона в системе:

Чтобы убедиться в правильности подключения микрофона, в консоли необходимо выполнить следующую команду:

arecord -l

Вывод команды должен быть следующим:

**** List of CAPTURE Hardware Devices ****
card 2: ahubhdmi [ahubhdmi], device 0: ahub_plat-i2s-hifi i2s-hifi-0 [ahub_plat-i2s-hifi i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0

Как видим из вывода, устройство USB PnP Sound Device успешно определилось в системе, если устройство отсутствует, то необходимо убедиться в его корректном подключении.

Настройка аудиовыхода:

Чтобы сконфигурировать аудиовыход под наши задачи, в терминале необходимо выполнить следующую команду:

alsamixer

В консоли появится окно с аудио устройствами, нажав F6 необходимо выбрать наше устройство с именем audiocodec и выполнить настройку как отображено ниже на картинке:

После этого можно выполнить алгоритм теста аудиосистемы.

Вывод списка доступных устройств воспроизведения звука:

aplay -l

Вывод команды:

**** List of PLAYBACK Hardware Devices ****
card 0: audiocodec [audiocodec], device 0: CDC PCM Codec-0 [CDC PCM Codec-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: ahubhdmi [ahubhdmi], device 0: ahub_plat-i2s-hifi i2s-hifi-0 [ahub_plat-i2s-hifi i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0

Мы используем линейный выход, поэтому наше устройство имеет имя CDC PCM Codec-0 [CDC PCM Codec-0]. Давайте протестируем вывод звука через наше устройство.

Первое что нужно сделать — это включить наш усилитель с помощью команд:

gpio mode 18 out
gpio write 18 1

Далее нам необходимо запустить тест с помощью генератора шума, командой в терминале:

speaker-test -c2 -Dplughw:0,0 # plughw:0,0 - это адрес нашего звукового устройства

Вывод команды:

speaker-test 1.2.4

Playback device is plughw:0,0
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 32 to 131072
Period size range from 16 to 16384
Using max buffer size 131072
Periods = 4
was set period_size = 16384
was set buffer_size = 131072
0 - Front Left
1 - Front Right
Time per period = 2.742858
0 - Front Left
1 - Front Right
Time per period = 5.461073
0 - Front Left
1 - Front Right
Time per period = 0.580064

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

❯ Итог

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

Предугадывая ваш вопрос — «Почему бы не использовать Yandex Алису и подобные коммерческие решения?», сразу же изложу свою мысль:

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

Спасибо за ваше внимание! Ниже под спойлером несколько видео работы собранного устройства.

Файлы проекта:

• Файлы модели корпуса.

• Печатная плата проекта.

Так же рекомендуем почитать:

• Как проклятие невидимой стены ждало меня 20 лет

• DECstation 5000/260 — когда интернет был еще молодым

• Простая гравировка для дома: электрический карандаш

Когда на меня накатывает хандра, я бросаю всё и пилю свой игровой движок. Это неблагодарное занятие, но меня прёт.

В самом начале у меня были такие планы: вжух-вжух, щас возьму ведро, накидаю туда всяких библиотек для графики, физики и звуков, добавлю сетевую библиотеку по вкусу, перемешаю всё с какой-нибудь системой сообщений, и готово. Приключение на 15 минут.

И вот я тут спустя 5 лет.

Ладно, если быть честным, то я почти не уделял времени разработке, потому что постоянно спотыкался на всяких бесящих меня ошибках: то сериализация не работает с наследованием, то потоки не хотят нормально разделять память, то обновление языка ломало совместимость… Я могу, блин, целую Камасутру написать про соитие с игровым движком. Все эти ошибки сильно демотивируют, потому что хочется уже наконец-то заняться делом, а не ковыряться с байтиками.

Это не моё видео, но оно очень точно передаёт, как у меня происходит разработка:

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

Ну и вот про одну такую ошибку я хотел поговорить. Есть такой движок — ODE (Open Dynamics Engine). Он появился где-то в палеолите, динозавры его накодили, от документации остались только царапины на скалах. Но он работает, он простой в использовании, и у него есть сишные заголовки, поэтому я мог просто написать враппер на Nim и использовать его в своём движке. В Nim вообще ни хрена нету, поэтому канонический способ — это взять какую-нибудь библиотеку из Си, научиться её вызывать, а потом говорить всем, что ты написал крутую программу на Nim.

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

Разумеется, если вы не планируете делать Minecraft, то вам может понадобиться что-то поинтересней, чем кубик. В ODE есть специальный класс Trimesh, который как раз позволяет вам сделать сложную геометрию. Фактически, вы можете создать любое тело из набора треугольников. Типа такого:

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

Я создал треугольник, он успешно отрисовался на сцене, я начал ходить по миру… и обнаружил, что треугольник не в том месте, где нарисован, а где-то непонятно где.

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

Фактически, я мог ходить по сцене, и где-то я упирался в тот самый треугольник, который вообще-то должен был быть там, где нарисован. Я в принципе даже что-то такое и ожидал, потому что, как я уже где-то писал, только три раза в своей жизни я написал код, который заработал с первого раза. Наверняка я где-то перепутал координату — вместо X передал Y, или наоборот, ну что-нибудь такое. Эти программисты, вы знаете!

Отрисовать этот треугольник я не мог, потому что координаты были правильные, графический движок всё отрисовывал правильно, но вот физический движок как-то неправильно интерпретировал мои правильные данные. Поэтому я стал ходить по миру и пытаться определить очертания этой невидимой стены. В конце концов я её нашёл (она была достаточно странной), и я решил немного подвигать треугольник, чтобы посмотреть, как он влияет на эту стену. Казалось бы, если я просто где-то перепутал координаты, то подвинув треугольник, я немножко подвину эту стену. Но хрен мне там! Стена исчезала и появлялась совершенно случайно, прыгала далеко даже от малейшего изменения координат, и я не мог понять, почему.

И тут я вспомнил эту недалёкую женщину из заЩИТников! Если кто не знает, она сделалась невидимой и решила спрятаться в дожде. Отличный план, надёжный, как швейцарские часы:

Я подумал, что это прям мой случай, и решил полить свою стену дождём, чтобы увидеть её. Дождя у меня не было, зато были кубики, поэтому я создал штук 50 и стал кидать их вниз. При касании стены они к ней прилипали, и я мог видеть её очертания. А когда что-то видишь — отлаживать в разы легче!

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

Если нужно где-то найти таких же неудачников, как я, то самое лучшее место для этого — интернет. И я нашёл его — единственного человека, который отстрадал своё и рассказал об этом. Представляете, в 2006 году у какого-то чувака из Германии пятая точка горела точно так же, как у меня сейчас! Не знаю, что он выкурил (похоже, что исходники), но, ОКАЗЫВЕТСЯ, физический движок ожидает от вас трёхмерные точки, но передавать их надо как четырёхмерный вектор, просто в четвертой координате надо поставить мусор, типа так: [x1, y1, z1, 0, x2, y2, z2, 0, ...]. Скажите, как по const dReal* Vertices я должен понять, что там ждут в гости четырёхмерные вершины?

За что я люблю опенсорс — можно всегда докопаться до истоков всего. Я полез в исходники, и вот что обнаружил.

В 2003 году пришёл Russel Smith и добавил всю эту функциональность с trimesh collisions, в том числе интересующую меня строчку:

Тут всё понятно, потому что в определении чётко говорится, что dVector3 — это четырёхмерный вектор (есть некий шарм в этой логике).

А потом через пару месяцев врывается Erwin Coumans и переписывает так, чтобы тип был непонятен:

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

Я переписываю код с добавлением четвертой координаты, и все начинает работать.

Такие дела.

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

Получается такой вот эффект бабочки, как с этой невидимой стеной. Поэтому когда вы в следующий раз сядете писать код, представьте, что какой-то разраб через 20 лет будет в нём разбираться, и, пожалуйста, постарайтесь сделать жизнь этого чувака хоть чутоку легче. Ведь однажды этим кем-то можете оказаться вы сами.

Не только лишь все могут смотреть в будущее, но вы сможете, если подпишетесь на мой уютненький канал Блог Погромиста.

А ещё я держу все свои яйца в одной корзине (в смысле, все проекты у одного облачного провайдера) — Timeweb. Поэтому нагло рекламирую то, чем сам пользуюсь — вэлкам.

❯ Платформа

На этот раз мне в руки попала экстремально редкая машина — DECstation 5000/260, представитель временной линейки RISC-станций, выпускавшейся Digital Equipment Corp. в ожидании готовности их собственной процессорной архитектуры — Alpha AXP. Да, вам не показалось — компания, создавшая PDP, VAX и Alpha, выпускала компьютеры не только на собственных архитектурах. И если представители линеек на базе х86 процессоров (HiNote, DECpc, Celebris/Venturis итд) известны многим, то линейка рабочих станций и серверов DECstation/DECsystem на базе процессоров MIPS, из-за небольших объемов и короткого времени производства (с 1989 по 1994 год). Последняя модель на базе процессоров MIPS была представлена годом ранее, в 1993. Этой моделью и была 5000/260, на базе новейшего процессора MIPS R4400 с частотой 120 МГц.

Линейка DEC 5000 относилась к сегменту Hi-End и начиналась с моделей 200 и 240, использовавших процессоры R4000 с частотой 25 и 40 МГц соответственно, с частотой шины, равной частоте ядра. В R4600 появляется умножение внутренней частоты и процессор, использующий 60 МГц шину, работает на частоте 120 МГц. Часто в информации о модели 260 указывалась именно частота внешней шины процессора. В качестве основной шины, использовалась фирменная разработка DEC — TURBOchannel. Эта шина позволяла достичь пропускной способности в 50-100 Мбайт/с в зависимости от частоты (12.5-25 МГц), в моделях 5000/240 и 260 используется наибыстрейшая ее версия. Из-за использования собственной системной шины и собственного стандарта Firmware, эти машины часто выделяют в отдельную “подархитектуру” Pmax, например так обозначаются поддерживающие эти машины версии NetBSD.

К сожалению, это означает, что вам не удастся запустить на DECstation IRIX или Windows NT/MIPS. Хотя, разработка NT/MIPS велась именно на этих машинах и даже первые демо этой ОС проводились с их использованием, в финальную версию системы поддержка DEC 5000 не вошла. Впрочем, DEC подготовила для своих машин фирменную версию Юникс под названием Ultrix. Она выпускалась в двух вариантах — Ultrix/VAX для систем VAX/MicroVAX и Ultrix/RISC для систем MIPS. Уже ближе к концу жизненного цикла платформы, эта система была заменена OSF/1, вскоре портированной на Alpha AXP и сменившей несколько имен — Digital UNIX, Tru64 Unix.

Интересный факт — первые машины на процессорах Alpha тоже относились к линейке DECstation и использовали шину TURBOchannel. Для корректной работы карт расширения в прошивку был добавлен эмулятор процессора MIPS — ведь прошивки карт TURBOchannel были рассчитаны именно на них. В дальнейшем таким же образом была организована поддержка карт PCI/ISA в более новых Alpha машинах.

❯ Машина

Итак, перед нами машина не только редкая, но и довольно необычная. Во-первых, в ней не предусмотрено место для накопителей вообще. Несколько непривычно для топовой модели, не правда ли? Тем не менее — это так, пространство корпуса поделено между блоком питания и материнской платой с 15(!) слотами оперативной памяти, занимающими почти треть ее площади. Поддерживается до 480 Мбайт ОЗУ типа FPM в собственном формате модулей. Существовали модули на 8 и 32 Мбайт, а также специальные энергонезависимые (читай — с батарейкой) модули для кэширования ввода-вывода. В нашей машине установлено пять обычных модулей по 32 МБайт, общим объемом 160 Мбайт. Цифры огромные для начала 90х!

Рядом со слотами памяти расположилась процессорная карта, на ней расположен процессор, сопроцессор и кэш второго уровня (целый мегабайт!). У задней стенки — три слота TURBOchannel, один из которых занят видеокартой “HX Smart Frame-Buffer Graphics Module" (PMAGB-B) — средней из доступных карт, предоставляющей вывод 8-битного цветного изображения в разрешении до 1280х1024 и обеспечивающей базовые функции 2D ускорения. В линейке же присутствовали и 3D ускорители — редкая и дорогая опция. Остальные два слота свободны. В них можно установить дополнительные SCSI и сетевые опции, например FDDI или Token Ring. На плате интегрированы сетевой контроллер DEC Lance (10 Мбит/с, разъем AUI) и SCSI-контроллер NCR 53C94. Оба контроллера подключены к шине через 128 Кбайт локального кэша для ускорения операций ввода-вывода.

Внимательный взгляд наверняка уже зацепился за шильдик “5000/240” на передней панели девайса. Действительно, эта машина начала свою жизнь 7 мая 1992 года как DECstation 5000/240, но уже в начале 1993 года она была официально обновлена до модели 260, о чем гласит наклейка на задней панели (KN03 и KN05 — коды обозначения процессорных плат этих моделей, соответственно). В комплекте набора для апгрейда должен был быть и новый шильдик, но, судя по всему, кто-то его решил оставить себе в качестве сувенира 30 лет с лишним назад…

И так — у нас есть сеть и есть SCSI. Можно использовать машину как бездисковую рабочую станцию и загружать полностью по сети — встроенный контроллер и прошивка это умеют — причем как с использованием фирменного протокола MOP, так и с помощью привычной связки BOOTP+TFTP. Но такой подход ограничивает производительность — больше 1 Мбайт/с от NFS поверх Ethernet ждать не стоило, а топовые SCSI диски уже могли быть в пару раз быстрее.

В принципе, с DECstation можно использовать любой внешний SCSI диск или даже дисковую полку (мне досталась в комплекте небольшая симпатичная полочка на 3 диска с горячей заменой), но DEC не была бы DEC, если бы не предусмотрел все ситуации. В комплекте с машиной мог поставляться DEC Storage Expansion — второй корпус, в том же стиле, что и основная машина, но чуть выше и уже. Казалось бы, вот так промах! Но и делали его изначально для VAX, к которому он подходил замечательно — тут уже результат унификации. В корпусе находится собственный блок питания и два посадочных места под SCSI устройства форм-фактора 5.25” Full Height (то есть в высоту как два привода CD-ROM). Одно из мест занято огромным, занимающим всё отведенное пространство, диском RZ57 на 1 Гбайт производства самой DEC, второе место доступно для установки еще одного диска или ленточного накопителя (для этого на корпусе установлена заглушка). Возможно можно установить и CD-ROM, но у меня не нашлось подходящего. Всю жизнь машина и блок хранения проработали вместе, долгие годы трудясь в офисе самого вендора — о чем гласит наклейка “Property of Digital”. Этим, я думаю, и объясняется такое везение с апгрейдом процессорной платы — все же модель 240 значительно уступает в производительности 260. Вторая наклейка — несколько умиляет. На ней выбито изначальное сетевое имя машины — “MOULEFRITE”, в переводе с французского, наиболее близкое значение — “Сковородка”.

Казалось бы, повезло — получить редчайшую машину в отличном комплекте и требующий всего лишь тщательной чистки после гаражного хранения и замены “Далласа”, модуля, хранящего настройки firmware на “протез”. Но не все так просто — как вы могли заметить, разъем для подключения монитора здесь проприетарный — 3W3, на сигнальном уровне совместимый с VGA и 13W3, но без переходника (который по редкости сравним с самой машиной) обычный монитор к нему не подключить. Также и разъем для клавиатуры и мышки здесь свой, сигнально не совместимый с чем-либо другим.

❯ Приключения

Но и это — не проблема. Компорт — лучший друг инженера! На многих серьезных машинах до появления систем удаленного управления можно было выбрать вывод системной консоли на последовательный порт. Для родственных серверов DECsystem, отличавшихся отсутствием видеокарты, это и вовсе основной способ взаимодействия с оператором. К нему можно подключить последовательный терминал, например Digital VT100, или просто обычный компьютер с эмулятором терминала. В качестве терминала, я использовал в основном машину из статьи Dreamstation с программой HyperTerminal — примерно вдвое более мощную, чем герой этой статьи. Хотя на паре фото DECstation запечатлена с чудесным ноутом Digital HiNote — его я использовал во время первоначальной отладки.

Опустим историю с чисткой, это не так уж интересно — лишь много воды, пузырьков и куча стертых дисков для шлифовки от ржавчины. Первоначальная отладка тоже не таила сложностей — заменить “даллас” (он тут в панельке), подключиться терминалом, настроить переменные firmware, попробовать загрузиться — и узнать, что диск пуст.
А вот с установкой операционной системы возникли сложности. Самый простой путь — установить её с компакт-диска. Благо, внешний SCSI CD-ROM у меня есть, и даже не один. Но тут кроется засада! У некоторых старых RISC машин есть прикол — они ожидают, что CD-ROM будет использовать секторы размером 512 байт, как у жесткого диска, а не 2048 байт, как подавляющее большинство приводов. Но я был готов и к этому — у меня есть привод, который щелчком тумблера позволяет переключать размер сектора — Yamaha 2100S. В режиме 512 байтных секторов машина загружается с диска, запускает инсталлятор Ultrix и…падает с ошибкой размера сектора CD-ROM. Что за магия, мне понять не удалось, а оригинального CD-ROM тех времен с прошивкой от DEC в моих запасах нет. Альфа же уже не столь привередлива.

Подход номер два случился через несколько недель. В этот раз я решил попробовать загрузку по сети. Сначала, я достал старую добрую “малинку” и попробовал поднять mopd — собрать его под ARM не составило большого труда. Взять его можно здесь — github.com/qu1j0t3/mopd/tree/master, а если будете идти моим путем — нужно сказать линковщику, чтобы он не обращал внимания на повторные объявления переменных. Запустить сервис мне удалось, но в процессе выяснилось два интересных обстоятельства. Во-первых я не смог найти образ Ultrix для сетевой загрузки, во-вторых — я узнал, что DECstation умеет работать с BOOTP+TFTP, прежде я не знал об этом. Ultrix устанавливаться так не умеет, но зато NetBSD может. Поэтому я решил начать с нее.

Я использую pfSense в качестве домашнего роутера — его же я и использовал в качестве сервера BOOTP. BOOTP отличается от DHCP лишь отсутствием поддержки динамической конфигурации хостов, поэтому если вы сделается статическое выделение адреса в DHCP сервере, машина сможет получить его по BOOTP-запросу. Не забудьте в свойства указать поддержку сетевой загрузки и имя файла с образом. Вам понадобится образ инсталлятора в формате ecoff (в моем случае netbsd-INSTALL.ecoff). TFTP не идет в базовой поставке pfSense, но его легко установить из пакетов. В веб-интерфейсе нет поддержки вложенных папок, но их легко создать при подключении по ssh.

❯ NetBSD

Я выбрал версию NetBSD 8.0, в 9.3 сломали поддержку моего SCSI контроллера, а 10 пока не является стабильной. Установка проходит без проблем, главное не забывать, что это достаточно современная система и она требует заметного пространства на диске. Стоит выбрать минимальную установку, а потом доустановить требуемые пакеты. Впрочем, если у вас диск больше 4 Гбайт, можно об этом не задумываться.

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

❯ Ultrix

Одновременно коллеги мне подкинули идею, о которой я должен был догадаться сам. Раз размер сектора у образа установочного диска и обычного харда совпадают — нужно его просто раскатать с помощью dd на второй жесткий диск. Для этого у меня нашелся забавнейший 3.5” дюймовый Micropolis полной высоты емкостью в целый гигабайт (мой друг и коллега по увлечению Slex обозвал его Necropolis — за древность и неспешность).

Трюк удался. Меньше чем через полчаса у меня был рабочий инсталлятор — можно приступать! Установка проходит без особых проблем, главное запастись терпением. Процесс занимает минут 40. Устанавливать стоит сразу полный набор компонентов, Ultrix бережет место на вашем диске. Важно правильно разбить диск, базовые варианты разбиения не оптимальны и оставляют слишком мало свободного места в разделах, а изменить таблицу разделов после установки будет очень неприятной задачей. Сложных вопросов установщик почти не задает, из важного — пожалуй, лишь выбор графической оболочки — XUI или DecWindows/Motif. Я выбрал вторую, но надо будет как-нибудь решиться и попробовать вариант с провокационным неймингом.

После установки потребуется настроить сеть и выполнить несколько базовых настроек (хорошо описаны тут в разделе Some basic customization). Если, вы будете, как и я работать с машиной через последовательный терминал, обязательно включите его в /etc/ttys (сделать это придется в single user mode), иначе вы можете оказаться с нормально загружающейся машиной, после загрузки отказывающейся реагировать на ваши действия в консоли.

После завершения настроек, вы можете использовать машину как сервер или пользоваться консольными приложениями. Но ведь это совсем не интересно, правда! Эта машина практически ровесница интернета, для нее доступен один первых браузеров — NCSA Mosaic, так что грех не установить его и не попробовать выйти в интернет. Но, как вы помните, у меня нет ни монитора, ни даже клавомышки…

❯ X-терминал

Что чаще всего приходит на ум, когда идет речь о выводе графики по сети? VNC, а следом возникают слова “медленно”, “задержки”. Может быть это не такая и плохая идея в качестве временного решения, но в любом случае для Ultrix нет сервера VNC, ну или я его не нашел. Мне удалось найти лишь небольшой набор freeware софта под эту ОС (теперь он доступен для загрузки из архива Digital Vintage — тут). В процессе поисков информации, я вспомнил об X-терминалах, упрощенных машинах с небольшим объемом памяти и младшим в линейке процессором (а иногда и созданным специально для них), но с полноценной видеоподсистемой, созданных, чтобы обеспечивать работу множества пользователей с одной мощной рабочей станцией. В коллекции даже есть одна такая машина — Sun X-terminal 1, ее настройка еще только предстоит, поэтому я выбрал программное решение.

Х-терминалы отличаются от тонких клиентов тем, что обрабатывают вывод видео полностью на своей стороне, а не предоставляют доступ к сгенерированной на удаленной машине картинке.
Так как под MacOS ничего не нашлось, я думал использовать X-ming для Windows в режиме XDMCP, первые успехи пришли с его использованием, но, как оказалось, приложения ожидают наличия определенных шрифтов, которых нет в Windows и в их отсутствие могут работать некорректно или вовсе не запускаться. Поэтому я установил Linux в виртуальную машину (каюсь, у меня нет под рукой десктопной Linux-машины), в дополнение к минимальной десктопной установке поставил растровые шрифты 75 и 100 dpi и главное — Xephyr. На DECstation понадобится установить дополнительный файлсет с утилитами X-windows, на установочном диске он лежит в разделе Unsupported. Вместе с ним можно поставить и игры:

• монтируем установочный образ — mount /dev/rz2a /mnt

• переходим в папку с “неподдерживаемыми” файлсетами — /mnt/RISC/UNSUPPORTED

• запускаем установщик — setld -l ./

• выбираем нужные файлсеты

• запускаем установку

• перезагружаемся

• устанавливаем значение переменной setenv DISPLAY %IP_ADDR%, указывая адрес машины, где будет запущен Xephyr

• запускаем xdm — /usr/bin/X11/xdm -nodaemon

• запускаем Xephyr на машине с Linux — Xephyr -ac -query %DEC_IP_ADDR% -retro -screen 1280x1024 (можно выбрать и другое разрешение, на ваш вкус)

И вот, перед вами рабочий стол настоящего Unix начала 90-х! Как при подключении по telnet, так и в графическом режиме машина работает очень быстро, ОС и софт рассчитаны на более скромные конфигурации — всю мощь рабочей станции мог бы раскрыть специализированный софт, например инженерные пакеты CAD/CAE или программы для видеоконференций — эти машины даже могли поставляться в виде готового решения для их проведения.

Установка софта из каталога freeware проста — либо вы просто распаковываете исполняемый файл и перемещаете в /usr/local/bin, либо выполняете make install. Прописать программу в меню программ можно в настройках сессии (Application Definitions). Mosaic установлен, сеть работает, осталось последнее дело — сходить в интернет!

А вот с этим не все так гладко… По традиции, на ретро машинах я делаю скриншот с главной страницей архива Digital Vintage, но Mosaic в GET запросе не указывает имя домена, поэтому открывается дефолтный бэкенд K8s, причем браузер искренне считает его бинарным файлом и предлагает сохранить на диск. Из всех сайтов мне удалось открыть лишь архив EISA конфигов mR_Slug — его вы и можете видеть на скриншоте. Другого же браузера для Ultrix мною обнаружено не было…

❯ Заключение

Но на этом интернет, конечно, не заканчивается и не заканчивался уже тогда. Я не пробовал Gopher, а ведь на заре интернета это был очень популярный протокол. Но есть консольный FTP клиент — с его помощью я и загружал программы на DECstation. И пусть сегодняшние сайты не по силам тридцатилетней машине, но, пожалуй, нужно будет завести копии сайтов того времени в локальной сети — чтобы демонстрация таких раритетов была более интересной и захватывающей! Благодарю вас за внимание и до новых встреч!

P.S. Хотелось бы объявить искреннюю благодарность «Ленинградскому компьютерному клубу» и лично его основателю Ивану за помощь в обретении героини этой статьи.

Связаться с автором можно через канал.

Однажды у меня возникла потребность подключения своего узла учета электрической энергии к системе умного дома «Home Assistant», но вот беда, установленный счетчик ЭНЕРГОМЕРА СЕ101 не обладал смарт функциями, позволяющими без проблем подключать его к системам умного дома, а цена электросчетчиков со смарт функциями просто заоблачная. Но я нашел экономичное решение с ценой решения задачи менее $5 и об этом далее.

❯ Исходные данные

Итак, как я говорил ранее, для учета электрической энергии у нас установлен счетчик ЭНЕРГОМЕРА СЕ101 модификации R5 — достаточно бюджетное решение. Чтобы изучить подопытного в плане доступных интерфейсов, изучим техническую документацию на данный счетчик. Я особо не испытывал иллюзий в плане наличия доступных интерфейсов, но мне повезло.

Бинго! — сказал я, найдя в документации следующие пункты:

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

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

2.3.3. Испытательный выход реализован на транзисторе с «открытым» коллектором, для его функционирования необходимо подать питающее напряжение постоянного тока от 5 до 24 В. Величина номинального тока через контакты испытательного выхода в состоянии «замкнуто» равна (10±1) мА, максимально допустимая не более 30 мА.

Техническая документация нам прямо говорит:

Счетчик имеет в своем составе испытательный выход для подключения к системам автоматизированного учета потребленной электроэнергии или для поверки.

Ниже приведена схема подключения счетчика

Решено! Будем использовать данный выход для интеграции электросчетчика с Home Assistant. Нам останется только преобразовать импульсный сигнал в удобную форму данных, чем и займется дешевый микроконтроллер ESP8266.

Дополнительная информация по испытательному выходу:

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

❯ Алгоритм преобразования данных

Здесь все просто. Каждый счетчик имеет параметр «частота следования импульсов, пропорциональная входной мощности», который указан на панели счетчика, в моём случае это 3200 imp/kW*h. То есть, чтобы нам узнать накопленную мощность, просто нужно будет значение инкрементного счетчика, который суммирует входящие импульсы от счетчика, поделить на 3200. Чтобы отслеживать потребление за определенный период времени нам нужно будет реализовать дополнительные интервальные счетчики.

❯ Разработка аппаратной части

Итак, как описывалось ранее, преобразование импульсных значений электросчетчика достаточно тривиальная задача, с которой вполне справится микроконтроллер ESP8266.

Принципиальная схема устройства:

Рендер печатной платы:

На самом деле, схема настолько простая, что монтаж можно реализовать навесным методом.

Пример навесного монтажа. Особо впечатлительным не смотреть! )

❯ Корпус

Модель корпуса, как обычно, я разрабатывал во FreeCAD.

В корпусе предусмотрен отсек для аккумулятора, который обеспечит устройство резервным питанием. Питание устройства и зарядка аккумулятора выполняется с помощью популярной платы на буде контроллера заряда TP4056. Но использование аккумулятора не обязательно, я просто перестраховался.

Модель корпуса напечатана HIPS пластиком на 3D принтере.

❯ Микро ПО

Прошивка устройства написана в среде Arduino IDE, большую часть прошивки занимает веб интерфейс и функция работы с MQTT протоколом. Для работы с входным сигналом используется аппаратное прерывание. Ссылку на исходный код прошивки я оставлю конце статьи, а теперь давайте рассмотрим веб интерфейс устройства:

• Вход в устройство

Для входа в устройство требуется авторизация, пароль по умолчанию: admin

• Главная страница устройства

На главной странице отображены данные по потреблению электроэнергии:

1. Потребляемая мощность (сред. 10 сек, 1 мин, 5 мин, 60 мин), Вт*ч — усредненное рассчитанное часовое потребление за период 10 сек, 1 мин, 5 мин, 60 мин. Для отслеживания динамики по потреблению эл.энергии.

2. Показания счетчика — накопленное значение кВт*ч

• Конфигурация передачи данных по MQTT протоколу

Как вы могли заметить, для интеграции с Home Assistant используется протокол MQTT, настройки вполне понятные, не требует дополнительных описаний.

Ниже указаны топики, для примера, указано корневое имя топика «m_power»:

1. m_power/10s — передача значения «Потребляемая мощность (сред. 10 сек)», периодичность отправки 10 сек.

2. m_power/1m — передача значения «Потребляемая мощность (сред. 1 мин)», периодичность отправки 1 мин.

3. m_power/5m — передача значения «Потребляемая мощность (сред. 5 мин)», периодичность отправки 5 мин.

4. m_power/60m — передача значения «Потребляемая мощность (сред. 60 мин)», периодичность отправки 60 мин.

5. m_power/total — передача значения «Накопленная мощность», периодичность отправки 5 мин.

• Настройка типа счетчика

Здесь необходимо ввести два параметра вашего электросчетчика:

• "Количество импульсов счетчика на 1 кВт*ч" — данный параметр указан на табло счетчика

• "Текущие показания счетчика" — данный параметр передается в устройство, как начальное значение накопленной мощности, далее к этому параметру будут прибавляться рассчитанные контроллером данные.

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

❯ Интеграция в Home Assistant

Чтобы интегрировать данное устройство в Home Assistant, необходимо прописать в файле конфигурации configuration.yaml следующий код:

Обратите внимание, что в примере указан корень топика с именем «m_power».

Код карточки «объекты» для вывода данных:

В результате у вас должно получиться что-то подобное:

❯ Подключение нашего контроллера к электросчетчику

Важное предупреждение!

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

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

Ниже фотография собранного устройства с подключенным счетчиком.

Видео работы контроллера при включенном электрическом водонагревателе.

Ниже демонстрация графиков данных, полученных с контроллера:

❯ Подводим итоги

В итоге у получилось простое и дешевое устройство для интеграции «глупого» электросчетчика в системы умного дома. Я очень доволен результатом! Теперь нет необходимости переодически записывать показания со счетчика для отправки, а просмотр статистики потребления, по временным интервалам, дает возможность анализа расхода электроэнергии с последующей оптимизацией.

Дополнительная опция

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

Исходные файлы проекта:

• Модель корпуса

• Гербер файлы печатной платы

• Исходный код прошивки

• Образ прошивки (ESPTool в помощь)