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

Всё ниже описанное является следствием моего личного опыта, и ни на какую истинность не претендует. Все советы рассчитаны не людей только решившихся на переход с AVR на STM32

Вопросы типа почему Linux, VSCode и прочее, думаю, освещения не требуют. Считаю, что все заинтересованные в вопросе, на эти мелочи давно нашли СВОЙ ответ. Однако отмечу, в Винде всё это тоже работает, проверено, и проекты спокойно переживают миграцию между машинами.

Пожалуй начнём!

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

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

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

Введение

Как только сложность программы выходит за пределы "Hello Word!", у начинающих ардуинщиков появляются проблемы. Самая тяжелая из них - удержать в голове структуру программного кода. Нельзя сказать, что у опытных программистов встраиваемых систем этой проблемы нет. Достаточно попытаться реанимировать собственный проект двухлетней давности, если он недостаточно документирован, то включиться в работу будет очень трудно.

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

Все это хорошо, но новичку просто лениво. Зачем что-то рисовать, если того же результата можно добиться несколькими строчками кода? Ответ: макрокоманды. Такие, например, как WAIT(Time,Counter), она позволяет с легкостью организовать временную задержку. И это будет вовсе не Delay(Time) от Arduino, которая остановит выполнение всего остального пользовательского кода. Нет. По предоставляемым возможностям ближайшей аналогией будет RTOS - операционная система реального времени. Если один автомат замер в ожидании отсчета времени, то остальные автоматы проекта будут продолжать работать.

Рассмотрим практическое использование графических конечных автоматов под Arduino на примере часов-метеостанции.

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

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

Поэтому сегодня мы поговорим об установке и использовании графической панели 3X-UI для сервера X-Ray с поддержкой всего того, что умеет X-Ray: Shadowsocks-2022, VLESS с XTLS и т.д.

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

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

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

Эта статья объединяет в себе две: "домашний лабораторный БП" и "источник питания 350Вт на IR2153". Можно считать её продолжением "Нестабилизированный AC/DC источник питания. IR2153".

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

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

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

Простая звуковая карта. Схема, описание...
Сделай сам.

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

Спектр задач по пайке при этом у связистов простирается от антенно-фидерного хозяйства (кабели, разъёмы), через аксессуары (зарядки, гарнитуры) и до ремонта собственно радиоаппаратуры (SMD-компоненты).

В связи с этим я не только провёл краткий ликбез и показал пару табличек, но и хочу написать про это здесь, чтобы потом было удобно давать ссылку :)

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

Можно ли одновременно увеличить дальность связи с беспилотным летательным аппаратом (БЛА) и подавлять помехи без увеличения габаритов, массы и энергопотребления бортового модема? В настоящей статье мы рассмотрим как это можно сделать с помощью адаптивной антенной системы. Статья написана для разработчиков и эксплуатантов БЛА и является продолжением цикла статей автора про связь с БЛА.