Качество печатной платы зависит не только от оборудования, уровня технологов и процессов на фабрике. Не меньший вклад в него вносят конструкторские решения разработчика платы — тополога. От них зависит технологичность: то, насколько просто будет произвести и ремонтировать изделие. Наиболее технологичной плата получится, если тополог сразу учтёт технологические нормы и особенности производства, внеся их в параметры своего CAD‑проекта. Такой подход называется Design for Manufacturing (DFM) — дизайн, оптимизированный под производство. Давайте разбираться, что это такое.

Этот материал адресован в первую очередь топологам, технологам и всем, кто уже работает в RnD и на производствах — или готовится войти в индустрию. Но мы постарались сделать его доступным для всех читателей.

Уважаемые жители Habr‑а, В данной статье, речь пойдет о доступе к GPIO, и другим регистрам, используя C++.

Несколько лет назад, я подготовил статью, о том, как можно используя constexpr‑клаcсы, серьезно оптимизировать доступ к GPIO‑порту, таким образом, чтобы команда «PA0.set()» — превращалась в одну‑три ассемблерных инструкции, в зависимости от обстоятельств. Этот класс лишь выглядел обычным, который оптимизировался компилятором. Фактически, это была высокоуровневая оптимизация низкоуровневого кода. Теоретически возможно было перегрузить оператор равенства и писать просто PA0=1 или PA0=0, фактически это вызывало inline инструкцию, позволяющую добавить еще и барьерную инструкцию.

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

Итак. Задача состояла в том, чтобы максимально описать любой регистр, и получить доступ к нему, удобным способом. Я несколько раз пытался различными способами формализовать описание, и мои попытки привели меня к следующему коду.

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

Когда я вижу у недавнего выпускника в резюме какой-то из протоколов в котором используется valid/ready, например AXI или AHB, я прошу его спроектировать блок, у которого на входе два числа A и B, а на выходе их сумма. Разумеется не просто написать SUM=A+B, а еще и поставить valid/ready сигналы на каждый из A, B, SUM, чтобы A и B могли приходить в разное время, а также чтобы блок ждал, если SUM не может быть передана другому блоку сразу.

Некоторые не справляются. Грустно смотреть на человека, который потратил 6 лет своей жизни (4 года в бакалавриате и 2 года в магистратуре) и океан денег на образование - и не может сложить два числа и бьется как угорь на сковородке. То блок не работает когда числа приходят в разное время, то создатель забывает снять valid, и блок на 2+2 выдает не 4, а 4-4-4-4-4-4-4... То числа складываются не попарно, а просто записываются в регистры и на выход идет их текущая сумма, хотя количество аргументов A и B не совпадает. То не отрабатывается backpressure и результаты теряются, то (после того как кандидат написал страницу кода на верилоге) блок работает на половинной производительности, то есть не может принимать поток чисел подряд, а ожидает между ними пропуски (gaps). Короче ведет себя как ChatGPT.

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

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

К разработке этой библиотеки и написанию статьи меня натолкнуло отсутствие незаброшенной библиотеки эффективных хеш-таблицы для C.

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

Если вы знаете адекватные, сложные и интересные вопросы по теме разработки на MCU, то пишите их в комментариях.

Статья для тех, кто боится слова template в C++. Вводная информация с примерами и их подробным разбором.

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

Так уж случилось, что я пишу код для разных IoT-железок, связанных с электричеством, типа зарядных станций автомобилей. Поскольку аппаратных ресурсов, как правило, вполне достаточно, то основным фокусом является не экономия каждого байта и такта процессора, а понятный и надежный код. Поэтому в проекте разрабатывают под Embedded Linux и в качестве основного языка используют C++ в его современном варианте - C++17, активно поглядывая на фичи из стандарта 20-го года и новее.

Иногда запускаются новые проекты на той же платформе, с теми же процессами и с переиспользованием многих уже существующих компонентов, и тогда в эти проекты мы ищем программистов, с учетом вышесказанного - программистов на C++. В embedded, тем не менее, чистый C все еще очень популярен, и нередко собеседоваться на вакансию C++ Developer'а приходят именно сишники. Логика у человека простая: языки, на первый взгляд, довольно близкие, базовый синтаксис одинаков, про ООП кандидат что-то слышал, и значит, основная база уже есть и он сможет легко освоить C++ за 21 день в процессе работы, поэтому можно наплести про "с C++ тоже работал", начать писать на "Си с классами" и все получится.

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

Введение

ARM с ядром Cortex Mx (на примере STM32F10x)

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения