STM32 новичку в ARM что к чему

[veso74]

Остается только импортировать заголовочный файл с регистрами и периферией откуда-то еще (не от производителя чипов) или определить их самостоятельно. Что для одного микроконтроллера легко, но для нескольких микроконтроллеров подряд - уже бессмысленно (требует много времени и труда).



Для другого МК (напр. в случае: APM) проще перейти к написанию кода другими (похожими) абстракции.

[VladislavS]

[uquote="veso74",url="/forum/viewtopic.php?p=4753559#p4753559"][/uquote]Вы зачем псевдокод скомпилировать пытаетесь? Троеточие, главное, убрали, а PAEN посмотреть как в заголовочном файле правильно называется никак?

[veso74]

VladislavS, мало что понял (РУ->БГ). Другими словами если можно, пожалуйста?
(Могли бы привести пример?)

Keil, Devices, APM32F1 Series, APM32F103, APM32F103CB

[VladislavS]

Как я и говорил, обычный union.

Поэтому

Больше разговоров. Если это вызывает трудности, то стоит сменить род деятельности.

изображение_2025-10-13_154026266.png

(71.77 КБ) 1003 скачивания

изображение_2025-10-13_154155135.png

(9.69 КБ) 995 скачиваний

[veso74]

Теперь понял ваши слова. Спасибо. Да, так ОК -> необходимо вносит доп. #define.

Но напр. работаю с APM - 7 типами, а также с STIM32 - напр. 25 типами, с GD32 и другими, и другими, и другими МК. То есть приходится самому написать все периферийные устройства в МК и их адреса? А производители уже это сделали в их header файлы и просто используем то, что видно и уже реализовано.

Некоторые коллеги используют 1-2 вида МК за всю жизнь. И знают документацию наизусть. Напр. я открываю документацию по мере необходимости, на нужной странице ... Нет времени. На самом деле, каждый выбирает свой путь.

[linux_rulezz]

Кстати, а никто ли случаем не натыкался на хоть какое-то подобие сниппетов для STM32H503?
Ну или хотя бы где почитать, есть ли смысл заводить себе MMU без RTOS и многозадачности? Да и вообще, с какой стороны к нему подойти bare-metal. А то поиск в интернетах только убогие огрызки на калокубе выдает…
Да и сишный стартап не помешал бы готовый: лень все это руками писать!

[Adrift]

[uquote="linux_rulezz",url="/forum/viewtopic.php?p=4753703#p4753703"]Кстати, а никто ли случаем не натыкался на хоть какое-то подобие сниппетов для STM32H503?
Ну или хотя бы где почитать, есть ли смысл заводить себе MMU без RTOS и многозадачности? Да и вообще, с какой стороны к нему подойти bare-metal.[/uquote]
Какое MMU у H5, может все-таки MPU? ) А подход точно такой как и для других кортексов, стартап сишный абсолютно стандартный, можно взять от M4, разве что при желании можно еще установку MSPLIM добавить.

[linux_rulezz]

Adrift, тьфу, да, MPU, конечно.
Больше всего напрягает бешеное количество всяких "движков" в области тактирования. Хотя, это всегда одноразовая работа: один раз настроил, что тебе нужно, потом пользуешься. По мере необходимости добавляешь остальное. Вот, писал себе под F303, потом обнаружил, что надо тактировать I2C от 72МГц. ОК, добавил еще строчку в функцию инициализации. Наверное, с таким подходом - постепенно, а не пытаться все сразу - будет проще войти в такой жирный МК. Разве что с USB повозиться придется. Надо, наверное, как-нибудь недельку-две свободных вечеров уделить OTG, да портировать свои USB'шные сниппеты и на OTG'шные МК. Host мне все равно не нужен и никогда не понадобится, а вот device сделать надо (по классике: эмуляцию PL2303, "обычный" CDC и "клавомышь" на HID).

[VladislavS]

