Тормознутость Ардуино... Сравнение скорости (Arduino vs. AVR vs. STM32)

[@SkyVladTV]

Шикарный монтаж, это ж какой труд! Уважаю специалиста в своем деле!

[@xKyPAx]

Ассемблер всегда был быстрее. Но жизнь слишком коротка.

[@AxGxP]

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

[@AxGxP]

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

[@AxGxP]

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

[@AxGxP]

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

[@Violancergta]

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

[@Argentum79]

Аж слеза навернулась... :( спасибо.

[@treugolinik]

Длинная беседа и как посмотрю людей критикующих библиотеки и платформу ардуино не мало ну так в том и смысл OpenSource чтоб пониммающие ребята писали библиотеки и проги лучше так давайте создадим репозиторий в который зальем переписанные и оптимизированые библиотеки дадим советы как писать тру код для ардуинки чего попусту языком теребить. Перепишем IDE убрав JAVA из него и добавив елементарных функций, напишем модуль и конфиги для более простой работы с Vim. Лично как по мне Arduino дала толчок к тому чтоб больше людей интересовались програмированием и хардуером а функция знающих и понимающих ну как все тут давать более точные и правельные знания.

[@MaiklTil]

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

[@logicfacts9964]

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

[@LiebGoth]

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

[@LiebGoth]

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

[@logicfacts9964]

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

[@alexs8579]

Такое счас не только в мире микроконтроллеров, но и в мире софта. Большое количество надстроек программирования, порождающих другие надстройки, ведет к тому, что тормознутость нивелируется увеличением тактовой частоты и количеством ядер. Мы с этим столкнулись еще во времена ВИН95, когда написанная на ассемблере мультиоконная графическая ОС умещалась на дискете 1.44 и работала на самом слабом железе, позволяя реанимировать че-то пк. тогда еще не было лайв сиди или рекавери флешек. Немного отступления: "и возомнили люди себя богами"... "и смешал он их языки, что бы не могли они понять друг друга" .... Да тут и смешивать не надо, мы сами себя закапываем в расстантартизации и увеличении паразитного кода. Вместо того, чтобы заставлять думать, мы все создаем и создаем "более дружественный интерфейс" и как результат сравнивая по моей отрасли качество софта с 15 летним... извините, но доступность и легкость и скорость написания идет в ушерб надежности и простоты. Есть незыблимый закон физики чем больше шестеренок в механизме, тем меньше его КПД.

[@ТауБөрісі]

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

[@ЮрийСамофал-ю9ь]

Колибри??? )

[@qybsrir]

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

[@sam_po_sebe_35]

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

[@ДанилаГладкий-л8к]

Монтаж и в целом подача великолепны А возможности оптимизации кода под восьмибитный AVR поражают

[@terrakottech417]

Великолепное видео (да и весь канал), спасибо! В ответ тем, кто пишет, что Arduino это игрушка для детей и т.п. могу сказать, что всё зависит от поставленной задачи. Минусы Arduino известны (согласен со всем, что сказано в видео, в т.ч. в поле «фанатам Arduino не читать» :) ), но его плюсы это быстрота и простота реализации ряда задач. Притом человеку практически не нужно обладать никакими знаниями в области программирования и схемотехники. Если для реализации задачи достаточно быстродействия и функционала (самого дешёвого китайского) Arduino (и тех малых знаний человека), то не важно, во сколько там раз родной AVR, или STM будет быстрее. Можно сделать сравнение с тем, что нет смысла стрелять с пушки по воробьям, когда их можно поразить пневматической винтовкой. Ну и конечно для того чтобы заинтересовать детей (и не только) данной темой, Arduino, я думаю, подходит лучше чего-либо другого. P.S. Говорю всё это как человек, впервые познакомившийся с программированием AVR на ассемблере, а уже потом программировавший AVR на C в то время когда Arduino ещё не был таким популярным.

[@AxGxP]

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

[@terrakottech417]

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

[@ОлегВоденников]

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

[@FLomasterZ]

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

[@Vlad_4572]

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

[@durnevm]

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

[@Bagasl]

Ну зачем так качественно и наглядно, придется подписаться и поставить лайк

[@andrumosko687]

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

[@makoveliprod]

Кстати, если на AVR переписать вывод данных типа i2c spi на ассемблер, то можно еще раз в 5 ускорить выполнение передачи 8 бит данных. В ассемблере AVR есть специальные команды, ускоряющие вывод отдельных битов в порт. Только вот компиляторы на это забили... Ну и время входа в прерывание тоже затягивается в пару раз из-за сохранения огромного количества регистров перед выполнением тела прерывания (потому что си).

[@TheMorpheus017]

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

[@windy_sky]

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

[@kardanium]

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

[@markgajevskis8824]

Как STM Microelectronics говорит: разработка Std peripheral library была прекращена. Взамен появились HAL и LL. Былобы интересно их быстродействие увидеть. 👍🏻

[@vovan5341]

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

[@peterlents983]

Все супер, но блин Ц.Э.Л.К.А.!!! Пин читается - КЛОК! :)

[@Oleg_Parfenv]

Без ардуино библиотек мы бы не получили столько энтузиастов и будущих инженеров. За это разработчикам спасибо. И за видео спасибо. Всё так, как и должно быть.

[@qybsrir]

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

[@HamsterTime]

Не очень понимаю в програмировании, но было интересно)

[@Vlad_4572]

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

[@33KK]

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

[@XYZ.cnc.]

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

[@АндрейИ-ф3л]

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

[@ДенисШилов-ц2г]

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

[@АлександрПронин-х3ъ]

Невероятно ценный и полезный эксперимент Вы провели, показав, что ардуино в помойку, индусские библиотеки STM тоже в помойку. Для Real-time программ ( например оцифровка звука внутренним АЦП и передача его по радиоканалу посредством СС1101) программа пишется, только путем жесткого "вкуривания" даташита и жесткого обращения к регистрам и битам. Только так.

[@Konoplj2010]

Молодец! Приятно осознавать что в нашем мире кроме "Упоратых Ардуинщиков" есть ещё и нормальные специалисты. Когда я пытался сделать такое же видео то меня так обплевали в комментах что я даже не рад был что я вообще принялся пояснять людям что кроме Ардуинки ещё есть на чём можно работать. Лайк.

[@sergeyvp]

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

[@AxGxP]

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

[@ЕвгенийПанкратов-г5ь]

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

[@AxGxP]

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

[@saturn9754]

Это должен знать каждый!!!И вообще,Ардуино -это просто материнская плата микроконтроллера,обвязка,питание и пины для подключения к портам...для начала можно работать в Ардуино,а потом перейти на AVRSTUDIO...для большинства задач автоматики возможностей этого контроллера вполне хватит...

[@МаксимАнтонов-ъ9ч]

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

[@АндрейКим-ж1р]

