Тут ключевое слово "БЫЛ"! На современных процессорах и компиляторах (с включенной оптимизацией) придется очень сильно постараться, чтоб на ассемблере написать хоть немного быстрее.

@@kazancevss откуда такая уверенность, может проверим? Это мнение не больше чем ошибочный миф... Если писать правильно на Си, учитывая всякие преобразования типов, явные и неявные, правильно используя типы данных и указатели, имея понятие, как это всё будет выглядеть после компиляции, то компилятор оптимизирует проект намного лучше, чем человек. А главное намного быстрее и без банальных ошибок присущих человеку! К тому-же в Си вполне возможно будет что-то подредактировать и это не приведет к необходимость переписывать заново всю функцию, компилятор сам все переоптимизирует. Ассемблер имеет смысл только там, где нужно четко зафиксировать количество байт, тактов, и выполнять инструкции в четкой последовательности, или для выполнения экзотических инструкций процессора, которые не предусмотрены языком Си (например барьеры памяти). P.S. работаю с ARM Cortex-M3 именно на этом микроконтроллере согласен сравнивать C vs ASM. Всякие древние x86 не предлагать!

​@@kazancevss ну вот, что и следовало доказать, вы говорите про микроконтроллер с набором инструкций 90-х годов. Меня тоже когда-то очень удивило, как на практике автоматическая оптимизация творит чудеса... Нет смысла писать проект на ассемблере для Cortex-M, не получится заметно лучше, какие-то места может и лучше, а какие-то хуже, в общем в лучшем случае ничего не изменится. Тут больше инструкций предназначенных для конкретных целей, меньше свободных регистров, не остается особо места для всяких извращений и полета фантазии. Большинство узких мест старых процессоров, типа условных переходов, обращений к памяти, извлечения полуслов и изменения отдельных битов, имеет свои специальные инструкции и нет никакой необходимости изобретать велосипед, все делается аппаратно. Кстати только вчера мне нужно было перевести данные little-endian в big-endian, и тут как раз воспользовался вставкой единственной ASM инструкции, REV16, как заставить это сделать компилятор я не знаю. Но писать целиком на асме не имеет никакого смысла... Тут главный вопрос именно в том, что опытный программист знает как написать, чтоб это было оптимально. Для этого конечно нужно знать архитектуру, знать команды ассемблера и понимать, как заставить компилятор сделать то, что хочется, как подсказать ему, что именно и как именно нужно оптимизировать... Всё это нужен опыт, и именно опытность программиста в большей степени определит быстродействие и компактность. А количество ошибок в Си-шном варианте будет точно меньше, хотя-бы только потому, что там меньше строк.

@@kazancevss Мне тоже несколько раз дизассемблировать приходилось. Так вот, что скажу, это не компиляторы кривые, это руки кривые у тех кто библиотеки к этим ARM-ам писал. Там только от этих вложенных функций на одно действие с ума сойти можно... Ни к чему не призываю, у каждого есть свой опыт, свое мнение. Взаимно))

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

Наверное по этому сейчас в новом железе нету поддержки Windows XP, она просто быстрее Windows 10. Пробовал на своём уже старом ПК на 1156 сокете, жаль ХР лишилась поддержки ряда нужных мне программ, так бы на неё перешёл а так на Windows 10 LTSC сижу.

Колибри??? )

Бесконечное согласие с комментом

Все просто, стоимость машинного времени сейчас ниже стоимости времени работы программиста.

Правильные мысли!

Наоборот Ардуино остановил развития даст возможность дебилов делать свои программы и проекты и распространят их на вес мир, а те кто смогли бы сделать это все профессионально остались без работы и пошли мыть туалеты. Ардуинчики их хлеб взяли а они им будут помагат да? Все эти опен сорс проекты как Arduino, Raspberry Pi, CMS, и так далее хрен делают что бы установит технического развития и убит малый и средний бизнес и остались одни корпорации и разумеется Ардуинчики дебилы. Тот кто хочет он и без Ардуино может заниматься электроники и делать свои проекты, только после Ардуино он эти проекты некому продавать, потому что каждый дебил скачает все на готово и сделает себе что захочется

