Предисловие

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

Одни считают изобретателем триггера М.А. Бонч-Бруевича, другие — У. Икклза и Ф.У. Джордана. Как бы то ни было, действующие образцы были у всех троих, и в нынешнем году схеме исполнилось сто лет. За прошедшие годы триггеры расплодились в огромных количествах: в одном только устройстве, с которого вы читаете эту статью, их, конечно, уже не ламповых, больше, чем людей на планете. Придуманы разные виды триггеров, отличающиеся количеством и назначением входов и выходов, логикой работы.

Как отметить этот юбилей? Например, воздвигнуть памятник триггеру. Для него не потребуется ни гранит или бронза, ни несколько квадратных метров пространства: он займёт на вашем столе совсем немного места, зато будет действующим. Приобрести пальчиковый двойной триод несложно, а сборка схемы займёт от силы полчаса. Но автор IEEE Spectrum Ричард Брюстер решил немного усложнить поставленную перед собой задачу…

Если Вы читаете эти строки, значит что-то пошло не так… с подключением данного микроконтроллера. Знаю, у меня самого за сутки до написания статьи было так-же, но техноманьяки — народ упоротый упертый

«Проще, чем кажется» — бизнес-роман о том, на что еще способны программисты.

4

— Ты задачу по бухгалтерии сделал? Отчет. Ты обещал сегодня закончить.

— Сегодня и закончу, еще весь день впереди. Не надо из-за этого переживать, Галина.

— О чем ты хотел поговорить?

— О зарплате.

— Ну, говори, я слушаю.

В данной публикации я поделюсь опытом о создании IoT устройства с ноля: от появления идеи и воплощении ее в «железе» до создания микропрограммы для контроллера и web-интерфейса для управления созданным устройством через сеть интернет.

До создания этого устройства я:

• Почти не разбирался схемотехнике. Только на уровне принципов работы
  резистора/транзистора… Я не имел никакого опыта в создании сколь-нибудь сложных схем.
• Никогда не проектировал печатных плат.
• Никогда не паял SMD компонент. Уровень владения паяльником был на уровне припаивания проводов и какого-нибудь реле.
• Никогда не писал таких сложных программ для микроконтроллера. Весь опыт был на уровне «зажги светодиод в Arduino», а контроллер ESP8266 я встретил впервые.
• Совсем немного писал на C++ для «большого брата», но это было более десятка лет назад и все давно забылось.

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

Как говорят специалисты по информационной безопасности «Ломают всё, всех и всегда». При этом, атаки на ASP.NET — вещь достаточно редкая. Поэтому всегда крайне любопытно узнавать про это что-то новое. Под катом рассказ специалиста отдела информационной безопасности Rambler Group Алексея Морозова о сильных и слабых сторонах данной технологии.

Речь пойдёт о таком простом, но часто используемом паттерне как chain of responsibility(цепочка ответственности). Суть паттерна в том, что для обработки какого либо события мы используем несколько обработчиков, каждый из которых принимает решение о том, что и когда передавать следующему. В сети есть масса примеров реализации на C++, но я хочу показать реализацию только на лямдба-выражениях. В этой реализации можно будет посмотреть немного уличной template-magic.

Сегодня мы поговорим о такой актуальной теме, как таймеры и организация многозадачности на Arduino. Поводом для написания этой статьи послужили лекции Олега Артамонова @olartamonov для студентов МИРЭА в рамках IoT Академии Samsung, а точнее, высказывание Олега, цитата (2-я лекция, 1:13:08):

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

Судя по высказываниям Олега, у него весьма превратное представление об Arduino вообще и об «ардуинщиках» в частности. Мигание пятью светодиодами в означенных им режимах это абсолютно тривиальная задача для Arduino, а для Arduino Mega Server это вообще не задача, а сущее недоразумение — его штатными средствами организуется многозадачность, которая легко управляет сотнями различных сущностей (светодиодов, сервоприводов, шаговых моторов и т. д.) в реальном времени.

Давайте вместе разберёмся как организовать многозадачность на Arduino, а заодно поможем студентам МИРЭА избавится от навязанных им стереотипов восприятия по отношению к социо-культурному и технологическому феномену нашего времени под названием Arduino.

Опубликовано 17 мая 2018 года

Сразу после установки улья я подумал: «Интересно, как подсчитать количество прилетающих и улетающих пчёл?»

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

Во-первых, нужно собрать образцы данных. Raspberry Pi, стандартная камера Pi и солнечная панель: этого простого оборудования достаточно, чтобы записывать один кадр каждые 10 секунд и сохранять 5000+ изображений в день (с 6 утра до 9 вечера).

Введение

Для определения баллистико-временных характеристик движения центра масс парашютиста приходится выбирать упрощенную математическую модель, вполне доступную для аналитического исследования и в то же время сохраняющую наиболее характерные черты исходного объекта.

