Программирование микроконтроллеров *

Различие в подходах: нормы или анализ рисков.

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

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

В бывшем СССР сложилась система норм и правил, которые жестко регламентировали требования, как организационные, так и технические. Эта система была унаследована и РФ. Достаточно посмотреть «Общие правила взрывобезопасности для взрывопожароопасных химических, нефтехимических и нефтеперерабатывающих производств» утверждены приказом Федеральной службы по экологическому, технологическому и атомному надзору от 15 декабря 2020 года № 533. Документ содержит 70 страниц ценных указаний. И таких «нормативных документов» у нас бесконечное количество, при желании можно найти «нормативку» на все случаи жизни. Соответственно проектировщику не надо понимать процесс, детально знать все особенности технологии, иметь опыт эксплуатации, достаточно просто найти нужную «нормативку» и выполнить все требования. Эксперт при проведении экспертизы проектной документации также проверяет технические решения на соответствие «нормативке», и инспектор Ростехнадзора тоже будет проверять объект на соответствие этой же «нормативке». При этом никого не волнует, на сколько обеспечена реальная безопасность технологического процесса (технологической установки), эффективность и достаточность принятых решений, возможность устойчивой работы оборудования и т.д. Соответствие нормам снимает ответственность за конечный результат со всех – проектировщиков, экспертов, инспекторов, и перекладывает всю ответственность на эксплуатацию, людей, которые непосредственно работают на технологической установке и реально рискуют своей жизнью.

Что такое безопасность технологического процесса или технической системы (устройства), что такое риск и вообще зачем все это?

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

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

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

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

Библиотеки являются мощным инструментом при работе с проектами. Особенно когда используются внешние модули, подключенные к Рудирону. Библиотека – файл или набор файлов, к котором используется такой же код по синтаксису, как и в основном тексте программы. Можно подключить библиотеку в свой код и использовать тот функционал, который она нам в этом случае предоставляет, а вариантов там может быть очень много: готовые функции высокого уровня для работы с внешними датчиками, различными модулями, экранами и т.п., для работы с внутренней периферией микроконтроллера (часы, таймеры, АЦП), библиотеки различных математических функций и многое другое, всего и не перечислить. Для опытного программиста это способ сократить время разработки программы, а для начинающего – готовые рабочие примеры работы с внешней периферией.

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

Шаблоны и примеры проектов ПАК Рудирон размещены в репозитории: https://gitflic.ru/project/akvarius-rudiron/rudiron-projects

FC7300F8MDT — это микроконтроллер компании FlagChip as FlagShip.

В этом тексте я показал, как можно запрограммировать микроконтроллер FC7300F8MDT, буквально на пустом компьютере.

В предыдущих публикациях (Часть 1 и Часть 2) рассказывалось, как изготовить самодельный счётчик объектов, пересекающих единственный инфракрасный луч (барьер). В счётчике использовался механизм внешних прерываний микроконтроллера. Соответственно, скетч для Arduino выглядит крайне простым.

Теперь мне хочется чуть‑чуть пошалить и предложить вашему вниманию альтернативный вариант: странный инфракрасный счётчик с одним лучом. В нём не используются внешние прерывания. И скетч выглядит посложнее.

Зато он может определить, сколько времени объект провёл в инфракрасном луче.

В этой заметке речь больше про принцип — программатор можно сделать так, чтобы на стороне компьютера не требовался дополнительный софт. Будем прямо лить HEX‑файл в последовательный порт. Идея не новая, но не лишне напомнить (в том числе об одном‑двух подводных камнях рассказать).

Собственно программатор — голый Arduino с прошивкой, разбирающей HEX‑файл построчно и реализующий программирование целевого чипа по SPI. Прошивка и инструкции сложены в репозитории на гитхабе: At89s‑prog.

Конкретные чипы (At89s...) здесь скорее для примера. Мы не будем воспевать достоинства 8051-й архитектуры (конечно, они архаичны но у них есть плюсы, благодаря которым они до сих пор сохраняют популярность). У меня в какой‑то момент оказалась их горстка а программатора под рукой не нашлось. Они (те что с индексом S) программируются через SPI, а не стандартным «многоногим» интерфейсом что делает удобным их применение в любительских поделках.

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

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

Идеяустройства возникла у меня давно. Захотелось аппаратного менеджера паролей. Надоело перепечатывать 20-символьные пароли из телефонного KeyPass, а на каждый компьютер, где нужно что‑то вводить, устанешь устанавливать. Посмотрел, что предлагают, посмотрел, что делают. В основном, не понравились размеры. Иногда цена. С другой стороны, телефон с паролями всегда с собой. А тут ещё бесплатный DeepSeek.

TL;DR: Просто история мучений. В конце прошивка для контроллера + Android‑приложение, работает. Хотя и на стадии «концепт».

