All streams
Search
Write a publication
Pull to refresh
-4
0.4

User

Send message

Единственное что меня сдерживает от приобретения такого устройства это морально устаревшее разрешение экрана 720p(хотя физический размер экрана вполне себе 10.1"), делающее крайне некомфортным работу с многочисленным современным софтом. Замечу что именно работа на полноценном десктопном Линуксе(в силу специфики Линукса под ARM руками скомпилировать и собрать в пакет можно практический любой нужный софт). Но 720p и современные GUI-интерфейсы это боль.

Хороший набор для обучения, и даже просто полезного развлечения. Единственно чего бы не советовал это пытаться резко повысить радиус действия передатчика антенной.

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

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

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

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

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

То, что операционка крутится на SSD это однозначно хорошо. Значит одного типичного недостатка точно нет. UPS это вообще без чего нельзя делать, и так же здорово, что вы собираетесь это учесть на практике. Но все прочие мягко говоря спорные решения они никуда не делись.

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

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

К слову радиоканальная система "Стрелец", хоть формально и имеет все сертификаты(да и понадежный в плане ЭМС чем зиг-би), но применяется в требующих реальной надежности системах охранно-пожарной сигнализации весьма ограниченно. Как говорил поэт - опыт сын ошибок трудных.

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

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

Да и в целом архитектура умного дома при которой между компьютером и оконечными устройствами(датчиками и исполнительными механизмами) не предусматривает узлов на микроконтроллерах вряд-ли может считаться надежным решением и в домашней системе автоматизации.

Очередной концепт - "как не надо делать". Тоесть весь этот умный дом с соединением "по воздуху" это во первых одна большая дыра в плане информационной безопасности, а во вторых например Wi-Fi это в первую очередь открытые публичные радиодипазоны, которые хотя бы по факту относительно надежно ваши лишь на уединенной даче, а применяемые в Wi-Fi протоколы передачи данных они отнюдь не под домашнюю лайт-АСУТП оптимизированы. В плане ЭМС bluetooth и zig bee получше Wi-Fi будут(где например в диапазоне 2,5 ГГц лишь 3(три) не мешающих друг другу канала), но все остальные проблемы(вроде сосед врубил микроволновку за стеной, а его сын-школьник балуется вашими девайсами bluetooth и zig bee, причем это еще довольно безобидный сценарий) остаются.

matplotlib мягко говоря заметно лагает при выводе графиков, пока это все для внутренних нужд, оно не принципиально.

Но когда вопрос юзабельности программ более критичен, то разные графики, включая гистограммы, лучше выводить через библиотеку pyqtgraph, тем более что там есть подробный интерактивный сборник примеров функционала библиотеки, который вызывается простым коротким скриптом на python3:

#! /usr/bin/env python3

import pyqtgraph.examples

pyqtgraph.examples.run()

FLASHSIZE=64k

flashwrite:
st-flash --reset --format ihex write {BUILD_DIR}/{TARGET}.hex

flashread:
mkdir -p {BUILD_DIR}  st-flash --format ihex read ${BUILD_DIR}/{TARGET}.hex 0x08000000 ${FLASHSIZE}

erase:
st-flash --reset erase

Про Куб - если Вы результат конструирования начальной инициализации конкретного STM-32 с нужными оптимизациями выведите из него в виде Make-файла, то при наличии в компе компилятора ARM и утилиты st-flash, дописав в конец Make-файла код приводимый ниже(FLASHSIZE=64k поправьте по объему флэша конкретного STM-32), то "make", "make flashwrite", и "make flashread" обеспечат сборку прошивку и вашего Src/main.c, к которому никто без вашего ведома ничего не инклюдил. Очистка флеша - "make erase"

Строго говоря, так и есть. Но сугубо теоретически, если говорить об идеализированной IDE в сферическом ваккуме. Тут же статья о конкретике. А как, правило, "фирменные" IDE для МК созданы, с прибитыми к ним библиотеками даже для ного-дрыга в блинке, так сказать, по "Ява-философии", где добродетель, максимальной переносимости кода с хрустом подминает под себя все прочие добродетели. Что мягко скажем оптимально далеко не всегда, тем более в мире МК, где вы в итоге пишите прошивку под голое железо, где нет даже cin и cout, а есть имена регистров периферии к которым в итоге и напрямую и обращается ваша скомпилированная программа для МК.

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

Вопрос тут вовсе не 'CLI или GUI', а в том, что даже для программ уровня банального блинка "Мега-IDE" вместо нескольких строк на С/С++ по присвоению значений регистрам МК(которые с точки зрения синтаксиса языка служебные перемененные, имена которых указанные в даташите на МК) и чтения, того что там есть, пихают туда под килобайт и более разного кода, просто потому что они устроены по принципу мутного стекла напрочь не способствующего росту понимания про создание прошивок МК без разных эксклюзивных "мега-костылей", заменяющих и прячущих от программиста работу с системными перемененными МК.

Если не затруднит, киньте ссылку где можно найти рабочий релиз локальной GUI mbed ide на основе электрона. Электрон понятно по удобству не Qt, но все равно любопытно попробовать.

Правительство РФ вправе ограничить возможности защиты прав на объекты интеллектуальной собственности, для тех кто отказался от легальных поставок в Россию. Это если без воды про юридический аспект.

Если говорить про Cube-IDE(речь именно о Cube-IDE, а не Cube-МХ, который может выдавать Make-файлы для STM-32), Кейл, и т.п. IDE, то их обхожу стороной, по простой очевидной причине - с одной стороны их, например в отличии от упоминаемого выше Arduino-IDE, нельзя рекомендовать даже начинающим, чтоб снизить порог вхождения в программирование МК на С/С++, а с другой стороны, когда вы выполнили начальное вхождение в тему, регулярное сидение на таких "Мега-IDE"(точно так как и дальнейшее сидение после начального вхождения в Arduino-IDE) сводит Ваш дальнейший профессиональный рост в работе с МК, лишь к навыкам работы в конкретной IDE, а не общего понимания специфики процесса программирования МК как класса железяк.

В статье речь идет о GUI-IDE дающего возможность работать не только из CLI. Mbed CLI — это название инструмента командной строки. Бек-энд описываемого в статье решения, понятно может работать и без GUI, прямо из CLI(Make-файлы к слову можно делать не только написанием/правкой в ручную, но и при желании еще и в GUI-утилите Cube MX). А потому, как ни крути Mbed CLI дает куда больше ограничений.

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

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

Статья с элементами новизны, от первого лица, изложение по существу, без воды. С удовольствием плюсую!

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

12 ...
26

Information

Rating
2,121-st
Registered
Activity