‍C++20 в bare-metal программировании, работа с регистрами микроконтроллеров Cortex-M

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

Кто-то может подумать, что данная тема уже рассказана вдоль и поперек в многочисленных мануалах по проектам для STM32 (например, хабр). Те же, кто уже понял о чем будет идти речь, может подумать что это полное повторение уже существующих подобных идей (например эта и другие статьи автора зародили во мне интерес к этой теме несколько лет назад, а вот в языке программирования Rust большинство ящиков/крейтов Cortex-M/PAC уже используют проверками безопасности при манипулировании регистрами). Однако, не нужно спешить с выводами. Я полагаю, что могу дать интересную и полезную информацию для обоих вышеперечисленных категорий читателей.

Перед началом, тему того 'Зачем вообще лезть на уровень регистров, если каждый производитель дает HAL/BSP?' я оставлю вне рамок данной статьи. Я предполагаю, что если читатель открыл статью, то ему уже интересна данная тема, и мне не столь важно почему.

https://habr.com/ru/articles/819499/

📲 Мы в MAX

👉 @Bookflow

RustDesk

Клиентское программное обеспечение для удаленного рабочего стола с открытым исходным кодом, написанное на Rust.

Работает "из коробки", настройка не требуется. Отличная альтернатива TeamViewer и AnyDesk! Вы полностью контролируете свои данные, не беспокоясь о безопасности.

Вы можете использовать сервер разработчика или настроить свой собственный сервер или написать свой собственный сервер для рандеву/ретрансляции

https://github.com/rustdesk/rustdesk

📲 Мы в MAX

👉 @Bookflow

Если на каждой ноде Kubernetes кластера нужно запустить контейнер, то какой ресурс Kubernetes вам подойдет?

DaemonSet является контроллером, основным назначением которого является запуск подов на всех нодах кластера. Если нода добавляется/удаляется — DaemonSet автоматически добавит/удалит под на этой ноде.

DaemonSet подходят для запуска приложений, которые должны работать на всех нодах, например — екпортёры мониторинга, сбор логов и так далее.

📲 Мы в MAX

👉 @Bookflow

Joshuto

ranger-подобный терминальный файловый менеджер, написанный на Rust

https://github.com/kamiyaa/joshuto

📲 Мы в MAX

👉 @Bookflow

Совет по чистому коду в Python

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

📲 Мы в MAX

👉 @Bookflow

Челлендж по обработке миллиарда строк на Go: от 1 минуты 45 секунд до 4 секунд

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

Я немного опоздал, соревнования проводились в январе. И на Java. Меня не особо интересует Java, зато давно интересует оптимизация кода на Go.

Этот челлендж был очень прост: обработать текстовый файл названий метеорологических станций и температур, и для каждой станции вывести минимальное, среднее и максимальное значение. Чтобы упростить задачу, было ещё несколько ограничений, однако я проигнорировал те, что относятся только к Java.

https://habr.com/ru/articles/798215/

📲 Мы в MAX

👉 @Bookflow

Ни одна реализация элементарных функций не соответствует стандарту IEEE 754

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

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

Моя работа в течение последнего года заключалась в анализе погрешности различных математических функций, накопления этой погрешности и способов её уменьшения при помощи различных программных паттернов. Одной из исследованных мной тем были базовые математические функции, используемые в функциях активации нейронных сетей, а также способы их аппроксимации для повышения производительности. В процессе работы нам пришлось столкнуться с противодействием со стороны людей, активно стремящихся к корректной реализации математических функций и к соответствию их стандартам, в частности, к соблюдению обеспечения корректности одной наименее значимой единицы измерения (unit in last place, ULP) для элементарных функций.

https://habr.com/ru/companies/ruvds/articles/881698/

📲 Мы в MAX

👉 @Bookflow

std::exception — это базовый класс для всех стандартных исключений в C++

Почему стоит наследоваться от std::exception?

• Единообразие в обработке исключений: Когда вы наследуетесь от std::exception, ваш класс исключения приобретает интерфейс, который делает его совместимым с другими стандартными исключениями

• what() метод: std::exception предоставляет важный метод what(), который возвращает строковое представление исключения. Это позволяет вам предоставлять информативные сообщения об ошибке при обработке исключений

• Легкость в поддержке кода: Если вы используете сторонние библиотеки или фреймворки, они также могут ожидать обработку исключений, производных от std::exception

• Стандартные типы исключений: std::exception имеет несколько стандартных подклассов, таких как std::runtime_error, std::logic_error и другие. Вы можете использовать эти подклассы вместо базового std::exception, чтобы более точно определить характер ошибки

📲 Мы в MAX

👉 @Bookflow

Облачные базы данных: Шпаргалка

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

Структурированные базы данных📌

Структурированные базы данных организуют данные в предопределенные схемы и модели.