@@МаксимАнтонов-ъ9ч что за бред? Любой комп подойдет.

[@irongarden8415]

В свою защиту могу сказать, что купив ардуину и поработав с ней загорелся изучением мк, через пол года уже играюсь с tft экранчиком, и возникло несколько проблем, ну если не учитывать проблему подключения, то проблема скорости уж точно. Рисовать графики на экранчике или сложные последовательные цикличные анимации очень интересно, но ждать пока оно все прорисуется по пять минут полный отстой. Естественно я стал интересоваться поч? Так как я не программист и изучаю программирование и С в свободное время, обучение идет не быстро. Появилось желание интегрировать мк в свои проекты, задумки. Стало интересно потрогать больше памяти, более высокую скорость тех же Stm32 или даже fpga но это для меня пока дальняя цель, благодаря вашему видео я переосмыслю некоторые моменты своего путешествия в мир мк. Благодарю за внимание, лойс однозначно поставил!

[@AxGxP]

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

[@irongarden8415]

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

[@AxGxP]

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

[@irongarden8415]

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

[@AxGxP]

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

[@tutralex]

Да, Arduino кривой, тут поддерживаю, но теория заговора в конце ролика - это просто смешно. То, что там наставляли проверок параметров - это нифига не заговор разработчиков (StdPeriph). Эти проверки по умолчанию не производятся, пока не раскомментировать или не поменять некоторые определения (USE_ASSERT_INFO/USE_FULL_ASSERT), так что никакой дополнительный код не генерируется. Конечно это не inline-функции и есть расходы на передачу параметров через регистры, переход и возврат из функции, но назвать это ошибкой, заговором или криворукостью разработчиков - бред!

[@AxGxP]

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

[@tutralex]

Ссылок на пруфы конечно же не будет? Давайте вы не будете говорить за 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 функция, но это ж библиотека!!! Они дали вам возможность легко включить ловушки возможных ошибок, при отладке, а вы называете это криворукость!ю? Посмотрите правильные примеры кода, как этим вообще пользоваться.

[@tutralex]

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

[@AxGxP]

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

[@AxGxP]

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

[@Drex_Andrey]

Красиво и доходчиво. Но развязка настолько трагична, что аж слеза навернулась. Но тем не менее, лайк

[@a1ex_sk]

Хорошее виде, автору спасибо. Хочется при этом заметить, что минусы Ардуино во многих задачах компенсируются скоростью прототипирования и низким порогом вхождения. Я сам в программировании больше 15 лет, хотя и пишу по большей части на высокоуровневых языках, и микроконтроллерами на уровне хобби заинтересовался совсем недавно. При этом в первом работающем проекте на базе Ардуино на код потратил несколько часов, плюс несколько статей и десяток роликов суммарнй продолжительностью час-полтора. С stm32 разбирался несколько месяцев, что бы научиться делать элементарные вещи. Конечно только особо упоротые люди будут делать большой серьезный проект в среде Ардуино (notepad++ больше умеет), да и разработкой пролетных контроллеров или чего-то похожего на Ардуино разве что на спор можно заниматься. Но если задача тривиальная (простой ПИД-регулятор, контроллер полива, простейшее удаленное управление чем угодно через тот же GSM можем или по другим событиям и прочие ламповые самоделки без rocket science), то все же намного проще и быстрее сделать это на ардуинке

[@AxGxP]

К сожалению, или может к счастью, из личного опыта скажу, во многих случаях сделать по нормального с нуля без всяких ардуино часто быстрее чем потом бороться с глюками ардуино. Случай из жизни, попросил чел помочь с проектом на ардуино. Задача: генератор сигнала квадрат/синус, с регулировкой амплитуды 0-100% и частоты 20-200 Гц, ЖК дисплей, несколько кнопок. На AVR единственный вариант осуществить вывод синуса - таймер, OutputCompare, и при каждом переполнении обновлять значение OCx. Выбрал несущую 8кГц, написал все за пол часа, для Timer0, кидаю ему, говорит не компилируется! Как выяснилось Timer0 ардуина зарезервировала для себя и юзать его не дает. Ладно, меняю все на Timer1, вроде работает. Но перестал работать дисплей, какую либу он использовал - не знаю, попросил поменять ногу. Переделываю ему с OCA на OCB. Ничего не поменялось. Взял он другую либу для дисплея, теперь ситуация наоборот, дисплей работает, а сигнал прерывается во время обновления картинки... Два дня он мудохался, пока опять ко мне не обратился, чтоб помог ему найти, в чем проблема. Оказалось не понятно для чего либа отключает на время все прерывания, убрали, все заработало.... Проект, который я сделал бы за пару часов на STM32, просто правильно сконфигурировав периферию, чел делал две недели! Да и меня несколько раз напрягал, "переделай на ту ногу", "переделай на другую", а оно все равно "не работает", "глючит"... Так что пока есть одна задача, используется одна библиотека на ардуино - все ОК. Но как только появляется немного больше задач, и необходимость обработки и выдачи сигналов в реальном времени, с ардуино начинаются напряги))) Удачи!

[@a1ex_sk]

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

[@AxGxP]

@@a1ex_sk Видимо мне пока не повезло, с проектом, в котором с ардуиной получилось бы быстрее.... Простые вещи обычно делаю на attiny13(в целях экономии), ну а более сложные STM32. А вот с атмегами последнее время как-то некуда поставить, не то, что ещё и ардуино... Ибо как раз с точки зрения программирования, многие вещи на stm сделать проще, быстрее и удобнее, а по цене разницы нет. Хотел сделать прибор походный, радиация, давление, температура, уровень УФ, и т.д. В целях экономии батарейки думал PIC использовать, но вот сейчас смотрю, наверное на STM совсем не хуже получится, а только лучше.

[@a1ex_sk]

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

[@AxGxP]

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

[@masterkit9517]

перешёл на STM32, ардуино действительно 80-90 годы по удобству и мощности. Каменный век, дорогой раритет.

[@TheIntellekt]

Очень круто! спасибо! если есть возможность то сделайте такой обзор на PIC!

[@AxGxP]

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

[@AxGxP]

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

[@ВадимАлиев-ю4ъ]

Всем в нашем чате (да, есть такой) говорю что Ардуино и ХАЛ для чайников и что-то серьезное делать на нем - ну такое себе. В ответ получаю лишь выпады, что мол тогда уж замени микросхемы транзиторами и пиши на АСМе. Вы один из немногих, кто видит реальную картину =))

[@AxGxP]

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

[@81n90]

Монтаж ролика збз, красава! По теме - чем ниже уровень и опытнее и внимательнее прогер, тем быстрее исполнение. На асме было бы ещё быстрее. Но в наше время, стоимость железа, несравнимо меньше по сравнению со стоимостью работы прогера. Мы тож кушать хотим и не только электроэнергию ) А ещё ведь может быть целая компания, со сроками и все хотят кушать. Поэтому много раз наблюдал наращивание кластеров в датацентрах, без допиливания оптимизации проектов. А вы тут про копеечные контроллеры.