[uquote="linux_rulezz",url="/forum/viewtopic.php?p=4753703#p4753703"]Да и сишный стартап не помешал бы готовый: лень все это руками писать![/uquote]На третий день Орлиный Глаз заметил, что у сарая одной стены не хватает (стартапы кортексов только таблицей векторов прерываний отличаются).

Код: Выделить всё

{ //H503
	&_estack,
	&Reset_Handler,
	&NMI_Handler,
	&HardFault_Handler,
	&MemManage_Handler,
	&BusFault_Handler,
	&UsageFault_Handler,
	NULL,NULL,NULL,NULL,
	&SVC_Handler,
	&DebugMon_Handler,
	NULL,
	&PendSV_Handler,
	&SysTick_Handler,
	&WWDG_IRQHandler,
	&PVD_AVD_IRQHandler,
	&RTC_IRQHandler,
	NULL,
	&TAMP_IRQHandler,
	&RAMCFG_IRQHandler,
	&FLASH_IRQHandler,
	NULL,
	&GTZC_IRQHandler,
	&RCC_IRQHandler,
	NULL,
	&EXTI0_IRQHandler,
	&EXTI1_IRQHandler,
	&EXTI2_IRQHandler,
	&EXTI3_IRQHandler,
	&EXTI4_IRQHandler,
	&EXTI5_IRQHandler,
	&EXTI6_IRQHandler,
	&EXTI7_IRQHandler,
	&EXTI8_IRQHandler,
	&EXTI9_IRQHandler,
	&EXTI10_IRQHandler,
	&EXTI11_IRQHandler,
	&EXTI12_IRQHandler,
	&EXTI13_IRQHandler,
	&EXTI14_IRQHandler,
	&EXTI15_IRQHandler,
	&GPDMA1_Channel0_IRQHandler,
	&GPDMA1_Channel1_IRQHandler,
	&GPDMA1_Channel2_IRQHandler,
	&GPDMA1_Channel3_IRQHandler,
	&GPDMA1_Channel4_IRQHandler,
	&GPDMA1_Channel5_IRQHandler,
	&GPDMA1_Channel6_IRQHandler,
	&GPDMA1_Channel7_IRQHandler,
	&IWDG_IRQHandler,
	NULL,
	&ADC1_IRQHandler,
	&DAC1_IRQHandler,
	&FDCAN1_IT0_IRQHandler,
	&FDCAN1_IT1_IRQHandler,
	&TIM1_BRK_IRQHandler,
	&TIM1_UP_IRQHandler,
	&TIM1_TRG_COM_IRQHandler,
	&TIM1_CC_IRQHandler,
	&TIM2_IRQHandler,
	&TIM3_IRQHandler,
	NULL,NULL,
	&TIM6_IRQHandler,
	&TIM7_IRQHandler,
	&I2C1_EV_IRQHandler,
	&I2C1_ER_IRQHandler,
	&I2C2_EV_IRQHandler,
	&I2C2_ER_IRQHandler,
	&SPI1_IRQHandler,
	&SPI2_IRQHandler,
	&SPI3_IRQHandler,
	&USART1_IRQHandler,
	&USART2_IRQHandler,
	&USART3_IRQHandler,
	NULL,NULL,
	&LPUART1_IRQHandler,
	&LPTIM1_IRQHandler,
	NULL,NULL,NULL,NULL,NULL,
	&LPTIM2_IRQHandler,
	NULL,NULL,NULL,
	&USB_DRD_FS_IRQHandler,
	&CRS_IRQHandler,
	NULL,NULL,NULL,NULL,
	NULL,NULL,NULL,NULL,
	NULL,NULL,NULL,NULL,
	NULL,NULL,
	&GPDMA2_Channel0_IRQHandler,
	&GPDMA2_Channel1_IRQHandler,
	&GPDMA2_Channel2_IRQHandler,
	&GPDMA2_Channel3_IRQHandler,
	&GPDMA2_Channel4_IRQHandler,
	&GPDMA2_Channel5_IRQHandler,
	&GPDMA2_Channel6_IRQHandler,
	&GPDMA2_Channel7_IRQHandler,
	NULL,NULL,NULL,NULL,NULL,
	&FPU_IRQHandler,
	&ICACHE_IRQHandler,
	NULL,NULL,NULL,NULL,NULL,
	NULL,NULL,NULL,
	&DTS_IRQHandler,
	&RNG_IRQHandler,
	NULL,NULL,
	&HASH_IRQHandler,
	NULL,NULL,NULL,NULL,NULL,
	&I3C1_EV_IRQHandler,
	&I3C1_ER_IRQHandler,
	NULL,NULL,NULL,NULL,
	NULL,NULL,&I3C2_EV_IRQHandler,
	&I3C2_ER_IRQHandler,
	&COMP1_IRQHandler
}	

