Сравнение цен на сами МК забавно, но взяли-то вы не голые чипы, а STM32F0-Discovery, который стоит 10-14$. Тогда уж сравнивайте его с Arduino Mega 2560 или ESP32S/NodeMCU — характеристики последнего вообще камня на камне не оставляют от STM32.
Для своего проекта я буду использовать голые МК, а учиться будем на Discovery!)
STM32F0-Discovery у местных поставщиков (promelec.ru), равно как и из Китая стоит 17.5$.
Arduino Mega 2560 у них же 80$
ESP32S/NodeMCU из Китая 14.5$ + время доставки (которое тоже =деньги).

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

Ну и использование ESP32 и Arduino не даёт новичкам такой возможности сформировать фундаментальные навыки и опыт разработки под МК в отличии от хорошо документированного STM32.

О гибкости решения на Arduino можно и не заикаться.
О надежности и отказоустойчивости ESP рассуждать не буду. О энергоэфективности решения на Wi-Fi относительно простых радиомодулей суб-гигагерцового диапазона тем более.
сформировать фундаментальные навыки и опыт разработки под МК
И конечно же вы можете дать ссылку на учебник под вашей редакцией, на котором выросли целые поколения студентов, позже устроившихся на профильную работу связанную с МК?

от хорошо документированного STM32
Отличная шутка.

О гибкости решения на Arduino можно и не заикаться.
Я заинтригован.
И конечно же вы можете дать ссылку на учебник под вашей редакцией, на котором выросли целые поколения студентов, позже устроившихся на профильную работу связанную с МК?

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

Отличная шутка.

Всё относительно, если вы ставите моё утверждение под сомнение.

Я заинтригован.

Дальше функций из библиотек не уползёшь.
Дальше функций из библиотек не уползёшь.

Чой-то? Никто не запрещает все писать самому.
Мне это не показалось удобным. Архитектура проекта, навигация по нему в ArduinoIDE — невозможна.
При попытке перенести работу в AVR Studio столкнулся, на момент знакомства, с неописуемым количеством костылей.
А вот надстройка над Visual Studio для Arduino показалась мне достаточно удобной для работы. Но это решение я нашел уже тогда, когда во всю уже работал с STM.
На текущий момент с помощью Visual Studio + Arduino проверяю на общую работоспособность датчики, модули и др.

Да и опять же напомню про общие предпосылки — мне хотелось начать свое изучение МК именно с STM.
При попытке перенести работу в AVR Studio столкнулся, на момент знакомства, с неописуемым количеством костылей.


Так возьмите WinAVR. Никаких костылей. Обычный Си. Встроенный ассемблер. Простые команды асма и абсолютная предсказуемость их времени выполнения (1-2 такта обычно).

мне хотелось начать свое изучение МК именно с STM.


Посмотрите размер *.h в CMSIS. :) Мегабайт у stm32f407! Это не самый простой процессор для мигания светодиодом. А ещё есть ST-Periphery (не помню, как пишется). А ещё есть HAL. И всё это сваливается в кашу — друг с другом не стыкуется.

Отдельной строкой идёт Keil. Может, я чего не понимаю, но обычно среда разработки должна предлагать включать в проект библиотеки без их компиляции (файлы lib должны быть — и подключаться к проекту либо ручками, либо для стандартных библиотек lib должны лежать в стандартных папках. А у STM библиотеки в *c-файлах — компилируются вместе с программой (при этом в файлах проекта они не отображаются)). А где ищет библиотеку Keil — загадка природы. Если я ставлю пакеты разных версий, они все там свалены в разных каталогах. И что при подключении компилирует Keil я до сих пор в неведении.

от хорошо документированного STM32


Я тут USB-Host для тепловизора запускал на STM32F407 с помощью CubeMX (а без него вообще не понятно, что делать — примеры из инета не компилируются, так как используют совершенно разные библиотеки, которые ещё как-то надо к проекту прицепить (а после прицепления — откомпилировать)). Так вот, документации как это правильно делать фиг найдёшь.
Никто не запрещает все писать самому.

При чём тут тогда Arduino?
Не понятно))) Парадигма Arduino построена на использовании готовых библиотек и отчасти кода из семплов с последующей переадаптацией
В том-то и дело, Arduino — просто огромный фреймворк, который либо используем, либо делаем всё сами. В последнем случае всё это превращается в обычное программирование под AVR8, которое, кстати, тоже довольно увлекательно.
Возьмите от ардуины только железную часть. Т.е. экстремально дешевые готовые для втыкания в бредборду платы от наших азиатских друзей. А программную часть… Выбросить и забыть. Взять AtmelStudio (которая есть удобнейшая Visual Studio) и пишите на правоверной и удобной сишечке без всех этих ужасных digitalOutput и прочих макросов поверх коллбеком обернутых в макросы.

И нет. Не подумайте что я защищаю ардуину и/или протестую против стм.

Просто каждому инструменту свое место. И чем шире ваш опыт в инструменте как разработчика — тем больше вам цена.
А т.к. вы позиционируете себя как преподавателя — тем больше к вам требования в плане обширности кругозора.
Хочу добавить еще один + в пользу STM.
Сам начинал с AVR и именно голых чипов — так пока разбирался с их фьюзами пару чипов залочил.
С STM же никаких проблем, залочить нереально, убить чип — тоже нужно постараться.
Я тоже так думал, но у STM есть защитные биты которые действуют ещё хуже — чип зашивается намертво и его нельзя будет ни прошить ни прочитать и даже очистить нельзя будет.
Да, но они не являются одним из главных инструментов настройки. Короче — не трогай их и всё будет хорошо.
А как же переключение с HSI на HSE? Там же фьюз битами всё делается. Я по неопытности две тиньки залочил как-то раз)))
Я про защитные механизмы STM :)
С AVR с этими фьюзами разработчиков, похоже, икота до сих пор не отпускает.
Боюсь что до манипулирования этими вещами в прикладных задачах вряд ли руки доходит. А вот до Fuse-битов в ATMega/Tiny…
То же самое, фузы тоже надо трогать только один раз. И тем не менее…
Вы наверное изолентой только провода изолируете?
Лучшая закладка, чем ссылка на страницу DiHALT я не знаю.
не там отобразился, речь про «закладку базиса»
Согласен. DiHALT очень хороший базис даёт. Просто о сложном — это про него.
Под фундаментальностью я подразумевал плотную закладку базиса в освещаемом вопросе.

А я — профессиональный программист и потому отношусь к рассуждениям о базисах весьма скептически. Ниже в комментариях shell4692 рассказывает про многопоточные задачи. Это действительно интересная тема и в ней наверняка есть некоторые нюансы, которые следуют непосредственно из железа. А для мигания светодиодом (или IR/RF передатчиком) никакие базисы не нужны, это тривиальные задачи.

Дальше функций из библиотек не уползёшь.

Разве что в том смысле, что уже существуют тысячи библиотек и есть библиотека (а то и несколько) для практически любой железки или протокола. Но в целом, не вижу никаких проблем с написанием своих библиотек.
До проф. программистов мне явно далеко, и пока я возможно кому-то помогу понять базовые стартовые вещи поняв которые человек уже сможет отправиться в обучение самостоятельно. Я, к примеру, когда только взял в руки Discovery понятия не имел как ее запрограммировать и как поморгать светодиодами — мои статьи скорее для зеленых новичков нежели для проф. программистов. Нужно понимать на какую аудиторию нацелены мои материалы.
«ESP32S/NodeMCU из Китая 14.5$» — где вы такие цены находите?
Неделю-две назад заказал на BangGood ESP32 DevBoard за 4.07$ (это была акционная цена, сейчас 6.79$ стоит)
Судил по первой ссылке из поисковика: ru.aliexpress.com/item/Nodemcu-ESP-32S-ESP32-Development-Board-For-Arduino-IDE-Wireless-Wifi-Bluetooth-Micro-USB-Shield-Module/32802435488.html

