Учимся программировать микроконтроллеры
Есть у нас в институте старенькое спортивно табло eltablo. По нему я, ещё будучи студентом, мячом попадал. И есть (точнее была) у него неприятная проблема: это табло управляется по страшному проводному пульту (как этот пульт работает, я до сих пор не разобрался). Длина провода от пульта до табло на глаз метра 3-4. В стоке его хватает, только чтобы сидеть прямо под ним, что, естественно, неудобно (не видно счёт, неправильный ракурс для судейства и т.д.) Поэтому наши физруки им управляют с противоположной стороны зала, что тоже не совсем удобно, но хотя бы видно, что на этом табло происходит.
В этом, собственно, и заключается проблема: чтобы подключить пульт, пришлось прокинуть не хилой длины проводок, на вскидку, метров 20. Из-за этого табло управляется не всегда стабильно. Это меня и попросили решить. Естественно, я решил, что проводам и пульту место на помойке, а таблом будем рулить по беспроводному соединению и с телефона!
На третьем курсе некоторые направления в МИЭТ проходят лабораторный практикум, на котором им даётся возможность спроектировать собственную систему архитектуры RISC-V и написать под неё программу на С или C++.
В качестве затравки и повышения мотивации, хотелось показать им на что будет способна их процессорная система, и для этого было решено написать какую-нибудь простенькую игру, не требующую особых требований к ресурсам и графике. Так выбор пал на Змейку.
В этой я расскажу о том, как была написана данная игра под платформу, поддерживающую символьный вывод.
Выбор SCADA системы определяет решение, которое скорее всего вы будете использовать в течение как минимум 10+ лет. Поэтому крайне важно понимать принципы выбора ПО. Предлагаем ознакомиться с мнением Роя Кока (Roy Kok) – инженера с более чем 30-летним опытом работы в области электротехники и промышленной автоматизации.
В работе на планерках и от коллег порой такое услышишь, что это становится либо цитатой или мемом. Вот небольшая подборка того, что мне понравилось за 12 лет работы программистом МК. Некоторые цитаты имеют автора другие, просто безымянные афоризмы сродни народному творчеству. Итак обо всём по порядку...
Хотите узнать, как мне удалось преобразовать проект управляемой по CAN светодиодной матрицы с коммерческого Keil uVision IDE и RTX RTOS в полностью бесплатную связку VS Code + FreeRTOS, не написав ни строчки кода?
В статье рассказывается о нетривиальном процессе ремонта электронного устройства, приведшему к разработке новой платы, программированию микроконтроллеров и всяким интересным изысканиям.
Если интересно, прошу под кат.
После проведения HAZOP и формирования контуров безопасности ПСБ с определением целевого уровня полноты безопасности, нам, как инженерам реализующим систему безопасности прислали исходные данные: технологическая схема с КИП, перечень контуров безопасности, матрица причинно-следственных связей, значение целевого УПБ. Мы, как подготовленные инженеры, понимаем из чего могут быть построены контура безопасности, отвечающие заданному целевому УПБ. Осталось подобрать оборудование, собрать контура, посчитать результирующее значение УПБ и сравнить его с целевым.
Если подходить к решению задачи правильно и грамотно, ПСБ еще на предыдущих этапах должна быть разделена на систему аварийного останова ESD и систему технологических защит PSD. ESD предназначена именно для предотвращения катастрофы, аварии и гибели людей. PSD предназначена для защиты оборудования и технологического процесса (например, не дает загубить катализатор в реакторе или выпустить некачественную продукцию). Позже, когда будем разбираться, в чем разница между ESD и ПАЗ разберем этот вопрос подробнее.
Когда мы говорим о снижении риска до целевого значения и расчете уровня полноты безопасности, мы говорим про ESD.
Весь перечень контуров безопасности сразу делим на две части: контура с целевым УПБ1 и ниже, и контура с целевым УПБ2,3. При объективно проведенном анализе рисков контуров УПБ3 будет очень ограниченное количество, обычно несколько единиц. Подобрать оборудование для обеспечения УПБ3 контура в целом достаточно сложно.
Для снижения риска технологического процесса или технического устройства (защиты человека от гибели или травмирования), всегда задействованы несколько различных «слоев безопасности»: методы, мероприятия, технические решения, подходы направленные на обеспечение безопасности.
Можно выделить следующие слои безопасности:
- совершенствование технологического процесса с целью исключения опасных факторов – уменьшить давление в системе, снизить объем опасных веществ, изменить технологическую схему, уменьшить количество оборудования…;
- ОСУП (организация системы управления процессом) – контроль состояния оборудования, контроль за технологическим процессом, уменьшить количество персонала в потенциально опасной зоне, построить эффективную систему обучения и инструктажей …;
- система сигнализации о приближении к опасным границам и квалификация операторов – наладить полноценную систему сигнализации, выделить сигнализации приоритета 1, которые требуют незамедлительных действий от операторов, постоянно и квалифицированно вести анализ срабатывания сигнализации, максимально исключить ложные срабатывания, наладить систему постоянных тренингов для поддержания необходимой квалификации операторов (в правильно построенной системе, сигнализации уровня 1 срабатывают крайне редко при реальной угрозе аварии, количество параметров для крупного объекта не превышает 10-50, каждое ложное срабатывание детально исследуется, программа подготовки и квалификация операторов должны обеспечивать корректные действия персонала при срабатывании сигнализации). В правильно построенной системе, сигнализации должны быть разделены на аварийные и информационные, с разной схемой визуализации и разными журналами, но на практике все сигнализации собирают в один перечень, называют «Перечень сигнализаций и ПАЗ», и в системе управления нет разницы между сигнализацией о перегреве реактора и сигнализацией о низкой температуре теплофикационной воды в операторной. В результате в общий журнал сигнализаций каждый день пишется по 1000 записей, 999 из которых не имеют какого-то смысла.
В данной статье на примерах попробуем разобрать порядок построения системы безопасности технологического процесса на основе анализ рисков. Поскольку цель статьи постараться объяснить «нормальным инженерных языком» назначение и порядок создания системы безопасности технологических объектов на основе анализа рисков, придерживаться «процедур в соответствии с ГОСТ-МЭК..» и описывать процедуры я не буду.
Еще раз напомню, что любой технологический процесс или техническое устройство несет потенциальный риск – угрозу жизни и здоровью работающих или находящихся по близости людей. Риск есть всегда и для всех, все живое рискует погибнуть. Риск, которому мы все подвержены в повседневной жизни называют фоновым. Для каждого производства или технологического процесса существует значение риска, принятого как допустимое. При построении нового процесса или технологического объекта необходимо принять такие меры обеспечения безопасности, чтобы обеспечить расчетный риск не выше допустимого.
В целом порядок создания системы безопасности будет следующим:
- исследуем риски, выявляем факторы риска, оцениваем значение;
- если значение риска превышает допустимое, разрабатываем дополнительные мероприятия (технологические, организационные и т.д.) для снижения риска до приемлемого;
- если технологическими и организационными решениями снизить риск до приемлемого не удается, переходим к созданию приборной системы безопасности (ПСБ), определяем контура безопасности, оцениваем требуемый уровень полноты безопасности (SIL) контуров, строим систему аварийного останова (ESD);
Различие в подходах: нормы или анализ рисков.
Поскольку практически любой производственный процесс или техническое устройство несут потенциальную опасность жизни и здоровью людей, необходимо разработать и использовать определенный набор организационных и технических мероприятий, для снижения этой опасности (риска) до приемлемого уровня.
Для обеспечения безопасности технологического процесса или технического устройства, снижения риска получения травмы или гибели до допустимого значения, возможны два подхода – выполнить технологический процесс в соответствии с «нормативными документами» или провести анализ рисков, выявить все источники и разработать компенсирующие мероприятия.
В бывшем СССР сложилась система норм и правил, которые жестко регламентировали требования, как организационные, так и технические. Эта система была унаследована и РФ. Достаточно посмотреть «Общие правила взрывобезопасности для взрывопожароопасных химических, нефтехимических и нефтеперерабатывающих производств» утверждены приказом Федеральной службы по экологическому, технологическому и атомному надзору от 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 памяти.