[linux_rulezz]

У меня вот так:

Код: Выделить всё

vector_table_t vector_table __attribute__ ((used, section(".vector_table"))) = {
    .initial_sp_value = &_stack,
    .reset = reset_handler,
    .nmi = nmi_handler,
    .hard_fault = hard_fault_handler,
    
/* Those are defined only on CM3 or CM4 */
#if defined(__ARM_ARCH_7M__) || defined(__ARM_ARCH_7EM__)
    .memory_manage_fault = mem_manage_handler,
    .bus_fault = bus_fault_handler,
    .usage_fault = usage_fault_handler,
    .debug_monitor = debug_monitor_handler,
#endif

    .sv_call = sv_call_handler,
    .pend_sv = pend_sv_handler,
    .systick = sys_tick_handler,
    .irq = {
        IRQ_HANDLERS
    }
};

А уж дефайл IRQ_HANDLERS зависит от типа МК.
В заголовочном же файле определяются функции сброса периферии (обычно я ей не пользуюсь) и инициализации тактирования, например:

Код: Выделить всё

TRUE_INLINE int StartHSE(){ // system bus 72MHz from PLL
    __IO uint32_t StartUpCounter = 0;
    RCC->CFGR &= ~RCC_CFGR_SW; // set sysclock to HSI
    WAITWHILE(RCC->CFGR & RCC_CFGR_SWS);
    RCC->CR &= ~RCC_CR_PLLON;
    WAITWHILE(RCC->CR & RCC_CR_PLLRDY); // wait while PLL will be off
    RCC->CR |= RCC_CR_HSEON; // disable PLL to reconfigure, enable HSE
    WAITWHILE(!(RCC->CR & RCC_CR_HSERDY));
    // Enable Prefetch Buffer. Flash 4 wait states for 48..72MHz
    FLASH->ACR = (FLASH->ACR & ~(FLASH_ACR_LATENCY)) |
            FLASH_ACR_LATENCY_2 | FLASH_ACR_PRFTBE;
    // HCLK = SYSCLK (AHB prescaler = 1), PCLK1 = HCLK/2 (APB1 prescaler = 2, max freq = 36MHz),
    // PCLK2 = HCLK (APB2 prescaler = 1), PLLCLK = HSE * 9 = 72MHz
    RCC->CFGR = RCC_CFGR_PLLSRC_HSE_PREDIV | RCC_CFGR_PLLMUL9 | RCC_CFGR_PPRE1_DIV2;
    RCC->CR |= RCC_CR_PLLON; // Enable PLL
    // Wait till PLL is ready
    WAITWHILE(!(RCC->CR & RCC_CR_PLLRDY));
    // Select PLL as system clock source
    RCC->CFGR = (RCC->CFGR & ~RCC_CFGR_SW) | RCC_CFGR_SW_PLL;
    // select system clock as I2C source
    RCC->CFGR3 |= RCC_CFGR3_I2C1SW_SYSCLK | RCC_CFGR3_I2C1SW_SYSCLK;
    // Wait till PLL is used as system clock source
    WAITWHILE((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL);
    SysFreq = 72000000;
    return 1;
}

А для G вот так:

Код: Выделить всё

#define WAITWHILE(x)  do{register uint32_t StartUpCounter = 0; while((x) && (++StartUpCounter < 0xffffff)){nop();}}while(0)
TRUE_INLINE void StartHSEHSI(int isHSE){
    RCC->CR &= ~RCC_CR_PLLON; // disable PLL
    WAITWHILE(RCC->CR & RCC_CR_PLLRDY); // wait while PLL on
    if(isHSE){
        RCC->CR |= RCC_CR_HSEON;
        WAITWHILE(!(RCC->CR & RCC_CR_HSERDY)); // wait while HSE isn't on
    }else RCC->CR |= RCC_CR_HSION;
    RCC->APBENR1 |= RCC_APBENR1_PWREN;
    // Enable high performance mode
    PWR->CR1 = PWR_CR1_VOS_0;
    WAITWHILE(PWR->SR2 & PWR_SR2_VOSF);
    if(isHSE){
        RCC->PLLCFGR = ((PLLR-1)<<29) | ((PLLQ-1)<<25) | ((PLLP-1)<<17) | (PLLN<<8) | ((PLLM-1)<<4)
                | RCC_PLLCFGR_PLLREN | RCC_PLLCFGR_PLLPEN /* | RCC_PLLCFGR_PLLQEN */
                | RCC_PLLCFGR_PLLSRC_HSE;
    }else{ // 64MHz from HSI16
        RCC->PLLCFGR = (8<<8) | (1<<4)
                // enable P and/or Q if need
                | RCC_PLLCFGR_PLLREN  /* | RCC_PLLCFGR_PLLPEN  | RCC_PLLCFGR_PLLQEN */
                | RCC_PLLCFGR_PLLSRC_HSI;
    }
    RCC->CR |= RCC_CR_PLLON;
    WAITWHILE(!(RCC->CR & RCC_CR_PLLRDY));
    FLASH->ACR |= FLASH_ACR_PRFTEN | FLASH_ACR_ICEN | FLASH_ACR_LATENCY_1;
    RCC->CFGR = RCC_CFGR_SW_1; // set sysclk switch to pll
}

#define StartHSE()  do{StartHSEHSI(1);}while(0)
#define StartHSI()  do{StartHSEHSI(0);}while(0)

(правда, вообще не проверяю, если вдруг косяк случился).

[VladislavS]

Ну вот, а то я уже было подумал, что тебе там ctrl-c и ctrl-v не завезли.

[linux_rulezz]

Читаю даташит на STM32H503 и все больше недоумеваю (да и задаю себе вопрос: зачем я девборду на нем купил?): камень вообще ниже среднего! Ну и что, что частота в 3.5 раза выше? А периферии - с гулькин нос! Еще и USB все то же наркоманское. А больше в USB поразило, что там аж 2кБ ОЗУ на буферы, но при этом всего-то все те же самые 8 endpoints! Как говорится - разгуляемся! Т.е. все так же больше семи CDC на одном камне не сделать (хотя, с такой скудной периферией это и не нужно). DMA в USB все так и не добавили. Ну, хоть резистор подтяжки внутренний есть (правда, вот так привыкаешь к ним - а потом рисуешь плату и заказываешь без подтяжки, и приходится эмулировать ее ногодрыгом USB DP, а резистор "навесным" куда-нибудь подпаивать).
Ну, а скажем, для управления хотя бы восемью шаговиками с обратной связью нужно 16 независимых таймеров: 8 в режиме ШИМ (микрошаги генерить) и 8 в режиме энкодера. И хде?
В общем, ну его нафиг! Пусть и дальше в "дальнем ящике" лежит. Недоразумение какое-то, а не микроконтроллер!
G-серия значительно интересней.

[Adrift]

[uquote="linux_rulezz",url="/forum/viewtopic.php?p=4754041#p4754041"]Ну, а скажем, для управления хотя бы восемью шаговиками с обратной связью нужно 16 независимых таймеров: 8 в режиме ШИМ (микрошаги генерить) и 8 в режиме энкодера. И хде?[/uquote]
Действительно, где? Какие там у вас мк есть из относительно жирных? F303/F407/G431/H503? Убираем простые счетчики TIM6/7, в каком из этих мк остается 16 таймеров? ) А вот у H563 целых 14 таймеров(два 32-битных) плюс 6 LPTIM у пяти из которых есть энкодер. Хотя у G4 может быть HRTIM который потенциально кучу таймеров может заменить.