Исследований ESP-рынка не проводил)
Ну тогда для комплекта давайте такую ссылочку оставим тут:
Geekcreit® ESP32 Development Board WiFi+Bluetooth Ultra-Low Power Consumption Dual Cores ESP-32 ESP-32S Board banggood.app.link/F7X2zBdMDG
А Keil по-прежнему платный? Лет 10 назад писал на нем для Atmel'овскоко 51-го микроконтроллера и лицензия, ЕМНИП, стоила 8000 EUR. Хотя, не то, чтобы я ее покупал…
Сейчас есть бесплатная лицензия на Cortex-M0 но ее установка блокирует возможность работы с другими типами ядер (M4, M7, etc.)
Процесс выбора МК не описан. Из таблички можно сделать и совсем другие выводы.
Мне например сложно представить зачем нужны пять таймеров. Для просыпаться и что то делать достаточно одного, ну пусть нужен ШИМ, под него ещё один, итого, для 90% задач достаточно 2 таймера. Более точный АЦП тоже нужен редко. Под 5 вольт проще и дешевле найти обвязку (хотя это спорно). У 328 большое количество вариантов корпусов, от DIP (проще макетировать) до BGA (меньше места), у stm только LQFP/SSOP что для начинающих большая трудность. Ну и наконец, флеша одинаково, но один 8 битный, второй 32, совсем грубо во втором поместится в 4 раза меньше команд.
Ничего против stm32 не имею, просто не понятны критерии выбора, и мне кажется что это важный момент для начинающих, ведь это статья для них.
Я думаю что, этот вопрос необходимо раскрывать ориентируясь на конкретное ТЗ и на основании определенного перечня требований. Этот вопрос я раскрою когда буду раскрывать выбор МК для своего устройства.
Насчёт DIP — полностью согласен, жаль что ST не потрудились сделать такой корпус для начинающих.

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


На мой взгляд реальный минус тут не в макетировании, а в том, что если самому плату проектировать, то у LQFP между ногами дорожку не протащишь, что сильно усложняет трассировку дорожек с питанием и землёй (которых нужно четыре пары). Особенно на односторонней плате. Можно, конечно, делать Gerber и заказывать платы, но для меня это хобби. А что это за хобби, когда его за тебя кто-то другой делает? :)

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

Это интересно. А как там к выводам подпаиваться в домашних условиях? Фен и паяльная паста? И где берёте STM32 в таком корпусе? На Aliexpress сходу не нашёл.

Всё ношу в голове мысль попробовать паяльную пасту. Но пока только флюс, фен, паяльник.
Последовательность проста:
1. Залуживаем после вытравки дорожки
2. Наносим флюс
3. Позиционируем МК
4. Нагреваем феном удерживая МК пинцетом
5. Ждём пока усядется МК.
6. Чистим плату от флюса, проверяем пропайку через микроскоп.
7. Допаиваем ноги острым жалом, если где-то есть подозрения на непропай.

Закупки все осуществляю у местного (г.Екатеринбург) поставщика, в Промэлектронике.

Если интересно — загуглите STM32F051K8U6, на Али они тоже есть в продаже. Ценник особо не отличается от «Промки», мне лично время дороже, не люблю ждать. Либо обычно заказываю заранее.
Да не бойтесь вы LQFP, паяются они с закрытыми глазами. Плату изготовить сложнее, но есть вариант развести и заказать у китайцев, только подождать доставку придётся. Но зато девайс будет выглядеть как заводской. Плюс вы не ограничены одним слоем и имеется возможность сделать металлизированные переходы, а при разводке это просто кайф, в отличии от разводки под утюг.
после ssop32 я ничего выводного не боюсь )) Но до этого надо дойти. Естественно использовать DIP в готовом устройстве уже выглядит немного странным, но возможность по быстрому натыкать их в бредборд, накидать перемычек и убедиться что белый дым не выходит — бесценно. А потом, когда уже все работает и отлажено можно делать разводку платы под любые корпуса.
один 8 битный, второй 32, совсем грубо во втором поместится в 4 раза меньше команд

Прямо скажем, такой подсчёт некорректен; более того — лукав. 1) В ядре AVR регистры данных 8-битные; но слова программы 16-битные. 2) Ядро CortexM0 в STM32 использует 16-разрядный набор инструкций Thumb.
«совсем грубо» же. Ок, в два раза меньше команд. Но что то мне подсказывает, что у ARM на настройку периферии уйдет больше команд чем в AVR, и в итоге в AVR все рано поместится больше полезного кода.
один 8 битный, второй 32, совсем грубо во втором поместится в 4 раза меньше команд

Прямо скажем, такой подсчёт некорректен; более того — лукав. 1) В ядре AVR регистры данных 8-битные; но слова программы 16-битные. 2) Ядро CortexM0 в STM32 использует 16-разрядный набор инструкций Thumb.
У стм есть скорость и довольно развитая периферия, у авр есть прецизионный ногодрыг. Каждому молотку свое применение. Вы ведь не будете кувалдой забивать какойнить гвоздик в часовую оправу? Вот здесь точно так же.

Я, признаться, довольно часто использую связку стм+авр причем даже нередко в виде +ардуина(как железка-плата, а не фремворк) именно по этой причине — когда требуется именно прецизионный ногодрыг когда нужно высчитать все задержки с точностью до такта. А стм это не всегда позволяет — см RMxxxx
Зато в стм32 можно писать из памяти в порт через DMA. Очень даже прецизионно и плюс проц не занят.
И как в посылке между битами обработать условия при использовании DMA?
Вопрос риторический. Не отвечайте — никак.

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

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

Для решения именно этой задачи, да, перебор, но для обучения — почему бы и нет?

Тема насчёт дистанционного выключателя была взята в качестве отправной точки. В сущности я не планирую останавливаться только на выносном выключателе. На текущий момент я работаю над цельной централизованной экосистемой устройств а-ля «Умный дом», в т.ч. для управления освещением/нагрузками (тех которые действительно требуют управления, например электронагреватель, теплый пол и др.), системой датчиков качества воздуха, приточной вентиляцией, датчиками температуры и т.д.
Ну и попутно ставилась цель научиться. Понимание того, что знания по теме достаточно фрагментированы — я решил поделиться своим опытом и наработками с начинающими, т.е. ровно тем, чего мне не хватало когда я сам начинал учиться.
Сразу подскажу куда ковырять эту тему. К сожалению, многие тяготеют к топологии «звезда». А ведь в быту это крайне неудобно. КМК, самое разумное примерно следующее: «полуумные» устройства. Т.е. «выключатель» логически вяжется с «лампочкой». Смысл в чем. выключатель напрямую говорит лампочке включиться или выключиться. БЕЗ участия центрального контроллера. Он, конечно, тоже слушает весь этот трафик и послушно рисует во всех этих веб-интерфейсах красивые анимированные иконки состояния. Но на этапе управления его роль маленькая — задает связи выключатель-лампочка, и… и ВСЁ! дальше выключатель и лампочка общаются между собой.
Это дает огромное преимущество — можно просто выдернуть из розетки центральный контроллер, но свет в туалете/ванной буде включаться.
Домашние это оценят особенно высоко.
Завтра как раз буду растягивать провода в доме под схожую архитектуру — отдельный кабель до каждого источника света и каждого выключателя. В щитке будет сменный блок коммутации, позволяющий либо управлять всем барахлом с ардуины, либо на чистом аналоге. Хотя по здравому размышлению баловство все это — проще держать в запасе прям в щитке пяток ардуин на смену, чем перекоммутировать.
Что за кабели решили использовать? У меня пока ремонта нет — над тем же думаю. Склоняюсь к витухе.
Ээээ… ВВГнгЛС. Смысл в том, что сигнальный кабель параллельно силовому тянуть не буду — вся коммутация только в щитке. Вместо обычной схемы, когда от щитка идет провод до коробки, оттуда фаза ответвляется до выключателя, возвращается и с нулем идет до светильника — и выключатель, и светильник имеют свой выделенный трехпроводной кабель. Если захочу — в щитке организую классическое подключение, а захочу — приведу проводник с выключателя на дигитал.ин, а фазу возьму с дергаемого той же ардуиной реле. Благодаря трем проводникам до каждого выключателя есть возможность использовать трехклавишные выключатели, обеспечивая управление тремя источниками. Благодаря ардуине (в отличие от бистабильных реле) можно использовать традиционные выключатели, а не «кнопки», которые дороже и реже в наличии — сигнал на включение/выключение можно кодировать изменением статуса клавиши, а не кратковременным нажатием.
А, вон как. Я думал, вы про сигнальные.
На самом деле я тоже думал тянуть от каждой розетки/выключателя отдельно, но получается слишком затратно/геморно. К примеру, есть блок розеток 4-6 штук, уже жгут силовых проводов, что их непросто проложить, а в комнате таких блоков может быть 2-3, это пучок в руку толщиной.

