C *

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

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

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

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

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

Многие embedded-разработчики привыкли работать без автоматизированных тестов, полагаясь на ручное тестирование и отладку через программатор. Это кажется простым и быстрым решением для небольших проектов. Однако при росте кодовой базы и команды такой подход приводит к критическим проблемам: баги возвращаются в новых релизах, знание о системе хранится только в головах разработчиков, а каждое изменение требует длительного ручного тестирования на стенде.

Автоматизация CI/CD для embedded-систем решает эти проблемы, хотя требует начальных усилий на настройку инфраструктуры.

В сентябре мы рассматривали релиз 86Box v5.0, приуроченный к тридцати годам со дня выхода в розничную продажу Windows 95, и пообещали показать ещё кое-что. О чём мы сознательно умолчали, и почему оставили находку для отдельной статьи?

Многие разработчики привыкли везде ставить if-проверки, даже для условий, гарантированных кодом. Зачем проверять то, что не может нарушиться? Такие проверки создают шум в коде и мусор в релизе. Assert решает эту проблему: документирует допущения и исчезает из финальной сборки. В статье покажу все преимущества assert'ов и предостерегу от подводных камней их использования.

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

Нет, я не про сложность задач, которые они решают, не про количество кода или его качество, а про то, что они представляют собой для конечного пользователя.

Библиотеки не просто сложны, они выглядят намеренно переусложнёнными, как будто разработчики намеренно делали всё, чтобы то во что они вкладывали годами свой труд невозможно было использовать.

Для незнакомых с ситуацией вкратце - любая библиотека на С это в конечном счёте всего лишь набор .c файлов и набор .h файлов, а также опции компиляции которые записываются в современности в CMakeLists.txt. Для адекватных библиотек CMakeLists.txt обычно состоит из набора опций в самом верху (и только они нужны пользователю) и дальше описания таргетов (библиотеки, исполняемые файлы), зачастую это укладывается в сотню строк

Но по какой-то причине в реальности всё совсем не так и тут нужно смотреть на примеры

Типичным примером можно считать репозиторий OpenSSL. Взгляните на (ЧАСТЬ) того что видит перед собой человек, который хочет использовать OpenSSL:

Всем привет!

В данной статье я хочу Вам рассказать про датчик HEDR(от компании avago technologies) - это двухканальный инкрементальный оптический датчик, предназначен для измерения пройденного пути, линейной скорости, угловой скорости и направлении вращения вала.
С помощью данного датчика будет реализован энкодер на базе микроконтроллера STM32, который будет производить вычисление пройденного пути.

Будет рассмотрено:

Принцип работы датчика HEDR-5420-ES214;

Схема подключения к микроконтроллеру STM32;

Программная реализация (расчет пройденного пути и вывод информации на дисплей).

Привет, мир! Меня зовут Василий, я работаю инженером-программистом в научно-исследовательском институте. Последние лет пять занимаюсь внедрением регистрирующего оборудования на базе микрокомпьютера Raspberry Pi, хочу поделиться опытом разработки. Работа еще не завершена, но материала накопилось много, думаю, он будет полезен всем, кто работает с Linux-микрокомпьютерами и учится писать драйвера для подключения разных железок. Буду также крайне признателен, если отпишутся знающие люди, поделятся советом и укажут на мои ошибки.

Конец осени, первый снег и идеальный момент, чтобы заглянуть под капот системного софта. 22 ноября в Москве соберем системных инженеров, исследователей и разработчиков, чтобы обсудить, как устроены компиляторы, ядро Linux и драйверы. Митап разделен на два потока: С++ и C/Linux kernel. Регистрируйтесь и подключайтесь — офлайн или онлайн.

Может ли Rust заменить C? Этот вопрос беспокоил меня много лет. Тем временем я успел написать upb — библиотеку C для работы с Protocol Buffers, и сейчас являюсь её техническим руководителем. Вполне понятно стремление обеспечить безопасность памяти в пределах всего программного стека — поэтому и возникла идея портировать upb на Rust.

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

Но недавно я открыл для себя одну технику, которая заставила меня немного переосмыслить этот вопрос. Я назову её «Rust без паник». Притом, что этот метод определённо не нов, мне нигде не удалось найти подробного разбора, в котором бы рассказывалось, как именно этот метод используется и какие проблемы решает. Правда, интересная дискуссия по этому поводу велась в теме Enforcing no-std and no-panic during build, где есть ссылки на некоторые релевантные треды из почтовой рассылки, посвящённой разработке ядра Linux. Вот другой интересный тред: Negative view on Rust: panicking

Надеюсь, эта статья позволит заполнить данный пробел.

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