@@logicfacts9964 ахахахахаха))))))

Ахахахахаха, ардуинщики отняли работу у настоящих программистов и инженеров, ахахахахаха)))))))

@@LiebGoth А ты все время о себя та у себя. Хватит о себя. Если ничего разумного сказать не можеш лучше стой молча

Hamster Time , понимаю чуть больше, но тоже было интересно)

Нифига не понял, но очень интересно)

@@33KK слышу какой то набор звуков и всё ровно интересно )))

@@XYZ.cnc. , не смотрел видео, но интересно. Кажется, дальше абсурдность поднимать уже некуда )))

Вы о чем? Очень интересно :))

Таких уроков в youtube не мало, например погуглить программирование stm32. Конечно везде есть ошибки... Но как говориться, не ошибается тот, кто ничего не делает. Информации много, учитесь, разбирайтесь, никто вам свои мозги не подарит. Есть конкретные вопросы, задавайте, отвечу.

Скачайте и посмотрите. Потом тут напишете. :-)

Обычно использую avr-gcc, он без проблем оптимизирует установку/снятие бита через битовые операции с чтением в одну инструкцию sbr/cbr

Нормальное ПО стоит денег, а эта халява всегда боком выходит.

Почему забивают? Код: PORTx |= (1

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

@easyJet А с чего бы им переставать? У них объемы продаж микроконтроллеров огромные, они могут себе позволить снижать цену за счет количества продаж. Сейчас STM32 уже во все, что угодно пихают, от mp3 плееров до роботов и промышленной автоматизации... Даже если ST поднимут цену (что вряд-ли) остается еще множество аналогов на тех-же Cortex-ах. Да и у ST уже есть полные китайские аналоги, еще дешевле и даже быстрее Giga Device (GD32). Кто перешел на ARM-ы назад не вернется!

Очень спорно, особенно по поводу будущих инженеров. Осмелюсь предположить, что "ардуинщиков" мы получили сильно больше, но толку то от них? Также, осмелюсь предположить, что без ардуино библиотек инженеров было получено сильно больше. Короче, корелляции между количеством инженеров и существованием ардуины нет.

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

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

В свое время ВМ80 в HEX программировал, то еще удовольствие) Зато фундамент в понимании программирования просто железобетонный дает.

@@terrakottech417 Нет ничего странного. Рубят бабло, экономят на программерах. Библиотеки явно кто-то бухой сонный и зеленый пишет. Во многих девайсах тырят опенсорс и не открывают код по лицензии, чтобы скрыть позор и подлог.

@@AxGxP , они стали исправляться. Время выполнения некоторых команд сократили до адекватного.

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

На максималке, 72 MHz.

Где - нет разницы. Главное желание и соответствующий склад ума. Поймите, где бы Вы не учились, никто вам свои мозги не поставит. 90% зависит от Вас, и только 10% от "учителей".

У него же вроде есть по Си, без плюсов, я считаю, что актуальнее. А по поводу микроконтроллеров, документации от производителей вполне достаточно. AVR наверное проще, зато с STM можно отладкой на лету пользоваться, без значительных дополнительных вложений. В любом случае рекомендую с 8-bit начинать. А 32 - STM мне намного больше нравится.

@@AxGxP интересно ответишь или нет, но после последнего вопроса где то 3 месяца лета я поработал и подеградировал и только вот последние 3 месяца из которого первый месяц учил авр а потом последние два учу stm32. Как адекватный человек учу с cmsis с голыми регистрами чтоб понимать каждый такт и чих. Рекомендуют перейти на халл, но не хочу. Возможно в будущем когда я буду профи буду кое что брать с халла. Во время универа были проблемы с обучением, относительно меньше времени уделял. Но вот с начала декабря как вышли на зимние каникулы каждый день стараюсь по максимуму учиться. С голой документацией тоже проблематично. Я долго откладывал темы с таймерами в стм наивно полагая что они так же просты как у авр, но тут оказывается так много настроек и возможности. А в документации не сразу понятен алгоритм настройки шим или захвата импульса. Да кое что написано но по любому лезу по форумам. Можешь дать какой то совет по изучению? или как гуглить интересную тему. Ибо что б я не гуглил с стм всегда выходит халливар

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

