Специфика синтаксиса arduino IDE (да и не только - даже у АВР студио WIN AVR и code vision AVR расхождения в нюансах трактовки имеются).
А тут платки с разными МК и единый синтаксис пользователя (при том, что "тонкие настройки" в библиотеках написаны частенько на основе иных компиляторов). Для начала минимум достаточности при максимуме результата, а со временем можно и поглубже копнуть (при желании, здоровье и соответствующей денюжке).

Касательно работ с отдельными семействами - само собой у кого оные "под лапой" - вполне понятно "не побрезгую укусить" - но... более в плане самодельной схемотехники и собственного ПО под ассемблером.
Поскольку это прикладные конструкции специального назначения. И главное...почему в прикладных конструкциях ассемблер... Си опирается на использование ОЗУ. А по опыту при испытаниях на помехостойкость именно такое решение весьма зависимо от местоположения устройства и грамотной проработки схемотехники/топологии монтажа устройства. В то же время приемы для увеличения "дуростойкости" в автоматическом режиме... несколько неудобны для "простопользователя"(речь о профи программистах не идет, хотя....).
Так что готовые платки лучше оставить для "домашних условий" во "втором эшелоне".
По крайней мере это не конструкции у которых рабочим режимом может быть искровой разряд в шины питания.

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

А у меня аппетит на разные МК с единообразным компилятором.
Могу себе таку роскошь позволить на пороге пенсионного возрасту!

Да и задачка для блоков с ардуинками ставится иная чем для прикладных самоделок "периферии с мозгами" - промежуточный/оконечный центр обработки, отстраненный от прямого дрыголапа (хотя и таковой на первых порах освоения и для "относительно мелких" образцов ардуинок использовать намечается).
Все остальные типы IDE по отношению к Си рассматриваются как составная часть /расширенное толкование результирующего направления. В то же время прикладной средой низкоуровневой разработки "периферии с мозгами" остается ассемблер. Может и удастся "соединить хотелки" в неспешно-ленивом порядке.

