К1921ВГ015 общее

[fog]

А я пока отложил все, пока не будет хоть какого-то прогресса от производителя ...

[RabidRabbit]

День добрый.
В файле https://gitflic.ru/project/niiet/niiet_ ... nch=master есть следующая настройка для HSE 24 МГц и PLLOUT 50/30 МГц:

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

#elif (HSECLK_VAL == 24000000)
// Fout0 = 50 000 000 Hz
// Fout1 = 30 000 000 Hz
    RCU->PLLSYSCFG0 =( 7 << RCU_PLLSYSCFG0_PD1B_Pos) |  //PD1B
                     ( 4 << RCU_PLLSYSCFG0_PD1A_Pos) |  //PD1A
                     ( 2 << RCU_PLLSYSCFG0_PD0B_Pos) |  //PD0B
                     ( 3 << RCU_PLLSYSCFG0_PD0A_Pos) |  //PD0A
                     ( 2 << RCU_PLLSYSCFG0_REFDIV_Pos)       |  //refdiv
                     ( 0 << RCU_PLLSYSCFG0_FOUTEN_Pos)    |  //fouten
                     ( 0 << RCU_PLLSYSCFG0_DSMEN_Pos)     |  //dsmen
                     ( 0 << RCU_PLLSYSCFG0_DACEN_Pos)     |  //dacen
                     ( 3 << RCU_PLLSYSCFG0_BYP_Pos)       |  //bypass
                     ( 1 << RCU_PLLSYSCFG0_PLLEN_Pos);       //en
    RCU->PLLSYSCFG1 = 0;          //FRAC = 0                     
    RCU->PLLSYSCFG2 = 65;         //FBDIV

На первый взгляд не "бьётся" с формулами из документации. Если подставить значения в формулы, получается:
fVCO = 24000000 * 65 / 2 = 780000000
fOUT0 = 780000000 / ((3 + 1) * (4 + 1)) = 39000000
fOUT1 = 780000000 / ((2 + 1) * (7 + 1)) = 32500000
В моём калькуляторе получается REFDIV = 1, FBDIV = 25, FRAC = 0, A0 = 0, B0 = 11, A1 = 0, B = 19
Или я что-то, как обычно, упускаю

[ejsan]

Подозреваю, что все такие тонкие нюансы проистекают из-за того, что мы пользуем сборку от Syntacore, заточенную, соответственно, под особенности ядра их собственной разработки. Но в недрах ВГ015 прячется CloudBear, посему мы и получаем кривую оптимизацию. И в целом, это странно, что, по сути, производитель чипа предлагает нам не совсем то, что нужно! А нужно было бы предложить или тулчейн от CloudBear (кстати, а такие бывают? Или как, бывают, но уже не бесплатно?), или так, как делают всякие китайцы вроде WCh - "generic" версия GCC под самый базовый набор RISC-V, безо всяких специфических оптимизаций.

[RabidRabbit]

Исключение вызывает сама malloc

А кто у Вас собственно ecall обрабатывает? Вы попадаете в trap_handler собственно по команде вызова "ОС" (MCAUSE_EXCEPT_ECALLFRM_M_MODE), а никакой "ОС" у Вас вроде и нет.

[RabidRabbit]

Подозреваю, что все такие тонкие нюансы проистекают из-за того, что мы пользуем сборку от Syntacore, заточенную, соответственно, под особенности ядра их собственной разработки. Но в недрах ВГ015 прячется CloudBear, посему мы и получаем кривую оптимизацию.

Собираю "штатным" компилятором из комплекта riscv64-unknown-elf (под Debain 12), который ни на что не заточен Все "заточки" - указать в ключах компиляции поддерживаемые ядром расширения. Вроде всё норм.

[fog]

На первый взгляд не "бьётся" с формулами из документации.

Там от балды все написано.

а никакой "ОС" у Вас вроде и нет.

Нету, для других МК с "коробки" все работает без оси, а тут свой менеджер памяти писать, этим я еще не занимался...

[RabidRabbit]

Там от балды все написано.

По остальным вроде правильно Прилагаю свой "калькулятор" https://gitflic.ru/project/rabidrabbit/ ... nch=master, на входе частота HSE и требуемая частота на выходе блока PLL, само считает всё остальное.

Нету, для других МК с "коробки" все работает без оси, а тут свой менеджер памяти писать, этим я еще не занимался...

Менеджер писать не надо. Тут при обработке ecall достаточно отработать функционал вызова sbrk(), который просто увеличивает "выделенную" память, т.е. минимально проконтролировать только, что не залезли на область стека. Вот тут https://stackoverflow.com/questions/698 ... em-call-do хорошо описано.

[Vcoder]

Где можно почитать про "стандартные" функции RISC-V ядра, не описанные в документации на К1921ВГ015? В частности про mtimer и обработку его прерываний, регистры mie, mstatus и др. Применительно к ВГ015 естественно.

В РП К1921ВГ015 (актуальная сейчас версия от 05.06.2025) в разделе 9.5 "Программная модель обработки внешних прерываний" есть ссылки "см. [3]", но я не нашёл в документе списка ссылок на источники. Плохо искал? Подскажите пожалуйста, где взять этот список.

[ejsan]

Где можно почитать про "стандартные" функции RISC-V ядра, не описанные в документации на К1921ВГ015?

Может, покопаться в документации от самих CloudBear? https://tools.cloudbear.ru/docs/
Кстати, делал на mtimer-е простой delay_ms(), просто взяв какой-то пример от Gigadevice что-ли, уже даже не помню. Но всё заработало. Видимо, этот таймер везде одинаковый.

[Vcoder]

Может, покопаться в документации от самих CloudBear? https://tools.cloudbear.ru/docs/

Спасибо за наводку. Нашёл описание интересующих регистров в документах "riscv-privileged". Осталось понять, какой из двух относится к нашему МК.

Но что скрывается за ссылкой "[3]" в РП К1921ВГ015 всё равно интересно.