Здравствуйте, друзья, меня зовут Ерохин Кирилл, я программист‑любитель, и в этом сентябре я втихаря провёл соревнование по алгоритмическому программированию на C/C++ под платформу «Эльбрус» (e2k), собрав 31 участника со всей России, результатами которого я решил поделиться с вами. А Хабр мне в этом поможет, ему не впервой.

Всем привет!

Пишу этот пост, чтобы поделиться своим опытом и получить критику или советы от людей с большим опытом.

Мне 22 года, я из Латвии. По образованию я судовой механик, но уже около 4 лет увлекаюсь программированием. Долгое время это оставалось хобби: пробовал сайты, простые игры — но они не приносили настоящего удовольствия. Я считал, что в программировании нужно было разбираться ещё со школы, и долго не верил, что могу найти себя в этой сфере.

Переломный момент наступил, когда я заинтересовался системным программированием. Каждый раз, когда узнаю, как работает низкоуровневая часть ОС, у меня будто открывается новый мир. Особенно зацепила тема процессорного планирования: все говорят «железо, CPU, видеокарта», но на практике даже реализация планировщика процессов может заметно влиять на производительность.

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

Меня зовут Ярослав Бомбов и я более 30 лет занимаюсь созданием АСУТП. Как вы понимаете жизненные циклы в АСУТП штука длительная и иногда возникают задачи что-то добавить в систему работающую уже лет 20. И именно такой случай произошел - возникла необходимость изменить код в контроллере под управлением QNX4.

Можно конечно было поговорить на тему "вы в каком морге этого Франкенштейна получали туда и обращайтесь", но при ближайшем рассмотрении оказалось что код мой собственный ;). Самое простое решение открыть mcedit, что-то поправить и собрать в самом QNX4, но для начала надо вспомнить разобраться как все работает, а это удобней делать в современных IDE. Поиск бинарников OpenWatcom (OW) под линукс дал ровно два архива которые в моей системе не заработали. Поэтому решено действовать по принципу - лучше день потерять, потом за пять минут долететь.

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

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

В данной статье будет рассматриваться разработка коммутатора, для приема, обработки и передачи потока данных от GNSS-приемника и энкодера, осуществляться передача ведущему устройству будет по интерфейсу RS-485.

Интерфейс RS-485 - представляет собой промышленный стандарт физического уровня передачи данных, широко применяемый в распределенных системах управления, телеметрии и автоматизации, его ключевая особенность - использование дифференциального сигнала, что обеспечивает высокую помехоустойчивость и надежность передачи данных на значительные расстояния (до 1200 метров).

Исходный сигнал разделяется на два синхронных сигнала, передаются они по двум проводникам - линия А и линия В образующих витую пару.

На линии А передается исходный сигнал, а на линии B формируется инверсное отражение, в приемной части установлен дифференциальный усилитель, который вычисляет разность потенциалов между линиями:

Если разность положительная (+200 мВ) - логический 0;

Если разность отрицательная (-200 мВ) - логическая 1.

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

Когда речь заходит о корутинах (сопрограммах) на С++, большинство программистов вспоминает фреймворк coroutine_ts, появившийся в стандарте С++20. Многие даже не догадываются о том, что писать корутины можно было задолго до появления упомянутого стандарта. При этом можно было использовать не только С++, но и Си. Данной статьей я открываю серию, в которой хочу описать свой личный опыт изучения корутин и привести примеры их использования. Надеюсь мои статьи помогут начинающим разобраться в этой сложной и интересной теме.

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

Виртуализация позволяет отлаживать драйверы и приложения в идеально воспроизводимых условиях, параллельно работать над разными фичами и начинать писать код еще до того, как готово физическое устройство. Особенно это актуально при разработке и тестировании embedded-решений, где часто требуется работа с периферией — например, I2C-устройствами: датчиками температуры, давления, влажности, EEPROM-памятью и другими компонентами.

Признайтесь, сколько раз вы начинали учить новый язык программирования, открывали очередной учебник с заголовком "Hello World" и... забрасывали через неделю?

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

Особенно это касается языка C:
-- Сложный синтаксис
-- Указатели, которые пугают новичков
-- Управление памятью вручную
-- Отсутствие "красивых" фреймворков для быстрого результата

И вот вы сидите, компилируете очередную программу, которая выводит факториал числа, и думаете...

Рассказ о самой полезной части Nix — управление пакетами из репозитория nixpkgs.

Я использовал и использую разные языки. В Rust есть прекрасный пакетный менеджер cargo и инсталлятор rustup, для JavaScript — npm. Мне также нравится conda в мире Python.

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

Я хотел, чтобы инструмент из коробки давал максимум без дополнительной настройки.

Поэтому я расскажу, как использовать Nix в качестве пакетного менеджера для Си и C++.