C *

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

В статье рассматриваются тонкости создания синтезаторов с функцией фазовой автоподстройки частоты (ФАПЧ, или PLL) на основе чипа ADF4113.

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

Кроме того, описана измерительная схема и результаты измерений. В завершение, предлагаются альтернативные технические решения для разных условий и ТЗ.

В среде профессионалов, которые измеряют партии своих устройств в килоюнитах и считают контроллеры, меньше чем на 100 выводов, ерундой, часто всплывает одна парадоксальная тема. А какой контроллер сейчас стоит рублей 20-30, и подойдет для бомж DIY? AVR после продажи компании ATMEL подорожали, STM8 после кризиса полупроводников подорожали тоже, но не так сильно. Я купил свои 15 портовые STM8S003 по 25 рублей за штуку. Конечно, CH32V003 дышат им в спину, но о них позже.

В сегодняшнем мире, где всё тесно связано и ориентировано на данные, производительность сети имеет решающее значение для обеспечения эффективного взаимодействия и оптимального пользовательского опыта. XDP и eBPF — это мощные технологияи, которые помогают обрабатывать пакеты с высокой скоростью и оптимизировать работу сети.

В этом пошаговом руководстве мы рассмотрим процесс создания XDP eBPF программы с использованием языков C и Golang.

C и C++ — культовые языки, на которых написано огромное количество кода. Но какой путь они прошли, чтобы стать таковыми? В этой статье расскажем о появлении C, начале его официальной стандартизации, а также о C with Classes и его окончательном превращении в C++.

Совсем коротенький рассказ — о довольно бесполезной но забавной штуковине, извините :)

Как-тораз я написал интерпретатор BASIC, который можно использовать на контроллере хоть с 1кб памяти (в частности AVR / Arduino). В основном мы им пользовались через Bluetooth‑модуль с телефона (я уж рассказывал). Но у меня руки чесались сделать своеобразный «терминальчик» — ну я и сделал.

Как видите — в качестве экрана тут дисплей 4 строки по 20 символов. А клавиатура полноценная — обычная c PS/2 разъёмом. Между ними и UART‑ом воткнут контроллер (младший STM32). Вообще‑то можно было без него, реализовать общение с клавиатурой и дисплеем в том же контроллере где интерпретатор крутится — но тогда это не был бы терминал, его нельзя было бы использовать с любым другим UART‑интерфейсом.

Покажу картинки, код — и немножко расскажу про устройство. А если сами строили что‑то похожее — расскажите и вы :)

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

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

В своей обители в Р'лайхе мёртвый Ктулху спит в ожидании своего часа. А в C коде проекта DPDK спит множество ошибок, и тоже в ожидании своего часа. Давайте посмотрим, какие из них может выявить анализатор PVS-Studio.

Я являюсь автором проекта по математическому моделированию прикладной механики и в работе моей программы до 90% вычислительного времени уходит на решение системы линейных уравнений. Цель этой статьи сугубо практическая - найти оптимальный метод решения системы линейных уравнений с точки зрения производительность/трудозатрат для небольшого проекта и рассказать о результате.

В прошлом я уже несколько раз обращал внимание на вычисления на GPU, но всегда что-то останавливало. И вот у меня накопился достаточный практический опыт программирования на C/C++ и наконец дошли руки, чтобы протестировать OpenCL.

Друзья! В данной статье мы бы хотели рассказать про кроссплатформенную коллекцию утилитных C++ компонентов CUtils.

CUtils — это довольно полезный инструмент при разработке кроссплатформенного программного обеспечения на языке программирования C++.

Недавно была опубликована статья под заголовком "Глобально оптимальный, восьмой и наиболее быстрый вид интерпретаторов байткода". Несколько тезисов из статьи вызвали у меня сомнения в их справедливости. Об этом я попробовал написать ряд комментариев тире вопросов к указанной статье. Но основной лейтмотив всех ответов сводился к тому - "а ты напиши свою статью". Подход не столько инженерно-научный, сколько детсадовский. Мне бы хватило и содержательных ответов в формате комментариев, но как говорится - уговорили :).

Итак, что же утверждается автором статьи про наиболее быстрый интерпретатор:

В этом тексте я показал как конечный автомат может работать ядром для драйвера аппаратного I2C трансивера.

