Привет, Хабр.

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



Продолжение под катом (осторожно, траффик).

Если кто пропустил первую часть, желательно начать с нее, чтобы лучше понимать о чем речь.

_{Паяльник второй половины XIX века, который нагревался на огне}

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

Всем доброго времени суток!

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

Любому из этих случаев я буду очень рад.

Здравствуйте! Сегодня мы познакомимся с новым семейством дешевых и малопотребляющих ПЛИС от Lattice Semiconductor семейств iCE40LP/HX/LM, научимся работать с фирменным компилятором iCEcube2 и редактором кода Sublime Text 3, а также программировать чип на отладочной плате Lattice iCEstick с помощью прошивки, написанной на SystemVerilog.

Все будет сопровождаться подробными инструкциями и скриншотами.

Советский плакат «Автоматическую систему управления производством — народному хозяйству!», художник Р. Сурьянинов, 1972

«Рассказ о моделировании именно сложных систем»

Предыстория

К одной из моих статей по моделированию «сказочной» предметной области (часть 1, часть 2) был оставлен комментарий, цитирую:

«Было бы здорово увидеть рассказ о моделировании именно сложных систем».

И я пообещала подобрать что-то из реальной жизни.

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

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

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

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

Стало интересно выполнить анализ применимости этих понятий для общепринятых парадигм программирования, например для ООП. Хорошо, если результат этой работы будет полезен и Вам.

Есть проблема с описанием и толкованием принципов развития архитектуры SOLID (авторства Роберта Мартина). Во многих источниках дается их определение и даже примеры их использования. Изучая их и пробуя использованием примерить на себя, стабильно ловил себя на мысли, что не хватает объяснения магии их применения. И пытаясь увидеть внутренние шестеренки, понять — и для меня значит запомнить — разложил их по своим "терминам-полочкам". Хорошо если это будет полезно еще кому-нибудь.

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

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

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

1. Структура и схема.
2. Представление и доступность.
3. Выбор используемых графиков.
4. Усовершенствование контекста.

Часть 1. Структура и схема

Давайте для начала остановимся и зададим себе два вопроса: кто наша целевая аудитория и каковы её цели?

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

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

Осциллографы

Встраиваемые и промышленные системы — моя любимая тема в разработке дизайна. Когда делаешь интерфейс ПО какого-нибудь лазера или яхты — это чистый кайф и творчество.
На прошлой неделе я посетил выставки expoelectronica и embeddedday именно как UI разработчик. Целью было посмотреть на новинки вживую, пощупать, набраться опыта.
В итоге я посмотрел более 100 GUI различных систем, но вот с набором опыта возникли проблемы...

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

Внимание! Много фото!

В интернете, в том числе и на хабре, можно найти много информации про фильтр Калмана. Но тяжело найти легкоперевариваемый вывод самих формул. Без вывода вся эта наука воспринимается как некое шаманство, формулы выглядят как безликий набор символов, а главное, многие простые утверждения, лежащие на поверхности теории, оказываются за пределами понимания. Целью этой статьи будет рассказать об этом фильтре на как можно более доступном языке.
Фильтр Калмана — это мощнейший инструмент фильтрации данных. Основной его принцип состоит в том, что при фильтрации используется информация о физике самого явления. Скажем, если вы фильтруете данные со спидометра машины, то инерционность машины дает вам право воспринимать слишком быстрые скачки скорости как ошибку измерения. Фильтр Калмана интересен тем, что в каком-то смысле, это самый лучший фильтр. Подробнее обсудим ниже, что конкретно означают слова «самый лучший». В конце статьи я покажу, что во многих случаях формулы можно до такой степени упростить, что от них почти ничего и не останется.

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

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

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



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

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

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

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

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

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

Введение

Не так давно мой отдел столкнулся с трудностями поиска новых инженеров программистов для разработки встроенного ПО. Опытным и умным не нравился уровень зарплаты, а молодых просто нет в нашем городе. Поэтому под патронажем нашей доблестной глобальной компании со штаб квартирой где-то в Сент Луисе, мы начали сначала набирать студентов в интернатуру, а потом, решили пойти другим путем и сделать целых два курса по разработке ПО, а уже там самим выбирать самых “толковых” если понадобятся вдруг новые сотрудники. Это намного дешевле и позволяет охватить максимальное количество претендентов.
Немного отступлю от темы, сам я программировал последний раз очень давно, и вообще больше на С#, а последний глобальный проект на микроконтроллере (PIC16 на зыке Си) был сделан в далеком 2007 году.
Поэтому мне предстояло разобраться с современными микроконроллерами, языком С++ и операционной системой реального времени.
Конечно все наши проекты уже сейчас используют ОСРВ и пишутся на С++, но как разработчик я в них не учувствую, а занимаюсь тунеядством управлением проектами разработки такого ПО.

Выбор

Времени у меня на все про все было дано 1 месяц. С начала июня 2015 до начала июля 2015, потому что потом я собирался в отпуск, а после отпуска обычно полно работы. Надо было делать все быстро и четко.
Немного проконсультировавшись с коллегами, выяснил, что модное направление ARM Cortex различные ядра и из доступных отладочных плат можно заказать Olimex STM32P152 которые стоили 25 долларов. Они пришли очень быстро — 6 плат по цене примерно 2000 рублей. Стоит заметить, что эти платы были закуплены нами для университета, где собственно и будет проходить этот курс.

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

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

Привет, Хабр!

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

Отвечаем коротко: да, но нет.

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

Ответ немного длиннее — под катом.