Пришел к выводу протянуть к каждому такому блоку/розетке сигнальный провод, оставить место под управляющую плату, и подключить всё по старинке.
С розетками — скорее всего так и сделаю (хотя не очень понятно, нахрена рулить каждой розеткой), даже если не понадобится для автоматики, витая пара в каждом блоке не помешает. Со светом это смысла не имеет — одна/две нагрузка на точку, дешевле и проще дотянуть до каждой кабель.
Со светом конечно, при том сечение провода будет гораздо меньше.
На счёт розеток: в идеале видеть нагрузку на каждую из них и рулить соответственно. Банальный пример — воткнули в один блок ноут на зарядку и утюг, и ушли из дома. Как погасить одно, не трогая другое?

Ещё выбор витухи вызван тем, что может понадобиться розетка для LAN, при этом можно задействовать 2 пары на своё усмотрение. То есть растянуть их везде во время ремонта, а потом делать/не делать по мере появления желания.
Гигабит становится обыденностью, двумя парами уже не обойтись… темболее еще и неэкранированными.
Знаете, я ретроград. Я дома удаленно не рендерю и кластеров из холодильника и торшера делать не собираюсь. 100 МБит хватит всем, почти как 64к памяти.
Разве что если цель сети — только доставка интернета. А когда бэкап при полностью свободной сети заливается на NAS больше 40 минут… это очень уныло.
Бэкап чего? Всех фоточе и фильмов с диска + образ системы? А нафига? Я конструктор, у меня рабочие файлы мелкие, за месяц может гиг-другой генерирую, так что быкапы небольшие. И они на работе, естественно — нафиг не надо дома рабочие файлы держать.
За год, у вас стало быть 12Гб генерируется, и с каждым годом объём растёт…
Образ системы — для того чтобы быстро восстановить работоспособность в случае глобальных и серьезных проблем, даже если нет ничего ценного восстановить из бэкапа всегда быстрее чем переустанавливать систему с нуля и ставить весь нужный софт. Пару раз эта функция пригодилась.
Бесконечный инкрементальный бэкап плох тем что при повреждении где-то в середине цепочки весь «хвост» становится протухшим. Поэтому инкрементальный бэкап захватывает максимум две последние недели. И копии всех бэкапов храняться как локально так и на NAS-е. Вот этот перенос копии бэкапов на NAS и занимает существенное время.
Фотографии тоже надо бэкапить как особо ценные файлы которые не с чего восстановить. А их накопилось пожалуй даже больше чем образ системы.
NAS, инкрементальный бекап… Что-то круто для дома. Если такое количество информации дома генерировать, то когда работать?
А несколько фоток + домашние проекты заливаются в облако по мере их появления, и всё.
Я работаю когда хочу и где хочу. Если приспичило дома — то и дома можно. Другое дело, что один фиг даже в самом запущенном случае пару раз в неделю появляюсь в офисе.

Но в общем по поводу домашних проектов согласен.
Не круто а обыденно. Информация генерируется постепенно, но в итоге накапливается её много — и это надо периодически бэкапить и обновлять чтобы не потерять ВСЁ.
Облака это пока ещё ненадёжная игрушка. Заблочат аккаунт по каким-то своим соображениям и прощай данные, к тому же где взять бесплатно 50-100-200Гб места в облаке? Пожалуй, съёмный винт(даже два винта) в перспективе и меньше рисков и дешевле обойдётся. А облако… разве что для оперативного бэкапа и синхронизации между несколькими локациями. На надёжное хранилище бесценных данных оно не катит, только как очень временное или дополнительное.
Не, у меня не массив рабочий растет, а архив — он остается неизменным, его нет смысла бэкапить. Ну и как бы трех бэкапов (на работе, на ноуте и на станках) хватает за глаза, дома нафиг не надо.
Ну вот как раз я долго и упорно думал — может ли у меня быть ситуация втыкания в один блок ноута и утюга… Пожалуй, нет — у меня утюг будет только в гардеробе. Ну и так далее: отдельный «всегда вкл» блок для мультимедиа, блок с резервированием под сервер, некоторое количество управляемых блоков. На кухне тоже: управляемые (розетки для кухонной фиготы типа блендеров/кофемолок), «всегда вкл» (для девайсов с таймером) и резервированные (для холодильника).
А так чтобы смешивать… очень редко когда пригодится.
Так что витуха скорее всего именно под ЛАН.
Товарищ, пишите ищо!
Материал для новичков на эти чипы в основном напоминает майкросовтовские курсы. Нифига никто ничего не объясняет, просто дают методичку для достижения конкретной цели. Если Ваша цель отличается — фигово быть вами. Без фундаментальных знаний можно только быдлокодить.
Обратите внимание на библиотеку HAL — это куча всякой полезности для микроконтроллера, инициализаторы всего и вся… не, не смогу кратко описать всю ее полезность (вот щас некоторые начнут рассказывать что всё должно быть без библиотек… а то развели..)
Другая тема — CubeMX. Тоже на сайте производителя можно найти, программка для конфигурирования камня. Там например в настройках частоты такой бардак, что сами микроэлектроники за голову хватаются, вот и сделали программку. Частота процессора одна, шин другая, периферии третья… и это далеко не все… Ну плюс настройка ввода вывода, интерфейсов и многого другого тоже там есть.
Я считаю HAL очень мусорным, нечитабельным. Дебаг в нем превращается в сущий ад.
CubeMX смотрю, как правило, только для того чтобы сформировать значения по тактированию, возможно глазком заглянуть в генерацию таймингов. Но генерируемый им код считаю не юзабельным. Глубоко не копнешь, всё разбросано по куче файлов в проекте. Словом возмутительный бардак.
От использования HAL и CubeMX напрямую я отказался.
Со своей формой библиотек я так же ознакомлю в последующих материалах.
HAL, конечно, перегружен и сгенерирован, со всеми вытекающими, но зато довольно богат и серьезно упрощает жизнь, если проект не слишком заморочен.
и серьезно упрощает жизнь, если проект не слишком заморочен.

то в таком юзкейсе ардуина — божья роса.
А ардуина не всегда достаточна, не всегда подходит, и все-таки не industrial grade. А вот взять камень, развести под него плату какого надо функционала, размера и типа, и быстренько, не заморачиваясь, накидать несложный функционал, без необходимости изобретать велосипеды — бесецнно.
Будучи уже 5 лет разработчиком на stm32 хочу обратить внимание автора статьи на один нюанс. Главное отличие stm32 от AVR есть возможность вложенной обработки прерываний и наличие DMA. А также, наличие SysTick — таймера, который тикает не во внешней периферии, а в ядре. Это позволяет делать на нём многопоточные приложения, чего AVR8 лишён в принципе (я имею ввиду mega328p/mega16/mega32 и вообще AVR ядрёные версии). Для однопоточной задачки вполне себе подошёл бы и Ардуино, ничего такого ужасного в нём нет. С моей точки зрения, оба контроллера пригодны для решения задач, у каждого есть свои преимущества и недостатки. Пятивольтовые AVRки вполне себе могут уживаться в одной схеме с трёхвольтовой stm32. А для выключателя на стенке вполне себе, наверное, хватило бы и чего-то мелкого, вроде attiny.

Кстати, использование CMSIS для новичков, это довольно сложный способ вхождения в тему. Есть гораздо более простые вещи, например, библиотека Peripheral Library, которая является надстройкой над CMSIS и предлагает простые и удобные функции работы с очень запутанной периферией контроллера, без надобности (на первом этапе) вникать в структуры периферийных регистров и карты их полей. Ну, или более современный вариант, вроде CubeMX.