@@AxGxP у вас есть телеграмм? Я обычно так и поступаю. Перехожу с переферии на переферию по рм. Но бывают моменты, когда из за большого количества регистров, просто не понятно алгоритм действий для настройки.

Представьте, что Вам надо быстро получить каноэ из бревна. Вы его будете выдалбливать топором (Си) или вырезать скальпелем (ассемблер)? Каждый решает сам, как он будет достигать результата.

@@Al.Sy. , конечно вначале пишется основа на языке высокого уровня, а потом дорабатывается на низком, в углах, где есть проблемы и недоработки, но последнее занимает порой годы. Другое дело, когда попутно правятся библиотеки и в новых проектах уже используют более удобный и точный инструмент, но это уже наработка каждого разработчика под себя. Невозможно изучить какое-либо дело с нуля за пару дней, если делом не заниматься постоянно, ни о каких сверх результатах надеяться не приходится. За примером ходить далеко не надо, посмотрите историю создания проигрывателя WinAmp.

@Lada Timofeeva , была уже где-то на АВРе... :-)

Чтоб сделать программный USB на микроконтроллере с ограниченными возможностями конечно ассемблер. Проект MJoy называется, напиан в 2003-м году на ассемблере под микроконтроллер AVR. На то время ничего лучшего, за адекватные деньги не было... Сегодня есть дешёвые и мощные Cortex, но некоторые почему-то продолжают жить в прошлом.

увидел 1.8.5 )))

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

Однако у стм32 рефмануалы от 1000 страниц начинаются, поэтому даже опытные программисты в первый год знакомства боятся всю программу делать на регистрах а не на ХАЛовских абстракциях

@@nixtonixto у NXP даже посложнее имхо

я БЫ ПЕРЕШОЛ ДАК ВЕДЬ НЕЗАДАЧА ПОД СТУДИО НУЖЕН РЕАЛЬЬНО ДОРОГОСТОЯЩИЙ КОМП

@@user-zi8kn9sl1g что за бред? Любой комп подойдет.

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

Я не умолчал, а просто явно на этом не акцентировал. Сегодня опции оптимизации это обязательная фича любого компилятора. На 2:00 в тексте написал, что в Arduino IDE настроек оптимизации к удивлению нет (там всегда с -O3 GCC компилит). Конечно-же на всех примерах в этом видео одинаковые условия, включена оптимизация -O3.

Неа, грохнул...

Маловероятно... Точнее, что-то может и можно найти, но там другие глюки вылезут. Подход у людей разный... Многие пишут программы с помощью копипаста (весь рунет завален однотипными ошибками), другие используют библиотеки (в большинстве из которых четко написано "распространяется как есть, автор не несет ответственности, и не гарантирует работоспособность"), но я рекомендую самый надежный способ - открыть документацию и написать согласно datasheet, хотя там тоже иногда ошибки попадаются, но это достаточно редкое и обычно относится к уникальным конфигурациям. Так вот, я когда первый раз взялся программировать на STM32 тоже думал, что все очень сложно, и неделю времени убил пытаясь заставить работать все, что мне надо с помощью библиотек всяких.... В основном безрезультатно, лучший случай был - работает 10-15 сек и зависает нафиг... Для того, чтоб поиграться - пожалуйста. Но если делать готовое устройство, никаких opensource библиотек, только хардкор))) Дешевле получается, не смотря на кажущуюся на первый взгляд сложность.

Китайский клон на Saleae... Там разве ссылок в описании нет?

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

На 72.