Кстати... при работе с ардуино я заранее поставил самоограничения -
никаких спецсредств за рамками предоставляемого в перечнях IDE (https://www.arduino.cc/en/Reference/HomePage) директив/функций при разработке программ и/или библиотек.
Посмотрим что из того выйдет...

Отсутствие дебаггер-отладчика в составе IDE при возможности работы с макетом не слишком уж затруднительная штука - кто работал с mcs51 "в начале славных дел" (80-е - начало 90-х) вполне справится с такой ситуацией.

Только будет все очень не оптимально. Примерно тоже что ехать из Петербурга в Москву через камчатку...

Современные ЯВУ ничуть не хуже ассемблера.

Если в шину питания попадет миллион вольт и много ампер (например молния), то думаю не будет разницы где хранятся данные в ОЗУ и регистрах... Тут нужно думать как бы в флеш памяти прошивка не исказилась, а то ведь может.

Открыт интернет-магазин MEAN WELL.Market – весь ассортимент MEAN WELL, выгодные цены

Открыта удобная площадка с выгодными ценами, поставляющая весь ассортимент продукции, производимой компанией MEAN WELL – от завоевавших популярность и известных на рынке изделий до новинок. MEAN WELL.Market предоставляет гарантийную и сервисную поддержку, удобный подбор продукции, оперативную доставку по России. На сайте интернет-магазина посетители смогут найти обзоры, интересные статьи о применении, максимальный объем технических сведений.

Подробнее>>

Насчет оптимальности...
Тут у каждого свой подход.
Причем весьма часто зависит от текущих внешних факторов. То, что не оптимально в одной ситуации может оказаться совершенно к месту в другой.
Насчет удобства ЯВУ/ассемблер...
Зависит от выбранного кристалла и конечной задачи.
Если подход "впихнуть все сразу в один навороченный" - явно идем к ЯВУ.
Туда же следует отнести МК с большим количеством аппаратной периферии (сложность конфигурации избыточных аппаратных средств).
Если использовать концепцию "периферийный расширитель с некоторым количеством мозгов" на основе малолапого малой начиненности МК плюс составную из нескольких подобных устройств конструкцию то предпочтительно ассемблер.
В конце-концов на тех же ЯВУ в большинстве случаев используются ассемблерные вставки - а это уже не "чистое ЯВУ", а ГИБРИД, при котором глубокие знания как самого компилятора ЯВУ, так и ассемблера обязательны.

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

LED-драйверы MOSO - надежные решения для индустриальных приложений

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

Несколько размышлений по поводу самой ардуино IDE... относительно средств отладки проекта/отсутствия привычного симулятора...
Собственно сама система построена на взаимодействии реального макета и оболочки в ПК.
Ежли кто занимался ранними отладочными системами на основе "имитатора ПЗУ" у I8080/Z80/MCS51 в принципах работы ничего нового (исключение все-таки ограниченное количество перепрошивок МК на "подопытном кролике").
Дополнительное удобство - встроенный в IDE терминал при наличии отработанной библиотеки обмена для прикладной платки.
Практически то же самое и в КОТУИНКО применено (только без среды разработки - макетка с совмещенным ОЗУ/ПЗУ и терминальная прожка в ПК).
Далее собственно любой контрольный тест для программно-аппаратной реализации в реальном времени на действующем макете можно отработать.
Да и мозги потренировать в вопросе тестирования прикладного программного обеспечения.


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

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

Отладчик для STM8 и STM32 можно спаять самому. http://we.easyelectronics.ru/STM32/sozd ... nk-v2.html
Или купить готовый за 100 рублей. https://ru.aliexpress.com/item/Free-shi ... 42186.html

Отладка с выводом в uart не сравнится с нормальной аппаратной отладкой. Это лучше один раз увидеть, чем 100 раз услышать...

Для примера скрин МК STM32F030F4P6 программа которого выполняется под отладчиком. http://www.radiokot.ru/forum/viewtopic. ... 0#p3184550
На скрине видно что программа остановлена на 45 строке и ее можно выполнять пошагово (построчно). Справа в окне показаны регистры таймера TIM2. Выполняя программу пошагово можно наблюдать за ними и за другими регистрами, просматривать память и отдельные переменные и много чего другого. Вывод в uart не даст всех этих возможностей и потребует гораздо больше времени на отладку программы, поскольку пошаговая отладка недоступна и если потребуется выводить значение другого регистра или переменно, нужно изменить код, перекомпилировать его и залить в МК.

Ну допустим к STM8 я может и вернусь после обнаружения некоторых древнекнижек по ассемблеру для Интел или под Си. Это ежли их (STM8) аппаратная начинка и корпусирование будет соответствовать задаче при условии невозможности заменить иным, имеющимся в прямом доступе МК.
Не слишком уж и новинка - практически тот же Z80... Тут более теоретический интерес может представлять PIC24 - одначе и дорого и "вне доступа" (как и современные МК от ZILOG).

Я писал про STM32, а не о STM8...
STM8 это 8-ми битный МК с ядром разработанным STMicroelectronics.
STM32 это 32-ух битный МК с ядром ARM.

PIC24 далеко до STM32...

УВЫ ...
Для STM32 я пока достойного применения не вижу - проектировать устройство типа "смартфон/ПК" на ближайшее время не планируется. Будет потребность - тогда и интерес появится.

Да и сами АРМы одними STM32 не ограничиваются - это самостоятельное класс изделий с подвидами (аналогично деления 8-битовых).

То что периферия гораздо функциональнее этого мало? Разрабатывать программы проще потому что не нужно думать как обходить ограничения периферии. Контроллер прерываний поддерживает, вложенные прерывания, приоритеты и группы что позволяет не думать о том что МК может пропустить важное прерывания обрабатывая другое прерывание. Важному назначают больший приоритет и оно сможет прервать другие прерывания с более низким приоритетом. DMA (по русски ПДП - прямой доступ к памяти) позволяет избавится от множества частых прерываний, что разгружает ядро МК и опять же не нужно думать, успеет забрать МК данные или нет.
Пример того что нельзя сделать на ATmega http://purebasic.mybb.ru/viewtopic.php?id=574
Обратите внимание что датчик подключен к одному выводу МК. Дальше процитирую оригинальное сообщение.В ATmega можно настроить USART таким образом чтобы TXD и RXD были подключены к одному выводу (а второй вывод который должен был использоваться USART, можно использовать для других целей, что видно во втором сообщении темы где использован вывод PA3 под дисплей)? Можно ли в ATmega настроить вывод как открытый сток?
Вот из-за таких "мелочей" стоит обратить внимание на STM32 поскольку их периферия гораздо функциональнее чем у ATmega и разрабатывать устройство проще.

Верно, но они дешевле и средства разработки для них доступнее чем МК других производителей. Для профессионалов это не так важно, а для любителей имеет значение, потому что не все готовы тратить много денег на хобби.
В Китае можно купить STM32F030F4P6 по 0.4$ за штуку, что дешевле многих AVR, но при этом F030 поступает с ATmega как тузик с грелкой.
ИМХО многие не хотят переходить с AVR и AT89 на STM32 только из-за нежелания (или отсутствия свободного времени) изучать что-то новое, но из-за этого многое упускают.

Большая часть вышеуказанного уже даавно применяется в самом "древнем" из семейств - MCS51.
Да и в других семействах не хуже функционал - надо только уметь им пользоваться.
Не стоит убеждать кого-либо в пользе одного из семейств - будет конкретное оправданное применение - можно и с ним проработать.
А вот неоправданное применение излишней аппаратной начинки даже "дешевизной" (коммерческой) обосновать... Как-то не слишком удобно...
Мощная избыточная начинка у кристаллов с ограниченными ресурсами ПЗУ и ОЗУ порой даже для одновременной качественной работы пары аппаратных модулей не очень-то "достаточна" - а именно такие варианты сейчас и рекламируются как максимально дешевые...
Неохота повторятся -
КАЖДОМУ МК СВОЯ СФЕРА ПРИМЕНЕНИЯ.
Если речь о "навороченном" - так и задачи соответствующие должны быть.
А насчет
"...Разрабатывать программы проще потому что не нужно думать как обходить ограничения периферии...."
дык...
как раз думать всегда надо (и даташиты вычитывать) ежли СВОЮ схемотехнику лепить придется, а не типовые решения покупным блочно-модульным конструктором делать.

Почему излишняя? Применяется только та периферия что нужна, а на остальную тактирование не поступает и она "кушать не просит" в смысле ток не потребляет.

У STM32F030F4P6, ПЗУ 32 КБ, ОЗУ 4 КБ. Мало для дешевого МК? У многих AVR гораздо меньше, а стоят больше.
Если мало, можно взять другой популярный МК STM32F103C8T6. У него ПЗУ 128 КБ, ОЗУ 20 КБ.

Задачи бывают простыми и сложными. Более гибкая периферия упрощает задачу.

Все равно меня на такой садомазохизм не охмурить!

Воть ежли свой смартфон сооружать или еще чего равноценного - тогда может и подумаю...

Ну как бы не все беруться сразу за стм32. Есть такой проектик, называется Olduino, на совсем древнем камне CDP1802
Штука неудобная, нет указателя стека, нету CALL/RET, но.. ведь можно как-то.
Раз сделали такое, то почему бы не сделать такое на MCS-51. Камушек известный, море информации про него, примеров кода. До сих пор используются.

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

У 24-й серии интерес в организации ядра имеется.
И преемственность в освоении.

Касательно АРМов - у этого класса отдельная тема на форуме
viewtopic.php?f=62&t=105290
- вот там и обсуждается "что круче"(у кого... ...).
Да и раздел немалый viewforum.php?f=59 воть там спецы по этому виду МК собираются.

Доберемси за исчерпанием ресурса до АРМов - тогда и милости просим - НО или с обсуждением имеющихся в теме устройств или со своими разработками на соответствующую тематику.
Флудить "ни о чем" размывая смысл уже опубликованного как-то не слишком полезно.
...
Пока здесь рассматриваются МК - представители семейств
MCS51, PIC10/12/16/18, ATmega/tiny с программами на ассемблере и некоторые пробы Cи для ардуиноподобного представительства.
Плюс всевозможные схемотехнические варианты на "рассыпухе"/специализированных ИС/БИС и их комбинации.
Ежли есть что добавить к уже ранее опубликованному и/или свое для обсуждения предложить/выложить - всегда рад мозги потренировать!


/Снова две страницы флуда "свидетелей STM32"

И хош бы едино слово критики/обсуждения по существу моих проектиков....
/

я, например, могу вставить слова по сути проекта, но они будут касаться его организации, и будут весьма нелицеприятными, при этом скорее всего покажутся весьма субъективными)