На мой взгляд, самым «вкусным» контроллером 30й серии stm является ИМХО stm32f030f4p6. Имея встроенный генератор на 8МГц, который раскачивается ФАПЧем до 48МГц и корпус TQFP20, он очень красиво становится на адаптер TQFP->DIP и занимает всего лишь пару квадратных сантиметров на бредборде. На него запросто можно уместить 10-15 поточное приложение, которое будет иметь некую структуру драйверов и сервисов.
1. Насчёт использования AVR/Arduino/ATTiny — по секрету говоря, я с них как раз таки начинал, но STM32 мне показался более перспективным в плане моего развития, да и коллеги могли помочь в значительной степени на начальном этапе. Я не говорю что мой вариант и способ решения единственно правильный или сообразный — я говорю о том, что мне он показался наиболее интересным. Согласен, тут свои плюсы и минусы.

2. Использование CMSIS было использовано с целью максимально быстро организовать сборку проекта для того, чтобы увидеть вожделенное моргание светодиодами. А приучать себя заранее работать с битовыми операциями, картами регистров, изучая работу низкоуровневой части, если это подано в доступной и понятной форме, ничего сложного не вижу. Сам именно с этого начинал. Разбирался и прокачивал скилл с нуля. Смог. Справился.
Это позволяет делать на нём многопоточные приложения, чего AVR8 лишён в принципе (я имею ввиду mega328p/mega16/mega32 и вообще AVR ядрёные версии). Для однопоточной задачки вполне себе подошёл бы и Ардуино, ничего такого ужасного в нём нет.

scmRTOS — считается? Я запускал её и использовал на Arduino (в одном из журналов Хакер есть статья как это сделать). Нормально вроде работает, процессы переключает.
Несомненно считается. Автор scmRTOS делал её для не только для AVR, а вообще для МК и делал её на C++. И это наложило отпчаток на системные требования scmRTOS — 512 байт ОЗУ минимум. Однако, простой кооперативной многозадачности было бы достаточно для небольшого (по сравнению с stm32) ресурса этих контроллеров. Честно говоря, не хочется превращать беседу в holywar типа stm32 vs avr. Я много лет назад начинал на AVR и до сих пор их использую. Также, как и stm32.
Вот насчёт контроллера «умного дома» на stm32Discovery у меня возникают сомнения. Тридцатка слабовата, чтобы тянуть на себе RTOS на целый умный дом, для таких целей, наверное, могли бы подойти модули Maple-Mini, на stm32f103c8, у которых 72Мгц с внешним кварцем. Да и они тоже как-то слабоваты.
Да не на Discovery же, я их беру в поле рассмотрения только для обучения же, ну!
Целевой девайс будет полностью кастомным на отдельном МК. А центральный контроллер будет на ARM Cortex-A53.
Вы понимаете всю пропасть в схемотехнике и проектирование ПП? Это иная область. Я мало знаю людей, которые одновременно могут это делать еще и разрабатывать ПО.
Имхо, ядро вашей системы должно быть на одноплатнике. Проще и удобнее решение.
Именно так и есть: под ARM Cortex-A53 я подразумевал Raspberry Pi 3.
Там уже предстоит командная разработка. С вами не поспоришь.
Невозможно быть экспертом-профессионалом во всех областях IT.
Тогда не понятно, зачем вам нужен stm32. Делать на нем периферию?
Вы же не будете писать свою ОС под RPi3.
1. Одноранговые устройства сети: датчики, управлялки, модули, драйверы и др. — это всё на STM32 + LoRa.
2. Центральный контроллер на RPi3 + LoRa.
а почему LoRa?
Дальность большая нужна?
Вообще, на самом деле, прежде чем выбрать LoRa я опробовал целую кучу решений для радиосвязи прежде чем остановился на LoRa.
1. ESP8266 — глючил, не оживал после резкой перезагрузки. Прожорлив по питанию. В целом не очень решение для организации низкопотребляющего автономного устройства.
2. RF-433 модули — примитивные, ASK-модуляция, никакого протокола и механизма обработки пакетов, полностью ручное управление.
3. NRF24L01+ — хорошие модули НО: криво работающая система адресации, ограничение на количество сетевых адресов в сети (7 по-моему). Бывает такое что одному модулю прилетает не предназначенный для него пакет, он шлёт ACK на передатчик и целевое устройство не получает то что должно было придти к нему.
4. SPIRIT1 — богатые по функционалу и возможностям устройства, но требуют разработки радиотракта (лежит за пределами моих текущих компетенций) и настройки согласования антенны. Готовые модули SPSGRF-XXX дорогие и имеют малый радиус покрытия даже с антенной.
5. LoRa — низкое потребление, большая дальность. Настраиваемые прерывания на ноги GPIO самого модуля, RSSI, пакетный конвейер, и много других фишек (которые к слову есть и в SPIRIT1). Предстоит еще обкатать чтобы сделать выводы об этом модуле. Ну и много хороших отзывов.
Мне нравятся всех больше si4432 (si4463). Дешевле чем LoRa.
Для дома (+ около дома) помоему самое то.
Возможно это только мне повезло так.
есть ещё вариант CC1101 от ti. Но я его не пробовал.
Это и есть купленный в последующем ST SPIRIT1)))
Они отличаются немного ST-шных. Сам не юзал, не могу дать оценку качеству и пригодности к использованию данных модулей.
RTL8710 — типа ESP8266, но лучше.
А как же 802.15.4 — ZigBee или Thread?
У NXP есть очень интересная серия — KW41Z (с Bluetooth и без него), у Atmel — Mega RF, SAMR и множество других.
ESP8266 — глючил, не оживал после резкой перезагрузки
Типичная проблема неправильного питания. Такое часто случается если кто-то после дешевого стабилизатора не поставит нужный конденсатор для выравнивания ряби и/или не поставит достаточно емкий конденсатор для сглаживания скачка питания, возникающего при включении радиомодуля. Если все сделать по даташиту (я знаю, это кажется нелепым, но все же), то ESP работает без малейших проблем и сбоев.

Я мало знаю людей, которые одновременно могут это делать еще и разрабатывать ПО.

Зайдите на любой радиолюбительский форум. Таких людей масса, но они больше ориентированы на низкоуровневое программирование, «ближе к железу».
Реально сильных программистов, которые делают правильно не так-то и много. Просто кодить это вот ардуино доказало, что может каждый. Вы ещё скажите, что любой из них под плис напишет.
И под плис пишут, и в связке с МК, и в сочетании с нехилой схемотехникой. Но таких конечно мало, а составить схему и написать код (не идеальный, но рабочий) — очень многие. При том ардуино не жалуют.
Последнее, о чем нужно думать новичку при выборе первого контроллера — это сравнение производительности, наличие DMA и пр. Простота входа — вот первый шаг — тут и лёгкий старт, наличие простых обучающих материалов, а не копание в даташитах. А дальше, после первых проб и проектов, уже будет понятно, что надо, а что не надо. И можно будет выбрать соответствующий МК.
Если вообще -то нужно предварительно разобраться в вопросе прежде чем принимать то или иное решение в пользу того или иного контроллера. И всё очень сильно зависит от целей и возможностей конечного пользователя.

В свете данного комментария я могу сказать что я стал очень необычным новичком. И своими статьями хочу снизить порог вхождения в кодинг МК на STM32, ну или сделать процесс вхождения более просты путём изложения накопленного мною опыта.
> снизить порог вхождения в кодинг МК на STM32, ну или сделать процесс вхождения более просты путём изложения накопленного мною опыта

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

Смотря в каком направлении нужно шагать ;)

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

Когда управление проектом в стиле "не заводится? поехали, потом заведешь" — странно ожидать другого ;). А так,


  • задача выполнена? Да.
  • возьми бы авторы вместо ардуин STM32 Discovery, было бы иначе? Вряд ли.
Еще один туториал по STM32? А зачем?
Вся проблема в том, что информация по вопросу достаточно фрагментарна и приходится её аккумулировать, ползая по огромному количеству ресурсов и складывая общую картину из пазлла. Ну и некоторые вещи которые я собираюсь рассмотреть взяты из англоязычных источников. А начинающие, как правило, не отягощены знанием тех. английского и порой передовой опыт зарубежных коллег обходит новичков стороной.

