Язык Си - один из наиболее влиятельных языков программирования за всю историю. Он стал незаменимым инструментом разработки операционных систем, сместив с этого пьедестала языки ассемблера. Изучение Си обязательно для любого уважающего себя программиста. Этот язык любим за свою внешнюю простоту и ненавидим за беспощадность к ошибкам. Благодаря нему у нас есть ядро Linux и тысячи уязвимостей в нём же в придачу.

Попробуем понять, что же такое этот противоречивый язык Си - благословение или проклятие?

Зачастую разработчику, или даже пользователю, требуется посмотреть, что происходит внутри устройства. Обычно в таких ситуациях используют либо текстовой вывод в терминал (через голый UART или самописный протокол гарантированной доставки), либо пишут свои собственные системы логирования. Однако, всегда ли оправдан такой подход? Есть ли решение проще и производительнее? В данной статье мы рассмотрим одно из таких - библиотеку логирования uP7.

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

Редко когда речь заходит об обратной проблеме, имеющей место в куда более узких кругах разработчиков встраиваемых систем, включая системы повышенной отказоустойчивости. Есть основания полагать, что ранний опыт использования MCS51/AVR/PIC оказывается настолько психически травмирующим, что многие страдальцы затем продолжают считать байты на протяжении всей карьеры, даже когда объективных причин для этого не осталось. Это, конечно, не относится к случаям, где жёсткие ценовые ограничения задают потолок ресурсов вычислительной платформы (микроконтроллера). Но это справедливо в случаях, где цена вычислительной платформы в серии незначительна по сравнению со стоимостью изделия в целом и стоимостью разработки и верификации его нетривиального ПО, как это бывает на транспорте и сложной промышленной автоматизации. Именно о последней категории систем этот пост.

Речь пойдёт подключении дисплея AT070TN94 с параллельным интерфейсом к контроллеру STM32H743, начиная от выбора электронных компонентов, заканчивая настройкой блока LTDC. И хотя в сети достаточно много информации по данной теме, при создании своего устройства у меня периодически возникали те или иные вопросы, ответов на которых найти не удавалось. Пишу в первую очередь для новичков, а профи приглашаю почитать ради советов и аргументированной критики (первая статья как-никак). Приступим.

Неожиданное открытие

Доброго времени суток, дорогой читатель!

Сегодня я хочу поведать тебе забавную, ещё не закончившуюся историю странных совпадений, побед и поражений, радости и смуты. Если интересно как создавался, возможно, один из самых маленьких в мире "умных" (а не просто р/у) танков как на КДПВ, а так же при чём тут IoT, PHP и Angular - прошу под кат!

Сегодня речь пойдет о модном — о RISС-V микроконтроллере. Я давно хотел познакомиться с этим ядром и ждал когда появится что-то похожее на STM32 и вот дождался, встречайте — китайский GigaDevice — GD32V.

Инфраструктура для этого микроконтроллера не такая обширная как для STM32, но есть все необходимое для того, чтобы начать с ним работать. Благо отладочные платы можно заказать на аликекспресс, например, вот тут: Longan Nano GD32VF103CBT6 RISC-V MCU

Китайцы продвигают для этого микроконтроллера среду разработку Platform IO, которую можно поставить как расширение под Visual Studio Code. Но мы не будем её использовать, это ведь не по инженерным понятиям, мы же инженеры и хотим разобраться во всем сами. Поэтому давайте попробуем запустить плату на IAR, написав все с нуля.

Кстати, IAR раздает отладочный комплект (отладочная плата + отладчик I-Jet + 30 Дней полная лицензия) IAR RISC-V GD32V Evaluation kit. Вот тут можно оставить заявку Request for Development Tools. Не уверен, что они посылают комплект всем желающим, но мы получили в течение 5 дней. Спасибо им за это!

Ну что же, кто заинтересовался, добро пожаловать под кат

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

(КДПВ – см. аннотацию к диаграмме в конце)

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

Учить лексику

Введение