Проект КОТУИНКО любительский и естественно не без проблем.
Реализованный вариант является ограниченной минимальными затратами версией (что не исключает и "чистового", более оптимально-прилизанного исполнения, а также тест-контроля с более высокочастотным кварцем и/или иной элементной базы ядра).
Тем более, что само устройство является весьма обобщенной идеей радиолюбительского расширителя к ПК на простейшей элементной базе. А по сему... Вроде как имеет право на существование и некоторые перспективы...

В принципе любое мнение по сути есть основа для возможных модификаций под конкретного потребителя и дополнительное расширение кругозора о возможностях и недостатках устройства.
Вот насчет "стороннего видения" пока и туговато... Следовательно ограничено лишь моим видением вопроса - а это весьма однобокое(личное) представление. Нужно и "взгляд со стороны" услышать, независимо какой "полярности". НО... Именно ПО СУТИ - ошибки схемотехники, ошибки/доработки программных исходников, свой вариант схемотехники/исходников, возможные решения модификации проекта альтернативная схемотехника и ПО)... о проверенности на работоспособность предлагаемых вариантов ...как бы "по умолчанию" обязано макетом подтверждаться...
Средства разработки также ограничены рамками указанными в начале темы - общедоступно-бесплатные и без взлома/"креков" - иначе разговор "на разных языках" об одном и том же. Схемки помимо сплана/лэйоута обязательно дублировать *.pdf или *.jpg *.gif рисунком (учет замечаний от Ser60).
Возможно и иные МК/ПЛИС, однако то, чем пока не владею обсуждать не смогу - лишь обзорно оценить... и облизнуться...
Так что милости просим - чего сумею - отвечу.

Попали в лапы WS2812 на платке запаяные


(правда маркировки на самих светиках и на платке нету - верю продавцу на слов, что именно WS2812)...
соорудил под них "хвостик" согласно моих макеток

Уж больно хоччется проверить протокол загрузки прошлых лет теоретически нашкрябаный...