Для другого МК (напр. в случае: APM) проще перейти к написанию кода другими (похожими) абстракции.
Для другого МК (напр. в случае: APM) проще перейти к написанию кода другими (похожими) абстракции.
Код: Выделить всё
{ //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,
>ZC_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
}
Код: Выделить всё
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
}
};
Код: Выделить всё
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;
}Код: Выделить всё
#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)
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 писал(а):G-серия значительно интересней.
Из перечисленного я половины не знаю и 100% не использую и не собираюсь. Не нужно.SDMMC/DCMI/PSSI/I3C
Аналогично - не нужно вообще.QSPI вместо OSPI
Это нужно лишь для МК, у которых своей оперативки 2кБ. А здесь ее - хоть ведрами жри! Спокойно можно 128кБ вообще выделить в отдельный буфер для аллокаторов (хоть лично я считаю, что на МК аллокаторов ни в коем случае быть не должно).без возможности прозрачно прицепить PSRAM
Для управления восемью шаговиками с трапециевидным рампом хватит за глаза мощности STM32F0!производительность G4 меньше в 1.8 раза
Он для двигателей вообще не нужен. Даже аппаратное целочисленное деление не обязательно.FPU похуже
Их нужно много лишь для всяких мультиинтерфейсных решений. Но тут мы утыкаемся в маразм: даже у самых крутых STM32 на весь USB все равно лишь 8 конечных точек! Ну почему хотя бы не 32?USART-ов в 2 раза
Вот это - здорово! Но все равно векторов мало. А уж каналов DMA - так совсем… Ну сделали такой супержирный МК, почему бы не запилить DMAMUX на двух DMA по 128 каналов в каждом? Это было бы здорово.теперь для каждой периферии выделили отдельный вектор
Таймеров одинаково в любом корпусе, но нужно смотреть можно ли все нужные пины заремапить в 64-х пиновом. Если вдруг не получится и нужен больший корпус, тогда и с мк других серий скорее всего будет то же самое.linux_rulezz писал(а):У H563 только в 144-ногом корпусе хватает таймеров.
Лишняя память, как минимум, не мешает.linux_rulezz писал(а):Правда, ресурсов у него слишком много: что делать с таким количеством ОЗУ? Да и флеша чересчур много даже для использования его как эмуляцию EEPROM.
Зачем аллокатор? Во-первых, списки можно хоть во флеше хранить. Во-вторых, ну выделите RAM под список статически, сами же спрашивали зачем ее так много )linux_rulezz писал(а):А связные списки для DMA - это интересно. Правда, опять же, нужно лишь в случае, если соберешься свой аллокатор устраивать.
Это да. Разве что за нее денежку берут лишнюю…Лишняя память, как минимум, не мешает.
Связные-то? А смысл, если массив будет меньше места занимать, ведь все равно все будет по порядку! Связные списки хороши в задачах, где объект может быть удален из середины списка, а целостность при этом достаточно легко восстанавливается. Вот мне в poll этого не хватает, когда под ПК серверное что-нибудь пишу: очень уж удобно было бы клиентов связанными списками держать. А дескрипторы все равно массивом приходится. И когда клиент отключается, приходится дескриптор последнего впихивать на его место (и аналогичным образом двигать списки с "клиентской информацией").списки можно хоть во флеше хранить
Ну так ведь при ОЗУ в 640К можно просто грузить в него программу на этапе отладки. И время экономится, и ресурс флэш. Вероятно, при работе программы из ОЗУ какие-то отладчики могут вообще снять ограничение на количество точек останова.linux_rulezz писал(а):Это да. Разве что за нее денежку берут лишнюю…