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

Появилась идея в домашнем проекте попробовать использовать сопрограммы из С++20 на маленькой железке. В качестве модуля для экспериментов был выбран E73 NRF52832. Из инструментария, который использовался в процессе разработки- arm-gcc-gnu-none-eabi 10.2, MSVC для проверки идей и прогона тестов на Windows-платформе. Изначально было в планах продемонстрировать на чем-то концепцию и как именно их можно было применять. Была идея адаптирования примера в виде мигания светодиодом, но он был слишком простой. Необходимо было придумать что-то более сложное и более полезное, что ли. Таким образом появилась идея переписать драйвер дисплея и пары фрагментов SPI-FLASH в проекте-долгострое.

В этой статье мы попробуем разобраться с одним из самых неоднозначных и непонятных нововведений стандарта C++17 — функцией стандартной библиотеки std::launder. Мы посмотрим на std::launder с другой стороны, посмотрим на источник. Разберем что лежит в основе функции на примере решения задачи девиртуализации и реализации виртуальных указателей в LLVM.

Недавно приобрел я себе на Алиэкспресс векторный анализатор цепей портативный S-A-A-2 NanoVNA-F V2, тестер HF VHF [1]. Разработан этот прибор в Китае – ссылка на разработчика и описание прибора [2]. Инструкция (англ. язык) [3]. И еще одна инструкция [4].

Прибор удобен своей портативностью и возможностью измерять параметры цепей в диапазоне частот от 50 кГц до 3 ГГц, в частности S11 и S21. Удобство состоит еще в том, что прибор можно подключить к компьютеру (ноутбуку, планшету) по USB и на компьютере произвести анализ полученных измерений. Обнаружил, что в районе выключателя питания можно увидеть зеленый светодиод внутри корпуса, не выведенный наружу, он свечением индицирует режим измерения, отсутствие свечения режим индикации, при отсутствии качания частоты светодиод погашен.

Для начала мной были проведены измерения КСВ всех имеющихся у меня в наличии проволочных антенн. Результаты обнадежили.

После, я обнаружил в конце инструкции, что этим прибором можно управлять по виртуальному COM порту, подключив к компьютеру через USB type3 кабель (из комплекта) и используя любую терминальную программу со стандартными настройками и скоростью обмена 115200. Параметры подключения port='COM3' (у меня так определился в компьютере), baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=0.05, xonxoff=False, rtscts=False, dsrdtr=False.

Система команд прибора приведена в таблице 1. Результаты получены экспериментально, путем анализа описаний других аналогичных приборов [5] на приборе с указанной прошивкой при помощи бесплатной терминальной программы YAT – [6].

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

Продвигаясь в изучении программирования микроконтроллеров, я осознал необходимость освоить USB, поскольку это, бесспорно, основной интерфейс НЕ-внутрисхемного подключения устройств. Однако оказалось, что соответствующих материалов в открытом мире немного. Попробуем разобраться?

Я продолжаю изучать CAN шину авто. В предыдущих статьях я голосом открывал окна в машине и собирал виртуальную панель приборов на RPi. Теперь я разрабатываю мобильное приложение VAG Virtual Cockpit, которое должно полностью заменить приборную панель любой модели VW/Audi/Skoda/Seat. Работает оно так: телефон подключается к ELM327 адаптеру по Wi-Fi или Bluetooth и отправляет диагностические запросы в CAN шину, в ответ получает информацию о датчиках.

По ходу разработки мобильного приложения пришлось узнать, что разные электронные блоки управления (двигателя, трансмиссии, приборной панели и др.) подключенные к CAN шине могут использовать разные протоколы для диагностики, а именно UDS и KWP2000 в обертке из VW Transport Protocol 2.0.

Предисловие

Как простыми средствами прочитать защищенную прошивку из микроконтроллеров PIC18, что для этого нужно. И как избежать "недозащиты" результатов разработки (только для PIC18).

Вы когда-нибудь задумывались, как много вокруг умной электроники? Куда ни глянь, натыкаешься на устройство, в котором есть микроконтроллер с собственной прошивкой. Фотоаппарат, микроволновка, фонарик... Да даже некоторые USB Type C кабели имеют прошивку! И всё это в теории можно перепрограммировать, переделать, доработать. Вот только как это сделать без документации и исходников? Конечно же реверс-инжинирингом! А давайте-ка подробно разберём этот самый процесс реверса, от самой идеи до конечного результата, на каком-нибудь небольшом, но интересном примере!

