Остается только импортировать заголовочный файл с регистрами и периферией откуда-то еще (не от производителя чипов) или определить их самостоятельно. Что для одного микроконтроллера легко, но для нескольких микроконтроллеров подряд - уже бессмысленно (требует много времени и труда).
Для другого МК (напр. в случае: APM) проще перейти к написанию кода другими (похожими) абстракции.
Теперь понял ваши слова. Спасибо. Да, так ОК -> необходимо вносит доп. #define.
Но напр. работаю с APM - 7 типами, а также с STIM32 - напр. 25 типами, с GD32 и другими, и другими, и другими МК. То есть приходится самому написать все периферийные устройства в МК и их адреса? А производители уже это сделали в их header файлы и просто используем то, что видно и уже реализовано.
Некоторые коллеги используют 1-2 вида МК за всю жизнь. И знают документацию наизусть. Напр. я открываю документацию по мере необходимости, на нужной странице ... Нет времени. На самом деле, каждый выбирает свой путь.
Кстати, а никто ли случаем не натыкался на хоть какое-то подобие сниппетов для STM32H503? Ну или хотя бы где почитать, есть ли смысл заводить себе MMU без RTOS и многозадачности? Да и вообще, с какой стороны к нему подойти bare-metal. А то поиск в интернетах только убогие огрызки на калокубе выдает… Да и сишный стартап не помешал бы готовый: лень все это руками писать!
_________________ Windows must die! And the users of this crap should either become smarter or become janitors.
Кстати, а никто ли случаем не натыкался на хоть какое-то подобие сниппетов для STM32H503? Ну или хотя бы где почитать, есть ли смысл заводить себе MMU без RTOS и многозадачности? Да и вообще, с какой стороны к нему подойти bare-metal.
Какое MMU у H5, может все-таки MPU? ) А подход точно такой как и для других кортексов, стартап сишный абсолютно стандартный, можно взять от M4, разве что при желании можно еще установку MSPLIM добавить.
Adrift, тьфу, да, MPU, конечно. Больше всего напрягает бешеное количество всяких "движков" в области тактирования. Хотя, это всегда одноразовая работа: один раз настроил, что тебе нужно, потом пользуешься. По мере необходимости добавляешь остальное. Вот, писал себе под F303, потом обнаружил, что надо тактировать I2C от 72МГц. ОК, добавил еще строчку в функцию инициализации. Наверное, с таким подходом - постепенно, а не пытаться все сразу - будет проще войти в такой жирный МК. Разве что с USB повозиться придется. Надо, наверное, как-нибудь недельку-две свободных вечеров уделить OTG, да портировать свои USB'шные сниппеты и на OTG'шные МК. Host мне все равно не нужен и никогда не понадобится, а вот device сделать надо (по классике: эмуляцию PL2303, "обычный" CDC и "клавомышь" на HID).
_________________ Windows must die! And the users of this crap should either become smarter or become janitors.
/* 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
А уж дефайл 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; }
Читаю даташит на STM32H503 и все больше недоумеваю (да и задаю себе вопрос: зачем я девборду на нем купил?): камень вообще ниже среднего! Ну и что, что частота в 3.5 раза выше? А периферии - с гулькин нос! Еще и USB все то же наркоманское. А больше в USB поразило, что там аж 2кБ ОЗУ на буферы, но при этом всего-то все те же самые 8 endpoints! Как говорится - разгуляемся! Т.е. все так же больше семи CDC на одном камне не сделать (хотя, с такой скудной периферией это и не нужно). DMA в USB все так и не добавили. Ну, хоть резистор подтяжки внутренний есть (правда, вот так привыкаешь к ним - а потом рисуешь плату и заказываешь без подтяжки, и приходится эмулировать ее ногодрыгом USB DP, а резистор "навесным" куда-нибудь подпаивать). Ну, а скажем, для управления хотя бы восемью шаговиками с обратной связью нужно 16 независимых таймеров: 8 в режиме ШИМ (микрошаги генерить) и 8 в режиме энкодера. И хде? В общем, ну его нафиг! Пусть и дальше в "дальнем ящике" лежит. Недоразумение какое-то, а не микроконтроллер! G-серия значительно интересней.
_________________ Windows must die! And the users of this crap should either become smarter or become janitors.
Ну, а скажем, для управления хотя бы восемью шаговиками с обратной связью нужно 16 независимых таймеров: 8 в режиме ШИМ (микрошаги генерить) и 8 в режиме энкодера. И хде?
Действительно, где? Какие там у вас мк есть из относительно жирных? F303/F407/G431/H503? Убираем простые счетчики TIM6/7, в каком из этих мк остается 16 таймеров? ) А вот у H563 целых 14 таймеров(два 32-битных) плюс 6 LPTIM у пяти из которых есть энкодер. Хотя у G4 может быть HRTIM который потенциально кучу таймеров может заменить.
linux_rulezz писал(а):
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, теперь для каждой периферии выделили отдельный вектор...
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к вполне вмещается)!
Такие гигантские ресурсы развращают! Страшно с ними работать: чуть не углядишь - и мужеложцем станешь…
_________________ Windows must die! And the users of this crap should either become smarter or become janitors.
ну вот у F407 12 таймеров с ШИМ/энкодерами, т.е. можно 6 шаговиков с обратной связью подключить.
У F407 можно найти 6 таймеров с энкодерами и еще останется 6 с шимами, т.е. он не дотягивает до ваших хотелок где нужно 8 + 8. У H563 то же самое по основным таймерам, но дополнительно 5 из 6-ти LPTIM и шимят и с энкодерами работают, потому его хватает на 8+9.
linux_rulezz писал(а):
У H563 только в 144-ногом корпусе хватает таймеров.
Таймеров одинаково в любом корпусе, но нужно смотреть можно ли все нужные пины заремапить в 64-х пиновом. Если вдруг не получится и нужен больший корпус, тогда и с мк других серий скорее всего будет то же самое.
linux_rulezz писал(а):
Правда, ресурсов у него слишком много: что делать с таким количеством ОЗУ? Да и флеша чересчур много даже для использования его как эмуляцию EEPROM.
Лишняя память, как минимум, не мешает.
linux_rulezz писал(а):
А связные списки для DMA - это интересно. Правда, опять же, нужно лишь в случае, если соберешься свой аллокатор устраивать.
Зачем аллокатор? Во-первых, списки можно хоть во флеше хранить. Во-вторых, ну выделите RAM под список статически, сами же спрашивали зачем ее так много )
Связные-то? А смысл, если массив будет меньше места занимать, ведь все равно все будет по порядку! Связные списки хороши в задачах, где объект может быть удален из середины списка, а целостность при этом достаточно легко восстанавливается. Вот мне в poll этого не хватает, когда под ПК серверное что-нибудь пишу: очень уж удобно было бы клиентов связанными списками держать. А дескрипторы все равно массивом приходится. И когда клиент отключается, приходится дескриптор последнего впихивать на его место (и аналогичным образом двигать списки с "клиентской информацией"). Но то - компьютер, там аллокатор - нормально.
А за намек на H563 спасибо. Буду иметь в виду на будущее.
_________________ Windows must die! And the users of this crap should either become smarter or become janitors.
Ну так ведь при ОЗУ в 640К можно просто грузить в него программу на этапе отладки. И время экономится, и ресурс флэш. Вероятно, при работе программы из ОЗУ какие-то отладчики могут вообще снять ограничение на количество точек останова.
Ну так ведь при ОЗУ в 640К можно просто грузить в него программу на этапе отладки. И время экономится, и ресурс флэш.
А я за внедрение FRAM в микроконтроллеры. Сколько можно жить под гнётом убожества Flash?!! Долой Flash!!! Даёшь FRAM в каждый микроконтроллер!!!
Да и SRAM вобщем-то тоже не нужна - просто одна сплошная FRAM (или MRAM) в МК! А уже сам программист пусть решает - сколько из неё отрезать для кода и констант, а сколько - для R/W-данных. Вот житуха настанет!
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 24
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
Что для одного микроконтроллера легко, но для нескольких микроконтроллеров подряд - уже бессмысленно (требует много времени и труда).
