Люди, начинающие интересоваться электроникой, рано или поздно сталкиваются с проблемой получения ответов на вопросы разной степени наивности. И здесь новообращённый адепт паяльника и вольтметра упирается в проблему технической информации по указанному направлению. Хорошо, если под боком есть терпеливый и грамотный наставник. Но такая удача выпадает не всем. Прямо скажем, мало кому так везёт. Сетевые форумы? Там новичков не жалуют и часто грубо оскорбляют репликами «RTFM» и «почитай, наконец, учебник». Короче, рано или поздно любой человек, влезающий в сложную и хорошо разработанную тему, сталкивается с проблемой поиска достойных печатных источников знаний. Печатные источники имеют массу достоинств, и самые основные из них — терпеливость и вежливость. Книга не скажет: «Ну что за тупой читатель», или «Чем ты занимался в школе?». Книгу можно неторопливо и вдумчиво читать, снова и снова проходя сложный материал, не рискуя исчерпать терпение наставника.

В прошлой статье я рассказывал про прерывание DebugMon и регистры с ним связанные.

В этой статье будем писать реализацию отладчика по UART.

В данной статье я расскажу вам как можно использовать регистры отладки и breakpoint'ов в микроконтроллерах, построенных на ядрах ARM Cortex-M

Серверы сбора данных по последовательным портам MOXA Nport и им подобные — в настоящее время являются стандартом де факто в области построения систем передающих или принимающих данные через интерфейсы RS-232,RS-485 и RS-422.

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

Все, что может генерировать данные или управляться удаленно и имеет интерфейс RS-232, RS-485 и RS-422 — работает через данные преобразователи.

Общий смысл их использования — обычно заключается в следующем: пробросить интерфейсы RS-232,RS-485 и RS-422 через существующую локальную сеть, подключить устройство или прибор имеющий один из последовательных интерфейсов к ПК (серверу, SCADA) через Ethernet, подключится к прибору имеющему последовательный интерфейс через Internet для удаленного управления и т.п.

Цены на данные преобразователи не сильно высоки, младшие модели можно взять за 100-200$. Но учитывая что на любом автоматизированном производстве таких устройств может быть установлено сотни а то и тысячи — вырисовывается довольно лакомый кусочек для отечественных «импортозамещальщиков».

Им то я сегодня и попытаюсь помочь.

Что будем делать?

Во первых — разберемся в теории, как оно устроено внутри.

Во вторых — вычленим минимальный функционал для запуска работы в режиме Real Com Mode (то есть по сути для проброса виртуального COM порта до устройства через Ethernet).

В третьих — ради интереса разберем протокол поиска и конфигурирования устройства через утилиту NPort Administration Suite. Получим полное понимание, как создать pin-to-pin аналог железки, которую можно воткнуть вместо существующей MOXA Nport при этом получив полную поддержку со стороны родного ПО и драйвера.

Ну и на последок — попробуем посчитать, сколько индусов писало код прошивки MOXA.

Меня зовут Вячеслав, я хронический математик и уже несколько лет не использую циклы при работе с массивами…

Ровно с тех пор, как открыл для себя векторные операции в NumPy. Я хочу познакомить вас с функциями NumPy, которые чаще всего использую для обработки массивов данных и изображений. В конце статьи я покажу, как можно использовать инструментарий NumPy, чтобы выполнить свертку изображений без итераций (= очень быстро).

Не забываем про

import numpy as np

и поехали!

Введение

На данный момент, на рынке представлен большой ассортимент одноплатников на любой вкус по приемлемой цене.

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

Введение

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

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

Существует три способа запуска юнит-тестов для встраиваемых платформ:

Некоторое время назад автор этих строк взялся разрабатывать компактный регистратор одно-полярного аналогового сигнала в пределах 3 вольт с максимально возможной скоростью считывания и минимально возможными затратами и размерами. В список минимально возможных затрат я вписал также и свою головную боль и выбрал хорошо знакомый мне STM32F303. Это, напомню, Cortex-M4 на 72 мегагерца от известной компании, со встроенными 12 разрядными, довольно шустрыми, аналого-цифровыми преобразователями (АЦП или ADC, кому как нравится) и с CAN интерфейсом на борту.

Таких небольших регистраторов требовалось несколько десятков. А наличие у микроконтроллера корпуса о 48-ми ногах вселяло надежду на то, что получится назвать этот считыватель компактным. Интерфейс CAN, с которым у меня уже тогда были хорошие отношения, давал мне возможность объединить весь этот джаз в достаточно удобной манере.

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

Однако, некоторый осадок остался. Осталась мысль, что, в отношении быстродействия, выжато было не все.

И вот, совсем недавно появляется серия STM32G4 с тактовой частотой до 170 мегагерц с вариантом в маленьком корпусе, и с почти такими же шустрыми АЦП на борту в количестве пяти штук. Надо было что-то делать.

И снова здравствуйте. Делимся с вами интересной статьёй, перевод которой подготовлен специально для студентов курса «Разработчик C++».

---

Сегодня у нас гостевой пост Адама Балаша (Ádám Balázs). Адам является инженером-программистом в Verizon Smart Communities Hungary и занимается разработкой видеоаналитики для встраиваемых систем. Одна из его страстей — оптимизации времени компиляции, поэтому он сразу согласился написать гостевой пост на эту тему. Вы можете найти Адама в онлайне на LinkedIn.