[@bubuii]

бальзам на мою перфекционистскую душу. я люблю ассемблер.

[@Al.Sy.]

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

[@916363]

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

[@vovan5341]

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

[@AxGxP]

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

[@tonyb7977]

Когда-то давно проводил похожий эксперимент, но с объёмом кода. Был небольшой проект, где хотел использовать оставшиеся залежи ATTiny2313a-SU с мизерным 2КБ ROM (но всё же больше чем на Tiny13). Код незамысловатый, но чуток длинноват. Arduino IDE хронически не переваривал с самого начала, но ради смеха попробовал и на нём. Получилось почти 5КБ скомпилированного бинаря, который ну никуда не годился.... В AVR Studio почти вписался, но "почти" не считается. Пожже получилось оптимизировать код до 900Б с хвостиком, но это уже пост-фактум. Почитал немного макулатуры по AVR assembly, покопошился по даташиту, перевёл прогу один-в-один из С в ассемблер, попил кофе, добавил пару мелких оптимизаций, и в итоге получил 500 с лишним байт делающих то же самое что и всё вышеупомянутое. Оставшееся место использовал под пару сабрутин самодиагностики получившегося девайса. Кстати, всем скептикам и пессимистам, когда речь идёт об ассемблере на AVR, то на практике всё пишется так же интуитивно и просто как и на С. Особенно если есть привычка не юзать чужие модули и сниппеты слепо скачанные из инета. Во многом даже интуитивнее чем С или С++ конкретно в этой ситуации.

[@sergnova528]

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

[@tonyb7977]

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

[@tarasn.6892]

Ничего не понятно, но очень интересно. P.S. Лайк прставил 😂

[@KolyuhaKostylev]

Я только начал знакомство с ардуино, а тут такое, мало чего понял, но скорости вычисления впечатляют! Сейчас почувствовал себя пятилетним ребёнком, что я фигнёй занимаюсь...

[@AzamatTimerbaev]

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

[@kardanium]

Я ардуиновскую среду использую только с одним МК. Это ESP8266, ибо разбираться в его родном SDK у меня нет желания. С ESP32 ситуация конечно в разы лучше. Среду - в смылсе окружение, библиотеки и систему сборки. Только саму IDE я взял чуть поодекватнее - Visual Studio Code + PlatformIO, ибо Arduino IDE в этом плане - как отвертка без ручки. Неужели они не могут сделать "Режим для продвинутых", где ихняя IDE превращается во что-то нормальное? Хотя бы, просто с возможностью нормального управления файлами проекта. Если они задумали Arduino как учебный проект, то могли бы и сделать что-нибудь такое, что познакомило бы новичков с настоящим процессом разработки. В остальном - IAR, Atmel Studio, MPLABx и другие нормальные среды и нормальное программирование. В боевых проектах на STM32 я не использую SPL\HAL. HAL используется только для проверки идеи, ибо проект генерится легко и быстро с помощью STM32CubeMX. Да и то не всегда. Например, средствами HAL и Cube в частности, невозможно использовать аппаратную работу DMA с двумя буферами на STM32F407 и других камнях, DMA которых умеет работать с двумя буферами. Еще HAL проверяет все флаги периферии при входе в прерывание и тем самым растрачивая время, когда реакция нужна незамедлительная. Особенно если это касается внешних прерываний. Потому и STMicroelectronics не рекомендует использовать их библиотеки в критичных проектах.

[@yevhenukrainianer4781]

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

[@nobodyismyname.5193]

У меня порой складывается впечатление, что STM придумали для генерации ШИМа теми, кто не смог в схемотехнику, но смог в программирование. Эти макакт собирают свои взрывающиеся преобразователи на STM, попутно рассказывая, что Arduino - это медленно, не нужно и вообще зло. Причем рассказывают это тем, кому нужно автоматизировать полив в огороде, а не запускать космические ракеты.

[@yourobaz1376]

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

[@AxGxP]

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

[@ktspn]

Очень круто! Желаю успехов, видео просто отличное

[@Danshyn]

прям блокбастер в мире микроконтроллеров ))) за работу респект

[@Делайсам-м8о]

Могу дать прогноз.... С появлением искусственного интеллекта в бытовом уровне отпадет необходимость в знании языков программирования. Мы будем иметь устройство в виде ящика с входными и выходными шинами данных, а любой человек просто будет формулировать голосом свойства на входе и выходе устройства. Код и алгоритм выполнения будет писать искусственный интеллект. Это упрощённый пример . Я думаю моё видение подтвердится.. )))

[@AxGxP]

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

[@Popugaj4ik]

Так вот оно что Михалыч! А я то думал, почему микроконтроллеры такие медленные. А они на самом деле жесть какие быстрые.

[@СергейДавыдов-ф8п]

Спасибо! Очень интересно! Хорошая работа.

[@sergey7dvd]

Аж тронуло. Спасибо за видео. Кайфанул от просмотра))

[@electronicsashobby]

Видео познавательное. Еще интересно было бы взглянуть на скорости работы ОСРВ, например, FreeRTOS при выполнении тех же задач. Автору спасибо.

[@cdeblog]

Не может СТМ делить за 1 такт. А все сравнение это сравнение теплого с мягким. Если бы автор понимал как работает контроллер, то таких вопросов бы не возникало. Стдпериф работает медленнее как минимум из-за затрат на переходы в функцию и обратно, ещё и дополнительные проверки и манипуляции ос структурами, здесь не криворукость программистов СТМ. Нужно понимать, что чем-то приходится жертвовать, в данном случае скоростью выполнения и объемом занятой памяти в пользу скорости написания кода и его читаемости.

[@MaiklTil]

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

[@RogovAB]

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

[@dudanov]

Полностью поддерживаю! Можно таким образом было вообще писать на ассемблере и сделать автору ответное видео, что написание на Си, использование стандартных стартовых кодов и неэффективного компилятора это тоже ухищрения производителей, чтобы покупали более мощные МК. Нужно отделять одно от другого. Цели библиотек - абстракция от уровня, в данном случае железа. Почему attachInterrupt обязана сбросить флаги прерывания? Где это написано? Требования из даташита? Это все логика программиста! Просто автор немного разобрался в теме и решил "блеснуть умом", как можно оптимальнее написать программу. В замечание автору, насчёт "ошибок" в библиотеках. В основном, все эти библиотеки с открытым исходным кодом. Что мешает автору присоединиться к сообществу и исправить их? Не нужно себя возвышать над целыми сообществами людей и программистов, которые вложили свой труд в создание кода. Тщеславие - качество не из лучших.

[@personamems]