Реляционные базы данных, такие как MySQL и PostgreSQL, хранят данные в таблицах со строками и столбцами.

Колоночные базы данных, такие как Amazon Redshift и Google BigQuery, также имеют структурированную модель данных, но хранят их по-другому, оптимизируя для аналитических запросов.

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

Примеры использования: CRM-системы, управление запасами, бухгалтерский учет, аналитика


Полуструктурированные базы данных📌

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

Примеры включают в себя документ-базы данных, такие как MongoDB, графовые базы данных, наподобие Neptune, широкие колоночные хранилища, такие как ScyllaDB, и хранилища ключ-значение, такие как DynamoDB.

Преимущества:
- Гибкость для изменяющихся данных
- Масштабируемость на разных серверах

Примеры использования: Электронная коммерция, ленты социальных сетей, данные IoT


Неструктурированные базы данных📌

Неструктурированные базы данных оптимизированы для хранения и обработки огромных объемов разнородных данных, таких как документы, изображения, видео. Примеры: AWS S3, Azure Blob Storage.

Преимущества:
- Хранение огромных объемов данных
- Высокая масштабируемость

Примеры использования: Медиарепозитории, управление контентом, океаны данных, журнальные данные, резервное копирование.

📲 Мы в MAX

👉 @Bookflow

DBDiagram

Бесплатный, простой инструмент для построения ER-диаграмм путем простого написания кода.
Предназначен для разработчиков и аналитиков данных.

https://dbdiagram.io/home

📲 Мы в MAX

👉 @Bookflow

💡7 обязательных стратегий для масштабирования вашей базы данных.

1 - Индексация:
Проверьте шаблоны запросов вашего приложения и создайте подходящие индексы.

2 - Материализованные представления:
Предварительно вычислите результаты сложных запросов и сохраните их для быстрого доступа.

3 - Денормализация:
Уменьшите количество сложных соединений (join), чтобы улучшить производительность запросов.

4 - Вертикальное масштабирование:
Увеличьте мощность вашего сервера базы данных, добавив больше ЦП, оперативной памяти или хранилища.

5 - Кэширование:
Сохраните часто запрашиваемые данные в более быстром слое хранения, чтобы снизить нагрузку на базу данных.

6 - Репликация:
Создайте реплики вашей основной базы данных на разных серверах для масштабирования чтений.

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

📲 Мы в MAX

👉 @Bookflow

FTXUI

Простая кроссплатформенная библиотека C++ для пользовательских интерфейсов на базе терминала!

• Функциональный стиль
• Простой и элегантный синтаксис
• Создаваемые консольные UI поддерживают навигацию с помощью клавиатуры и мыши
• Поддержка UTF8
• Поддержка анимации
• Поддержка рисования
• Нет зависимостей
• Кроссплатформенность: Linux/MacOS, WebAssembly, Windows

https://github.com/ArthurSonzogni/FTXUI

📲 Мы в MAX

👉 @Bookflow

Как выполнять периодические обновления данных в PostgreSQL?

Для выполнения периодических обновлений данных в PostgreSQL можно использовать несколько подходов, в зависимости от требований к частоте обновлений и архитектуры системы. Вот основные методы:


1. CRON и SQL скрипты
- CRON (или аналогичный планировщик задач) — это системный планировщик задач, который может запускать SQL-скрипты в определенное время или с определенной периодичностью.
- Вы создаете SQL-скрипт, который выполняет необходимые обновления данных, и настраиваете CRON для его запуска.
- Пример команды в CRON:

     * * * * * psql -U user -d database -c "CALL your_update_function();"
     

Этот пример выполняет задачу каждую минуту.

2. pg_cron
- pg_cron — это расширение для PostgreSQL, которое позволяет планировать задания непосредственно из базы данных, используя SQL-синтаксис для задания расписания.
- Пример:

     SELECT cron.schedule('0 * * * *', $$CALL your_update_function();$$);
     

Это задание выполняет функцию каждый час.

3. pgAgent
- pgAgent — это более сложный планировщик задач, который интегрируется с PostgreSQL. Он позволяет создавать и управлять заданиями через интерфейс PgAdmin или SQL-команды.
- Пример задания:

     CREATE JOB update_job
     STEP 1
     WHEN '0 * * * *'
     EXECUTE PROCEDURE your_update_function();
     

4. Встроенные средства PostgreSQL
- Если задача достаточно простая, и вы хотите обойтись без внешних инструментов, можно использовать механизм LISTEN/NOTIFY или bgworker (бэкграундные воркеры).
- LISTEN/NOTIFY: используется для уведомления процессов о событиях в базе данных. Рабочие процессы могут запускаться при получении уведомления.
- bgworker: позволяет создавать фоновый процесс, который будет периодически выполнять необходимые задачи.

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

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

