STM32F103C8T6 и тактирование от внешнего кварца 12МГц

[prinv]

SPL устроила бы, если бы HAL не была перспективной библиотекой

[Serg1987]

HAL - перспективная библиотека?? Ооо... Это никакими матерными словами описать нельзя. Пользовался им. В итоге всю эту ахинею с ненужными проверками структур я тупо комментил и ставил одну единственную строчку со значением нужного регистра. Лучше старого доброго CMSIS ничего на свете нет. Запись напрямую в регистры forever.)
Для сравнения - банальный обработчик прерывания таймера по переполнению написанный на CMSIS работает в 2.5 раза быстрее, чем функция от HAL. Столкнувшись с багами и граблями, я её выкинул на помойку. Она годится разве что подсмотреть, что и куда записывает, не больше. Ну а после того, как я столкнулся с багами аппаратного SDIO (драйвер SD карт) я вообще делаю все интерфейсы (кроме ЮСба) на ПЛИС.

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

[prinv]

Вы сейчас спорите с тем, что красное не мокрое.

[КРАМ]

Вы сейчас спорите с тем, что....

Перспективность Вы пытаетесь оценить ДЛЯ КОГО?

Все конфигураторы (включая куб, спл) созданы якобы для ускорения процесса разработки. Но в серьезных проектах конфигурирование занимает так мало времени, что говорить всерьез о его экономии просто смешно. А кроме того, не понимая кода созданного чужим автоматом, и невозможно. Потому что риски напороть конфликтующий с собственным код не стОят забавы бездумного тыканья мышкой по картинке корпуса.
Это как в моем автомобиле есть функция автоматической парковки. За почти два года эксплуатации я ее использовал ЧЕТЫРЕ раза. Причем первый раз из личного любопытства, а остальные три из любопытства остальных членов семьи. Все. Абсолютно ненужная фича для водителя со стажем в 23 года и пробегом примерно 1 млн. километров. Кстати, на экране монитора задней камеры прямо написано, что за последствия такой парковки отвечаешь сам, а не производитель автомобиля...
Надеюсь, я был достаточно понятен, уважаемый...

[prinv]

Это не я перспективность определяю, а фирма ST.

[КРАМ]

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

[prinv]

Даже не буду спорить, наверняка вы правы.
Я именно неофит в области программирования ARM и мой опыт программирования других архитектур подсказывает, что самое правильное будет начать с использования продуктов и технологий, которые предлагает производитель МК. В данном случае, это Cube и HAL.
Что будет потом - посмотрим потом
Холивар начинается же. Я бы даже сказал - HALywar

[oleg110592]

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

нонче Куб и ХАЛ начали исправляться:

The STM32Cube HAL is an STM32 embedded software stack that ensures a maximized portability across STM32 portfolio, while the LL APIs make up a fast, light-weight, expert-oriented layer which is closer to the hardware than the HAL. HAL and LL APIs can be used simultaneously

корявенький гуглоперевод:
STM32Cube HAL - это встроенный программный стек STM32, который обеспечивает максимальную мобильность в портфеле STM32, в то время как LL API составляют быстрый, легкий, ориентированный на эксперт уровень, который ближе к оборудованию, чем HAL. HAL и LL API могут использоваться одновременно
Куб может генерить или HAL функции или LL функции или совместно:

LL функция выглядит как бы и неплохо:

Код:

  /* Peripheral clock enable */
  LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_TIM1);

это так:

Код:

__STATIC_INLINE void LL_APB2_GRP1_EnableClock(uint32_t Periphs)
{
  __IO uint32_t tmpreg;
  SET_BIT(RCC->APB2ENR, Periphs);
  /* Delay after an RCC peripheral clock enabling */
  tmpreg = READ_BIT(RCC->APB2ENR, Periphs);
  (void)tmpreg;
}

вроде напрямую с регистрами.
Разница размера (пример инициализация одного таймера):
с HAL:
Program Size: Code=3604 RO-data=492 RW-data=8 ZI-data=1088
с LL:
Program Size: Code=988 RO-data=428 RW-data=4 ZI-data=1028

[Мурик]

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

Производитель предлагает в том числе и SPL. Для STM32F103C8T6 и подобных МК она не утратила своей актуальности, но она требует гораздо меньше ресурсов (прежде всего ОЗУ) чем HAL.
Выше выложил проект с библиотекой SPL. Прошивка требует 740 байт флеш и 0 байт ОЗУ (не считая стека).
Аналогичный проект с применением HAL требует 2900 байт флеш и 2650 байт ОЗУ (не считая стека).
Видите разницу?

[prinv]

Для написания Blink с использованием Cube и HAL новичку нужно мышкой сконфигурировать выводы и руками всего 2 строчки написать