Отличная работа! Вы, гений! Хоть у кого-то голова работает. Ардуино превратило хорошее железо в игрушки

[@dreinakh]

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

[@БогданРогач]

Ардуино для учащихся и новичков...там никто не питался писать чот особо производительное...а так за видео однорзначно лайк

[@HeavyHeavyvich]

А почему бы не сравнить HAL vs STDPeriph vs CMSIS?

[@RogovAB]

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

[@nixtonixto]

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

[@yevhenukrainianer4781]

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

[@IgorChudakov]

А можно ещё сравнить STM32 CMSIS vs. оптимизированный HAL? Или уже было, всё-таки 2 года прошло?

[@vovan5341]

Отсюда мораль: библиотеки - зло! :-)

[@Vlad_4572]

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

[@ДанилаГладкий-л8к]

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

[@Vlad_4572]

@@ДанилаГладкий-л8к , что такое продакшен? Типа массовое производство?

[@ДанилаГладкий-л8к]

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

[@АлексейВиноградов-ц9ж]

Очень хорошая тема, безукоризненная работа, шикарный видос!

[@Legantmar]

спасибо. интересный обзор. очевидна плата за удобство программирования без изучения ассемблера и регистров. было бы интересно посмотреть на обзор esp8266 и ее "разгон"

[@isakneuman9995]

Если ты все еще ведешь канал, можешь подсказать, что мне учить? Тоже хочу кодить микроконтроллеры. Сейчас изучаю С++ по Прате чтоб базу получить. До этого были попытки изучить сам Avr и кодить для атмега8, но все заканчивалось тем, что не понимал даже библиотеку. Может ты знаешь по каким книгам учить, и что учить avr или stm. Спасибо

[@AxGxP]

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

[@isakneuman9995]

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

[@AxGxP]

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

[@isakneuman9995]

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

[@АлексейТТ-о3х]

Спасибо за видео, полезная информация.

[@heresytech9668]

Работал с stm, raspberry pi , nodemcu, avr. Avr меня так зацепил! Больше всего мне нравится, что можно из си пробиться к регистрам и управлять ими. В stm тоже так можно делать, но эта фишка плохо документирована(на мой взгляд). Короче, avr крут

[@AxGxP]

Как это плохо документирована?! Как раз наоборот, полностью вся инфа по ним в открытом доступе. STM32 - очень крутая штука. Жаль только, что теперь их фиг купишь.

[@PiFonCHEG]

Очень познавательно, спасибо за Ваш труд! На скольки МГц работает STM32 в этом тесте?

[@AxGxP]

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

[@ДмитрийРастегаев-з1ч]

О! Интересно было бы увидеть подобное сравнение stm с esp32...

[@looowblooow7508]

Вот это работа. Молодец. Теперь для меня все стало еще интереснее!!!

[@alhimn1]

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

[@MrPostal5]

