И главное ну вообще без малейших тормозов.

Это ерунда. Вот если вы придумаете обратное преобразование, такое же простое, вместо sscanf...

@@user-pc9wg4jt8l stoi

@@user-pc9wg4jt8l Вот скоростная преобразовалка HEX текста uint8_t HEXToInt(uint8_t *Buf) { uint8_t rint; if (Buf[0] >= '0' && Buf[0] = 'A' && Buf[0] = '0' && Buf[1]

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

Прочитать с sd карточки, прочитать из внешней flash. Как текстовые константы.

Спасибо

Я зарабатываю деньги на жизнь изготавливая электронику на заказ. А данный канал это просто блог. Если мне закажут изготовление MIDI устройства, то я его сделаю, а про интересные моменты расскажу на канале. Однако я скажу вам что в MIDI ну вообще сложного ничего нету и масса примеров есть. И кстати видел что на одном из каналов вам это видео уже обещали. Скоро сделают.

@@VladimirMedintsev да уже на всех обещали) не сделают никак)

Т.е. исходников www.chipdip.ru/product/midi которые даются вот с этим набором мало? Да и вот dml.compkaluga.ru/forum/index.php?showtopic=95923 с исходными текстами.

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

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

@@VladimirMedintsev Я только начал изучать микроконтроллеры, остановился на STM32, но с IDE еще не определился, с одной стороны CubeIDE предлагает сам производитель ST, плюс она бесплатная а с другой стороны все примеры в интернете в основном на Keil, IAR

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

С Си у меня проблемы. Я перешёл из схемотехники..

@@VladimirMedintsev Ссылки и указатели - это организация косвенной адресации. Т.е. обратившись по указателю к 32-хбитной переменной и далее увеличивая этот указатель я буду перемещаться по байтам???? Так было бы в 8-ми разрядном МК и то на ассемблере. Здесь такое явно не пройдет. Или я не правильно вас понял???

А Илон Маск это кто?

@@VladimirMedintsev какой-то очередной американский блогер наверное

@@alexandrakovshova3748 ну да типо того)

Дык я про то и говорю.

Что то у тебя не то, у меня небольшой проект под f103c8t с freeRtos, hal и использованием sprintf примерно так же весил. (Keil5)

Рука-лицо.

@@VladimirMedintsev И что эта фраза значит?

@@VladimirMedintsev Добрый день, Владимир. Давно на вашем канале, и ваше мнение для меня является экспертным. Я может быть много прошу, но если у вас найдется минутка, не могли вы сказать чем плох этот пресловутый xprintf?

@@ravil6018 Вот тут есть хорошая статья на эту тему. Там ближе к концу прямо отдельный раздел по xprintf. we.easyelectronics.ru/Soft/formatnyy-vyvod-na-si-dlya-mikrokontrollerov.html

@@VladimirMedintsev Понял. Спасибо большое!

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

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

@@JingoBo префиксный инкремент это l-value, а постфиксный это r-value, тут компилятору сложнее сообразить, если Google Code Style не авторитет, вот Yandex clickhouse.tech/docs/ru/development/style/ 32. Всегда используйте префиксный инкремент/декремент, если постфиксный не нужен. for (Names::const_iterator it = column_names.begin(); it != column_names.end(); ++it) за каждым for-ом в ассемблерный код не налазиешься, лучше сразу писать правильно, читабельность такая-же.

Если речь идёт об итерации (цикла for, в частности), то операция ++ используется исключительно ради побочного эффекта, т.е. нас не волнует значение, ею порождаемое. В этом случае машинный код будет одним и тем же, напиши вы ++i, i++, i+=1 или i=i+1 - компилятор с этим справится. Это справедливо как для Си, так и для C++, если не используется поделие под названием STL. В случае же STL в форме ++i значением, возвращаемым из operator++, будет _новое_ значение итератора, при этом возвращается ссылка на свой собственный объект - "бесплатная" операция, которую оптимизатор всё равно выкинет. Если же используется форма i++, нужно вернуть значение, которое _было_, поэтому приходится сделать копию самого себя (на стеке, есстно) и вернуть объект по значению (переменная ведь локальная), что бьёт по производительности, т.к. оптимизатор тут уже практически бессилен. Именно по этой причине STL-фаги "настоятельно рекомендуют" в C++ всегда писать ++i, т.е. просто вот взять и привыкнуть писать вот так, и никогда не писать наоборот, чтобы не вызвать "не тот" метод итератора. Но в обозначенном выше примере это, повторюсь, не играет никакой роли.

@@user-dk6nt5gg9b любопытно, как использование STL может повлиять на инкремент инта?

В цикле 1000 итераций. Соответственно автор и говорит в видео о времени одного вызова sprintf.