Много ли нужно, чтобы изменить пробег или залезть в память приборной панели?

Есть только один способ узнать — попробовать сделать это самому.

С удовольствием и даже гордостью публикуем эту статью. Во-первых, потому что автор — участница нашей программы Summ3r of h4ck, Nalen98. А во-вторых, потому что это исследовательская работа с продолжением, что вдвойне интереснее. Ссылка на первую часть.

Добрый день!

Прошлогодняя стажировка в Digital Security не оставила меня равнодушной к компании и новым исследованиям, так что в этом году я взялась поработать над проектом так же охотно. Темой летней стажировки «Summer of Hack 2020» для меня стала «Символьное исполнение в Ghidra». Нужно было изучить существующие движки символьного исполнения, выбрать один из них и реализовать его в интерфейсе Ghidra. Казалось бы, зачем, ведь в основном движки представляют собой самостоятельные решения? Этот вопрос будет возникать до тех пор, пока не попробовать то, что автоматизирует действия и сделает их наглядными. Это и стало целью разработки.

Статья в какой-то степени является еще и продолжением статьи моего наставника, Андрея Акимова, о решении Kao’s Toy Project с Triton. Только сейчас нам не придется писать ни строчки кода – решить крякми можно будет практически двумя кликами.

Итак, начнем по порядку.

Лет десять назад как-то по случаю я купил простенькую погодную станцию Oregon Scientific BAR208HG. Радовала она домочадцев достаточно долго, и продолжает радовать до сих пор. Мне же со временем стало не хватать её функционала и захотелось расширить свои возможности наблюдения за погодой. И тут выяснился один неприятный факт — покупка продвинутой метеостанции от того же Oregon Scientific не давала возможности транслировать показания с её датчиков на старую станцию. Не совпадала версия протокола передачи данных. Примерно в это же время я был вовлечён в такую увлекательную авантюру, как передачу метеоданных на сервис небезызвестного Народного мониторинга. Уже на тот момент сети имелось достаточно много информации о самих погодных станциях и датчиках Oregon, о протоколе передачи данных и методах их расшифровки. Я легко нашёл и несколько готовых программ и библиотек Arduino для приёма и расшифровки сигнала. Вся эта информация показалась мне недостаточно систематизирована, местами неточна, а программы давали удовлетворительный результат только на очень коротких расстояниях. В конечном итоге я пришёл к старой истине: "Хочешь сделать что-то хорошо — сделай сам". Результатом последующих изысканий стало написание вот этой заметки, в которой хотелось бы поделиться полученными знаниями и умениями.

https://www.youtube.com/playlist?list=PLwr8DnSlIMg0KABru36pg4CvbfkhBofAi

Как-то на Хабре мне попалась довольно любопытная статья “Научно-технические мифы, часть 1. Почему летают самолёты?”. Статья довольно подробно описывает, какие проблемы возникают при попытке объяснить подъёмную силу крыльев через закон Бернулли или модель подъёмной силы Ньютона (Newtonian lift). И хотя статья предлагает другие объяснения, мне бы всё же хотелось остановиться на модели Ньютона подробнее. Да, модель Ньютона не полна и имеет допущения, но она даёт более точное и интуитивное описание явлений, чем закон Бернулли.

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

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

Перед тем как мы начнём, я бы хотел сразу обозначить, что это статься не о физике самой модели. Эта статья о GPGPU-программировании. Мы не будем рассматривать физические свойства самой модели, потому что она груба и не подходит для настоящих расчётов. И всё же, эта неточная модель даёт куда более интуитивное описание явления подъёмной силы, чем закон Бернулли.

Для написания эффективных и корректных многопоточных приложений очень важно знать какие существуют механизмы синхронизации памяти между потоками исполнения, какие гарантии предоставляют элементы многопоточного программирования, такие как мьютекс, join потока и другие. Особенно это касается модели памяти C++, которая была создана сложной таковой, чтобы обеспечивать оптимальный многопоточный код под множество архитектур процессоров. Кстати, язык программирования Rust, будучи построенным на LLVM, использует модель памяти такую же, как в C++. Поэтому материал в этой статье будет полезен программистам на обоих языках. Но все примеры будут на языке C++. Я буду рассказывать про std::atomic, std::memory_order и на каких трех слонах стоят атомики.