G-серия значительно интересней.

SDMMC/DCMI/PSSI/I3C нет вообще, QSPI вместо OSPI, т.е. без возможности прозрачно прицепить PSRAM, SPI заметно проще, DMA вообще не сравнимы, ни по функционалу, ни по скорости, т.к. у G4 наверно самый медленный DMA из всех серий, разве что F1 может на том же уровне. Дальше, производительность G4 меньше в 1.8 раза, FPU похуже, аппаратного контроля переполнения стека нет, RAM может быть меньше в 5 раз, USART-ов в 2 раза, 100к ресурса части флеша тоже нет и дальше еще будет длинный список мелкий улучшений в H5, типа RTC с бинарным форматом хранения времени помимо BCD, LPTIM стали двухканальные и наконец пропали вектора прерываний типа TIM1_BRK_TIM15_IRQHandler, теперь для каждой периферии выделили отдельный вектор...

[linux_rulezz]

Adrift, ну вот у F407 12 таймеров с ШИМ/энкодерами, т.е. можно 6 шаговиков с обратной связью подключить.
У H563 только в 144-ногом корпусе хватает таймеров. И очень много умеют в энкодеры. Прикинул: хватит, чтобы 8 энкодеров подключить и 8 независимых ШИМ-выходов. Правда, ресурсов у него слишком много: что делать с таким количеством ОЗУ? Да и флеша чересчур много даже для использования его как эмуляцию EEPROM.