Хороший обзор, несколько но... Довольно сложно обучаться программированию, сужу по себе, а вот у ардуинщиков огромная фан база, куча групп и форумов, гораздо легче искать и разбираться с ней, поэтому народ и "хавает". По сравнению с тем же программированием на авр и пик, или того веселее стм, по личному опыту оооочень геморно разобраться не имея то ли профильного образования то ли склада мышления не знаю. Очень много потратил времени на изучение АВР дотянул только до прерываний, хотел найти курсы или еще что, но их просто нет, и знающих людей совсем немного, в отличии от тех же ардуин... В итоге обида, и возвращение к ардуинщикам ((( как научиться работать с AVR объясните???? кто может растолковать как писать код правильно, хоть на Си или же может Ассемблер ???

[@AxGxP]

+MrPostal5 Главное понять принцип работы. У всех микроконтроллеров он примерно одинаков. Ну и естественно знать синтаксис языка, побитовые операциии, указатели и т.д. Читать документацию на микросхему, и делать согласно ей, а не копипастить одни и те-же ошибки, что по всему рунету. А ардуино к сожалению это одна сплошная ошибка, что-нибудь сколь серьезное без глюков на ней сделать нужно постараться, для этого нужно знать не только как работает микроконтроллер, но и какие его функции и как использует ардуино. digitalWrite тормозит, attachInterrupt с ошибкой, analogWrite с ошибкой, дальше разбираться не стал....

[@Vlad_4572]

Кому красивая картинка, а кому и быстрый старт. А это многого стоит. Много времени я потерял, на логических элементах, пока не узнал про ардуино из Китая! Так что оно того стоит, и еще как! Люди дела меня поймут)

[@sopliviy_ezh]

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

[@DirectionToTheTop]

@@MrPostal5 Ассемблер не совсем язык программирования, это мнемоническое представление машинных комманд процессора. Пытаясь писать на ассемблере, вы плотно вникаете в суть логики работы микроконтроллёра. Поняв суть всё становится проще на любом языке программирования.

[@user--22]

Зачёт! Благодарность! Респект!

[@sovchem1275]

Ни разу не понимаю арДУРино.... AVR, хорошо, но есть же нормальная среда CAVR с виз. кодгенератором с человеческой отладкой и прошивкой !

[@gogmagog6285]

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

[@МаксимАнтонов-ъ9ч]

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

[@АбуЗаррФарадей]

Привет. Мне интересен ИТ и не мало времени искал направление, которое будет мне по душе. Смотрел статьи, видосы о том какое направление выбрать. Все они похожие и я не находил в них то что мне нужно. Но в одном ролике автор в нескольких словах что то сказал про программирование устройства, типа умные дома, машины, домашнюю технику, но ничего больше об этом не рассказал, как это направление называется. Хочу чтоб вы мне подсказали в каком направление двигаться. Я гуглить и самые частые слова попалались это IoT, микроконтроллеры, embedded, Arduino, пайка плат. Я бы хотел программировать, но лезть в железо не очень интересно, но как я понял это нужно, нужно знать Си, физику, электросхемы и электронику. Повторюсь, меня это направление заинтересовало, но требования с физикой и железом пугает. В общем, в голове каша. Может чего лишнего начитался. А ещё, я начинал учить Java и он мне понравился, по сравнению с python и js. На одном сайте были курсы по этим языкам, я все начинал, но java зашёл более менее. Но как я понял в этом направлении нужен Си. Не знаю осилю ли я его. слышал что с/с++ сложные. В общем как то так.

[@AxGxP]

Насколько я понял, интересует именно embedded программирование. Если хочется делать качественные, крутые вещи, без знаний электроники, архитектурвы ЭВМ и строении конкретного микроконтроллера - никак. Так-же, с большой вероятностью понадобится знание физики, особенно если устройство работает с физическими устройствами (датчиками, приводами). Вместе с этим обычно появляется необходимость вычислений, матан, численные методы, теория автоматического управления. Помогают знания и в других областях, по теме разрабатываемого устройства. С точки зрения программирования, на сегодняшний день, обычно это Си. Знание ассемблера тоже приветствуется, и не редко выручает. Без английского - наверное никак, спецификации всяких протоколов и докуиментация на микросхемы обычно доступна на английском. При работе не обойтись, без навыков работы с осциллографом и логическим анализатором. P.S. Начните, с чего-то более простого, и постепенно переходите к чему-то более сложному. Не пугайтесь, если сразу не получилось, всё приходит с опытом. А учиться никогда не поздно. Это очень интересная отрасль, не во всех профессиях можно регулярно получать такие эмоции как тут. Мало что может сравнится, с радостью от вселения "жизни" в "железо". Так-же, как и чувство безысходности, после нескольких дней попыток устранить необычный, редкий глюк. Удачи!

[@АбуЗаррФарадей]

@@AxGxP благодарю вас за такой развернутый ответ. Я этот вопрос задал в нескольких местах, но от вас ждал ответа особенно. Так как из этого ролика удивил момент где вы исправляете код производителя. Меня это впечатлило.) Мне почти 32 года, в школе я можно сказать не учился, на знания мне было всё равно, а о математики и физике думаю можно и не говорить. Но в последние годы как то все изменилось. Есть сильное желание стать профессионалом в своём деле и я уверен, что это ИТ, мне оно очень интересно. Можете оценить мои перспективы? За сколько времени я бы мог стать джуном и пойти пробовать устроится на работу? Понимаю у каждого это индивидуально, но если взять среднее. Конечно если перспектива есть вообще с такими данными.

[@AxGxP]

@@АбуЗаррФарадей тут очень много разных факторов, переменных... Не думаю, что на этот вопрос возможно достоверно ответить. Всё зависит от Вашего упорства, целей и способностей. Если это именно ради заработка, тогда не стоит заморачиваться... Чем Вы занималсь последние 5 лет? Что именно изменилось, кроме как переопределение ценностей?

[@АбуЗаррФарадей]

@@AxGxP да, ради денег, но зарабатывать я хочу на том, к чему у меня будет интерес. Последние 5 лет занимался сваркой, отделкой домов, в общем, ничего общего с ИТ. Был игроманом, но когда ценности изменились интерес к ПК остался. Свое знакомство с ИТ я начал с фронтенда. Более-менее научился вёрстке и понял, что долго продолжать не смогу, так как тут было желание только заработать и я обманывал себя, что мне это нравится. Потом хотел попробовать Андроид и тут тоже не было уверенности, что это моё. А теперь, когда есть уверенность во встраиваемых системах появилось препятствие, что это сложный уровень. Ещё, в этом году познакомился с Линукс, попутно читаю книжку про нее. Интересно понять её глубже.

[@EXEgg]

Я уже очень долго собираю информацию чтобы прояснить для себя некоторые моменты по поводу работы с микроконтроллерами. Порядка трёх дней. У вас в комментах я наблюдаю наиболее интересный срач по этой тематике так что может быть мне кто нибудь ответит. Сам я ни коем образом не программист и даже не технарь. Иначе наверное задавал бы такие вопросы не в ютубе а на хабре. Про ардуинку слышал краем уха что это такая маленькая платка со слабеньким контроллером внутри, для домашних поделок. Так вот, я пытаюсь понять в чем кардинальное отличие этой отладочной платы от других. Пока что, насколько я понял это отличие - Arduino IDE. Оно позволило писать хоть и херовенькие но работающие программы тем, кто до этого вообще не умел кодить. В следствии этого ардуина обросла огромным сообществом. И от этого огромного сообщества бомбит у всех трушных программистов изучивших 2000 страниц талмуда по работе с каким нибудь ARM. То есть хоть Arduino IDE снизило порог вхождения, оно не заставило ардуинщиков переключиться со временем на более трушные, низкие уровни программирования и новые микроконтроллеры. Хотя как я понимаю CMSIS это тоже уровень абстракции и если уж совсем по хардкору то нужно обходится и без него? В итоге Arduiono IDE в области микроконтроллеров стало чем то вроде Unity3d для геймдева. Позволяющей на уровне профана делать продукты жертвуя ресурсами и в последствии перспективой улучшить свой скилл, в пользу низкого порога вхождения и готовых решений от комьюнити. Там, где задача могла израсходовать в десять раз меньше ресурсов, умей автор выполнять её на более низком уровне абстракции, приходится использовать хоть и удобный но громоздкий Arduino IDE. И последнее. Как я понимаю усугубляет положение дел ардуины устаревший микроконтроллер AVR. Можно ли хоть как то компенсировать потерю ресурсов на ардуиновской платформе используя более мощные платы, например Arduino Due или Esp32? Или "скетчи" на атмеге уже не будут работать на других контроллерах?

[@AxGxP]

Конечно, по современным меркам микроконтроллер AVR ATMega328 (на самой распространенной ардуине) не кажется мощным, но для многих задач его хватает с головой, я не редко применяю даже ATTiny13, в целях экономии средств и места. CMSIS это просто представление понятными (для человека) словами непонятных цифр, адресов памяти, регистров периферии. Обходится смысла нет, во время прероцессинга всё это будет заменено цифрами-адресами, и компилятор получит ту-же самую программу. Назвать Arduino IDE удобной язык не повернется, ничего удобного в ней нет, если писать что-то самому, а не использовать чужую программу. Какую цель вы преследуете, есть конкретный проект который хотите осуществить, или просто-так интересуетесь? У разных микроконтроллеров разные достоинства и недостатки. Конечно если взять более мощную плату будет работать быстрее. Но есть специфические задачи, и специфические микроконтроллеры, которые справляются с этими задачами лучше других.

[@EXEgg]

В том то и дело что пока я не могу точно определить спектр задач. Пока что всё видится как "помигать светодиодиками" и возможно как то применить в быту. Хочется что то с низким порогом вхождения и готовой базой проектов (как у ардуины) но в то же время с перспективой на будущее.

[@AxGxP]

@@EXEgg вот и купите ардуину, самую дешевую. Надоест убогая среда, если до того момента не закинете, перейдете на AtmelStudio, тогда и придет понимание как микроконтроллер работает и какой вам нужен. Если в общем посмотреть принцип работы всех микроконтроллеров одинаковый, все они электронные, на двоичной логике, во всех процессор выполняет написанную и скомпилированную программу. Научившись программировать один, перейти на другой большого труда не составит (не относится например к ESP32, где производители намеренно скрыли внутренние регистры, и все работает через прослойку API от разработчиков). Начинать с Cortex думаю все-же не стоит, там слишком много фишек и наворотов, AVR намного проще особенно для начала и понимания. В любом случае нужно сначала разобраться с языком программирования (СИ), можно это делать и на компьютере, а уже потом к микроконтроллерам переходить.

[@ruslan.zhumabai]

грамотное видео. скажи плж где можно научиться программировать мк авр на си с нуля?

[@AxGxP]

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

[@KishovRasul]

А настройки компилятора в Keil какие? Как же можно про это умолчать? Максимальную оптимизацию выставить и сравнить не пробовали? А в IAR какой будет результат?

[@AxGxP]

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

[@NIKOLAY_PSHONIA]

Вы абсолютно правы - я в ардуинке заменял sbi(P_CS, B_CS); cbi(P_CS, B_CS); на PORT DDR библиотека UTFT и изображение на TFT начало летать.

[@ТимохаТимохавич-ч6с]

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

[@NIKOLAY_PSHONIA]

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

[@ТимохаТимохавич-ч6с]

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

[@Aleksandr_Sidorov]

Для одаренных компания STM продолжает модернизировать библиотеку LL и тут я могу поспорить , там прямое обращение к регистрам , а так кто мешает ни кто не мешает к ним обращаться , время выполнение , я думаю не совсем правильный подход , тут STM всего по вашему ускорилась в 3 раза но не в 28 раз , тоесть вывод STM всега в переди даже на стоковых либах , а так кто как хочет то так и др..... и да сравнение 32 с 8 битами , хорошо но мы то знаем уже давно о том что писать свои либы сложнее нужно понимание и знание простых физических величин , а тут стоковое и работает неплохо , по этому все что работает из среды Arduino IDE это полнейшая лажа и то что на ней построили CONTROLINO типа ПЛК , да оно работает , вопрос сколько , и на сколько точно и верно , и какую вы программу напишите если даже у ВАС нет многозадачности , тут об этом можно спорить рассуждать доказывать показывать , и такого контента в сети к сожалению уже прилично накапливаеться я давно перешел на STM и возвращаться в мир AVR не хочу , хотя есть некоторые проекты которые можно осуществить на AVR

[@AxGxP]

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

[@Aleksandr_Sidorov]

@@AxGxP по поводу ошибок редактируют , по всем шинам дает право выбора или сам будешь ловить стоповые биты или предоставь нам , есть ошибки и примеры есть в репозитории куба

[@РоманСазанов-ы4х]

STDPeriph нужно использовать только в целях инициализации периферии... Это реально удобно!

[@denisromantcov6713]

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

[@AxGxP]

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

[@ua6em]

а в какой версии IDE компилировалось? Я об ошибке - attachInterrupt(Pin, ISR_prog, RISING);

[@ua6em]

увидел 1.8.5 )))