Цель моего материала — наиболее широкое освещение спектра базовых вопросов и изложение аккумулированного мною опыта. То есть создание такого материала, которого мне так не хватало на момент когда я начинал изучать STM32.
Ну не знаю. Статей про светодиод и его мигание очень много. А вот статей про какие-нибудь редкие функции периферии, навроде режима захвата у таймера или про использование MAC контроллера, явно недостаточно, даже из референс мануала информации вытянуть получается немного. Поэтому, если начинать такую обширную тему с основ, которые разжёваны тысячу раз другими, до настоящих интересных задач вы не доберетесь, т.к. просто надоест писать столько статей.
Рассчёт был именно на «писать столько статей». Т.к. когда готовишь подобного рода материал для публикации — как минимум систематизируешь свои знания и иногда можно даже узнать что-то новое. Поэтому мотивация продолжать написание разного рода статей — железная! =)
В таком случае я бы вам посоветовал использовать CubeMX+какую-нибудь бесплатную IDE, например, Atollic, Coocox (кажется он уже всё), SW4STM32 или же чистый Eclipse с плагинами, т.к. размеры кода со временем вырастут за 32кб. CubeMX и библиотеку HAL многие ругают (возможно есть за что), но если при объяснении функционала микроконтроллера использовать и её, и чистый CMSIS, то статьи только выиграют. Удачи вам в ваших начинаниях!
В моих библиотеках получилась смесь CMSIS + HAL + плюшки CubeMX (в плане удобного интерфейса для рассчёта схемы тактирования и справочной составляющей этой программы) завёрнутая в удобные иерархически выстроенные и отлично откомментированные библиотеки.
Спасибо Вам за добрые слова! Именно хорошие отзывы больше всего вдохновляют! =)
Я думаю при изучении STM32 стоит ещё обратить внимание на wiki.stm32duino.com/index.php?title=Blue_Pill стоит копейки, но достаточно удобна для мелких проектов.
Да, это самое дешевое предложение из имеющихся на базе STM32 — около 100р. из Китая.
Но т.к. серия STM32F103 была пилотной серией 32-разрядных МК от ST — всё получилось по принципу «первый блин комом». И есть ряд различий по картам регистров и проблемы с совместимостью с текущим предложением в аналогичной линейке продуктов от ST.
Я использую HAL и про регистры не знаю, в целом спокойно перешел с 103 на L433 когда понадобилось, и всё работает.
Не рискну делать каких-либо выводов но мне кажется что портируемый код был достаточно прост чтобы плавно переехать с F103 на L433. Я люблю абстракции но с условием полного понимания что за этими абстракциями происходит.
А ещё можно было извернуться и воспользоваться проектом Stm32Duino: Получить мощь и функционал STM32 и обилие библиотек, готового кода, мануалов и прочих нищтяков от Arduino.
Так или иначе данный подход не реализует весь потенциал STM32 во всей широте и не даст ощутимой прокачки скилла и опыта т.к. всё будет уже готовое.
Почему не дает, поясните? Фреймворк ардуины только лишь берет на себя рутину, но ничуть не бьет по рукам желающим напрямую обращаться к регистрам и писать наиболее эффективный код. Поправьте если ошибаюсь.
Сам юзаю visual studio+visual micro и счастлив, хотя работать с широкой периферией задач не возникало.

P.S. С нетерпением жду от Вас статьи в которой будет расжевана работа с каналом DMA.
Спасибо за Ваш труд, он нужен нам.
Я имел ввиду традиционный подход к программированию Arduino в Arduino IDE
Рекомендую для начала всё же ардуино, чтобы не заморачиваться наперво по поводу железных вещей и сосредоточиться на качестве кода. Ну о каких циклах для задержки может идти речь? Гуглю давно пора забанить за такие костыли.
learn.adafruit.com/multi-tasking-the-arduino-part-1/a-classy-solution
Т.к. я и сам новичок, то хочется услышать от более зрелых коллег по поводу реализации т.н. задержек по ссылке. ИМХО — как раз там всё описано очень хорошо, и код мне люб.
Это HelloWorld в мире МК, минимально работающая программа, результаты которой видны. В реальной программе никто задержки циклами не делает, если это не считанные такты.
По ссылке — ардуино, что не имеет никакого отношения к теме.
Предложите лучший вариант без использования дополнительной периферии для организации задержки. Очень интересно было бы увидеть оригинальное и простое решение! =)

Я в этих STM32 не разбираюсь, но, чорт побери… Есть же usleep() (гуглится).

Вы про это что-ли? Обратите внимание на тело функции пожалуйста :D
int usleep( useconds_t __useconds )
{    
    volatile uint32_t nCount;
    RCC_ClocksTypeDef RCC_Clocks;
    RCC_GetClocksFreq (&RCC_Clocks);
    nCount = ( RCC_Clocks.HCLK_Frequency / 10000000 ) * __useconds;
    for( ; nCount !=0 ; nCount-- );
    return 0;
}

И? Стандартная функция, существующая почти на любой платформе.
Если сравнить это


for (int i=0; i<500000; i++){}  // Искусственная задержка

и это


usleep(500000)

, что более наглядно?

Я не преследовал цели сделать максимально красиво и наглядно.
Мне надо было только сделать простейшую моргалку светодиодом при минимуме усилиий со стороны читающего статью. Вводить функции и прочее в мои планы не входило. Если нужны были бы задержки — я бы сделал их средствами периферии.
Я не преследовал цели сделать максимально красиво

при минимуме усилиий со стороны читающего статью

Эти 2 предложения конфликтуют, или мне показалось? ;)
Проехали, смысл helloworld от этого никак не страдает, и подобных мигалок светодиодом гуглятся десятки, и у всех в нутре for(). Хотя как-то странно, для демонстрации очень простого алгоритма на супер-пупер-мощном кристалле все делают helloworld в том самом Arduino-style, на который с таким пренебрежением кивают ;)

Без использования периферии можно использовать счётчик, но не определено время инкрементирования (зависит от времени цикла) — это решение тоже не будет годиться для критичных к точному времени задач, но оно не будет блокировать остальной код во время между включением и выключением диода.
Вы про SysTick?
SysTick is an ARM core peripheral (с), следовательно — нет, я не про него. C ним как раз всё будет более-менее детерминированным. Но Ploop говорит, что это ардуино, а значит — плохо.
Без периферии просто uint32 счётчик, инкрементить раз в цикл.
Я не говорю, что это плохо, я говорю, что это не тема данной статьи.
А так всё вы верно сказали, без использования периферии не сделать чётких таймингов (если, конечно, основной цикл занимается хоть чем-то ещё).
Ардуино и качество кода. Вы это серьезно?
Расскажите, пожалуйста, что не так в примере по ссылке. Что не нравится, что нужно сделать по-другому. А мы с удовольствием почитаем комментарии специалистов в этой области.
Я про среднюю температуру по больнице.

STM32CubeMX — лучший инструмент. Он генерирует код под ВСЮ переферию МК. Я лично перешел с PIC -> AVR-> STM32 только ради HAL и STM32CubeMX. А корпуса то какие удобные! Малеенькие даже на 48 ног.

Генерируемый код, на мой взгляд, очень не читабелен и трудно отследить его до низкоуровневой составляющей. Нет наглядности. Простота — да, скорость — да, удобство — несомненно. Но я прежде всего планирую научить и рассказать, а потом уже предлагать готовые решения и уровни абстракции, причем на начальном этапе я рассматривают CubeMX как абстракцию от понимания того что происходит на нижних уровнях и как это всё работает. Мне, как инженеру, интересно как там всё устроено и по какому принципу всё работает.
Я уже писал подобный комментарий две недели назад под аналогичной статьей про STM32 на хабре, поэтому повторюсь.