SDMMC/DCMI/PSSI/I3C

Из перечисленного я половины не знаю и 100% не использую и не собираюсь. Не нужно.

QSPI вместо OSPI

Аналогично - не нужно вообще.

без возможности прозрачно прицепить PSRAM

Это нужно лишь для МК, у которых своей оперативки 2кБ. А здесь ее - хоть ведрами жри! Спокойно можно 128кБ вообще выделить в отдельный буфер для аллокаторов (хоть лично я считаю, что на МК аллокаторов ни в коем случае быть не должно).

производительность G4 меньше в 1.8 раза

Для управления восемью шаговиками с трапециевидным рампом хватит за глаза мощности STM32F0!

FPU похуже

Он для двигателей вообще не нужен. Даже аппаратное целочисленное деление не обязательно.

USART-ов в 2 раза

Их нужно много лишь для всяких мультиинтерфейсных решений. Но тут мы утыкаемся в маразм: даже у самых крутых STM32 на весь USB все равно лишь 8 конечных точек! Ну почему хотя бы не 32?

теперь для каждой периферии выделили отдельный вектор

Вот это - здорово! Но все равно векторов мало. А уж каналов DMA - так совсем… Ну сделали такой супержирный МК, почему бы не запилить DMAMUX на двух DMA по 128 каналов в каждом? Это было бы здорово.

А связные списки для DMA - это интересно. Правда, опять же, нужно лишь в случае, если соберешься свой аллокатор устраивать. Гадость.
Подозреваю, что H563 и им подобные разрабатываются с учетом требований всяких абдуринщиков-калокуберов, которым для мигания светодиодом подавай 8кБ флеша, а для тупого USB-CDC - все 32 (в то время как "голый" CDC в 4к вполне вмещается)!

