?

Log in

No account? Create an account

Заповедник репрессивной психиатрии

Entries by category: техника

LinkIt Smart 7688 и датчик CO2
metaclass
Дошли наконец-то руки запустить очередной бриколяж - датчики CO2 mh-z19 (https://geektimes.ru/post/272090/)
Наиболее прямым способом, без ордуин и прочего такого оказалось завести микрокомпутер с OpenWRT на борту - LinkIt Smart 7688 (http://wiki.seeedstudio.com/wiki/LinkIt_Smart_7688).

Подключение достаточно влоб: 3.3v usb-uart на пины земли, P9 и P8 для отладки загрузки c serial консоли, сам датчик на пины земли, +5вольт питания и P18(RX linkit)-P3 (TX датчика) P19(TX linkit)-P2(RX датчика).

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

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

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

Дольше всего времени ушло на то, чтобы чтобы разобраться с wifi - который не умеет каналы выше 11 по умолчанию, а у меня модем сел на 13 канал и его вообще не было видно и на то, чтобы вспомнить питон и как на нем отправить массив байт в uart и получить обратно ответ (2 и 3 питоны ведут себя по разному).

Тестовая прога на питоне: https://gist.github.com/metametaclass/fdcd53e4e699ed5a0a780bc74a8a5eca, отправляет результат опроса по udp на комп, где запущен nc на порту 49344 и всякие тестовые прожки на 49345.

Получается вот такая картинка, ночью - с закрытой дверью, днем с открытой и датчиком, на который я дышу: http://www.cacodaemon.org/co2/20161029_212640_20161030_153355.png

Простые модели и кодогенераторы на clojure
metaclass
https://github.com/csete/gqrx/blob/master/pulseaudio/pa_device_list.h (код не мой, просто я в нем сейчас разбираюсь)
По ссылке есть класс pa_device, единственное назначение которого - хранить три поля описания pulseaudio девайсов. Занимает это дело 23+8 - 31 строку.

Когда у меня возникает надобность на обычных языках делать такие классы, у меня не хватает терпения их писать вручную и я их генерирую или из t4-шаблонов или из описания на Clojure, например, этот класс я бы описал так, сделав макрос def-gen-class:
(def-gen-class pa_device 
  "комментарий к классу"
  index uint "комментарий к полю"
  name string "..."
  description string "...")

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

Полученное описание можно при желании расширить генерацией, например, пользовательского интерфейса или сериализации-десериализации.
Для своей опердени я таким образом генерю классы документов, которые умеют загружать-сохранять себя в JSON. Из 90 строк кода на кложури создается 1226 строк на дельфи.

Ардуино-срач
metaclass
В ru_radio_electr назревает ардуино-срач.

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

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

PS: Кстати, почитайте, чем занимается telegamochka с этим ардуино. Хорошее такое маньячество, но у меня лично это вызывает уныние фактом того, что это все эквивалентно какому-нибудь китайскому девайсу копеечной стоимости.

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

Вот пример: есть система распознавания речи, я к ней прикручиваю звукозапись и поле ввода текста с целью прямой диктовки документов в это поле.
Если не извращаться с мегапаттернами - делается один класс, создающий контрол для звукозаписи, контрол для ввода текста, грузит класс для управления с HID-микрофона с кнопками, реализует связь с системой распознавания, реализует всю дополнительную логику и все.

Но мы по ходу люди умудренные опытом, поэтому сразу приходится делать так: во-первых, система распознавания речи сумасшедшая и есть вероятность, что придется ее когда-нибудь отломать и прикрутить другую, поэтому весь ее API заворачивается во wrapper. Все обращения к нему ведутся через интерфейс типа ISpeechRecognizerWrapper. Для упрощения разработки(система распознавания тяжеловесная и каждый раз ее задолбаться запускать) делается mock-wrapper, реализующий тот же интерфейс. Итого +1 интефейс и два класса, реализующих его.

Поле для ввода текста тоже не так просто. Есть стандартный TextBox, работающий корректно с вводимым текстом. Есть наш собственный контрол - полнофункциональный RTF текстовый редактор, который не совсем адекватным образом взаимодействует с текстом переданным с распознавалки речи из-за разного понимания того, что такое знак абзаца. Так же есть стандартный RichTextBox, который может понадобится использовать. Поэтому вместо прямого обращения к методам и событиям текстового контрола - делается интерфейс ITextControl и классы-врапперы реализующие его для каждого из видов текстового контрола. +1 интерфейс +3 класса.

Контрол звукозаписи и сам по себе уже представляет собой базовое ядро с интерфейсом ISoundEngine и две вариации GUI для него. +1 интерфейс, +3 класса.

Управление с HID-микрофона - микрофонов много и разных, каждый представляется своим классом, тоже реализующим стандартный интерфейс. Кроме того, управление с микрофона должно в разных режимах работы направляться в разные части программы, поэтому все события с микрофонов в итоге попадают в менеджер микрофонов, и вызывают метод специального интерфейса IDeviceCommandSink, который этому менеджеру указывается извне теми, кто хочет получать события от микрофонов. Кроме всего этого, на микрофоне есть светодиоды сигнализации режима работы, для управления которыми нужен обратный поток данных от системы, через менеджер микрофонов, в класс-драйвер микрофона. +хрен знает сколько классов и минимум два интерфейса.

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

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

Т.е. планомерное следование заветам ООП и паттернам приводит к тому, что проект разрастается, приобретая "гибкость" и возможность независимого тестирования частей, но при этом ухудшается удобство работы с ним (это еще Visual Studio мешает, там без мыши между кучей файлов переключаться практически нереально) и становится сложно удерживать в голове структуру всего этого).