-
Постов
2 694 -
Зарегистрирован
-
Победитель дней
2
Весь контент repstosw
-
Вам спасибо персонально! :) С ваших слов понял, что секция и регион -не одно и тоже
-
Убрал эту противную ошибку. Теперь при открытии проекта всё хорошо! Так что работать в WinXP + Keil 5.16 + H743 можно)) Нужно было удалить message с pdsc-файла. Рисунок ниже.
-
Разобрался. Ошибка была в том, что сделал регионы, но секции не засунул. Потому что считал что регион=секция. Оказалось сложнее. Получилось вот так: ; Scatter-Loading Description File LR_FLASH 0x08000000 0x00200000 { ER_FLASH 0x08000000 0x00200000 { *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } DTCM 0x20000000 0x00020000 { *.o (DTCM) } AXI 0x24000000 0x00080000 { .ANY (+RW +ZI) } SRAM12 0x30000000 0x00040000 { *.o (SRAM12) } SRAM3 0x30040000 0x00008000 { *.o (SRAM3) } ; SRAM4 0x38000000 0x00010000 ; { ; *.o (SRAM4) ; } } Я доволен : всё пихается куда надо и работает :)
-
Собственно, что мы затеваем: http://vrtp.ru/index.php?showtopic=30174&st=0& Но хочется большего :)
-
ок, попробую разобраться
-
Как вариант - играть чип-тюны :) Гуглить 2A03, Adlib, OPL2/3. Исходников масса
-
Выше я дал пример (который почему-то все проигнорировали), что размещение в секции - ещё не гарантирует фактического туда попадания. Поэтому размещение по конкретному адресу - способ надёжнее
-
Объявил переменную в секции SRAM3: u8 AudioBuffer[1024] __attribute__((section("SRAM3"))); Скаттер-файл: LR_IROM1 0x08000000 0x00200000 { ; load region size_region ER_IROM1 0x08000000 0x00200000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } DTCM 0x20000000 0x00020000 { ; RW data } AXI 0x24000000 0x00080000 { ; RW data .ANY (+RW +ZI) } SRAM12 0x30000000 0x00040000 { ; RW data .ANY (+RW +ZI) } SRAM3 0x30040000 0x00000008 { ; RW data .ANY (+RW +ZI) } SRAM4 0x38000000 0x00010000 { ; RW data } } Из скаттера видно, что секция SRAM3 всего 8 байт, а надо 1024. Тем не менее, линковка успешна! Вопрос - почему? Какого чёрта линковщик засунул переменную AudioBuffer в другую область памяти? Что я сделал не так? выдержка из МАР-файла. точно, вообще в другую секцию засунул! как победить урода? (Keil) или только через : 1) u8 *AudioBuffer=(u8*)0x30040000; 2) u8 AudioBuffer[1024] __attribute__((at(0x30040000))); ?
-
Три способа: 1) Сделать в линкере секцию и через #pragma section объявлять массив 2) Так же как вы написали : char Buffer[1024] __attribute__((at(0x38800000))); 3) char *Buffer=(char*)0x38000000; Обращаться Buffer=j;
-
OK, спасибо. Попутно ещё обнаружил, что для DAC DMA с памятью 0x20000000 не работает, только с 0x24000000
-
1) нет внятных доков по его программированию. Хотя бы на уровне reference manual-ов как у STM 2) нет практических примеров использования (на уровне микроконтроллеров) 3) Application-ориентирование, а не Microcontroller. Это значит - Only for Linux, Only for Android, under Linux, Under Android. 4) Слишком сложное внутреннее устройство (без 1) -реверс черного ящика). В Linux BSP освещены не все моменты. Хотя бы банально - работы с TCON0 через i8080 bus я не нашёл. В частности, как расставлять времянки по сигналам D, A, CS, WR, RD, WAIT. Всё мощно! :rolleyes: Получилось работать с FMC + LCD и через адреса с 0x60000000. С помощью MPU запрещаем кеширование данного адресного региона и работаем: static void MPU_Conf(void) { MPU_Region_InitTypeDef MPU_InitStruct; HAL_MPU_Disable(); MPU_InitStruct.Enable=MPU_REGION_ENABLE; MPU_InitStruct.BaseAddress = 0x60000000; MPU_InitStruct.Size = MPU_REGION_SIZE_256KB; //256KB если линия A16 и 16-битная шина данных. 128KB если линия A16 и 8-битная шина данных MPU_InitStruct.AccessPermission=MPU_REGION_FULL_ACCESS; MPU_InitStruct.TypeExtField=MPU_TEX_LEVEL0; MPU_InitStruct.IsCacheable=MPU_ACCESS_NOT_CACHEABLE; //для портов ввода-вывода обязательно! MPU_InitStruct.IsBufferable=MPU_ACCESS_BUFFERABLE; MPU_InitStruct.IsShareable=MPU_ACCESS_SHAREABLE; MPU_InitStruct.Number=MPU_REGION_NUMBER0; MPU_InitStruct.SubRegionDisable=0x00; MPU_InitStruct.DisableExec=MPU_INSTRUCTION_ACCESS_ENABLE; HAL_MPU_ConfigRegion(&MPU_InitStruct); HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT); } int main(void) { MPU_Conf(); SCB_EnableICache(); SCB_EnableDCache(); HAL_Init(); .................. Убрать HAL_SetFMCMemorySwappingConfig(FMC_SWAPBMAP_SDRAM_SRAM); , если оно было. И использовать: #define LCD_COM16 (*(volatile unsigned short int*) 0x60000000) #define LCD_DAT16 (*(volatile unsigned short int*) 0x60020000) У меня работает через DMA и через CPU. Единственно, остался невыясненным момент в этих вещах: MPU_InitStruct.IsBufferable=MPU_ACCESS_BUFFERABLE; MPU_InitStruct.IsShareable=MPU_ACCESS_SHAREABLE; Какие бы не ставил значения - все 4 комбинации работают. И прироста/замедления в скорости не заметил. Играют ли они роль в контексте LCD по FMC или нет? Ещё по DMA бурстам вопрос. hdma_memtomem_dma1_stream0.Init.MemBurst = DMA_MBURST_SINGLE; //DMA_MBURST_INC4; hdma_memtomem_dma1_stream0.Init.PeriphBurst = DMA_PBURST_SINGLE; //DMA_PBURST_INC4; SINGLE и INC4 работает DMA + FMC LCD. С бурстами INC8, INC16 - нет. Почему?
-
Готовлю плацдарм для прыжка в будущее :rolleyes: Если быть точным, то у меня чисто академический интерес - пощупать Cortex-M7, посмотреть его достоинства и недостатки.
-
А я и не жду :) ждать - это вообще очень дорогое для меня удовольствие... Потому что время. Поэтому стараемся использовать всё что есть и выкручиваться. А вот в -A7, -A8 лучше не лезть. Пускай они для линуксоидов, андроидов, питонов и прочей нечисти:)
-
Видите ли, в чём дело... Вы со своей колокольни смотрите на проблему. Я же со своей. Тот туннель, что я выкладывал - ну никак не смотрится в 16 цветах - слишком убого. И в 256 цветах тоже будет плохо смотреться. Поэтому было принято решение использовать 65536 цветов. Цель была - перенести алгоритм построения трёхмерного туннеля из этой программы: http://www.sulaco.co.za/opengl_project_racing_tunnel.htm , не угробив при этом цветопередачу текстуры.
-
Сейчас набегут гуру ядра ARM-а и закидают шапками, что мол надо спецификации на Cortex-M7 ядро почитать, так как эта фишка (разграничение регионов адресов на "Device" и "Memory") заложена в самом ядре и К ЭТОМУ НАДО БЫЛО УЖЕ БЫТЬ ГОТОВЫМ! Так что это не глюк, а просто дефолтная установка. Попробую MPU настроить чтобы всё-же классический адрес 0x60000000 работал как "Device" (отключить кеширование этой области, возможно отключить буферизацию и включить shareable). А вот в AT91RM9200 был полноценный MMU - с поддержкой виртуальных адресов. А в STM32H7 нет, и это меня огорчает. Свершилась бы мечта идиота программиста - фрагментированную на куски SRAM сделать одним непрерывным большим массивом данных :) А так прийдётся писать нечто вроде: u16 VideoBuffer[n] __attribute__((at(0x20000000))); u8 SoundBuffer[n] __attribute__((at(0x24000000))); :)
-
2 байта на пиксел. 16bpp. 320x240x2=150 кБ два буфера - уже 300 кБ < 192 кБ в stm32f407 :biggrin:
-
Всё прям как у меня :) После инита FMC сделать: HAL_SetFMCMemorySwappingConfig(FMC_SWAPBMAP_SDRAM_SRAM); и обращаться к дисплею по адресам 0xC0000000 и 0xC0020000.
-
Это просто капец... Эта память жестко специализирована: DTCM - может быть стеком, данными и DMA AXI - тоже самое SRAM1,2,3 - только данными. Никакого ДМА и стека SRAM4 - данные, стек. Никакого ДМА Итого: DTCM и AXI - универсальная память. SRAM 1..4 - нет
-
Там где 24 Гц - это на STM32F407. У него 128+64 кБ памяти, хватает только на один буфер 320x240x2 и то, он реализован кусками! Двойная буферизация в STM32H743. Но там 63 FPS.
-
Память SRAM1,2,3 сидит в регионах 0x30000000...0x30047FFF. Тактирование включил. При попытке туда записать или считать с помощью CPU ни к чему не приводит. Эта память доступна вообще для процессора или нет? Читал манул, так и не понял.
-
24 FPS - это общий FPS: рендеринг картинки в буфер + перекидывание буфера на дисплей, а не чисто-перекидывание на дисплей Если перекидывание буфера на экран через SPI даст 24 FPS, то общий FPS программы упадёт до 10 и меньше.
-
Как оказалось, что сабжевый вариант вполне работоспособный: компиляция, прошивка -всё работает. Правда дебаг недоступен. В целом девелопать можно. Только при запуске выскакивет такое сообщение (игнорировать):
-
Всё просто замечательно! :rolleyes: Подключил дисплей к FMC, настроил времянки. Задействовал кеширование. Вышло 41 FPS. Потом сделал двойную буферизацию, задействовал ДМА память-память. В итоге пока процессор рендерит один кадр, ДМА отправляет на LCD готовый кадр. Путём таких ухищрений удалось выжать 63 FPS. Видео (по сравнению с видео выше с STM32F407, скорость намного выше 63 vs. 24 FPS): http://www.youtube.com/watch?v=4VpX5UfkmWA Исходники для STM32H743 Ниже. Просьба не ругаться(за кало-Куб), нужно было оценить отладочную плату и процессор STM32H743. Tunnel_STM32H743_DMA.rar
-
Вопрос по поводу кеша возник не случайно. Так как раньше было отображение регистров периферии в адресное пространство типа "память", то при включенном кеше данных устройство работало некорректно. Сейчас же при отображении регистров устройства в адресное пространство типа "Device" кеш данных не мешает. Вот инфа, которая расставляет все точки над "I": http://microsin.net/programming/arm/an4838...unit-stm32.html http://microsin.net/programming/arm/an4839...he-stm32f7.html И всё-же я помню, что в AT91RM9200 аттрибут в MMU "Buferable" ускорял работу с периферией. А "Cacheable" приводил к артефактам. Есть ли подобное в H743 ? И почему ж никто не подсказал, что для внешних устройств надо было ремэпнуть банки, так как дефолтные установки ставят тип "память", а не "device"? Про адреса явно же писал. не верю, что с FMC никто не работал.
-
В данном случае калокуб тут не причем. Подосрала сама STM electronix. Ошибка кривая и аппаратная. Проблему решил, работает по крайней мере на внешней SRAM: https://electronix.ru/forum/index.php?s=&am...t&p=1571320 Сейчас осталось вернуться LCD и раскочегарить 3D-туннель на 400 МГц при включенных кешах. Нужно ли включать кеширование кода и данных, если программа выполняется во встроенной Flash контроллера? Как запретить кешировать регион памяти для LCD, но оставить буферизацию? В AT91RM9200 делал это с помощью MMU, а тут как? P.S. Я - не сторонник кало-куба, пока его использую, так как только начал знакомиться с STM32H743. И очень жаль, что SPL нет, как это было в F407 :( Прийдется распиливать HAL и разбавлять с даташитами :) И почему тогда в сети куча примеров под кало-куб, а на регистрах нет нигде примеров?