Код:

   HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_3);
   HAL_Delay(1000);

Мне, на самом деле, после AVR и MSP430 никаких проблем нет работать с битами регистров.
Проблема новичка - въехать в имеющееся железо и понять как с ним работать.
А уж чем именно работать - это дело 10е. Хоть HAL, хоть SPL, хоть CMSIS - смысл спорить о вкусах? Под задачи и нужно выбирать инструменты.

[Мурик]

Для написания Blink с использованием Cube и HAL новичку нужно мышкой сконфигурировать выводы и руками всего 2 строчки написать

С SPL нужно написать на пару строк больше.

Код:

    GPIO_InitTypeDef Init;

    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE); // Вкл тактирование порта GPIOC

    Init.GPIO_Pin = GPIO_Pin_13;       // Пин 13.
    Init.GPIO_Mode = GPIO_Mode_Out_PP;
    Init.GPIO_Speed = GPIO_Speed_50MHz; // Предельная частота выхода.

    GPIO_Init(GPIOC, &Init); // Конфигурация GPIOC

    while(1)
    {
        GPIO_SetBits(GPIOC, GPIO_Pin_13); // Мигание светодиода.
        Delay(1000000);
        GPIO_ResetBits(GPIOC, GPIO_Pin_13);
        Delay(1000000);
    }


Ресурсы МК используются более рационально и имеется больший контроль над разработкой программы.
Проекты не "ломаются" при выходе новых версий куба.

[prinv]

Да на ARM проекты ломаются сами по себе - вот только что прошил Blink и МК перестал видеться по ST-Link'ом.
Светодиод моргает, МК программатором не видится, ни одно соединение после последней удачной прошивки не менялось - долбаная магия

Последний раз редактировалось prinv Вс апр 02, 2017 11:05:04, всего редактировалось 1 раз.

[Reflector]

С SPL нужно написать на пару строк больше.

Если уж сравнивать, то нужно паузу сделать как в HAL, на таймере, а не тупо циклом. И у меня стандартный HAL пример отжирает 36 байт RAM, а никак не 2650.

[Мурик]

вот только что прошил Blink и МК перестал видеться по ST-Link'ом.

В кубе нужно разрешать отладку, поскольку она по умолчанию отключена.
Теперь нужно прошивать зажав кнопку "сброс" или переведя МК в режим загрузчика, в котором залитая прошивка не выполняется.

Если уж сравнивать, то нужно паузу сделать как в HAL, на таймере, а не тупо циклом.

Не вопрос. Только код сложнее не стал.

Спойлер

Код:

    SysTim_Init(100);

    GPIO_InitTypeDef Init;

    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE); // Вкл тактирование порта GPIOC

    Init.GPIO_Pin = GPIO_Pin_13;       // Пин 13.
    Init.GPIO_Mode = GPIO_Mode_Out_PP;
    Init.GPIO_Speed = GPIO_Speed_50MHz; // Предельная частота выхода.

    GPIO_Init(GPIOC, &Init); // Конфигурация GPIOC

    while(1)
    {
        GPIO_SetBits(GPIOC, GPIO_Pin_13); // Мигание светодиода.
        SysTim_DelayMS(500);
        GPIO_ResetBits(GPIOC, GPIO_Pin_13);
        SysTim_DelayMS(500);
    }

Размер прошивки 856 байт. Требует 8 байт ОЗУ (не считая стека).

Вложения

Blink_TimDelay.zip

(272.63 KiB) Скачиваний: 209

[bolek]

Где вы такие умные были вчера и почему вместо ответа по существу вопроса начинаете срач на тему "все кал, кроме прямой записи в регистры"? Досикуса еще для полноты компании не хватает

...Все конфигураторы (включая куб, спл) созданы якобы для ускорения процесса разработки. Но в серьезных проектах конфигурирование занимает так мало времени...

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

«Хорошо быть умным, как моя жена назавтра» ©

Например, мне нужно просто считать и показывать картинки на цветном LCD по SPI, т.е из всего богатства периферии нужен только один шустрый блок, достаточный объем памяти, мегагерцы, невысокая цена, распространенность. STM подходит по этим критериям. И?
1. Религиозно-правильный подход: засесть за изучение даташитов, ассемблера (фууу, C - это практически Basic!, отстой!) месяцев на несколько, а лучше на пару-тройку лет, чтобы уж детально во всем разобраться, понаписать своих библиотек, а уж потом...
2. "Неправильный" - быстро решить задачу (скажем за неделю) используя куб для конфигурации, HAL, SPL или что там больше понравится и будет быстрее в освоении с нуля.