Ни в коем случае не хочу обидеть автора, но меня несколько удивляет методология такого подхода. Автор берет STM32 (внимание, контроллер с мощнейней перефирией), показывает, что через регистры можно изменять состоние светодиода и делает вывод, что таким образом можно делать все. Но ведь это не так. Если я беру STM32, то, очевидно, мне нужно много больше, чем мигать светодиодом. Например, RTC (включая все зубодробильную логику работы с датами и временем в разных часовых поясах и високосных/невисокосных годах), SDIO со всей логикой общения с карточкой (включая CRC контроль данных), USB-стек, внешняя память, и все это через DMA. Именно этот функционал и является основной частью HAL, а поморгать светодиодом — это так, базовый уровень. Вы высокоуровневый протокол работы SD карты, FatFS или USB-стек тоже сами будете с нуля переписывать? А если Вам этот слой HAL неинтересен (то есть нет потребности в этом функционале), то зачем Вы вообще берете STM, а, скажем, не Atmega16?

Да, HAL сложен, там есть ошибки, в документации сам черт ногу сломит, но он реализует высокоуровневые протоколы богатейшей перифирии STM32, которые не просто не нужно, но даже вредно переписывать самому.

И второй момент. Вы берете платную IDE в демо-режиме с ограничением по размеру программы и говорите, что все OK. Нет, не OK. Как только Вы задействуйте перефирию (USB, SD, дисплей), вы мгновенно в это ограничение упретесть, а именно перефирия и является сильной стороной STM32. Зачем такие костыли, когда есть официальная кроссплатформенная IDE именно для STM32, бесплатная, без ограничений, с полной интеграцией HAL и CubeMX, а также с тысячами рабочих и полезных плагинов. Я говорю про sw4Stm.
1. Я не делаю вывод на основании того, что поморгав светодиодом мы можем сделать всё что угодно. Поморгать светодиодом это своеобразный ритуал вожделенного дрыганья ногой от нашего МК, первое что хотят новички от МК и я не отказал им в праве удовлетворить своё желание вдоволь надрыгаться.
2. Вы видимо не уловили из этой статьй информацию о том, что я собираюсь написать цикл статей по данному МК и его периферии.
3. Большая часть моих библиотек это переработанный и адаптированный HAL, с организацией под удобную мне форму. Это вы увидите когда я выложу первый проект.
4. Кто вам сказал что мне не интересен сам HAL? Мне не интересна та форма в котором её подаёт ST.
5. Насчёт переписывания — ее никто не переписывает/переделывает — я сменил форму не меняя содержания.
6. Когда упрёмся — тогда и поговорим о переходе. Пока в текущих рамках Keil более чем достаточно.

Вы делаете полезную и нужную работу своими статьями — популяризация STM32. Обеими руками поддерживаю. Я только хочу сказать, что неудачно расставленными акцентами можно отпугнуть новичков. STM32 сегодня уже имеет очень развитую и качественную экосистему — SW4STM, HAL, CubeMX. Все это реально работает из коробки, все примеры по миганию светодиодами для всех демо плат уже включены в SW4STM, и именно это и понижает порог вхождения в тему. Но от Вашего рассказа создается впечатление, что такой экосистемы нет и поэтому все сложно.

И еще про HAL. На мой взгляд, как функциональная библиотека он вполне уже работоспособен. Чего не хватает, так это удобной объектно-ориентированной библиотеки драйверов как самой переферии МК, так и внешних устройств. Я в этом направлении работаю: github.com/mkulesh/stm32DevelopmentBoards/tree/master/src/StmPlusPlus

Если Вы двигаетесь в похожем направлении, то мы могли бы скооперироваться.
Вспомогательные утилки типа ST-Studio, ST-LINK Utility, CubeMX и многие другие я хотел рассмотреть в отдельной статье, особенно показав возможность Real-TIme отладки.

Я планирую плавный переход с С на С++. Но пока что не достиг должно уровня компетенции в вопрос чтобы кооперироваться по вопросу. Спасибо за предложение.
Про HAL и размер.
Одно и тоже функционально приложение (USB девайс). Одно на SPL, второе на HAL.
12/28К соответственно
Что там было про размер?..
добавлю, на регистрах (правда с пуллингом) — 1.2кб
Но сделав вывод, что я не узнаю, что творится внутри микроконтроллера за рамками Arduino-скетчей я решил поискать более интересный вариант, который подразумевал глубокое изучение и погружение в дебри микроконтроллерной техники.
Откуда такие выводы? AVR можно наверно программировать и без использования скетчей, на чистом Си. Есть тут кстати матерые ардуинщики, может накидаете ссылок как перейти от скетчей к программированию на обычном Си для AVR?
Я имею ввиду не тех необычных ардуинщиков а в целом парадигму Arduino-программирования и то на что она ориентирована. Если интересно: начните отсюда blogs.msdn.microsoft.com/rucoding4fun/2012/01/14/visual-studio-20082010-arduino
Вас понял, но ничто не мешает взять ту же атмегу328 и запрограммировать ее на Си. Причем взять именно отдельный чип, программировать через отладочную ардуинку. А потом этот чип уже смонтировать на плате с необходимыми компонентами в готовое устройство (не превращая это устройство в ардуину).
Согласен, ваше мнение безусловно имеет право на существование, но мне на момент определения какой МК взять для реализации задачи — показалось интереснее «броситься в омут с головой» и взяться именно за STM32, хотя и понимая, что AVR значительно проще в освоении.
Стоимость на ali atmega328 и например stm32f103 почти одинаковая.
А например stm8s003 стоит вообще копейки
Школьные учебники по математике стоят примерно столько же, сколько и Фихтенгольц. Улавливаете мысль?
Всё верно, нет смысла покупать atmega328, если за ту же цену можно взять stm32f103
Не надо брать голую 328. Вполне можно и в виде ардуины взять. И даже бутлодырь сносить не нужно — он довольно удобен бывает.
Просто отказаться от экосистемы и перейти на светлую сторону — голая С/С++
Есть тут кстати матерые ардуинщики, может накидаете ссылок как перейти от скетчей к программированию на обычном Си для AVR?

Не надо никуда «переходить», надо просто взять контроллер, даташит на него и писать. Благо архитектура проста до ужаса, и во многих случаях ардуино только усложняет всё.

И с чего это си-шники стали матёрыми? Не так давно 8 кило «нетто» кода на ассемблере считалось нормальным… :)
KolibriOS вообще вся а ассемблере написана. А авторы это даже хардокором не называют — для них это норма.
По большому счету нет особой разницы на чем писать когда проект проработан на высоком уровне.
Кстати, верно.
Достаточно посмотреть на готовые проекты. К примеру —
github.com/repetier/Repetier-Firmware/tree/master/src/ArduinoAVR/Repetier
Знатоки, поругайте, пожалуйста, если этот пример плохо отражает парадигму программирования ардуино
void setup()
{
    Printer::setup();
}

void loop()
{
    Commands::commandLoop();
}

Да. Оно.
А это хорошо или плохо?

По ссылке очень хороший пример программирования на C/C++ для Arduino. Не так часто встретишь C++ код для мк avr такого объёма. Автор, судя по всему, не заморачивался оптимизацией, т.к. Arduino Framework формирует очень жирный код, в отличие от C-стиля в C++.
Когда надо просто, чтобы штуковина работала, Arduino с готовыми шаблонами/проектами очень подходит.
В рецепте этого пирога всего 4 простых ингридиента: контроллер в DIP корпусе на монтажной плате, ISP программатор, Atmel-Studio (сейчас, может, по-другому называется), и книга Евстифеева «Микроконтороллеры AVR». Одна из моих первых поделок была именно такой, хотя я тоже не удержался и очень быстро перешел на С++ для более чистого разделения драйверов и логики приложения: github.com/mkulesh/avrDigitalClock

Я не матёрый, но накидаю: http://easyelectronics.ru/category/avr-uchebnyj-kurs/page/5
Читать снизу вверх

Автор, не тратьте время и силы на споры, лучше напишите следующую статью. Нравится спорящим AVR, HAL — пусть используют, зачем их переубеждать? На ваш труд найдутся свои читатели, которые оценят и скажут спасибо, когда начнут гуглить уроки по STM32 и попадут сюда.
Спасибо за дельный совет! Просто не хотелось бы оставить какие-либо вопросы адресованные мне без ответа)
Просто не хотелось бы оставить какие-либо вопросы адресованные мне без ответа)

