8МГц. Да я подозреваю, что бинарь-то будет нормально работать. Это я где-то умудрился накосячить. Хоть выводи MCO для проверки… Но эта функция нормально завершается:
Код:
TRUE_INLINE int StartHSE(){ // system bus 72MHz from PLL __IO uint32_t StartUpCounter = 0; #define WAITWHILE(x) do{StartUpCounter = 0; while((x) && (++StartUpCounter < 0xffffff)){nop();}; if(x) return 0;}while(0) RCC->CR = (RCC->CR & ~RCC_CR_PLLON) | 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 (APB1 prescaler = 1), PCLK2 = HCLK (APB2 prescaler = 1) // PLLCLK = HSE * 9 = 72MHz RCC->CFGR = RCC_CFGR_PLLSRC_HSE_PREDIV | RCC_CFGR_PLLMUL9; 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; // Wait till PLL is used as system clock source WAITWHILE((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_1); #undef WAITWHILE return 1; }
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
VladislavS, приведенный код от моего вообще ничем не отличается (кроме множителей: у меня везде 1). Зачем указывать флаги, которые равны нулю? P.S. У меня подтяжка на PA15, ты про это не спросил почему-то. Ведь у 303 нет аппаратной подтяжки DP.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Открыта удобная площадка с выгодными ценами, поставляющая весь ассортимент продукции, производимой компанией MEAN WELL – от завоевавших популярность и известных на рынке изделий до новинок. MEAN WELL.Market предоставляет гарантийную и сервисную поддержку, удобный подбор продукции, оперативную доставку по России.
На сайте интернет-магазина посетители смогут найти обзоры, интересные статьи о применении, максимальный объем технических сведений.
Продукция MOSO предназначена в основном для индустриальных приложений, использует инновационные решения на основе более 200 собственных патентов для силовой электроники и соответствует международным стандартам. LED-драйверы MOSO применяются в системах наружного освещения разных отраслей, включая промышленность, сельское хозяйство, транспорт и железную дорогу. В ряде серий реализована возможность дистанционного контроля и программирования работы по заданному сценарию. Разберем решения MOSO
подробнее>>
Забыл сказать: т.к. там PNP-транзистор, активируется он нулем.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Спасибо, работает: эхо введенных данных. Что и требовалось доказать: виноваты мои кривые руки. Судя по тому, что после USB_ISTR_RESET вообще не появляется USB_ISTR_CTR, я накосячил с инициализацией тактирования.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Последний раз редактировалось Eddy_Em Вс фев 13, 2022 23:48:38, всего редактировалось 1 раз.
И тоже получаем нули, а с +8 работает правильно, выходит и M0 требует выравнивания стека на 8? Конечно нет, этого требует printf, а на ПК где есть SSE она будет требовать выравнивания на 16, даже если у конкретного проца этого SSE нет, более того можно хоть для AVR написать функцию требующую любое выравнивание... Выравнивание стека на 8 - это требование ABI, не самой архитектуры cortex-m.
Конечно нет, этого требует printf, а на ПК где есть SSE она будет требовать выравнивания на 16, даже если у конкретного проца этого SSE нет, более того можно хоть для AVR написать функцию требующую любое выравнивание... Выравнивание стека на 8 - это требование ABI, не самой архитектуры cortex-m.
Да вполне возможно. Я и писал что "не знаю кто именно, но кто-то требует на >=M4F выравнивания на 8" (с более младшими ядрами я не работаю - не в курсе и не интересно). Но по-моему не факт, что эти требования printf() не обусловлены какими-то аппаратными возможностями CPU. Потому как - если бы это были только требования реализации printf(), которую можно было бы реализовать и без этих требований, то это очень странно: одна printf() всё таки - очень частный случай, может и вообще не использоваться ни разу в проекте. И из-за этого частного случая вносить такую кучу ограничений в генерацию кода! Вы посмотрите в листинги - сколько там лишних сохранений в стек из-за необходимости этого выравнивания! А это ведь и лишние расходы памяти и быстродействия. Причём вообще для всего кода. Даже для того, где требуется максимальное быстродействие и printf() и близко не лежит - всё равно будут лишние PUSH/POP. Имхо: такие существенные минусы можно оправдать только или аппаратными ограничениями системы команд/архитектуры (их никак не обойти) или принципильной невозможностью реализации функций стандартной бибилиотеки без этого выравнивания.
Интересное кино: если я вначале выставляю тактирование от HSI, то HSE потом не включается (хоть функция возвращает true)! Вот HSI:
Код:
TRUE_INLINE void StartHSI(){ // system bus 48MHz from PLL __IO uint32_t StartUpCounter = 0; #define WAITWHILE(x) do{StartUpCounter = 0; while((x) && (++StartUpCounter < 0xffffff)){nop();}}while(0) RCC->CR = (RCC->CR & ~RCC_CR_PLLON) | RCC_CR_HSION; // To adjust HSI set value of HSITRIM here WAITWHILE(!(RCC->CR & RCC_CR_HSIRDY)); FLASH->ACR = (FLASH->ACR & ~(FLASH_ACR_LATENCY)) | FLASH_ACR_LATENCY_0 | FLASH_ACR_PRFTBE; RCC->CFGR = RCC_CFGR_PLLSRC_HSI_DIV2 | RCC_CFGR_PLLMUL12 | RCC_CFGR_USBPRE_DIV1 | 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; // Wait till PLL is used as system clock source WAITWHILE((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL); #undef WAITWHILE }
А вот - HSE:
Код:
// @return 1 if OK, 0 if failed TRUE_INLINE int StartHSE(){ // system bus 72MHz from PLL __IO uint32_t StartUpCounter = 0; #define WAITWHILE(x) do{StartUpCounter = 0; while((x) && (++StartUpCounter < 0xffffff)){nop();}; if(x) return 0;}while(0) RCC->CR = (RCC->CR & ~RCC_CR_PLLON) | 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; // Wait till PLL is used as system clock source WAITWHILE((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL); #undef WAITWHILE return 1; }
Но, судя по тому, что в терминале с USART - тарабарщина, системными часами остается HSI (48МГц супротив 72).
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Но по-моему не факт, что эти требования printf() не обусловлены какими-то аппаратными возможностями CPU. Потому как - если бы это были только требования реализации printf(), которую можно было бы реализовать и без этих требований, то это очень странно: одна printf() всё таки - очень частный случай, может и вообще не использоваться ни разу в проекте. И из-за этого частного случая вносить такую кучу ограничений в генерацию кода!
Я потратил достаточно много времени пытаясь найти почему же именно нужно выравнивание на 8, если оно действительно нужно. И везде встречаю только разные интерпретации строк из "ARMv7-M Architecture Reference manual":
Цитата:
The ARMv7-M architecture guarantees that stack pointer values are at least 4-byte aligned. However, some software standards require the stack pointer to be 8-byte aligned, and the architecture can enforce this alignment.
Твой пример с printf() лишь подтверждает вышесказанное, чтобы доказать наличие именно архитектурных ограничений нужно что-то весомее неправильно работающих функций. У меня свое форматирование и с ним все работает(на M7):
Больше чем уверен, что всё выгрузится как надо. А раз ограничение не аппаратное, то это дело тулчейна такие вещи разруливать. Программисту остаётся лишь не мешать ему. Я вот стек руками не двигаю от слов совсем никогда.
Интересное кино: если я вначале выставляю тактирование от HSI, то HSE потом не включается (хоть функция возвращает true)!
Вероятно это не тот случай, но если бы перед вызовов StartHSE() этот HSE уже завелся, то с большой вероятностью были бы проблемы из-за того, что выключая PLL ты не дожидаешься его реального отключения(проверяя флаг PLLRDY), в таком случае запись в регистры PLL может быть заблокирована.
Действительно, PLL нужно было не просто отключить для перенастройки, а сначала очистить RCC_CFGR_SW в RCC->CFGR, чтобы назначить системным таймером HSI, а не HSE. И не просто бит выставить, а еще и подождать RCC_CFGR_SWS… Вот только к USB это дело никакого отношения не имеет. Судя по значениям RCC->CR и RCC->CFGR, тактирование у меня правильно настроено: RCC->CR=0x03035583 (PLL on and ready, HSE on and ready, HSICAL=0x55, HSITRIM=0x10, HSI on and ready), а RCC->CFGR=0x001d0404a (PLLMUL=0b111 - x9, PLLSRC=HSE, PPRE1=PLL/2, HSE selected and used as sysclock). То бишь частота USB в полтора раза ниже, составляя 48МГц. А вот какого ляда оно не работает с полностью перенесенным из F103 кодом (за исключением названия прерывания и инициализации подтяжки) - ХЗ..
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Надо на будущее накатать макрос какой-нибудь, чтобы не было таких приколов, что я ноги 11 и 12 нумерую в H-регистре как 4 и 5! USB заработал.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Действительно, PLL нужно было не просто отключить для перенастройки, а сначала очистить RCC_CFGR_SW в RCC->CFGR, чтобы назначить системным таймером HSI, а не HSE.
Каким образом он у тебя включенным оказался? По ресету у тебя включен только HSI и от него всё затактировано. Включаешь HSE и ждёшь пока запустится, конфигурируешь PLL, включаешь PLL и ждёшь пока запустится, переключаешься на PLL. Всё - мат в три хода. Как ты без куба так наблудить то умудряешься?
А насчёт конфигурации ног... Я когда на форуме вижу примеры/вопросы со всеми этими манипуляциями битами MODER-ов, то аж передёргивает. С этим надо что-то делать любым доступным тебе способом.
Даже с оптимизацией -O3 он пишет именно так вместо bic.w r2, r2, 0xc3c00000
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