Подход №1 - вырванные из жизни годы. КРАМ, много ли их еще осталось впереди? Да и сомнительно, что эти годы будут оплачены заказчиком.
Подход №2 - да, сильно похож на дилетантский, ардуинский и проч. ругательства. Но: задача решена и решена в короткий срок. Сейчас - это важнее, imho. Время такое - быстрее, быстрее, давай результат и поскакали дальше. Пока будешь по битам вылизывать код, конкуренты уйдут вперед. Да и бюджет не всегда (или всегда не) способствует обильным тратам времени. Завтра будет другая задача и другой МК, времена, когда можно было годами лепить поделки на PIC16C... и ассемблере давно ушли.

Так что, спасибо за примеры без куба и HAL, но здесь они не совсем в тему. Если бы был вопрос: как заменить код с HAL на ... - другое дело.
Все остальное - для МЯУ.

[Мурик]

фууу, C - это практически Basic!, отстой!

Что-то имеете против бейсика?
Нормальный ЯП я вам скажу (правда, зависит от диалекта и компилятора/интерпретатора).

[scorpi_0n]

Подход №2 - да, сильно похож на дилетантский, ардуинский и проч. ругательства. Но: задача решена и решена в короткий срок.

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

[КРАМ]

Подход №1 - вырванные из жизни годы. КРАМ, много ли их еще осталось впереди? Да и сомнительно, что эти годы будут оплачены заказчиком.
Подход №2 - да, сильно похож на дилетантский, ардуинский и проч. ругательства. Но: задача решена и решена в короткий срок. Сейчас - это важнее, imho. Время такое - быстрее, быстрее, давай результат и поскакали дальше. Пока будешь по битам вылизывать код, конкуренты уйдут вперед. Да и бюджет не всегда (или всегда не) способствует обильным тратам времени. Завтра будет другая задача и другой МК, времена, когда можно было годами лепить поделки на PIC16C... и ассемблере давно ушли

Отчаянный бред дилетанта-любителя.
Никто не пишет код годами. Вы совершенно не в теме. Я на АСМе решаю задачи быстрее, чем мои коллеги на Си. Впрочем на Си тоже быстрее. Да и написание кода занимает процентов 10...15 от времени разработки изделия. А все изделие от нуля создается примерно за полгода и оно состоит далеко не только из электроники, а сама электроника имеет обширную аналоговую часть. Обновление изделий происходит с интервалом примерно 4...5 лет. Нормальное время для осмысления новых решений на базе опыта эксплуатации старых и рефинансирования разработок. Скакать аки горный козел с бессмысленными псевдоновыми разработками мне никто не позволит: "Лучшее - враг хорошего" (с)
И таки да, новая разработка делается на новом современном МК, правда работа с ним не требует никаких особых временных затрат для освоения. Просто нужно иметь достаточную фундаментальную подготовку, дабы изучение даташитов, рефмануалов, эррат и апнот не вызывало рвотные рефлексы...

[bolek]

Отчаянный бред дилетанта-любителя.
Никто не пишет код годами. Вы совершенно не в теме. Я на АСМе решаю задачи быстрее, чем мои коллеги на Си. Впрочем на Си тоже быстрее. Да и написание кода занимает процентов 10...15 от времени разработки изделия

1.Уважаемый, я свой диплом получил 30+ лет назад, как и Вы, и разработал/запустил в производство не один прибор, поэтому "букварные откровения" от Вас мне неинтересны, думаю, что не только мне.
2. "Сам себя не похвалишь - весь день, как оплеванный" ©
Рад за Вашего работодателя, попросите установить во дворе конторы гранитный постамент: когда нагрянет очередной приступ нарциссизма, будете на нем стоять и олицетворять. Можно при этом еще рукой указывать в правильном направлении.

P.S. Ребяты, давайте сраться в МЯУ, а?

[КРАМ]

Уважаемый, я свой диплом получил 30+ лет назад, как и Вы, и разработал/запустил в производство не один прибор, поэтому "букварные откровения" от Вас мне неинтересны, думаю, что не только мне.

Да хоть 50+.
Если написанное мной - букварные откровения, то к чему был Ваш предыдущий спич? И Вы ли его написАли?

А то может как письмо из Простоквашино - сразу трое?
Если же говорить по существу, то использование конфигураторов уже потому малоэффективно, что сам по себе участок инициализации в коде не имеет сколь нибудь заметной трудоемкости при использовании знакомой платфомы, а при использовании незнакомой, отказ от настройки руками в пользу конфигураторов приводит к:
1. Бездарному использованию этой самой периферии в основной части кода
2. Борьбе с ошибками вызванными конфликтами кода из конфигуратора с собственным кодом, а равно ошибками самого конфигуратора.
Оно того стоит? Есть обоснованное мнение, что потери времени от такого "облегчения" превысят потери на нормальное освоение.