В прошлом году появилась необходимость дополнить старый проект написанный на C функционалом на Python3. Не смотря на то, что есть статьи на эту тему я помучился и в том году и сейчас когда писал программы для статьи. Поэтому приведу свои примеры по тому как работать с Python3 из C под Linux (с тем что использовал). Опишу как создать класс и вызвать его методы, получить доступ к переменным. Вызов функций и получение переменных из модуля. А также проблемы с которыми я столкнулся и не смог их понять.

Возможно, вам уже ранее попадались мои заметки по первым шагам в программировании САПР на примере NanoCAD.

Надо отметить, что для человека не умеющего программировать и знающего САПР на уровне «электронного кульмана» это было удивительное приключение. Однако, NanoCAD это все же в первую очередь коммерческий продукт. Его бесплатная версия не обновлялась, уже около шести лет и порядком устарела в плане возможностей для разработки.

А ведь так хотелось, чтобы как в одной замечательной повести: «Счастье для всех, даром, и пусть никто не уйдёт обиженный!» . Поэтому было принято решение, внять совету боевого товарища DrZugrik и установить себе FreeCAD.

Итак, по горячим следам пишу для вас материал, всего за один день я узнал, как подружить эту САПР с Anaconda, написал на Python простенький скрипт, который рисует квадратик с текстом и протестировал его на работоспособность в Windows и Linux. О чем я собственно готов вам по шагам рассказать и показать, чтобы вы тоже могли это сделать.

Хотите поближе познакомиться с очаровательной парочкой Python и FreeCAD? Тогда милости прошу под кат.

Привет, Хабр!

Некоторое время тому назад рабочая группа Сколтеха по Интернету вещей опубликовала проект национального стандарта узкополосной связи для IoT под названием «OpenUNB», полный текст которого можно найти здесь. С одной стороны, явление безусловно положительное – если в области стандартов широкополосных существует de facto открытый к применению всеми желающими LoRaWAN, то узкополосные стандарты до сего дня были исключительно проприетарными (Sigfox, XNB компании «Стриж», NB-Fi компании «Вавиот» — хотя последний также опубликован в виде проекта национального стандарта, в нём не открыты существенные для реализации сторонними лицами части).

При этом узкополосные и широкополосные системы имеют каждая свои плюсы и минусы, так что говорить «зачем вам что-то ещё, когда есть LoRaWAN» – не совсем верно. То есть, открытый стандарт на UNB-связь необходим.

Однако, необходимость – это лишь одно из двух условий. Второе – достаточность. Ок, то, что опубликовал Сколтех, необходимо, но достаточно ли оно для практического применения?



Мы ответим на это в формате, похожем на интервью – под катом цитаты из проекта стандарта OpenUNB и комментарии к ним, данные Александром Шептовецким (AS), техническим директором компании GoodWAN, и Олегом Артамоновым (OA), техническим директором компании Unwired Devices.

Итак, поехали. Стилистика, орфография и пунктуация авторов сохранены.

О смарт-картах сказано уже немало, но процесс взаимодействия с картами на физическом уровне до недавнего времени оставался для меня загадкой. В своей статье я хотел бы осветить вопрос работы со смарт-картами по интерфейсу, описанному в части 3 стандарта ISO7816. Признаюсь честно, что потратил немало времени добывая информацию, а все оказалось предельно просто. Если интересно, давай под кат.

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

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

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

В данной статье я расскажу, как я в течение пяти лет переводил предприятия, на которых работал, с ведения проектов под микроконтроллеры на C на C++ и что из этого вышло (спойлер: все плохо).

Добрый день! Мы в проекте Embox запустили Qt на STM32F7-Discovery и хотели бы об этом рассказать. Ранее, мы уже рассказывали как нам удалось запустить OpenCV.

Qt — это кроссплатформенный фреймворк, который включает в себя не только графические компоненты, но и такие вещи как QtNetwork, набор классов для работы с базами данных, Qt for Automation (в том числе, для реализации IoT) и многое другое. Разработчики команды Qt заранее предусмотрели использование Qt во встроенных системах, поэтому библиотеки довольно хорошо конфигурируются. Однако до недавних пор, мало кто задумывался о портировании Qt на микроконтроллеры, вероятно потому, что такая задача выглядит сложной — Qt большое, MCU маленькие.

_{Рис. И. Кийко}

Всем доброго здравия!

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

Примерно в том же ключе я хочу продолжить обсуждение использования С++ для микроконтроллеров и рассмотреть способы как можно работать с регистрами используя С++. И хочу заметить, что для достижения безопасного обращения к регистрам простого пути не будет. Попытаюсь показать все плюсы и минусы способов. Если вы знаете еще способы, кидайте их в комментарии. Итак начнем:

Всем доброго здравия!

При обучении студентов разработке встроенного программного обеспечения для микроконтроллеров в университете я использую С++ и иногда даю особо интересующимся студентам всякие задачки для определения особо больных на голову одаренных учеников.

В очередной раз таким студентам была дана задача поморгать 4 светодиодами, используя язык С++ 17 и стандартную библиотеку С++, без подключения дополнительных библиотек, типа CMSIS и их заголовочных файлов с описанием структур регистров и так далее… Побеждает тот, у кого код в ROM будет занимать наименьший размер и меньше всего затрачено ОЗУ. Оптимизация компилятора при этом не должна быть выше Medium. Компилятор IAR 8.40.1.
Победитель едет на Канары получает 5 за экзамен.

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