В данном тексте я написал про то, как я написал загрузчик для российского микроконтроллера MIK32 (K1948BK018).

Это, пожалуй, первый случай, когда столько функционала мне пришлось утрамбовать всего в 8kByte ROM памяти.

Осторожно: помните ли вы, как в вашем телефоне Siemens, Motorola и Sony поселились маленькие программы — «эльфы»? В рамках этой статьи мы во всех деталях исследуем прошивку бюджетного кнопочника, разберемся в её архитектуре, хакнем и напишем загрузчик тех самых эльфов с MicroSD-флэшки. При этом я постараюсь объяснить всё максимально простым и доступным языком!

Недавно я познакомился с легендой форума allsiemens.ru — Ilya_ZX, который известен своим огромным вкладом в тему реверса и моддинга телефонов на платформе E-Gold и S-Gold. Илья поведал мне интересную историю о том, как в начале нулевых, будучи студентом, поспорил с одногруппником, сможет ли он добавить ‭‭«змейку‭‭» в свой Siemens A60. И спор он этот выиграл, путем бессонных ночей ковыряния прошивки в IDA Pro! Я подумал ‭‭— «а чем я хуже?‭‭». Взял в руки кнопочный телефон на платформе Spreadtrum, сдампил прошивку и загрузил в дизассемблер...

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

Наверное каждый любитель электроники имеет в запасе модули приобретенные на всякий случай. Так несколько лет назад я не смог пройти мимо 1.5 дюймового E-Ink дисплея, лежащего на витрине радиомагазина. Через некоторое время нашлось для него применение. В статье ESP32 E-Paper Thermometer описывается, как отображать окружающую температуру, измеренную с помощью датчика DS18B20. Проект выполнен в Arduino IDE. Но я решил пройти "Путь самурая" и портировать код на ESP-IDF. Пришлось немного повозится с библиотеками для работы с дисплеем. На этом мой путь не окончился, как говорят: "У самурая нет цели, есть только путь". И я решил, что было бы неплохо добавить еще несколько сенсоров, измеряющих влажность, давление, CO2, а потом отправлять эти данные по MQTT. В том же радиомагазине был приобретен фанерный домик-конструктор со светодиодным ночником. А в другом магазине - модуль с датчиками. Таким образом родилась идея сконструировать Micro-smart-home. На передней части домика расположен дисплей на пластиковых стойках. А с другой стороны расположен модуль с сенсорами.

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

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

При продолжительной разработке на одном семействе микроконтроллеров получается так, что приложение намертво привязано к конкретному семейству микроконтроллеров и его SDK, так как напрямую использует HAL от вендора.

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

Получается, что приходится заново писать всю прошивку, всё приложение, драйвера всех ASIC-ов. Драйвер светодиодов, драйвер кнопок, драйвер ASICов c I2C SPI управлением. В общем всё переписывать. Поменяли MCU и пришлось переписать все файлы в репозитории. Нормально так да?

В этом тексте я написал, как можно обойти эту проблему.

Когда одних юнит-тестов уже недостаточно, на сцену выходят интеграционные. В этой статье от команды Amplicode мы покажем, как протестировать REST API в Spring Boot с использованием современного стека: генерация тестов через Amplicode, автоматический запуск окружения с помощью Docker Compose Starter и поддержки со стороны LLM-инструментов от Яндекса.

В основном я работал на оригинальной отладочной плате Nucleo (stm32f411ret6) и прекрасно себя чувствал на macOs.
Не так давно я решил попробовать прошить blue pill через китайский st-link и получил море ошибок в CubeIDE с которыми решил разобраться раз и навсегда. На самом деле все оказалось не так сложно, как я думал по началу. Через костыли, но она работает!
Данная статья является дубликатом моего репозитория https://github.com/nikitatm333/ST-LINK_V2_for_macOS, я давно хотел написать свою первую статью на хабре и решил начать с дубликатов своих "шпаргалок".
Не будем затягивать, начнем!

GNU Make - это консольная утилита, которая запускает другие консольные утилиты в желаемой последовательности согласно скрипту. Только и всего.

В этом тексте я показал, как можно организовать самостоятельно написанные make скрипты для микроконтроллерных проектов.

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

Когда сенсорная система готова, интерес смещается к проблеме обработки поступающей от неё информации. Электронщик, отдохни, сходи попить кофе. Айтишник, просыпайся: твой выход.

В марте маленькая платка внезапно оказалась в центре глобального технологического скандала. Заголовки пестрили страшилками про «бэкдор» в «миллиардах устройств», и по новостям казалось, что хакеры вот-вот захватят все умные лампочки, термостаты и прочий IoT.

А потом... все как-то поутихло. Что же на самом деле нашли испанские исследователи в популярном микроконтроллере? Почему новость о «бэкдоре» разлетелась со скоростью лесного пожара? И главное — насколько реальна была угроза?

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