Есть не мало на youtube, рекомендую посмотреть Sappise или narod stream. Но в любом советую читать мануалы, самое главное это Reference Manual и Datasheet. Ну а потом, если хотите стать настоящим программистом на STM32, и вообще на ARM, нужно ознакомится с Programming Manual и Cortex M3 Technical Reference Manual. Если английского не знаете - очень плохо, нужно учить, а покамись учите поищите "Мартин М. Инсайдерское руководство по STM32", там на русском. P.S. Вместе с библиотеками STDPeriph идут примеры, по ним можно учится, подсматривая мануалы, так как в примерах есть некоторые ошибки.

В ардуино только на Си и пишется, компилятор GCC. Если писать через регистры возможно удасться добиться почти той-же скорости. Но Arduino запрещает доступ к некоторым регистрам, а также не позволяет настроить режимы оптимизации компилятора. А самое главное неудобно, сложно и медленно писать что-то в ардуино.

@@AxGxP я пишу в Sublime с плагином, это чуточку удобнее)

У Espressif IDF SDK хорошо задокументирована.

Конечно пробовал) LL в этом смысле очень не плохо работает, там большинство функций инлайнятся и в них нет ничего лишнего, просто можно сказать более понятная запись чем через CMSIS. Только вот CubeIDE часто генерирует код LL с ошибками, что затрудняет разработку. С HAL в этом смысле лучше, автогенерация обычно исправно работает. Но в HAL есть много всякого лишнего, поэтому и скорость программы страдает, и ROM и RAM нужно заметно больше.

Неужели вы думаете такие, что такие существуют? Кому это надо?

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

кто Это будет делать ? Сказать вот я поравил библиотеку теперь она быстрее и выложить для людей. Лучше же обгадить все и вся в и плакаться как все хуево.

@@sssserya1 это не каких то две строчки) так может вместо того чтобы плакаться как всё хуево и никто не делает хорошую библиотеку ты соберёшь деньги и наймёшь разработчиков?

@@Baton1804 та ничего там удобного в ардуино нет , начнете делать что-то нормальное и только время потратите . и закончится тем что будете сами писать библиотеки для вашего проекта

Нет, не зло. Это удобный вход для начинающих, крайне удобный!!! Я несколько лет не хотел заниматься МК, из-за их сложности, (поэтому работал на логике), но на базовом знании ардуино собрал работающие(уже несколько лет,) устройства. Стало тесно и вот я уже изучаю stm))

По большей части библиотеки на МК в продакшене - это попросту недопустимо

@@user-fs7ml9ql9q , что такое продакшен? Типа массовое производство?

Да, имелся ввиду этап перехода от прототипа к проектированию серийного образца

Удачи! Обращайтесь, помогу, чем смогу.

Я правильно понял, любой скетч написанный в arduino IDE, в 28 раз медленней, чем скетч написанный в правильной среде разработки?

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

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

Наверное можно... Разные способы есть, надо смотреть код. Фигуры на дисплее или для чего используются?

Ну так и посмейтесь, youtube же развлекательный портал! А то, что по вашему "бред" - факт давно признанный производителем. Мне вот интересно, почему так StdPeriph защищаете, к MCD Application Team имеете отношение? Хотя нет, знали бы, что ST сами считают ошибкой создание STDPeriph, в связи с безнадежностью реализации, и даже создали специальную утилиту, для автоматической миграции с STDPeriph на LL.

Ссылок на пруфы конечно же не будет? Давайте вы не будете говорить за ST, а просто покажете где они сказали, что STDPeriph - ошибка (именно ST). Далее, возьмем любую функцию из STDPeriph, которую вы назвали кривой, например GPIO_SetBits: void GPIO_SetBits(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin) { /* Check the parameters */ assert_param(IS_GPIO_ALL_PERIPH(GPIOx)); assert_param(IS_GPIO_PIN(GPIO_Pin)); GPIOx->BSRRL = GPIO_Pin; } Код одной строкой, но разбирающийся программер поймет. И так, если там исключить проверку параметров (assert_param), а она по умолчанию выключена, я писал уже об этом, то остается GPIOx->BSRRL = GPIO_Pin; - это и есть прямое обращение к регистрам, просто завернутое в функцию GPIO_SetBits. Ну и в чем тут криворукость разработчика? Да, это не inline функция, но это ж библиотека!!! Они дали вам возможность легко включить ловушки возможных ошибок, при отладке, а вы называете это криворукость!ю? Посмотрите правильные примеры кода, как этим вообще пользоваться.

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