[@БогданЛотоцький-и7ж]

Вот это я понимаю ролик! Класс!

[@MrASmitt]

В ардуино ИДЕ можно писать на С++, а также использовать регистры. Это позволит добиться той скорости, которую АТМега показала при использовании АВР? Я тут к арудине подключил самый простенький экранчик для вывод цифр из цикла, так она в 5 раз медленнее стала работать)))

[@AxGxP]

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

[@MrASmitt]

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

[@КоробейниковАлескей]

Могу сказать что если писать код без компиляторов, то скорость выполнения будет ещё выше на avr с stm не знаю, там может быть затык по как раз разрядности, если её не использовать полностью, то думаю браться за stm может и нет смысла.

[@AxGxP]

На некоторых моментах, может быть заметно быстрее, какое-нибудь прерывание например написать, но в общем, в целом оно того не стоит, прироста в разы не будет, десятки процентов в лучшем случае. По поводу stm32, он выполняет операции с 32-битными значениями. Так что использование 8-битных переменных иногда наоборот замедляет выполнение программы. Тут уже выбирать, что нужно память экономить и преобразования типов проводить или скорость выполнения, но с большим расходом памяти.

[@banzay989]

Голос, подача материала, а сам метериал!) Браво!)

[@RingQy]

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

[@RogovAB]

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

[@AxGxP]

По поводу обновлений методом замены контроллера как-то слишком уж жёстко)) Можно же и через UART сделать, и по USB, или например с SD карты... Зачем раскручивать и что-то перетекать внутри?

[@RogovAB]

@@AxGxP Я понимаю, но оказалось реально удобным. Я работаю с мощными преобразователями. У меня есть прошивки, которые отдельно позволяют проверить только силу, или только управление, или только канал связи, плюс есть отдельные прошивки для калибровки и т.д. Да, можно было бы их прошивать каждый раз в один контроллер, но скинуть крышку и переставить заведомо рабочую платку, очень просто, особенно,когда нужно сделать это 50 раз. Например, плата для настройки с экранчиком, сразу видно параметры и т.д... Ну и плюс замена в случае большого баха. Кроме того, в плане макетирования можно легко поменять контроллер на другой тип, корпус, архитектуру, просто заменив маленькую платку за 2 бакса оставив все базовое железо старым. У меня коллега тоже не понимает, но ему приходится каждый раз физически отключать силу от питания, что бы что-то проверить.

[@AxGxP]

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

[@ТауБөрісі]

@@RogovAB я начинающий но все равно возражу вам. Можно ведь на собственной плате создать точки подключения программатора + сделать вывод питания контроллера отключемым от основной схемы. Это же совсем не сложно.

[@windy_sky]

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

[@AxGxP]

Выиграш от ассемблера не так велик, как многие думают. Современные компиляторы весьма не плохо справляются с оптимизацией. Современные процессоры имеют набор инструкций с учётом использования высокоуровневых языков (Си). Так что использование ассемблера в 99% случаев неоправданно. Значительного ускорения и уменьшения кода можно добиться правильным написанием кода на Си. Не применять лишних вызовов функций, избавится от преобразований типов, правильно использовать области видимости переменных, по возможности не применять float на контроллерах без FPU и т.д. Это значительно уменьшит код и повысит быстродействие.

[@dred77780]

я начинал изучать АВР с ассемблера (аврасм). И мой мозг, даже если очень стараться, просто отвергает АрдуиноИДЕ... Начинал с AT90S2313

[@RogovAB]

Подключите цветной дисплей на ассемблере, посмотрим как будет работать.

[@porese]

Это прям про венду от мелкомягких. Кстати для ардуины есть и быстрые библиотеки, от гивера.

[@yehorpererva181]

Прекрасное сравнение. Хотя стоило бы добавить сюда же mbedOS

[@Baton1804]

Ну так почему бы не выложить в открытый доступ исправленные библиотеки Ардуинки?

[@AxGxP]

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

[@Baton1804]

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

[@sssserya1]

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

[@lord4683]

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

[@sergnova528]

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

[@николай-г7ю3з]

