Кто там ратовал за stm32?

Там есть STM32CubeMX, который избавляет от необходимости вглядываться в каждую букву документации. Если HAL напрягает, можешь часть под LL сгенерить.

Инициализация конечно не такая тупая как в авр, но один раз не водолаз. Зато потом писать и поддерживать нормально.

Там не то, что инициализация, там бы сперва ld правильный написать и таблицу прерываний. Чтобы до main() дело хотя бы дошло

Что-то ты не то делаешь. Cube умеет генерить под make проект, там уже все есть. Либо platformio возьми, там тоже готовые ld имеются.

У меня есть удобный VSCode и gcc под arm. Тянуть всякие сторонние IDE нет большого желания.

Ну наконец получилось поморгать светодиодом без использования либы от st

На асме что ли пишешь?

Ты в курсе, что за свои принципы надо страдать :) ?

Не, на си

С чего вдруг?

Почему не заюзать среду типа sw4stm32, и не париться?

Мне на каждый контроллер свою среду тянуть?

Ну... ты не ищешь легких путей :)

Минимализм) Ну дело твое.

Я про то, что в sw4stm32 отладчик из коробки работает. Установил среду и радуешься)

Раньше я обрастал кучей прог под разные мк, пока не перешел на stm и не повыкидывал все другие мк)

Сейчас использую sw4stm32 для stm32, и саблайм + sdcc для stm8.

man libopencm3

Вопрос привычки. Не нравится st periph libs - есть opencm3. И ты учти, что на stm32 тот же код будет жирнее, это тебе не восьмибитное ядро.

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

Но блин, все-таки stm32 это нифига не легкая и удобная замена avr, где даташиты заметно короче

А ты как думал? Там больше периферии понатыкано и архитектура сложнее. Но и задачи гораздо тяжелее STM32 может решать. Если тебе хочется чего полегче и поудобнее, то пользуй MSP430. Настолько простой, удобной и понятной работы на C с микроконтроллерами я ещё нигде не видел. А для совсем простоты и удобства есть TI Launchpad, где можно чипы перетыкать и использовать плату для отладки и прошивки, но для DIP.

Мне на каждый контроллер свою среду тянуть?

Прикинь - да. Вполне себе вариант. Даже для каждого проекта своё окружение.

На avr вообще легко без библиотек для периферии писать. Только заголовочники для номеров портов нужны.

Так никкто ж не запрещает, берешь даташит и фигаришь битовыми масками в регистры. Вообще странно, что на LORе и предложили взглянуть на libopencm3 далеко не в первом коментарии.

plaformio есть под vscode

Да и Cube тебе просто проект генерит, это не IDE, это утилита.

Они действительно сложнее. И документация, на мой взгляд, написана хуже. Зато как разберёшься, будешь в восторге :)

Для STM32 точно так же можно сделать, если тебе не феншуй юзать либы.

ну понятно, что можно.

Я к тому, что тут неоднократно заявлялось, что stm32 это прямо легко и просто и что avr можно выкинуть.

Когда я начал знакомиться с avr, довольно быстро смог самостоятельно разобраться с даташитом и без всяких дополнительных либ (которые в tiny13 вообще и некуда пихать) написал код. Я не уверен, что начинай я с stm32, я бы смог обойтись без готовых либ. Т.е. замена avr на stm32 это палка о двух концах.

Хм... а к микросхеме K155ЛА3 даже код писать не надо. И много ты на ней сделаешь?

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

некорректно сравнивать stm32 и avr8, тогда уж avr32. Сравнивай stm8 и avr8. Хотя чего их сравнивать AVR нет смысла в новые разработки ставить, microchip вряд ли будут развивать эту архитектуру, им проще её похоронить.

некорректно сравнивать stm32 и avr8, тогда уж avr32. Сравнивай stm8 и avr8.

массовых призывов переходить с avr на stm8 или с avr32 на stm32 я не вижу)

microchip вряд ли будут развивать эту архитектуру

но и прекращать выпуск тоже они вроде как не спешат

STM32 это реально легко. Вот когда у тебя объем Refrence Manual несколько тысяч страниц - вот это реально серьезно

А что за железка вообще?

читать очень длинные даташиты чтобы вообще хоть что-то заработало.

Нет бы просто либу заюзать. На гитхабе полно примеров. Один даже у меня лежит.

Но в общем и целом согласен с тобой. stm32 после avr весьма сложный.

а в чем проблема библиотеки я что то не уловил?

А что за железка вообще?

stm32f103c8t6

1) в добавок к чтению даташитов надо еще и в либе разобраться

2) жирные они

3) любят туда чего-нибудь понапихать, типа длинной простыни ld файлов, в которых потом еще разобраться надо, если что не работает

stm32f103c8t6

Собственно, по ссылке в предыдущем посте для неё минимальный пример и есть.

microchip вряд ли будут развивать эту архитектуру, им проще её похоронить.

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

Мне трудно представить, что AVR не надёжнее ARМ во столько-же раз, во сколько проще. Больше транзисторов, больше используемой памяти, сбой в которой критичен, больше частоты и тоньше техпроцесс (хотя это уже не всегда, наверное).

В тред ворвался специалист по надежности! Все в машину!

Мне на каждый контроллер свою среду тянуть?

Каждый производитель контррллеров именно так и считает. Причём в 99% это будет перепакованный eclipse.

Если не хочешь использовать готовые либы, посмотри на mcu-info-util. Он по имени МК генерирует 1 заголовочник со всеми регистрами и 1 ld-скрипт. А ещё выдаёт требуемые опции компиляции. И не надо искать ничего. Тупо указать имя МК типа stm32f103c8t6. Поддерживает все stm32, arm от atmel, msp430 и avr. А еще умеет искать нужный компилятор в системе (особо актуально на винде, где всё подряд не прописано в path). OpenSource. Автор: я.

А ещё в примерах есть универсальный makefile, в котором нужно менять только 2 параметра - набор исходников и имя целевого МК, а так он подходит для любого проекта.

https://github.com/KivApple/mcu-info-util

для себя делал?

Да я отдаю себе отчёт, что это возможно отчасти иррациональное предубеждение - но...

Ага

В реальной жизни основная информация по надёжности берётся из статистики и реального опыта использования. Так что без реальных данных теоретизирования не очень интересны.

К тому же если ты не в космос под жёсткое излучение отправлять аппарат собрался, то контроллер будет последним, что выйдет из строя, если разводка правильная. Тут скорее за программные баги надо бояться, но они не так уж зависят от железа.

А зачем вообще выбирают stm, когда есть удобный ардуино с вагоном готовых либ? Я бы понял будь там прогрессивный python или хотя бы js, но нет там все тот же C++.

Хочешь обсуждать серьезно - выкати метрики повнятнее, чем «в разы». Мне не интересно тратить время на демагогию с непонятным выхлопом. Здесь речь о вполне конкретных прикладных вопросах программирования.

Для надежности у ST есть процессора серии SPC56/SPC57/SPC58