7. Materialized Views
- Если вам нужно обновлять агрегированные или сложные запросы, можно использовать материализованные представления с автоматическим обновлением.
- Вы можете создать материализованное представление и настроить его автоматическое обновление через CRON или pg_cron:

     REFRESH MATERIALIZED VIEW CONCURRENTLY your_view;
     

Заключение
Выбор метода зависит от конкретных требований и доступных инструментов. Если вам нужно периодически выполнять задачи непосредственно в базе данных и с минимальными усилиями, pg_cron и pgAgent — отличные варианты. Если хотите контролировать задачи с уровня операционной системы, то CRON или системные задачи на стороне приложения будут лучшим решением.

📲 Мы в MAX

👉 @Bookflow

Плывущий экран. Вирус на C++. Melting Screen

Программа предоставлена в образовательных целях! Автор не несёт ответственности за её использование!
В этом видео вы узнаете как написать вирус на с++ который заставляет экран сыпаться и плыть.

источник

📲 Мы в MAX

👉 @Bookflow

Прошиваем программу не только в начало FLASH памяти STM32

Знаете ли вы куда попадает ваша программа после того, как вы нажали кнопку RUN или DEBUG в IDE? Если да, то как изменить этот адрес или даже выйти за пределы постоянной памяти и прожигаться сразу в оперативную память.

Я работаю в CubeIDE и весь мой интерфейс будет именно из этой среды разработки.

Начнем с ответа на первый вопрос, если использовать стандартные настройки IDE и взять стандартный ST-LINK (не важно оригинал или свисток), то при прожигании микроконтроллера будет очищено нужное количество секторов во FLASH памяти и на их место будет записана программа, причем в самое начало FLASH памяти по адресу 0x08000000.

Тут немного остановимся. Для большинства проектов этого достаточно, программа находится во FLASH памяти, при перезагрузке микроконтроллера ни куда не исчезает и исправно запускается. Проблемы начинаются, когда приходит задача, встроить загрузчик, который будет самостоятельно принимать прошивку по одному из интерфейсов, будь то UART/USART, I2C или CAN и сохранять ее в требуемом месте FLASH памяти, а после перезагрузки должен самостоятельно подготовить и передать управление требуемой программе.

https://habr.com/ru/articles/831016/

📲 Мы в MAX

👉 @Bookflow

CppCoreGuidelines

Основные принципы C++ - это набор проверенных рекомендаций, правил и лучших практик по программированию на C++.

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

📲 Мы в MAX

👉 @Bookflow

Анатомия Kubernetes - как это работает изнутри? ☸️

Часто мы используем kubectl, не задумываясь, что происходит «под капотом». На этой схеме отлично разложено устройство кластера Kubernetes. Давайте разберем три главных уровня архитектуры.

1. Control Plane (Панель управления) - «Мозг» кластера 🧠

Это центр принятия решений. Именно здесь определяется, что и где должно работать.

🔴API Server (в центре): Единая точка входа. Все компоненты общаются только через него (и вы через CLI тоже). Примечание: на схеме иконка подписана как Kube-Scheduler, но функционально и визуально (надпись API) это именно API Server.
🔴etcd: «Память» кластера. Надежное хранилище типа «ключ-значение», где лежит вся конфигурация и текущее состояние системы.
🔴Kube-Scheduler: Логист. Решает, на какую именно ноду (узле) запустить новый Pod, исходя из свободных ресурсов.
🔴Controller Manager: Смотритель. Следит, чтобы текущее состояние кластера совпадало с желаемым (например, если упал под - он его перезапустит).
🔴Cloud-Controller Manager: Связной с облаком. Управляет ресурсами, специфичными для облачного провайдера (AWS, Azure, GCP).


2. Worker Nodes (Рабочие узлы) - «Мускулы» кластера 💪

Здесь крутятся ваши приложения.

🔴Pod (Под): Минимальная единица в K8s. Внутри пода живет один или несколько контейнеров.
🔴Container Runtime (Docker): Движок, который фактически запускает контейнеры.
🔴Kubelet: Главный агент на узле. Получает задачи от Control Plane и гарантирует, что контейнеры в поде запущены и работают.
🔴Kube-Proxy: Сетевой регулировщик. Отвечает за сетевые правила и проброс трафика к подам.


3. Kubernetes Extensions - Инструменты 🛠

То, с чем взаимодействуем мы или системы мониторинга:

🔴CLI: Консольная утилита (kubectl).
🔴Web Admin UI: Дашборд для визуального управления.
🔴DNS: Для обнаружения сервисов внутри кластера.
🔴Monitoring: Сбор метрик ресурсов.

💡Control Plane командует, Worker Nodes исполняют, а Extensions помогают нам этим управлять.

Сохраняй шпаргалку, чтобы не путаться в компонентах! 👇

#devops #kubernetes #k8s #architecture #docker


📲 Мы в MAX

👉 @Bookflow