Ардуино и не подходит для написания каких то серьезных программ, это больше для детей и подростков которые ходят в кружки программирования, порог вхождения очень низкий. Я сам пишу на HAL stm32 и могу сказать, что HAL реально много лишнего внутри себя содержит, я даже не смотрел внутрь, достаточно просто попробовать решить какие нибудь задачи по скорости. Я один раз пытался реализовать счетчик через таймер, чтобы тот тикал миллион раз в секунду, то есть считал микросекунды. В обработчике он просто увеличивал нужную переменную, но как оказалось потом, таймер считал с частотой 150 кГц, а все потому что обработчик прерывания от HAL выполняется дольше 1 микросекунды, могу предположить что около 4-5 микросекунд. И что делать в обработчике можно так долго? более вероятно, кучу проверок производит. Но согласитесь, писать реально сложную программу где нужно пользоваться sdio, fsmc, usart и так далее, на smsis вы будете очень долго, быстрее сделать на hal и это будет реально работать очень долго и без проблем. А если учесть что некоторые периферийные модули stm32 содержат десятки регистров с конфигурационными битами, копаться вы в них реально не захотите, особенно если задача все таки собрать устройство и чтоб оно работало, а не месяц писать библиотеку работу с дисплеем каким нибудь или внешним модулем каким то. Тут просто надо смотреть какая задача стоит перед нами. Если делать какую нибудь очередную умную теплицу, то конечно arduino подойдет, а вот если проект уже более сложный, то уже думать о чистом avr или stm32. А вообще, я считаю что avr уже давно морально устарели, если бы не arduino, то эти контроллеры валялись бы давно на помойке. Кому они сейчас нужны, если есть те же stm32 которые потребляют столько же или даже меньше, более гибкие и нафаршированы так, что даже самая простая модель контроллера подойдет под вашу задачу в 80% случаев.

[@AxGxP]

В большинстве с вами согласен. На самом деле с uart напрямую работать даже проще чем с hal. Конфигурируеться он за несколько строчек с помощью CMSIS. Да и FSMC тоже, просто нужно один раз сконфигурировать, а дальше просто писать, читать как из обычной переменной. Лично я сколько раз не пробовал на HAL писать, нифига не получается. Точнее начать получается, а дальше сплошная борьба с HAL. Думаю может в нем есть смысл когда есть несколько ядер и т.д. но хз, я таким не занимался.

[@николай-г7ю3з]

@@AxGxP на smcis можно писать гораздо лучше и работать оно будет идеально и лучше чем hal но, по моему мнению, при работе с hal я больше уделяю времени на сам алгоритм работу программы и переферии, то есть большинство рутинных задач все таки остаётся за библиотекой, да и сам куб мне мне нравится, наглядно показывает все ножки. На hal ещё писать тоже учиться надо. Но в одном соглашусь, все написанное на smcis будет быстрее,качественнее и без багов. Но недавно например мне встала задача быстро сделать один проект(который я до сих пор делаю, точнее модернизирую) и я на hal разобрался с ним довольно быстро, а на smcic пришлось бы читать кучу даташита и смотреть эти регистры по пол часа, высматриваы нюансы работы, которых, кстати, не мало- бит не в то время выставил и программа встала, причём не сразу а в каком то месте, потом вместо того чтобы решать вопрос программы, пол дня ищешь баг. Но тогда приводим к выводу, что нужно просто более тщательно изучать смсис, но тут нюанс что не у всех есть на это время и ресурсы

[@николай-г7ю3з]

@@AxGxP и да, есть ещё такой маленький момент,что когда я начинал писать проги под stm, я писал на keil, как раз на сиэмсис, но тут внезапно надо было делать проект где был fatfs и другие примочки с буфером и большим потоком данных, а оказалось что keil больше 30кб не даёт прошивку писать, я ничего лучше stm32cubeide просто не нашёл на тот момент, до сих пор на нем и сижу. А там, сами понимаете, связка stm32cube вместе с hal, так я в этой среде и программирую до сих пор. Другой стабильной среды, чтобы писать под сиэмсис на всю прошивку, я не нашёл, ну или плохо искал. Так что тут своего рода сама ситуация вынудила. Можно конечно на сиэмсис писать прям в stm32cubeide, но это же изврат по факту - пол кода на hal, пол кода на сиэмсис. Ну и не забывать надо, что hal легко переносим, что мне пригодилось часто, так как в процессе написания прошивки я постоянно перескакивал на контроллеры помощнее из за нехватки периферии, 99% написанного кода я просто копировал и вставлял в код другого контроллера и все работало, а на сиэмсис такое можно? Нет. Поэтому, тут надо уже смотреть под какую задачу пишется код и будут ли будущие модернизации

[@СергейНевинномысский]

А вы не пробовали функции LL или HAL, интересно насколько они тормазят работу

[@AxGxP]

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

[@ID_Takasu]

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

[@olegotdelka37]

Имеет ли смысл связоватся с ардуино . Или продолжить изучение авр. А то получается устройство на процессоре а внем плата ардуино торчит . С тем же процером . Может ну её ардуино то ?

[@olegotdelka37]

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

[@AxGxP]

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

[@olegotdelka37]

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

[@AxGxP]

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

[@olegotdelka37]

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

[@romanbru9504]

Первым делом конда немного осовоился в Ардуино ушел от digital write, и всем советую PORTB |=(1

[@MsTim159]

Это все конечно круто, теория заговора и т.д.Но вот получили мы не микросекунды, а нано, и что?Где эта разница будет ощущаться? Вот я собрал себе автополив на ардуино, со стандартными библиотеками, работает все отлично и меня не волнует наносекунды там в скетче или микро.

[@logcom482]

Для етого 100% хватает.И чтоби начать програмировать на ардуину нужно день, два.Ардуино имеет один минус ето точность вычислений.....А скорость ето ххххх.

[@AxGxP]

+logtell com А если бы вместо ардуино взяли соответствующий задаче микроконтроллер, то ваш автополив мог бы на батарейках работать, а не жрать столько, сколько ардуино. Естественно, для полива быстродействие не надо. А вот например для современных полетных контроллерах квадрокоптера даже экономия нескольких микросекунд имеет значение.

[@MsTim159]

Alexander Guryanov Это какие такие батарейки нужны для помпы?Я понял о чем вы, но под мою задачу ардуино подходит как нельзя кстати.И под ещё огромное колличество проектов,ардуино подходит как нельзя кстати. Паять кварц на коленке и разводить плату-это конечно труъ, и плюс к чувству собственности важности и крутости,но каждому свое и под свои задачи.

[@AxGxP]

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

[@windy_sky]

Всё зависит от устройства в котором стоит контроллер. В сложных и быстрых процессах ни какое ардуино не поможет.

[@BorisYutube]

Спасибо за видео!!!

[@ПОКАНЕПРИДУМАЛ-м2у]

Чётко чеканишь!

[@TDMLab]

Круто! Но странно сравнивать Ардуино ИДЕ и Атмел Студио если там пользуешься функциями, а там напрямую с регистрами работаешь это как-то нечестно, интересно было бы при равных условиях сравнить компиляторы.

[@dima_dmitrenok]

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

[@TDMLab]

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

[@cultofsogga5863]

Посоветуй пожалуйста литературу или другие источники знаний🥺😭

[@AxGxP]

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

[@alee-j8q]

Крутое видео. Спасибо.

[@lunokhodtoy]

Но ведь через регистры можно из arduino IDE тоже запрограммировать. И stm32 можно из arduino IDE запрограммировать, хотелось бы увидеть и такие сравнения!

[@AxGxP]

Можно и левое ухо правой рукой чесать. А STM32 в Arduino IDE программировать - то же самое, что гвозди отверткой забивать. Без элементарных инструментов отладки даже трудно это представить! По поводу скорости к сожалению (точнее к счастью), проверить не могу, нет у меня больше Arduino, сгорела нафиг. Могу только предположить, что значительной разницы быть не должно, ведь Arduino IDE использует компилятор GCC (но управлять его настройками невозможно). Еще точно знаю, что на AVR прерывание переполнению Timer0 будет 1000 раз в секунду срабатывать, и отключить его Arduino IDE не позволяет.

[@МаксимДворников-у3э]

Обзор просто супер!

[@ПОКАНЕПРИДУМАЛ-м2у]

Я на всякий случай подпишусь =)