Такие гигантские ресурсы развращают! Страшно с ними работать: чуть не углядишь - и мужеложцем станешь…

[Zikon]

а если китайцев посмотреть

HC32F4A0PITB - допустим

правда там библиотека своя и внутри всё по другому
но совместим с F407 по пинам
везде продаётся для опытов можно взять (озон али) - недорого

[Adrift]

[uquote="linux_rulezz",url="/forum/viewtopic.php?p=4754298#p4754298"]ну вот у F407 12 таймеров с ШИМ/энкодерами, т.е. можно 6 шаговиков с обратной связью подключить.[/uquote]
У F407 можно найти 6 таймеров с энкодерами и еще останется 6 с шимами, т.е. он не дотягивает до ваших хотелок где нужно 8 + 8. У H563 то же самое по основным таймерам, но дополнительно 5 из 6-ти LPTIM и шимят и с энкодерами работают, потому его хватает на 8+9.

У H563 только в 144-ногом корпусе хватает таймеров.

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

Правда, ресурсов у него слишком много: что делать с таким количеством ОЗУ? Да и флеша чересчур много даже для использования его как эмуляцию EEPROM.

Лишняя память, как минимум, не мешает.

А связные списки для DMA - это интересно. Правда, опять же, нужно лишь в случае, если соберешься свой аллокатор устраивать.

Зачем аллокатор? Во-первых, списки можно хоть во флеше хранить. Во-вторых, ну выделите RAM под список статически, сами же спрашивали зачем ее так много )

[linux_rulezz]

Лишняя память, как минимум, не мешает.

Это да. Разве что за нее денежку берут лишнюю…

списки можно хоть во флеше хранить

Связные-то? А смысл, если массив будет меньше места занимать, ведь все равно все будет по порядку! Связные списки хороши в задачах, где объект может быть удален из середины списка, а целостность при этом достаточно легко восстанавливается. Вот мне в poll этого не хватает, когда под ПК серверное что-нибудь пишу: очень уж удобно было бы клиентов связанными списками держать. А дескрипторы все равно массивом приходится. И когда клиент отключается, приходится дескриптор последнего впихивать на его место (и аналогичным образом двигать списки с "клиентской информацией").
Но то - компьютер, там аллокатор - нормально.

А за намек на H563 спасибо. Буду иметь в виду на будущее.

[tonyk]

Это да. Разве что за нее денежку берут лишнюю…

Ну так ведь при ОЗУ в 640К можно просто грузить в него программу на этапе отладки. И время экономится, и ресурс флэш. Вероятно, при работе программы из ОЗУ какие-то отладчики могут вообще снять ограничение на количество точек останова.

[jcxz]

[uquote="tonyk",url="/forum/viewtopic.php?p=4754348#p4754348"]Вероятно, при работе программы из ОЗУ какие-то отладчики могут вообще снять ограничение на количество точек останова.[/uquote]Не какие-то, а все. Зачем аппаратный бряк если можно поставить программный? Аппаратные и придумали, чтобы флешь не перешивать туда/сюда.

Добавлено after 6 minutes 9 seconds:
[uquote="tonyk",url="/forum/viewtopic.php?p=4754348#p4754348"]Ну так ведь при ОЗУ в 640К можно просто грузить в него программу на этапе отладки. И время экономится, и ресурс флэш.[/uquote]А я за внедрение FRAM в микроконтроллеры. Сколько можно жить под гнётом убожества Flash?!! Долой Flash!!! Даёшь FRAM в каждый микроконтроллер!!!

Да и SRAM вобщем-то тоже не нужна - просто одна сплошная FRAM (или MRAM) в МК! А уже сам программист пусть решает - сколько из неё отрезать для кода и констант, а сколько - для R/W-данных.
Вот житуха настанет!