Смотря, что Вы подразумеваете под "содержится в ЯП". Если "содержится в стандарте ЯП", то любая программа должна решать проблемную задачу, иначе она просто не нужна. Следовательно, ничего о решении целевой проблемы в стандарте Вы не найдете. В программе будет содержаться логика решения проблемной задачи. Будь это коммуникация по MQTT или динамическое связывание с учетом ограничений ABI.


Официальная "ARM for Embedded Developer Guide"? Ну-ну )))


Это лишь наиболее очевидный пример того, что невозможно программировать, зная лишь стандарт языка.
В более общем случае, попробуйте почитать требования к вакансиям. С удивлением там обнаружите, что кодер (знающий только ЯП) вообще никому не нужен. В обязательных требованиях будет, для примера, Kafka, ClickHouse, gRPC, ProtoBuf, RabbitMQ, MQTT, PostgreSQL k8s и прочее, чего в стандарте ЯП обнаружить не удастся. И в итоге выяснится, что знания о конкретном ЯП для разработчика - лишь незначительная часть того, что ему действительно необходимо знать.


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

-- поскольу это несколько отличается от предыдущих вариаций твоих постов, то отвечу -- я не говорил вообще что в стандарте должо быть решение какой то задачи, в том числе описание того как надо писать логику -- это уже прерогатива каких-то гайдлайнов... Относительно к стандарту я указывал на общие концепции, которые применимы в коде, ты же начал внедрять неверный свой вывод, что требуется знать ABI как сущность ЯП и в соответствии с ABI кодировать так или иначе. При этом ты подразумеваешь, что необходимо как либо использовать сущности, которые должны пользоваться этим ABI. Хотя таковое вообще не предусмотрено ЯП -- о чем я уже многократно высказывался -- по этому прекращай вести этот нелепый спитч про сущности, которые не могут никаким образом повлиять на процесс программирования на определенном ЯП (в частности у нас тут обсуждение С++ было). Никакого механизма для управления dynamic linkage ЯП С++ не подразумевает в себе -- он даже не содержит такого понятия -- такого не существует в нем... В своей программе ты можешь задать какую угодно логику взаимодействия, используя средства ЯП -- ничего больше не требуется.

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

-- какие же в коде должны быть изменения? Я как и впредь предложу обратить внимание на тот факт -- что ты возможно пытаешься не там изменять для достижения своей цели? Такое называется "костылями" как я считаю.

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

У меня джиттера нет, ввод/вывод происходит после прерывания когда процессор спал, засыпает он всегда не позднее 950 мкс, когда завершит все текущие одномиллисекундные задачи. Сначала все активные задачи основные, после процессор запускает ADC на 700_й микросекунде, по очереди каналы, сам находится во сне во время работы ADC, просыпается только переключить канал и сохранить результат, после в сон до прерывания 1 миллисекунда, далее уже повторю - ввод/вывод по SPI.

Эт чё за херня?

Это по теме - хитрый алгоритм, но тебе похоже это не под силу понять.

Любой "хитрый алгоритм" - это джиттер. Джиттер почти отсутствует только у аппаратного процесса, да и то нужно постараться.
Например, триггер Шмитта - это гарантированный высокий уровень джиттера. А практически все ноги современных МК по входу - триггеры Шмитта.

Простой способ изменить порядок битов в байте.
Идея отсюда: In C/C++ what's the simplest way to reverse the order of bits in a byte?

напр. 0b10010011 -> 0b11001001

С листом бумаги и карандашом за минуту (и меньше) ясно, что делает метод .
Давно пользуюсь, например для зарядки данных в TM1637 по протоколу I2C (аппаратная или программная, без адреса).

Хочется сказать, что ноги завязаны на тактовую частоту МК

Это зависит от архитектуры. Но программное чтение порта несомненно завязано. Однако ТШ сам по себе способен вызвать джиттер, Особенно для сигналов с не крутыми фронтами.
Есть пины способные работать асинхронно с внутренней аппаратной периферией. И тогда ТШ станет камнем преткновения.

Хорошая идея, но неплохо было-бы уточнить для какого процессорa. Понятно, что на С будет работать на любом, но в АРМ это делается одной командой RBIT процессора. Кроме того, для использования аппаратного SPI (не I2C) драйвера с TM1637 в них имеется выбор засылки данных начиная с msb или с lsb, так что программное инвертирование битов не требуется. В аппаратных I2C драйверах такого выбора не встречал, так что может иметь смысл. Однако, при программной реализации I2C можно выталкивать биты сдвигом байта влево или вправо, так что дополнительное инвертирование порядка битов не требуется.

[uquote="veso74",url="/forum/viewtopic.php?p=4757753#p4757753"...напр. 0b10010011 -> 0b11001001

С листом бумаги и карандашом за минуту (и меньше) ясно, что делает метод
[/uquote]
Такой код выполняется за 17 тактов. Даже карандаш с бумагой доставать не надо. К тому же позволяет выполнить любую перетасовку битов.

Для простого разворота я всегда использовал пару сдвигов через С ROL/ROR (те же самые 16 тактов на байт). Но если нужна особая перестановка, то использование BST/BLD, конечно, без вариантов.

Ser60, для AVR, PIC, STM8/32, CH32, GD32, APM32, Teensy, ESP32 и другие.
Пo I2c oсобенно эффективно для МК с небольшим количеством пинам и ресурсам, при наличии других периферийных устройств на стандартном I2c. Прогр. код для комуникации с дисплея уже написан и не нужно писать новый (bit-banging).

---
Нашел для APM (Keil, arm_acle.h), спасибо, буду использовать.

Инвертирование порядка бит является фундаментальной процедурой FFT. Именно поэтому в любом процессоре рассчитанном на БПФ есть реверс битов как отдельная инструкция.

Для байта то - зачем так? Неужто нет места на один 256-байтный массив? Для архитектур, где нет спец.команды, проще и быстрее имхо - трансляцией через массив.

jcxz, какой, на хрен, 256-байтный массив, чтобы развернуть биты в одном байте?

А что не так?
Исходное значение - индекс массива, результат = значению по данному индексу.

jcxz, а если понадобиться развернуть двухбайтовое число, ты предложишь массив из 65536 байт?

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

КРАМ, извини, но вопрос был задан не тебе.
и еще я не спрашивал, какие способы существуют и сколько их.
я спросил про конкретный способ, который предлагает jcxz.