Меня удивляет, что в оригинальном коде от вендоров микроконтроллеров программисты прошли мимо конечных автоматов при написании I2C кода внутри своих официальных uHAL. Непорядок...

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

Патрик через минуту вернулся с небольшой пыльной коробкой. Мы с Дейвом смотрели, как Патрик ее открывает и достает сетевой свитч — такой староватый из тех времен, когда им еще делали железные корпуса. Он воткнул блок питания в розетку и аккуратно выпрямил шнур CAT-5, чтобы подключить этот свитч к нашей сети. Я хотел наорать на него за всю излишнюю осторожность в такой момент. Дейв сидел рядом со мной, нехарактерно тихо.

Я замер, пока у Патрика не получалось попасть шнуром в нужный порт. Я глядел на передние огоньки — Дейв, наверное, тоже. Мои глаза намокли. Патрик впихнул шнур. Сразу же огоньки загорелись и быстро замигали. Я почувствовал, как мои руки и лецо покраснели, а в углу глаза увидел как Дейв встал и открыл рот, будто пытаясь что-то сказать. Затем он нырнул лицом в сложенные руки, затем его вырвало.

Если сравнить расширяемое приложение с коробочкой, то плагины, это полезные вещи, которыми можно наполнить эту коробочку, придающие новое содержание нашему приложению. В этом ряду стоит и такая вещь как Script‑fu. Но что если я скажу, что Script‑fu так же может быть такой же «коробочкой» и может иметь расширения, давайте разбираться. Но сразу скажу, счастливы будут не все.

Совершать невозможное и раздавать пинки здравому смыслу — в этом и состоит жизнь членов Гуррен-Дана! (C) Камина

Эта статья вступает в техническую полемику со статьей 2015 года за авторством Atakua, подходы из которой я и атакую. Atakua исследует 7 видов интерпретаторов байткода, но делает это без уважения - быстрейшей оказывается двоичная трансляция, которая, по сути, уже не интерпретатор байткода, а форма Ahead-Of-Time компилятора. Эта двоичная трансляция транслирует байткод в машинный код, представляющий собой цепочку вызовов скомпилированных сервисных процедур. Тех самых, что в интерпретаторе байткода отвечают за выполнение каждого опкода.

Но Atakua не выжал из интерпретаторов байткода всю скорость которая возможна. Так что эта статья - туториал: как написать интерпретатор байткода, который может обгонять JIT/AOT-компиляцию по скорости. Интересно? Читайте дальше!

Бенчмарк прилагается. Будет немного хардкора и ни одной сгенерированной нейросетью картинки!

Оказалось, что тема суммирования целых чисел в кодировке ASCII в Haswell со скоростью memcpy гораздо популярнее, чем я мог ожидать. Именно поэтому я решил поучаствовать и в другом челлендже в жанре HighLoad: подсчёт uint8. В настоящее время я занимаю всего лишь 13 место в списке лидеров, проигрываю первому месту около 7%, но уже узнал немало интересного. В этом посте я полностью опишу моё решение, в том числе, удивительный паттерн считывания из памяти. Используя его, можно примерно до 30% (по сравнению с обычным последовательным доступом) повысить скорость передачи в контексте одноядерных рабочих нагрузок, ограниченных размером кэша. По-видимому, этот метод малоизвестен.

Как и в других постах автора, программа настроена для следующих входных характеристик высоконагруженной системы: Intel Xeon E3-1271 v3 @ 3,60 ГГц, ОЗУ 512 МБ, Ubuntu 20.04. В ней используется только AVX2, а AVX512 не используется.

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

Привет, я Антон Полухин из Техплатформы Екома и Райдтеха Яндекса. Моя команда разрабатывает userver — современный опенсорсный асинхронный фреймворк с богатым набором абстракций для быстрого и комфортного создания микросервисов, сервисов и утилит на C++.

Когда мы пишем какой‑то код для userver и для таких сложных проектов, как Boost, периодически мы сталкиваемся с нестандартными проблемами. И эти нестандартные проблемы требуют нестандартных решений. Вот о таких решениях мы сегодня и поговорим.

А именно:

— Посмотрим, как работают исключения на платформе Linux x86, и сделаем с ними что‑то интересное.

— Залезем ещё глубже под капот исключений и сделаем их ещё быстрее.

— Сделаем висячую ссылку на невалидный объект, и всё будет хорошо.

— А под конец то, что все любим, — погрузимся в шаблонное метапрограммирование.