Только недавно начали работать с процессором LH75401. Купили отладочную плату Zoom SDK, подключили TFT LQ084V1DG21 (640x480, цвет).
Написал простую программу, кокторая иницилизирует LCD-контроллер процессора (640х480, 8-битный цвет по палитре) и затем в вечном цикле заполняет весь видеобуффер каким-то значением (на экране видим заливку всего экрана одним цветом). При этом оказалось, что для того, чтобы заполнить весь видеобуффер (640*480 = 307200 байт) требуется около 0,1875 сек, т.е. скорость обновления экрана около 5,3 fps, скорость, с которой значения пишутся в ОЗУ около 1638400 байт/с.
В чем может быть проблема? Если не ошибаюсь, все должно работать в несколько раз быстрее. Может быть что-то недоинициализировал?
- Кварц: 20 МГц.
- Содержимое SysClk Prescaler Register: 0x00000001, т.е. System clock = (XTALIN frequency × 7)/(2 × SysClkPrescaler) = 70 МГц.
- Обращение к памяти происходит без циклов ожидания, т.е. содержимое регистров BCR0 - BCR4 = 0x10000400.
- Код выполняется из ОЗУ.
Полная версия этой страницы: Sharp LH75401 проблемы со скоростью
У Sharp на сайте есть экселевская табличка под названием "lh79520_performance_calculator". Из нее следует, что при экране 640 * 480 * 8 бит, требуется передать на индикатор 25 мегапиксел в секунду. А поскольку видеопамять совмещена с основной памятью, то данный поток "отедается" от выборок памяти программ/данных. Т.е. процессор как бы работает на меньшей скорости (вернее шина памяти). Согласно той-же таблички, LH79520 с 32 битной памятью и частотой 75 МГц (шина 50 МГц) работает на эквивалентной частоте ~29 МГц.
А поскольку у Вас шина 16 бит, то похоже числа правильные. Ведь процессору нужно выбрать команду (32 бита по 16 бит шине), потом записать в видеопамять и т.д. ... И это все на фоне нехилого потока данных на индикатор.
А поскольку у Вас шина 16 бит, то похоже числа правильные. Ведь процессору нужно выбрать команду (32 бита по 16 бит шине), потом записать в видеопамять и т.д. ... И это все на фоне нехилого потока данных на индикатор.
У меня тоже такая же плата! Все действительно тормозит.
Единтсвенное чем можно ускорить (причем здорово ускорить) - выполнять код из внутренней памяти
причем не важно из какой части ( у меня даже из TCM чуть медленне получилось, но не принципиально)
Единтсвенное чем можно ускорить (причем здорово ускорить) - выполнять код из внутренней памяти
причем не важно из какой части ( у меня даже из TCM чуть медленне получилось, но не принципиально)
Народ, вы не забывайте, что у lh79520 SDRAM, и он burst делать умеет. Так что в варианте статики, да еще и 16 битной (а какая статика стоит на плате с LH75401?) все будет очень тоскливо. 
Я приводил результат для SRAM, burst 8 Words и, самое главное (!) с учетом кэша - cashe hit 85%!
Для 75401 все действительно более тоскливо
. Да и сам шарп позиционирует данный контроллер максимум для индикатора 320 *240 при 4 бит (8 бит предел) - где-то видел подобную информацию.
Для 75401 все действительно более тоскливо
. Да и сам шарп позиционирует данный контроллер максимум для индикатора 320 *240 при 4 бит (8 бит предел) - где-то видел подобную информацию.
Спасибо за ответы. Не радостные новости. У меня еще вопрос.
Прошу не пинать сильно ногами, если задаю глупые вопросы, просто до этого работал только с AVR и компилировал только IARом, а сейчас приходится переходить на ARM + GCC. Неожиданно процесс перехода оказался болезненным.
Каким образом можно заставить выполняться код программы из флэш-памяти, а переменные хранить в ОЗУ? Процессор поддерживает четыре банка памяти, причем по адресу 0x40000000 начинается флеш, по адресу 0x48000000 - начинается ОЗУ. В начале флеш памяти прошит загрузчик. Имеется набор примеров исходников от Sharp, код которых должен выполняться из ОЗУ. Сценарий линковщика выглядит следующим образом:
Программа собранная таким образом нормально принимается загрузчиком и без проблем запускается из ОЗУ. Пытаюсь модифицировать сценарий следующим образом:
Если попытаться отдать полученный elf загрузчику, то получаю следующее сообщение:
В чем может быть проблема? Объясните, что я делаю не так?
Есть в наличии также пример программы, которая ложится во флэш, но при старте копирует себя в ОЗУ и выполняется оттуда. Это мне не совсем подходит. Хотелось бы выполнять код и хранить константы именно во флеше, не вытаскивая их в ОЗУ.
Прошу не пинать сильно ногами, если задаю глупые вопросы, просто до этого работал только с AVR и компилировал только IARом, а сейчас приходится переходить на ARM + GCC. Неожиданно процесс перехода оказался болезненным.
Каким образом можно заставить выполняться код программы из флэш-памяти, а переменные хранить в ОЗУ? Процессор поддерживает четыре банка памяти, причем по адресу 0x40000000 начинается флеш, по адресу 0x48000000 - начинается ОЗУ. В начале флеш памяти прошит загрузчик. Имеется набор примеров исходников от Sharp, код которых должен выполняться из ОЗУ. Сценарий линковщика выглядит следующим образом:
Код
/* bla-bla-bla */
/*
* Define the memory layout for the board
*/
SECTIONS
{
. = 0x480C0000;
/* Define a load region that resides at ram base */
.text :
{
PROVIDE(__text_start = .);
}
. = ALIGN(4);
.lr_rom :
{
sdk75401_startup.o (.text);
sdk75401_crt0.o (.text);
sdk75401_relocate.o (.text);
sdk75401_relocate_init.o (.text);
sdk75401_mem_sections.o (.text);
*(.rodata);
PROVIDE (__roend = .);
}
. = ALIGN(4);
.lr_sram :
{
* (.text);
}
. = ALIGN(4);
.data :
{
/* .data section */
PROVIDE (__data_sram_start = .);
*(.data);
/* .bss region start - execution address */
PROVIDE (__bss_sram_start = .);
*(.bss)
PROVIDE (__bss_sram_end = .);
}
. = ALIGN(4);
PROVIDE (end = .);
PROVIDE (__end = .);
}
/*
* Define the memory layout for the board
*/
SECTIONS
{
. = 0x480C0000;
/* Define a load region that resides at ram base */
.text :
{
PROVIDE(__text_start = .);
}
. = ALIGN(4);
.lr_rom :
{
sdk75401_startup.o (.text);
sdk75401_crt0.o (.text);
sdk75401_relocate.o (.text);
sdk75401_relocate_init.o (.text);
sdk75401_mem_sections.o (.text);
*(.rodata);
PROVIDE (__roend = .);
}
. = ALIGN(4);
.lr_sram :
{
* (.text);
}
. = ALIGN(4);
.data :
{
/* .data section */
PROVIDE (__data_sram_start = .);
*(.data);
/* .bss region start - execution address */
PROVIDE (__bss_sram_start = .);
*(.bss)
PROVIDE (__bss_sram_end = .);
}
. = ALIGN(4);
PROVIDE (end = .);
PROVIDE (__end = .);
}
Программа собранная таким образом нормально принимается загрузчиком и без проблем запускается из ОЗУ. Пытаюсь модифицировать сценарий следующим образом:
Код
/* bla-bla-bla */
/*
* Define the memory layout for the board
*/
SECTIONS
{
. = 0x400C0000;
/* Define a load region that resides at ram base */
.text :
{
PROVIDE(__text_start = .);
}
. = ALIGN(4);
.lr_rom :
{
sdk75401_startup.o (.text);
sdk75401_crt0.o (.text);
sdk75401_relocate.o (.text);
sdk75401_relocate_init.o (.text);
sdk75401_mem_sections.o (.text);
*(.rodata);
PROVIDE (__roend = .);
}
. = ALIGN(4);
.lr_sram :
{
* (.text);
}
/*Данные будем хранить в ОЗУ*/
. = 0x480С0000;
.data :
{
/* .data section */
PROVIDE (__data_sram_start = .);
*(.data);
/* .bss region start - execution address */
PROVIDE (__bss_sram_start = .);
*(.bss)
PROVIDE (__bss_sram_end = .);
}
. = ALIGN(4);
PROVIDE (end = .);
PROVIDE (__end = .);
}
/*
* Define the memory layout for the board
*/
SECTIONS
{
. = 0x400C0000;
/* Define a load region that resides at ram base */
.text :
{
PROVIDE(__text_start = .);
}
. = ALIGN(4);
.lr_rom :
{
sdk75401_startup.o (.text);
sdk75401_crt0.o (.text);
sdk75401_relocate.o (.text);
sdk75401_relocate_init.o (.text);
sdk75401_mem_sections.o (.text);
*(.rodata);
PROVIDE (__roend = .);
}
. = ALIGN(4);
.lr_sram :
{
* (.text);
}
/*Данные будем хранить в ОЗУ*/
. = 0x480С0000;
.data :
{
/* .data section */
PROVIDE (__data_sram_start = .);
*(.data);
/* .bss region start - execution address */
PROVIDE (__bss_sram_start = .);
*(.bss)
PROVIDE (__bss_sram_end = .);
}
. = ALIGN(4);
PROVIDE (end = .);
PROVIDE (__end = .);
}
Если попытаться отдать полученный elf загрузчику, то получаю следующее сообщение:
Код
losh> load elf
loading from stdin:
F.mh data is incorrect for > 1 program header(!)
elf file type : 0x0002
machine type: 0028 version: 1
prog start addr : 0x400c0000
num prog headers: 3
num sect headers: 19
offset : 0x2a2a2a00 disk length: 0x00000094 mem len: 0x480c0000
phyaddr: 0x8ee20000 vaddr : 0x0a0d2a03 dl addr: 0x480c0000
elf load failed.
ignoring rest of file... 69561 bytes.done
losh>
loading from stdin:
F.mh data is incorrect for > 1 program header(!)
elf file type : 0x0002
machine type: 0028 version: 1
prog start addr : 0x400c0000
num prog headers: 3
num sect headers: 19
offset : 0x2a2a2a00 disk length: 0x00000094 mem len: 0x480c0000
phyaddr: 0x8ee20000 vaddr : 0x0a0d2a03 dl addr: 0x480c0000
elf load failed.
ignoring rest of file... 69561 bytes.done
losh>
В чем может быть проблема? Объясните, что я делаю не так?
Есть в наличии также пример программы, которая ложится во флэш, но при старте копирует себя в ОЗУ и выполняется оттуда. Это мне не совсем подходит. Хотелось бы выполнять код и хранить константы именно во флеше, не вытаскивая их в ОЗУ.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.