В холиварных темах (а это она) пальцы сотрёте :)
Буду ждать статей про: ОС, взаимодействие между процессами, драйвер sd-карты, парсинг xml/json, httpd, ajax, ftpd, telnetd (настоящий), modbus tcp/rtu, usb, драйвер rndis, загрузчик… и работы всего этого совместно. Писать самому это всё не надо, хотелось бы разбора чужого кода, запущенного на stm.

Многое из этого (и кое-что ещё) у меня работает на Arduino Mega2560 (я не использую Arduino Framework). Посты про мигание лампочками пока не дают повода перейти на stm.
Жду продолжения. Но в первую очередь ради комментариев, чтобы узнать что там в мире STM32 делается. Мои прошлые попытки ознакомиться с STM были неудачны. Для ногодрыга годится и AVR, тем более он легко пояется и плата под него делается в домашних условиях. А если уж выбирать «фаршированные» STM, то программировать их используя более высокий уровень абстракции, чем писать биты в регистры. А с этим у STM был содом и гоморра, по крайне мере до выхода CubeMX.
На этом фоне PSOC от Cypress смотрелись… Ну скажем так, непонятно че люди занимаются этими STM, когда ест PSOC, дружелюбные как ардуины и мощнее как STM. Да еще и в корпусах с шагом 0,8 мм.
Первый раз прочитал про PSOC! Круто!
Есть что то подобное еще, но более мощное?
Интересная тенденция. Как сравнивать возможности самих чипов, так AVR и STM. А как сравнивать программирование их, так Arduino и HAL. Или с появлением Arduino думается, что программировать их как простые AVR не представляется возможным? Или же, STM32 нельзя программировать как Arduino, или для STM есть например MBED, что есть по сути своей Arduino для STM32

P.S. Хотя вижу подобное замечание, выше уже было высказано.
я просто оставлю это здесь: geektimes.ru/search/?q=stm32#h
Нам надо поморгать лампочкой!
Нет проблем, берем Intel Atom и ...

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


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

Во-первых Arduino — эта платформа с IDE, экосистемой и кучей разжованных мелочей и библиотек, однако она не навязывает их использования вообще никак. Вы можете взять и начать писать с нуля на Си (или ASM) без каких-либо дополнительных инструментов.
Главное, что она дает — быстрое программирование без программатора (через USB) и ворох примеров.
Никто не запрещает переписать loader и зашить все что угодно свое. При этом можно даже пользоваться AVR Studio, а не Arduino IDE.
Фишка лишь в том, что огромная популярность из-за невыского порога старта стала пречиной огромного количества библиотек, инструментов и информации по тому как что и как лучше сделать для данных процессоров.
Куча сред разработки (CodeVision, AVR Studio, Arduino IDE — самые известные), куча программаторов и средств отладки — что еще Вам нужно?

Мало того, что клонов Arduino на али кучи за копейки — если хотите получить полный контроль над однокристаллкой — там куча плат такого рода (тыц) с ATMEGA328 на борту за 1.85$ и USB ISP программаторов к почти всей линейки ATMEGA (тыц) за 2$, купив который можно программировать как эти платки так и тиньки и всякое другое.

И все — Вы получаете готовый кит, на котором можно построить очень многое.
Вот так вот легко на Arduino без Arduino.

Для вашей-же задачи за глаза хватило бы ATTINY13A, причем из-за ее режима энергосбережения она бы у Вас от одной батарейки жила бы годами. Написалось бы все это за пару часов, если знать и за сутки — если не знать и за 15 минут, если использовать стандартный скетч, коих просто дохрена — шутка такая ходит, что Arduino — это платформа для мигания светодиодами :D

STM — отличный процессор, но он для сложных задач и систем, у него есть офигенные плюшки в виде DMA, например, возможность писать многопоточку и т.д.
Но у него гораздо сложнее периферия, плохо с документацией (и есть куча неявных особенностей), гораздо меньшее коммьюнити и как следствие — гораздо меньше информации и примеров.
И браться за него надо тогда, когда четко понимаешь для чего и почему именно он нужен.
Мало того, Вы и для него использовали здоровенный оверхэд, нафиг не нужный, ну да ладно…

Использовать его для такой задачи — это ужасно. Учить других его использовать так — ужасно в квадрате.

Если копать дальше, то и ATTINY для мигания лампочкой — оверинжигиринг ;)

Это была гипербола, что, я надеюсь, вполне понятно ;)

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

Да нифига не понятно. Цель автора — раскурить STM, а задача тут так, побоку. Так что вместо него вполне мог бы быть и Intel Atom.
Но сделав вывод, что я не узнаю, что творится внутри микроконтроллера за рамками Arduino-скетчей я решил поискать более интересный вариант, который подразумевал глубокое изучение и погружение в дебри микроконтроллерной техники.
В компании, в которой я работаю, имеется отдел разработки, и я решил обратиться к инженерам… меня решительно отговорили от изучения Arduino...

Как-бы нет. Автор не разобрался в одном, сделал неправильные выводы, пришел к профи, которые конечно-же сказали что Ардуино для лохов и дали ему навороченный девайс, с которым, кстати он тоже не разобрался. Даже с IDE.

Так что увы и ах. Если бы он написал сразу, что решил изучить STM — другое дело.
Если так — да. Но этот момент пусть лучше он сам пояснит.
Хотя, с другой стороны, это его право. А материала для начинающих пусть будет чем больше, тем лучше.

К первому комменту: И браться за него надо тогда, когда четко понимаешь для чего и почему именно он нужен
Тогда вообще за него можно не взяться. Многие даже не представляют, какие финты можно творить на банальной 8й меге. У меня вот несколько лет лежит STM32F4-Discovery, так этого монстра я даже не могу вообразить, куда пристроить. Хорошо то, что в нём есть практически всё, что есть в более простых моделях, и из-за хорошей совместимости линейки на нём можно отлаживать код и заливать в другие контролеры. Сложных проектов не делал, но на простых удобно получается.
люди из f4-disco делают вот что, к примеру :)
www.youtube.com/watch?v=3-M-s6O-YW8
(по ссылке видео с синтезатором Goom (перевёрнутое Moog))
Описание
www.quinapalus.com/goom.html
Именно об этом и написано «Почему не AVR/Arduino?»
Как же любят люди интерпретировать то что написано не вникая в суть изложенного. Там речь шла о МОИХ мотивациях на момент выбора МК. Хотите решать свои задачи на Arduino — вперед, я никого тут не призываю изучать STM в обход Arduino.
зато у STM всё намного лучше с дебагом.
и у STM есть Nucleo64, которое хорошо шилды ардуины принимает на себя
STM — отличный процессор, но он для сложных задач и систем, у него есть офигенные плюшки в виде DMA, например, возможность писать многопоточку и т.д.
Но у него гораздо сложнее периферия, плохо с документацией (и есть куча неявных особенностей), гораздо меньшее коммьюнити и как следствие — гораздо меньше информации и примеров.