Для построения упрощённых математических моделей движения парашютиста проводится анализ, определение, систематизация постоянных и временных параметров.

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

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

Единым стандартом мог бы стать XMPP, но он, в отличии от E-Mail, появился относительно поздно и не успел набрать достаточную аудиторию, чтобы корпорации не могли уже от него отказаться. Ведь там быстро поняли, что без удержания аудитории внутри собственной экосистемы много не заработать. Да и кроме того, надо признать, у XMPP было достаточно недостатков из-за обилия расширений, многие из которых, несмотря на свою важность, оставались в экспериментальном статусе, а какие-то и вовсе дублировали друг друга.

Пожив в «новом дивном мире» десятка мессенджеров в смартфоне, и ощутив все недостатки такого положения дел, мы наконец готовы к чему-то новому.

И да, нам нужен новый стандарт!

«Цель этого курса — подготовить вас к вашему техническому будущему.»

Привет, Хабр. Помните офигенную статью «Вы и ваша работа» (+219, 2394 в закладки, 386k прочтений)?

Так вот у Хэмминга (да, да, самоконтролирующиеся и самокорректирующиеся коды Хэмминга) есть целая книга, написанная по мотивам его лекций. Мы ее переводим, ведь мужик дело говорит.

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

Мы уже перевели 21 (из 30) главу. И ведем работу над изданием «в бумаге».

Глава 27. Недостоверные данные

(За перевод спасибо Валентину Пинчуку, который откликнулся на мой призыв в «предыдущей главе».) Кто хочет помочь с переводом, версткой и изданием книги — пишите в личку или на почту magisterludi2016@yandex.ru

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

Позвольте мне начать с испытаний на долговечность. Хорошим примером служит мой опыт, участия в испытаниях жизненного цикла вакуумных труб. Они предназначались к использованию в первых подводных кабелях для передачи голоса с ожидаемым сроком службы 20 лет (после 22 лет мы просто вывели кабель из эксплуатации, которая стала слишком затратной – и это дает хорошее представление о скорости технического прогресса в те дни).

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

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

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

Вторая часть цикла «Заметки IoT-провайдера». Начало можете найти тут.

Итак, мы решили строить сеть.

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

Несколько месяцев назад на хабре появилась статья «Реализация многоуровневого меню для Arduino с дисплеем». «Но, погодите, — подумал я. — Я написал такое меню еще шесть лет назад»!

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

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

Хочу рассказать и показать результаты проекта, который развивается примерно 10 лет. Развивается как хобби, поэтому бывает, что за неделю делается новое устройство, а потом за полгода – не делается ничего. Я очень не люблю словосочетание «Умный дом», поэтому дальше оно не встретится. Также тут не будет схем, примеров кода, опутанных проводами макетных плат и прочих скучных вещей. Будет много фото и рассуждений на общие темы.

или как рассогласованные линии портят ваш сигнал

На форуме Dangerous Prototypes я однажды принял участие в одном обсуждении, посвященном проблемам с шиной SPI, кторая переставала нормально работать, начиная с некоторой длины. Мой опыт подсказывал мне две вещи: 1) проверить источник питания, 2) проверить линию на наличие отражений. Тогда я понял, что это должно быть общей проблемой для всех радиолюбителей. Линии передачи данных — сложная тема, и настало время снять покров таинственности с этой электронной магии.

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


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

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

Имеется 2 или более устройств на достаточно большом (1-100 метров) расстоянии, между которыми надо передавать данные. Рассмотрев некоторые интерфейсы (rs232/422/485, I2C, Ethernet) пришел к выводу — что они либо не гарантируют однозначную передачу данных, много проводов тоже мне не понравилось, не дают ответ что информация принята. За основу решил взять интерфейс RS485 — из его плюсов он может «далеко идти», 2 провода, можно одновременно подключить кучу приборов, прост, (UART) есть почти на любом контроллере.

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


Один цикл обмена.

Продолжаю цикл статей про опыт IoT-провайдинга на основе сети LoRa. Начало тут и тут.

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

Получилось как всегда: одного боялись, про другое даже не думали. В итоге первое обошлось, а второе создало кучу проблем.
Больше всего мы боялись, что в реальных условиях сеть начнет работать как-то иначе, чем на тестах. Когда первый абонент показал нам 40 подвалов, в которых стояли около 50 водосчетчиков, стало действительно волнительно. Подвалы – это обычные подвалы 5- и 9-этажных домов. С крошечными зарешеченными оконцами, сырые, с крысами и кошками.

Однако, после размещения всех радиомодулей оказалось, что боялись зря. Сеть отрабатывала без проблем, мы получили устойчивое покрытие в радиусе двух километров от базовых станций. Конечно, кое-что пришлось оптимизировать, но по мелочи. Именно с радиопокрытием проблем не возникло.

А вот сами счетчики нас удивили. В ЖКХ мы встретили зоопарк, а внутри документации – бардак.