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

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

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

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

Ну, если под любимым языком подразумевается русский, английский и т. д., то это в другой хаб. А если язык программирования или разметки, то конечно писать анализатор самим! На первый взгляд, это очень сложно, но, к счастью, существуют готовые многоязыковые инструменты, в которые относительно легко добавить поддержку нового языка. Сегодня я покажу, как можно с достаточно незначительными затратами времени добавить поддержку языка Modelica в анализатор PMD.

Кстати, знаете, что может ухудшить качество кодовой базы, полученной из последовательности идеальных pull request-ов? Тот факт, что сторонние программисты копировали в свои патчи куски существующего кода проекта вместо грамотного абстрагирования. Согласитесь, в какой-то мере такую банальность отловить ещё сложнее, чем некачественный код — он же качественный и даже уже тщательно отлаженный, поэтому тут недостаточно локальной проверки, нужно держать в голове всю кодовую базу, а человеку это непросто… Так вот: если на добавление полной поддержки Modelica (без создания конкретных правил) до состояния «может запускать примитивные проверки» у меня ушло около недели, то поддержку только copy-paste detector часто можно вообще добавить за день!

Все началось, казалось бы, с простого вопроса, который сначала ввел меня в ступор — "Зачем нужен make? Почему нельзя обойтись bash скриптами?". И я подумал — Действительно, зачем нужен make? (и самое важное) Какие проблемы он решает?

Warning

Информация в статье устарела, Flipper Zero был полностью пеработан на другой платформе. Актуальная информация в нашем блоге blog.flipperzero.one

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

Он будет уметь:

• Работать в диапазоне 433 MHz — для исследования радиопультов, датчиков, электронных замков и реле.
• NFC — читать/записывать и эмулировать карты ISO-14443.
• 125 kHz RFID — читать/записывать и эмулировать низкочастотные карты.
• iButton ключи — читать/записывать и эмулировать контактные ключи, работающие по протоколу 1-Wire.
• Wi-Fi — для проверки защищенности беспроводных сетей. Адаптер поддерживает инъекции пакетов и мониторный режим.
• Bluetooth — поддерживается пакет bluez для Linux
• Режим Bad USB — может подключаться как USB-slave и эмулировать клавиатуру, ethernet-адаптер и другие устройства, для инъекции кода или сетевого пентеста.
• Тамагочи! — микроконтроллер с низким энергопотреблением работает, когда основная система выключена.

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

AVR

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

_{Рис. взят с сайта www.extremetech.com/wp-content/uploads/2016/07/MegaProcessor-Feature.jpg}

Всем доброго здравия!

В прошлой статье я рассмотрел вопрос о проблеме доступа к регистрам микроконтроллера с ядром CortexM на языке С++ и показал простые варианты решения части проблем.

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

Всех кого заинтересовал, добро пожаловать под кат. Кода будет много.

Необходимое вступление

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

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

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

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

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

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

В данной работе примеры приведены на языке програмиирования C.

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

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

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

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

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

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

Всем привет! Мы — студия разработки Banzai Games. Рады наконец открыть здесь свой блог. Будем писать о наших технологиях, проектах и делиться историями из жизни компании. Первый материал — перевод интервью с основателем студии Евгением Дябиным, которое он дал коллегам из издания 80lv. В нем он рассказал о нашей программе для создания physics-based анимации Cascadeur и ее преимуществах перед mocap-анимацией.

Применение фотоэлектронного умножителя — это очень простой способ получить высочайшую чувствительность фотоприемника, вплоть до регистрации единичных фотонов при прекрасном быстродействии. А учитывая массу ФЭУ, выпущенных в СССР и до сих пор лежащих на складах, это еще и относительно недорого (современные «фирменные» ФЭУ все-таки неприлично дороги для любительского применения). Но для питания фотоэлектронного умножителя нужен источник напряжения в 1-3 киловольта, и притом очень стабильный.

Дело в том, что чувствительность ФЭУ зависит от анодного напряжения экспоненциально и очень резко: она увеличивается в 10 раз при увеличении напряжения на 80-300 В, в зависимости от типа ФЭУ. И если нужно обеспечить стабильность усиления на уровне процента, для некоторых ФЭУ необходимо, чтобы напряжение не менялось больше, чем на 0,1-0,3 В!

В данной статье я привожу схему источника высокого напряжения для ФЭУ, который хорошо зарекомендовал себя в лабораторных условиях. Он обеспечивает выходное напряжение от нескольких сотен до 1500 В при выходном токе до 1 мА и стабильности не хуже 0,2 В за час при неизменном потребляемом токе после прогрева. Несложная переделка увеличивает верхний предел напряжения до 3 кВ, правда, ценой меньшей стабильности.