Попробуйте не читать форумы и смотреть прочие обучалки на ютубиках, а все таки откройте для себя документацию производителя. Да-да! Те самые многостраничные RMxxxx, UMxxxx и прочие. Откроете для себя много нового, в том числе и новые возможности периферии…
Присоединяюсь. Это лучшее сравнение Arduino и STM32, что я видел. Лаконично, в точку, и по делу.
Как обычно не разобравшись и не поняв почему Я выбрал именно STM в обход AVR — вы перевернули с ног на голову. Я пишу не для тех кто начинает с нуля а для тех кто желает разобраться с STM, и описывал аргументацию обхода AVR для себя не призывая никого делать то же самое. Перечитайте пожалуйста абзац с заголовком «Почему не AVR/Arduino?».
Дело в том, что на том же алиэкспрессе stm32f103c8t6 стоит те же два бакса. А когда втянешься и разберешься, понимаешь что кучу вещей дополнительных можно сделать из-за дополнительной периферии и мощности.
Представьте себе молодого специалиста, который кроме работы с STM32 пока ничего не изучил. Его взяли на работу и дали задание сделать простенькое устройство, для реализации которого достаточно и Atmega16. Но он берет что-то из серии STM32F030, который вам, например, покажется избыточным. Однако, устройство сделано, выполняет свои функции и не проигрывает в себестоимости, при этом этот молодой специалист не потратил 2-3 недели на изучение новой для себя, но несколько устаревшей для всего остального мира, технологии. В чем тогда состоит смысл использовать эту самую Atmega16? В чем экономия? Если Intel Atom будет стоить 50 рублей, то пусть и его использует.
Вот что больше всего раздражает в американских компаниях, так это их иррациональная жадность до персональных данных, граничащая с упоротостью. Просто так под STM32 с официального сайта можно скачать разве только мануалы, и то не все. Всё остальное — только после регистрации, во время которой с вас запросят столько персональных данных, словно вы к ним по меньшей мере на работу устраиваетесь.
Место работы, полный домашний адрес, контактный телефон — и это ещё только разминка. Я, пока это заполнял, всё ждал, что от меня сейчас потребуют NDA подписать…
Причём некоторые вопросы в той анкете сформулированы так, что просто вгоняют в ступор — вот совершенно непонятно, что туда вообще вписывать.
Вы не правы. На st.com можно скачать файлы указав только свой мейл и вымышленные имена, на почту придет ссылка на скачиваемый файл.
Автор, а почему вы используете платный Keil и не используете отличную связку Cube, Visual Studio Code и arm-gcc? Куб генерирует (помимо инициализации чипа) мэйк файл, Студия — отличный редактор с подсветкой синтаксиса, переходом по прототипам функций и неплохой отладкой через arm-none-eabi-gdb, встроенный терминал и еще кучу плюшек.
Думаю что очень большую роль сыграла популярность данной IDE, количество уроков по настройке и подготовке к работе, юзер френдли GUI. Там такой же дебагер как в Keil? Где можно получить побольше инфы чтобы можно было ознакомиться с вашим вариантом?
Code не IDE, это продвинутый редактор с кучей возможностей.
Нужно поставить Cube скачав его у ST, установить Code, поставить из его онлайн репозитория расширения: C/C++, C++ Intellisense, Native Debug. Установить arm-none-eabi-gcc.Сгенерировать с Cube свой проект, в настройках выбрать — генерировать make-файл. В Code открыть папку с проектом. Подправить маке-файл под свои пути (не сложно). Секции C_INCLUDES (если надо), C_SOURCES (если надо), BINPATH -путь до arm-none-eabi-.
По настройкам дебагера можно глянуть: mcu.goodboard.ru/viewtopic.php?id=7
electronix.ru/forum/index.php?showtopic=139502&pid=1479913&st=0entry1479913
github.com/WebFreak001/code-debug
www.youknowwhatreallygrindsmygears.com/index.php/2016/06/18/arm-gdb-debugging-with-visual-studio-code

Все очень легко, достаточно 1 раз разобраться что к чему. Работает быстро, компилировать можно make прямо во встроенном терминале, работает одинаково во всех ОС. У меня в убунте и макоси.
Да ну на фиг
Я даже саблайм прикручивал в своё время (во, картинки от давности похерились). С дебагом.
В идеале бы эту статью сократить до написания привычного digitalWrite(PIN_A, HIGH); с полной разверткой (В виде кода с коментариями и пояснениями) этой функции. Причем без HAL и прочего. Так, чтобы скормить program.cpp, скажем, keil и залить через программатор в чип.
Тоесть без сторонних либ.
Только так можно понять, что там внутри происходит и как оно работает.

Кстати, использование такой функции-враппера добавляет оверхеад (Лишняя команда процессора.), неплохобы написать, как этого можно избежать.

Ps: Да, одна команда процессора (JMP если не ошибаюсь) — вроде мало, но если функция вызывается довольно часто — эта лишняя команда заметно просадит произвдительность.

Или я неправ?
На самом деле, я в написании статей опираюсь только на свой опыт и выстраиваю логику повествования в той последовательности в которой я начинал изучение сам. Мои статьи совсем не претендуют на академичность, всеобъемлющую широту и глубину освящения темы. Это всего лишь изложение моего непрофессионального опыта.

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

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

На мой взгляд, лучше было бы, чтобы Вы написали статью-конкурент по теме для сравнения)))
В идеале бы эту статью сократить до написания привычного digitalWrite(PIN_A, HIGH); с полной разверткой (В виде кода с коментариями и пояснениями) этой функции. Причем без HAL и прочего.

Зачем писать под STM32 в arduino-style?

У меня чуть другая плата, stm32f4, поэтому сразу видно, где в статье не хватило объяснений :)
Поскольку плата отличается, то просто копи-пастом ничего не получится, и надо разбираться что и почему, чтоб внести изменения. И это прекрасно. У меня светодиоды подключены к другому регистру, но благодаря вашему объяснению (в следующей статье :) все легко получилось.
Из того, что осталось за кадром:


В главном меню проекта настраиваем параметр Xtal в значение 8.0 MHz. Данный параметр отвечает за частоту работы кварцевого осциллятора нашего МК:

Почему именно 8? Этот параметр зависит от МК и его можно в datasheet узнать? Или его можно выбирать по своему желанию?


/ Заголовочный файл для нашего семейства микроконтроллеров/
include "stm32f0xx.h"

Как узнать название этого файла? Для моего МК вообщем можно угадать, что будет stm32f4xx.h или загуглить. А как вообще найти его? Или Keil может как-то подсказать?

Зависит от конкретной конструкции. Думаю, указывать частоту резонатора нужно для того чтобы автоматически можно было просчитать и настроить систему тактирования под нужды пользователя. Вообще тема выбора резонатора для МК это очень обширная тема со своими ньюансами. Казалось бы, можно взять один кварц на все контролеры а настраивать частоту уже умножителями/делителями. Но тут всплывают разные ньюансы, такие как джиттер и т.д. где-то не важно что фаза тактового сигнала будет дрожжать, а где-то от этого очень сильно будут зависеть метрологические характеристики прибора. Да и сами кварцы есть очень разные. В целом, чем сильнее умножается частота тем ВЫШЕ требования к кварцевому резонатору, на каком-то дешевом кварце низкой добротности на 1Мгц если поставить умножение на 30, для того чтобы получить частоту ядра в 30Мгц получим неработающий камень т.к. из-за сильного джитера умноженной частоты конвеер ядра перешел в недопустимое состояние. И по крайней мере получим высокую чувствительность к помехам — на столе работает, а вынес поле и бесконечные зависания или ещё хуже — плавающие сбои. И поди ж догадайся что это из-за некачественного резонатора. Или ударенного, у которого из-за удара надтреснула кварцевая пластина и он потерял прилично в добротности(многие наручные часы из-за этого дохнут со временем). Ещё надо смотреть на тип резонатора — как правило резонаторы на частоты выше 1Мгц работают на овертонах и при определённом сочетании обстоятельств могут завестись на основной частоте — например 8Мгц кварц работающий на 2-м овертоне может неожиданно завестись на 2Мгц если не обеспечить его согласование со схемой генератора(вспомните емкости подключаемые к выводам кварца, на самом деле их надо ставить не от фонаря а СТРОГО соответствующие установленному кварцу чтобы не получить подобные проблемы в будущем). Чем выше рабочий овертон кварца тем худшие характеристики он имеет. И когда для вашей конструкции джиттер тактовой частоты(как и всех её производных) имеет первостепенную важность подобрать кварцевый резонатор бывает очень непросто — дешёвые сразу отпадают.
Но, к счастью для большинства любительских задач хватает обычных кварцев с точностью 4-5 знаков а иногда и вовсе RC-генератора.
Почему именно 8? Этот параметр зависит от МК и его можно в datasheet узнать? Или его можно выбирать по своему желанию?

Я этот и многие другие вопросы касающиеся RCC планирую рассмотреть в статье про тактирование и внутреннее устройство МК)))

Если честно — хитрого способа я не знаю, обычно мне хватало возможности заглянуть в файловый состав библиотеки HAL или StdPeriph. И там сразу в дереве находятся соответствующие семейству МК файлы и их имена.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.