Нет, дело не в assert_param, они не были включены. Задержка возникает именно из-за вызова функции. Если посмотреть листинг disasm, то разница небольшая, всего в две команды, но появляется 32-битная команда перехода, из-за неё и возникает большая задержка. Дело в том, что контроллер flash памяти(FLITF), в которой и находится программа, работает на частоте всего 8MHz (FLITFCLK всегда подключен к HSI). Чтоб обеспечить возможность выполнения программы на частоте ядра 72MHz на шине ICode существует 2х64-бит буфер (prefetch buffer), в который и читаются команды процессору с опережением. Но когда мы вызываем функцию линейное чтение памяти нарушается, и ядро вынуждено ждать пока медленный контроллер памяти считает команды по нужному адресу, а при возврате из функции эта ситуация повторяется. При написании программ нужно знать этот нюанс. В библиотеках LL это уже учтено! Все короткие функции имеют директиву inline, что в несколько раз повышает производительность и уменьшает код. По поводу того, где ST сказали, что это ошибка даже не стану искать, это на какой-то конференции было, естественно, что они не идиоты, и не напишут у себя на сайте что их продукт фуфло. Но косвенно об этом можно судить и на сайте. Попробуйте скачать STDPherip на официальном сайте, вам сразу предложат HAL, LL и даже утилиту SPL2LL для переделки вашего проекта с STDPeriph на LL.

Хоть я и продолжаю использовать SPL в своих проектах, уже учитывая многие ошибки, мое отношение к её разработчикам уже никогда не поменяется. Из-за ошибки в библиотеке I2C я когда-то потратил неделю или больше времени, чтоб запустить тогда еще засекреченный DMP (Digital Motion Processor) на MPU6050. Какие сложности были, чтоб получить хоть какую-то документацию, подписание всяких соглашений о неразглашении и т.д. а оно нихера не заработало. Я уже тогда начал думать, что IvenSense не все документы дали, или специально какую-то ошибку в них сделали. И даже посоветоваться не с кем, в инете инфы конечно тоже нет. Только после долгих колупаний с логическим анализатором, я обнаружил, что MPU5060 зависает именно после передачи трехбайтной последовательности. Все заработало, только после того, как я сам переписал эту библиотеку.

@@AxGxP я занимался с avr некоторые проекты до сих пор работают . Но там не пользовался библиотеками . Чисто как логика не соожные вычисления . Как на авр с библиотеками ? Можно ли модули от ардуино прикрутить к avr . Интересует мп3 модуль . работа с сервой . И модули передатчиков. Возникла необходимость попаять. Ивот мне щас определится авр вспоминать . Или с ардуино связаться. Ардуино исключительно только из за модулей . Очень подкупает .

@@olegotdelka37 раза два пробовал пользоваться чужими библиотеками - лотерея ещё та, если и заработает, то от глюков долго избавляться придется! Когда квадрокоптер программировал почти две недели убыл перебирая разные библиотеки и в попытках заставить работать все вместе. А когда эти все датчики запустились вместе и вроде как все заработало - оно начало зависать через 12-15 сек после запуска, дальше нервов не хватило. Грохнул все, написал сам все, что надо, через два дня уже летал на проводе)) Так что мое мнение, нужно брать документацию на микросхему и использовать её в удобном режиме. Это будет лучше и быстрее, и места кучу сэкономит! А на ардуино в крайнем случае можно проверить работоспособность одного модуля, а если он в проекте не один - никто ничего не гарантирует.

@@AxGxP 1 тоесть всё риально самому на писть . 2 2 И модули от ардуино можно подружить с процем ? 3 на ардуино проще но не факт што всё дружно работать будет. 4. сильно ли отличаются програмирование на ардуино и на авр в плане команд ? Ну за исключением настройки частоты и фюзов . Я про само тело программы . Как я заметил очень похоже но ардуино у меня нет не очень понятно .