Развивая тему конспектов по магистерской специальности "Communication and Signal Processing" (TU Ilmenau), продолжить хотелось бы одной из основных тем курса "Adaptive and Array Signal Processing". А именно основами адаптивной фильтрации.

Для кого в первую очередь была написана эта статья:

1) для студенческой братии родной специальности;
2) для преподавателей, которые готовят практические семинары, но ещё не определились с инструментарием — ниже будут примеры на python и Matlab/Octave;
3) для всех, кто интересуется темой фильтрации.

Что можно найти под катом:

1) сведения из теории, которые я постарался оформить максимально сжато, но, как мне кажется, информативно;
2) примеры применения фильтров: в частности, в рамках эквалайзера для антенной решетки;
3) ссылки на базисную литературу и открытые библиотеки (на python), которые могут быть полезны для исследований.

В общем, добро пожаловать и давайте разбирать всё по пунктам.

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

Не буду лукавить: основная задача статьи — возбудить интерес. Так что в ней будет минимум пространных рассуждений и максимум конкретики.

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

В конечном итоге, как мне показалось, нет лучше способа разобраться, чем просто взять и создать свой маленький проект.

В статье показано, как создать нерекурсивную zip-бомбу, которая обеспечивает высокую степень сжатия путём перекрытия файлов внутри zip-контейнера. «Нерекурсивная» означает, что она не зависит от рекурсивной распаковки декомпрессорами файлов, вложенных в zip-архивы: здесь всего один раунд. Выходной размер увеличивается квадратично от входного, достигая степени сжатия более 28 миллионов (10 МБ → 281 ТБ) в пределах формата zip. Ещё большее расширение возможно с помощью 64-разрядных расширений. Конструкция использует только наиболее распространённый алгоритм сжатия DEFLATE и совместима с большинством парсеров zip.

• zbsm.zip 42 kB → 5.5 GB
  
• zblg.zip 10 MB → 281 TB
  
• zbxl.zip 46 MB → 4.5 PB (Zip64, менее совместима с парсерами)

Исходный код:

git clone https://www.bamsoftware.com/git/zipbomb.git

zipbomb-20190702.zip

Данные и исходники иллюстраций:

git clone https://www.bamsoftware.com/git/zipbomb-paper.git

В данной статье будет подробно рассмотрен алгоритм блочного шифрования, определенный в ГОСТ Р 34.12-2015 как «Кузнечик». На чем он основывается, какова математика блочных криптоалгоритмов, а так же как реализуется данный алгоритм в java.

Кто, как, когда и зачем разработал данный алгоритм останется за рамками статьи, так как в данном случае нас это мало интересует, разве что:

КУЗНЕЧИК = КУЗнецов, НЕЧаев И Компания.



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

О статье

Этот пост — небольшая заметка, предназначенная для программистов, которым хочется больше узнать о том, как GPU обрабатывает ветвление. Можно считать её введением в эту тему. Рекомендую для начала просмотреть [1], [2] и [8], чтобы получить представление о том, как в общем виде выглядит модель выполнения GPU, потому что мы будем рассматривать только одну отдельную деталь. Для любопытных читателей в конце поста есть все ссылки. Если найдёте ошибки, то свяжитесь со мной.

Содержание

• О статье
• Содержание
• Словарь
• Чем ядро GPU отличается от ядра ЦП?
• Что такое согласованность/расхождение?
• Примеры обработки маски выполнения
  • Выдуманная ISA
  • AMD GCN ISA
  • AVX512
• Как бороться с расхождением?
• Ссылки

Введение

Внимание, это не очередная «Hello world»статья о том как помигать светодиодом или попасть в свое первое прерывание на STM32. Однако, я постарался дать исчерпывающие объяснения по всем затрагиваемым вопросам, поэтому статья будет полезна не только многим профессиональным и мечтающим стать таковыми разработчикам (как я надеюсь), но и начинающим программистам микроконтроллеров, так как тема эта почему-то обходится стороной на бесчисленных сайтах/блогах «учителей программирования МК».

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

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

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

Почему?

Потому, что у любого инженера — как и у программиста, врача, юриста и вообще любого профессионала — есть базовая методология работы, без соблюдения которой деятельность из профессиональной превращается в бессистемные метания. Точнее, даже не методология — к методологии мы можем отнести аджайл, ТРИЗ и вот это вот всё, оно у каждого своё — а грубая стратегия, которую можно записать в несколько шагов.

Итак, что же это применительно к электронике?