[@ТимохаТимохавич-ч6с]

*_Бро, хоть и ролик старый, может сохранился сурс для STM?_*

[@AxGxP]

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

[@andreikashin]

качество на высоте

[@ivane1168]

бессмысленные команды и перебирание стека, это своего рода майнинг реальных денег для ST ;) Видео сделано отлично, от самой идеи, до малозаметных мелочей, типа кликов прироста МГц на 5й секунде!

[@AxGxP]

На самом деле я не сказал бы, что ST в этом виноваты. Микроконтроллер они сделали зачетный (есть конечно и нюансы, особенно много глюков с I2C), но доверили написание библиотек не тем людям. Рад, что это видео понравилось. Думаю этим я тоже смогу вас удивить: kzbin.info/www/bejne/pabFXpV3lJKCatk

[@ivane1168]

@@AxGxP виноваты, виноваты. Точно такя же ситуация с остальными воротилами IC бизнеса, близкий мне пример AD со своими недорогими $2 Sigma DSP, в которых как бы случайно отсутствует библиотечный multi-rate FIR, в итоге эти DSP никак нельзя использовать в FIR обработке аудио с приличным разрешением в низких частотах. На форуме поддержки слышны стоны - ну как же так, такие привлекательные IC и библиотека не дописана?! А вам ответят - ну возьмите Shark за $20, там всё есть + ассемблер пишите что хотите, MIPS'ов в 20 раз больше и памяти. Т.е. для аудио уже просто не нужно больше мипсов, чем даст чип за пару долларов, но вам не додали нечто, что вынудит вас докупать этих самых ненужных мипсов. Так что виноваты..

[@sergkaev6075]

Жаль, что нет варианта управления портами через регистры в Arduino, то же ускорилось бы, но интересна разница в т.ч. с Atmel studio. Я так понял STM-ка работала на 72mhz, а если на той же частоте что и AVR, то AVR походу быстрее.

[@AxGxP]

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

[@Максим-п1ж1д]

Я только олного не понял: на какой частоте работала STMка, на 16 или 72 МГц?

[@AxGxP]

На 72.

[@xintreavideo]

На 106 секунде я так и не понял: на экране написано что прерывания будут отключены. Голосом же автор говорит, что будет оцениваться скорость входа и выхода из прерывания. Так что же на самом деле хочет сделать автор?

[@BB-ti9bf]

Я напрямую общаюсь с регистрами, HAL не использую, только кондовый CMSIS, не для того, чтобы тут выпендриваться, кто тут true, просто если что-то идет не так, то тут точно понятно что сам накосячил и это сильно проще найти в своем коде, чем в чьей-то кривой библиотеке. Да, времени на написание и отладку выходит значительно больше, зато можно на более мелких и бюджетных камнях писать мощные и быстрые real time решения, ну и дополнительно прокачивать скилл.

[@AxGxP]

Поддерживаю! HAL один раз глянул, охренел с того, сколько там всякого бреда и больше не смотрел в его сторону. STDPeriph использовал не раз, но случалось и жесткое попадалово с ним... Несколько дней помню не удавалось на полную запустить один датчик (и злость уже была, и руки опускались, но я не сдался), вроде как основные функции работают, обмен идет, а когда всё вместе - не работает. Оказалось проблема в I2C, STDPeriph (без логического анализатора никогда бы не разобрался). С тех почти всегда всё своё, и на камень, и остальную периферию, дисплеи и т.д. В итоге всё работает быстрее, лучше и даже надежнее. Обычно те, кто пишет библиотеки, не задумывается над тонкой логикой, заложенной производителем устройства. Как итог, грабли на граблях...

[@BB-ti9bf]

@@AxGxP i2c на мой взгляд самый ужасный интерфейс. Медленно, сложно обрабатывать все прерывания, коллизии, пц какой-то, че его везде пихают? Программно его проще реализовать, чем аппаратно! 🤬Любимый - SPI, надежно, быстро, просто, особенно с DMA. Имхо, i2c изврат какой-то

[@AxGxP]

@@BB-ti9bf Проводки экономят))) Согласен, особенно в этом микроконтроллере не очень элегантно получается. Буфер этот, вроде и скорость добавляет но и проблем, ещё больше. В зависимости от количества байт в пакете нужно по разным алгоритмам работать. Грубо говоря 1 байт отправляет одна функция, 2 байта другая, 3 байта третья, а 4 или больше уже четвертая. В STDPerih на STM32F1xxx как раз с отправкой трех байт и возникала ошибка. _P.S. По поводу экономии проводков, недавно 1-wire понадобился, нигде в сети ничего адекватного не нашел под STM32, кроме костылей с UART. Оно и к лучшему, написал опять своё: одна ножка, таймер и DMA. Все тайминги строго по спецификации, быстро и красиво._

[@BB-ti9bf]

@@AxGxP я с 1wire разбирался как с помощью spi+dma (ага! Даже так экспериментировал, но так себе выходило), но остановился на использовании прерываний таймера, причем без ожиданий, чисто в виде call back, чтобы не замедлять другие задачи При старте переменная W ставится в 1(это флаг того, где мы находимся в цикле обмена) линия в 0 и таймер в режиме opm взводится на время reset, затем в прерывании таймера функция по case смотрит: ага, W==1 значит отмеряли reset, взводим таймер на время выборки ответа устройств, W ставим 2 и снова уходим на другие задачи.... В итоге при таких подходах на 24 МГц F100C8T6 висят 18В20, емкостная multitouch сенсорная клавиатура, графический дисплей со своими библиотеками вплоть до анимаций, компрессии шрифтов, куча других датчиков, аналоговых и цифровых, всё крутится, обрабатывается и не тупит.