@@olegotdelka37 ардуино это не язык и не процессор, это просто набор кривоватых библиотек. Все ардуино это тот-же C/C++.

@@AxGxP ну и нахер не буду покупать . Программатор куплю и макетку . Щас с ком портом проблеммы старый мой не подойдет. Да и в протеусе чудесно все моделировались

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

@@sergnova528 Лучшая литература - это даташит микроконтроллера и application notes, а если с регистрами уже привычно работать, то переход вобще будет безболезненный. Я как бы и сам не спец в ассемблере, но AVRASM настолько простой что там не запутаешься. Там всего сотня с хвостиком инструкций из которых повседневно будут использоваться от силы полтинник. Главное попрактиковаться с branch инструкциями, прерываниями, периферией после этого разницы от С не ощущается. Даже AVR Studio использовал только для отладки если было лень разбираться где накосячил. По началу ещё заглядывал на avrfreaks и просматривал интересные проекты на хабре и радиокоте. На ARM до сих пор не рискнул на асме писать. Ознакомительный курс прошёл, книжку прочитал, но там всё настолько запутанно, что можно только охарактеризовать фразой "стопиццот методов сложить 2+2". Там лучше на С/С++, да и обилие ресурсов не требует такой оптимизации.

Компилятор один и тот же

@@dima_dmitrenok У студии должна быть оптимизация только если на этом профит получить, может конечно и в ардуино можно через ключи это задать.

На что на смартфонах, что на PC проблема есть, у вторых даже хуже. Если углубиться, то все началось с изобретения транзистора и внедрения интегральных схем))) Вряд ли кто-то поспорит с этим прогрессом, да и современные компиляторы прекрасно справляются, не многие вещи на ассемблере ещё можно сделать лучше, чем это сделает компилятор с правильными опциями оптимизации. Кодить стало быстрее и проще, поэтому многие программисты забыли (а некоторые даже и не знали) что на самом деле происходит при вызове функции, выполнении сравнения, даже банальном преобразовании типов, явном и неявном. Появилась целая пирамида вложенных функций и библиотек... Пошла мода не исправлять ошибки, устраняя их причину в корне, а делать заплатки, а потом заплатки на заплатки, и т.д. В итоге имеем то, что имеем - лохмотья, кучу дыр и множество заплаток.

Объясните подробнее, что именно вас интересует?

Никола Пшоня *_Должно быть наоборот...._*

Работа с регистрами всегда работает быстрее. тест проходит на 9-10 сек быстрее.

Никола Пшоня *_Sbi и Cbi - старые DDR и PORT. _**_goo.gl/8FF1Y3_*

Ага, сейчас люди друг-другу объяснить не могут, чего хотят, а искуственный интелект будет уметь мысли читать?

Конкретных тестов я не проводил, но наличие значительного количества разных проверок, callback функций и т.д. вероятно сильно замедляет работу программы. Вместе с HAL сейчас распространяется LL, предназначенная как раз чтоб избавится от громоздкости HAL, но мне тоже пока не довелось ею пользоваться. Для большинства моих проектов вполне хватает CMSIS и StdPeriph. В чем-то более мощном чем STM32F103 необходимости не возникало. Только один раз не хватало USB-HiSpeed, а для этого уже надо хотя-бы STM32F4xx. Главный плюс HAL в простоте настройки USB с помощью Cube, и на этом все. Мне проще было потратить день-два и разобраться, как создавать необходимые USB устройства без HAL, тем самым избавляясь от уймы бессмысленных структур.

Ну а LL зачем тогда? И как оно вообще применяется, а то LL вместе с HAL завязано вроде, не стал вникать. Есть где инфа по этому поводу?

Да, STM32 во всех тестах на 72 Mhz.

А детские кубики, конструкторы с большими элементами -понимаешь? Для начинающих.

Все хорошо а ты попробуй подцепить i2C дисплей через Codevision