Мы предлагаем вашему вниманию статью Владислава Зайцева (vvzvlad), приглашенного гостя нашего блога. Владислав давно занимается темой «умных домов», и обобщив свой опыт, он предлагает следующие основные принципы дизайна такого рода систем.

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



Продолжая читать статью, вы соглашаетесь с тем, что вас устраивает следующий disclaimer.

---

Умный дом — это система, которая берёт на себя часть повседневных забот человека. Отсюда следует первый и самый основной принцип:

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

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

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

Виртуальная машина, байт-код и компилятор прилагаются бесплатно!

Адаптировано из нашей будущей книги «Рефакторинг UI»

Видели эти модные генераторы цветовой палитры? Когда выбираешь цвет, настраиваешь несколько параметров с музыкальными словечками типа «триада» или «четвёртый мажор» — и получаете пять идеальных цветов для своего веб-сайта?



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

"No matter how hard you try, you can't make a racehorse out of a pig. You can, however, make a faster pig" (комментарий в исходном коде Емакса)

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

Во второй части серии статей об интерпретаторах байт-кодов я на примере небольшой стековой виртуальной машины ПВМ («Поросячья Виртуальная Машина») постараюсь показать, что не всё потеряно для трудолюбивых поросят с амбициями и что в рамках (в основном) стандартного C вполне возможно ускорить работу таких интерпретаторов по меньшей мере в полтора раза.

Технологичное проектирование

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

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

• Кто задумывается о производстве электроники? Объясним, почему практически все игроки рынка электроники учитывают в своей работе производственные вопросы: и стартапы, и зрелые компании.
• Из каких этапов состоит процесс коммерческого производства? Разберемся, какой объем работ предстоит в рамках проекта. Кратко и по пунктам.
• Кто участвует в производственных проектах? Перечислим компании, которые нужны для организации производства.

Нечеткая логика для управления

Текст подготовлен на основе материалов книги Гостева В.В. «Нечеткие регуляторы в системах автоматического моделирования». Как все серьезные публикации по теме, данная книга перегружена математическими выкладками и тяжела для неподготовленного читателя. Между тем, сами по себе принципы создания и использования нечеткой логики достаточно просты и наглядны. Данный текст – попытка перевести пример из книги с математического языка на инженерный.
Показана возможную последовательность проектирования регулятора на базе нечеткой логики, путем последовательного усложнения логических правил и подбором параметров методами оптимизации.

Постановка задачи

Рассмотрим синтез цифрового ПИД-регулятора и нечеткого регулятора для системы управления ракетой по углу атаки. Методом математического моделирования определим процессы в системе и дадим сравнительную оценку качества системы при использовании синтезированных регуляторов.

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

Я провёл испытания шести таких светильников пяти производителей.

Создание электрических схем и трассировка печатных плат становятся всё более простыми делами. Производители компонентов интегрируют в изделия всё больше функционала, выкладывают готовые модели, условные графические обозначения (УГО) и целые схемы, сайты автоматически генерируют источники питания, фильтры и многое другое. Тем не менее, даже при проектировании простых печатных узлов обнаруживаются ошибки, часто — глупые и очевидные.

Мы с большим любопытством заглянули в R&D-отдел наших давних партнеров — компании Стриж, которая сама разрабатывает и производит в России базовые станции, конечные устройства IoT, протоколы передачи и ПО. Большая часть наших вопросов касалась организации процесса разработки и трудностей, с которыми они сталкивались.

Приветствуем!

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

Наша Wi-Fi розетка

Часть 1
Часть 2
Часть 3

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

Мне нравится называть это «Почему неопределённое поведение часто пугает и ужасает программистов на C».

Часть 1
Часть 2
Часть 3

Люди иногда спрашивают, почему код, скомпиливанный в LLVM иногда генерирует сигналы SIGTRAP, когда оптимизация была включена. Покопавшись, они обнаруживают, что Clang сгенерировал инструкцию «ud2» (подразумевается код X86) — то же, что генерируется __builtin_trap(). В этой статье рассматривается несколько вопросов, касающихся неопределённого поведения кода на C и того, как LLVM его обрабатывает.


В этой статье (первой из трёх) мы попытаемся объяснить некоторые из этих вопросов, чтобы вы могли лучше понять связанные с ними компромиссы и сложности, и возможно, изучить немного больше тёмные стороны С. Мы выясним, что C не является «высокоуровневым ассемблером», как многие опытные программисты на C (особенно те, кто сфокусирован на низком уровне) предпочитают думать, и что C++ и Objective-C напрямую унаследовали множество таких проблем.

Доброго времени суток, друзья.

Мы ведем разработки в области IoT-решений, производим инновационные продукты, постоянно мониторим мировой и российский рынки IoT, отслеживаем последние тенденции и разработки.

Мы уже писали в предыдущей статье о том, как создавался Центр управления — мозг нашего умного дома. В этой статье мы хотим рассказать вам об одной из наших последних разработок — умной Wi-Fi розетке, поэтапно разобрав этапы создания: от идеи до разработки и запуска.

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

Добрый день!

Потоки… Переключение контекстов… Базовая сущность ОС. И конечно, при разработке библиотек и приложений мы всегда полагаемся на то, что реализация потоков безошибочна. Поэтому было неожиданно найти грубую ошибку в переключении потоков для STM32 на ОСРВ Embox, когда уже продолжительное время работали и сеть, и файловая система и многие сторонние библиотеки. И мы даже успели похвастаться о своих достижениях на Хабре.

Я бы хотел рассказать про то, как мы делали переключение потоков для Cortex-M, и тестировали на STM32. Кроме того, постараюсь рассказать о том как это сделано в других ОС — NuttX и FreeRTOS.

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

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

Начало двухтысячных — бурное развитие телекоммуникационных сетей. Монтажники, сутки напролет проводившие на крышах, прокладывая кабель до конечного абонента, остро нуждались в устройствах для проверки соответствия кабеля подключенному порту. Остро стояла и проблема “зависания” оборудования. Монтажникам приходилось постоянно курсировать между узлами связи и перезагружать их вручную. Так возникла идея разработки первого SNR-ERD.

Пост посвящен датчику скорости потока Out Of Liquid — термоанемометру для измерения расхода жидких сред. Под катом читатель найдет описание принципа работы датчика, а также видео, на котором этот принцип наглядно демонстрируется.



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

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