Тут тоже с вами согласен, но тоже частично.
Моё мнение в том, что CubeMX — отличная утилита для «вхождения» в мир STM32. Но не альтернатива чтению даташитов и референс мануалов, а дополнение. Все-таки человек, пишущий код под микроконтроллер, худо бедно должен знать архитектуру контроллера, знать, как работает периферия, и иметь представление о том, какие регистры для чего нужны.
Например: работа с прерываниями.
В ядре Cortex M0 — вход и выход из прерывания по 16 тактов.
В ядре Cortex M0+ — по 15 соответственно, в ядре M3, 4 и 7 — по 12.
Но, взять, например, HAL-овский обработчик прерывания по таймеру.
Если в коллбэк прописать простой инкремент счетчика или установку флага, не залезая в библиотеку (а тем более в регистры), обработка данного прерывания вместе с исполнением пользовательского кода (элементарная операция) занимает более 120(!) тактов, и это на ядре Cortex M4. На M0 — больше 130.
Если залезть в обработчик ручками и просто убрать обработку непроисходящих событий (нас интересует только событие переполнения), то результат уже значительно лучше, порядка 50 тактов.
Если же работать напрямую с регистрами, то получим 27(±1 на джиттер) тактов.
12 тактов вход
считать, изменить, записать
12 тактов выход
Итак, 130 тактов на частоте 72 МГц (Не видел камней на CortexM0 с большей тактовой частотой) — почти 2 микросекунды. Устраивает вас такое время обработки прерывания? Если да — пожалуйста, не нужно разбираться в ядре, в регистрах и библиотеках.
1) Очень рад, что на хабре появляются такие статьи по современным библиотекам, полгода назад мне их очень не хватало, когда переходил с avr и pic на STM32.
2) С точки зрения курса «STM32 с нуля» — данная отладка совсем не лучший вариант. Объясняю, почему: другая архитектура относительно ядер Cortex M4,M3,M0(+) — Кэш данных, кэш команд, 64-бит шина данных, суперскалярность, ветвление в 1 такт.
Данный процессор — мощный агрегат для ЦОС, и содержимое отладки как бы намекает: микрофоны с PDM-сигналом на выходе, требующим цифровой фильтрации, интерфейс для подключения видеокамеры, жирный дисплей с сенсором. Все это добро требует нехилых вычислительных мощностей на обработку, и без хорошего понимания математических основ ЦОС даже этот контроллер не сможет выполнять свои функции полноценно, так-что этот камень не претендует на нишу «STM32 с нуля» совсем.
Для начала лучше всего пойдет любая отладка на ядре Cortex M3/M4, с небольшим количеством внешней периферии(светодиоды, кнопочки, датчики ускорения/углового ускорения, например), но с большими гребенками и выведением всех свободных выводов на них, где каждый из выводов можно пощупать тестером или осциллографом.
Там и все интерфейсы связи доступны, и микроконтроллеры вписываются в общую концепцию.
Так, например, держа в уме отличия Cortex M0 и M4, можно без проблем писать код и на то и на другое ядро, и даже ожидать соизмеримой производительности (с точностью до DSP инструкций и некоторых других нюансов, в среднестатистических проектах разница в скорости выполнения одной и той же программы там и там — порядка 10-15 %, а скорость обмена данными по интерфейсам связи так вовсе не отличается при равной тактовой).
С точки зрения оптимизации кода(и по скорости и по размеру) компили IAR и Keil показывают существенно лучшие результаты, нежели SW4STM32. Только есть два но:
1) Они платные.
2) Текстовые редакторы не намного лучше, чем блокнот.
Для некритичных по времени выполнения программ — SW4STM32 — хороший вариант, себе на линукс дома поставил и пользуюсь.
На работе же на машине стоит IAR, уже давно привык к его редактору кода, им и пользуюсь.
Моё мнение в том, что CubeMX — отличная утилита для «вхождения» в мир STM32. Но не альтернатива чтению даташитов и референс мануалов, а дополнение. Все-таки человек, пишущий код под микроконтроллер, худо бедно должен знать архитектуру контроллера, знать, как работает периферия, и иметь представление о том, какие регистры для чего нужны.
Например: работа с прерываниями.
В ядре Cortex M0 — вход и выход из прерывания по 16 тактов.
В ядре Cortex M0+ — по 15 соответственно, в ядре M3, 4 и 7 — по 12.
Но, взять, например, HAL-овский обработчик прерывания по таймеру.
Если в коллбэк прописать простой инкремент счетчика или установку флага, не залезая в библиотеку (а тем более в регистры), обработка данного прерывания вместе с исполнением пользовательского кода (элементарная операция) занимает более 120(!) тактов, и это на ядре Cortex M4. На M0 — больше 130.
Если залезть в обработчик ручками и просто убрать обработку непроисходящих событий (нас интересует только событие переполнения), то результат уже значительно лучше, порядка 50 тактов.
Если же работать напрямую с регистрами, то получим 27(±1 на джиттер) тактов.
12 тактов вход
считать, изменить, записать
12 тактов выход
Итак, 130 тактов на частоте 72 МГц (Не видел камней на CortexM0 с большей тактовой частотой) — почти 2 микросекунды. Устраивает вас такое время обработки прерывания? Если да — пожалуйста, не нужно разбираться в ядре, в регистрах и библиотеках.
2) С точки зрения курса «STM32 с нуля» — данная отладка совсем не лучший вариант. Объясняю, почему: другая архитектура относительно ядер Cortex M4,M3,M0(+) — Кэш данных, кэш команд, 64-бит шина данных, суперскалярность, ветвление в 1 такт.
Данный процессор — мощный агрегат для ЦОС, и содержимое отладки как бы намекает: микрофоны с PDM-сигналом на выходе, требующим цифровой фильтрации, интерфейс для подключения видеокамеры, жирный дисплей с сенсором. Все это добро требует нехилых вычислительных мощностей на обработку, и без хорошего понимания математических основ ЦОС даже этот контроллер не сможет выполнять свои функции полноценно, так-что этот камень не претендует на нишу «STM32 с нуля» совсем.
Для начала лучше всего пойдет любая отладка на ядре Cortex M3/M4, с небольшим количеством внешней периферии(светодиоды, кнопочки, датчики ускорения/углового ускорения, например), но с большими гребенками и выведением всех свободных выводов на них, где каждый из выводов можно пощупать тестером или осциллографом.
Там и все интерфейсы связи доступны, и микроконтроллеры вписываются в общую концепцию.
Так, например, держа в уме отличия Cortex M0 и M4, можно без проблем писать код и на то и на другое ядро, и даже ожидать соизмеримой производительности (с точностью до DSP инструкций и некоторых других нюансов, в среднестатистических проектах разница в скорости выполнения одной и той же программы там и там — порядка 10-15 %, а скорость обмена данными по интерфейсам связи так вовсе не отличается при равной тактовой).
1) Они платные.
2) Текстовые редакторы не намного лучше, чем блокнот.
Для некритичных по времени выполнения программ — SW4STM32 — хороший вариант, себе на линукс дома поставил и пользуюсь.
На работе же на машине стоит IAR, уже давно привык к его редактору кода, им и пользуюсь.