Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Помогите определиться с камнем, дисплеем и пр.
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2, 3
aaarrr
Цитата(zheka @ Dec 8 2011, 07:46) *
Я в 65 ноги пытался уложиться, а вы вмне 208 ногого монстра. ДА еще небось BGA.

Количество ног - тоже самоцель? BGA208 займет примерно столько же места, что и QFP64.

Цитата(zheka @ Dec 8 2011, 07:46) *
от 600 до 1050 рублей за штуку? Супротив 200 рублей за STM?

Где вы цены-то такие берете?
-=Женек=-
Цитата
Я правильно понял, что низкая скорость NANDFlash? Тогда видимо при включении вы собираетесь все картинки загрузить из NANDFlash в SDRAM?


Да потому что из NANDFlash в SDRAM,будет грузиться хоть и дольше 15 мсек, но все же быстро. Я этой загрузки не почуствую. А вот если выводить сразу на экран более чем за 15 мсек, будет Tearing Effect, хоршо заметный глазу. А так - загружу по быстрому в SDRAM и мгновенно (не более чем за 15 мсек) выведу на экран .

Цитата
Количество ног - тоже самоцель? BGA208 займет примерно столько же места, что и QFP64.


BGA - придется многослойку заказывать, да и макетку в домашних условиях не сделаешь.
Цитата
Где вы цены-то такие берете?

А где бы ни брал - дешевый в 3-5 раз STM беру там же.


efind.ru и конкретно мой поставщик deltel.ru
Qwertty
Вообще то LPC1787FBD208 в QFP, а не в BGA. Но видимо это не важно. Решение то все равно принято похоже. Зачем тогда вообще ветку было создавать?
Можно было брать вообще любой контроллер, лишь бы ног хватило. Можно еще CPLD поставить на переброс SDRAM->LCD. Какой нибудь EPM240 за 4$. И выжать абсолютный максимум FPS.
-=Женек=-
Qwerty, не нервничайте. Я из ветки извлек максимум информации.

Уже давно пора бы понять, что я принял решение по двум вещам - хочу дешевый дисплей и хочу SDRAM. ПО своим причинам. Эти две вещи, как справедливо кто-то заметил, делают наиболее оптимальным именно ногодрыг.

Меня могли бы разубедить люди, ответившие с какой скоростью с помощью FSMC можно читать данные из NAND, но люди, вроде бы разбирающиеся в контроллерах не могут ответить на этот вопрос уже несколько дней. ТОгда сколько времени мне, любителю, понадобится на то чтобы разобраться с FSMC? 3 месяцйа? Оно мне надо? Если ногодрыгом я получу нужную мне скорость и все у меня заработает через день? Дорогущий камень - оно мне надо? Если бы я собирал единичный эксземпляр, тогда да.
Но мне приходится и деньги считать.

Я понимаю, решение выглядит корявым, но именно к такому я пришел и убедительных контраргументов, которые я, видит бог, очень хочу услышать - не поступило.
aaarrr
Цитата(-=Женек=- @ Dec 8 2011, 21:32) *
Меня могли бы разубедить люди, ответившие с какой скоростью с помощью FSMC можно читать данные из NAND, но люди, вроде бы разбирающиеся в контроллерах не могут ответить на этот вопрос уже несколько дней. ТОгда сколько времени мне, любителю, понадобится на то чтобы разобраться с FSMC? 3 месяцйа?

FSMC простой как грабли. Чтобы подсчитать скорость, нужно:
1. взять даташит на конкретную NAND, извлечь из него время считывания страницы и тайминги интерфейса
2. последние прикинуть на FSMC
3. провести нехитрые операции сложения и умножения
Ничего сложного, но никто за вас этого делать не будет.
-=Женек=-
Цитата
Ничего сложного, но никто за вас этого делать не будет.

Упаси бог меня просить за кого-то что-то сдщелать.
Интересовал опыт.
aaarrr
Цитата(-=Женек=- @ Dec 8 2011, 22:11) *
Интересовал опыт.

Этот опыт, даже если он найдется, затруднительно будет перенести в другие условия. Скорости различных NAND-флеш и контроллеров экранов отличаются в разы. Поэтому и нужно заниматься подсчетами исходя из характеристик реального железа.
AndreyKar
Может вопрос не в тему, но: почему разработчики ЕвалБордов ставят внешнее АЦП для тачпанелей экрана? Чем их внутреннее АЦП не устраивает?
aaarrr
Цитата(AndreyKar @ Dec 9 2011, 15:59) *
Может вопрос не в тему, но: почему разработчики ЕвалБордов ставят внешнее АЦП для тачпанелей экрана? Чем их внутреннее АЦП не устраивает?

Во многих случаях это просто проявление косности мышления, ИМХО.
ViKo
Цитата(AndreyKar @ Dec 9 2011, 14:59) *
Может вопрос не в тему, но: почему разработчики ЕвалБордов ставят внешнее АЦП для тачпанелей экрана? Чем их внутреннее АЦП не устраивает?

Тем, что внутренний АЦП пользователь может задействовать для чего-то своего, жизненно необходимого.
Dron_Gus
Не все встроенные АЦП умеют драйвить панель.
aaarrr
Цитата(Dron_Gus @ Dec 10 2011, 13:36) *
Не все встроенные АЦП умеют драйвить панель.

Ну, это решается при помощи GPIO, если что.
-=Женек=-
Вот собственно статистика загрузки картинок из аппноута.
В моем случае будет на 25% медленнее.

Получается что без проблем с tearing effect из NANDFlash можно грузить картинку не больше чем 100х200.


Таким образом, учитывая, что я хочу при случае мгновенную смену ихображения на экране без tearing эффекта, SDRAM я буду рулить ногодрыгом, дислпеем - тоже ногодрыгом, иначе быстро из SDRAM информацию не передашь. Ну а NAND, дабы проше было с ним работать - c помощью FSMC.

По-моему - максимально оптимально учитывая мои пожелания и учитывая исполоьзуемый контроллер.
011119xx
Цитата(-=Женек=- @ Dec 10 2011, 20:57) *
Вот собственно статистика загрузки картинок из аппноута.
В моем случае будет на 25% медленнее.

Это таблица из аппноута. Приведи цифры полученные тобой.
-=Женек=-
Приводить пока нечего. КОнтроллер едет. Склонен верить аппноуту
011119xx
Цитата(-=Женек=- @ Dec 12 2011, 08:48) *
Склонен верить аппноуту

Надо еще добиться таких показателей.
Dron_Gus
Цитата(aaarrr @ Dec 10 2011, 14:08) *
Ну, это решается при помощи GPIO, если что.

Согласен. Но это уже на любителя.
MasterCat
Цитата(AndreyKar @ Dec 9 2011, 17:59) *
Может вопрос не в тему, но: почему разработчики ЕвалБордов ставят внешнее АЦП для тачпанелей экрана? Чем их внутреннее АЦП не устраивает?


тоже задался этим вопросом. в спциализированной таракашке схема выборки хранения не случайна. после борьбы с помехами и пр, оказалось дешевле взять заточенную под это мелкосхему. рвемя потрачено будет много больше и ради чего?


maksimp
Цитата(-=Женек=- @ Dec 10 2011, 18:57) *
Вот собственно статистика загрузки картинок из аппноута.

Какого аппноута? Можно ссылку?
011119xx
Как идут испытания выбранного камня и дисплея?
011119xx
Хотелось бы оживить тему. Вопрос остается в силе. Что показали испытания камня и дисплея? Как никак уже скоро год будет, очень интересно ознакомиться с полученными данными.
Falkon_99
Дисплей от Nokia6300 можно легко прикрутить к STM, там тот же интерфейс 8080. И модель телефона популярная, не пропадет через 5 лет, и цена дисплея удовлетворительная 4$
Lost_Viking
Че-то я не понимаю =). камень STM32F103VET6
CODE
fsmcTiming.FSMC_AddressSetupTime = 0x00;
fsmcTiming.FSMC_AddressHoldTime = 0x00;
fsmcTiming.FSMC_DataSetupTime = 0x01;
fsmcTiming.FSMC_BusTurnAroundDuration = 0x00;
fsmcTiming.FSMC_CLKDivision = 0x01;
fsmcTiming.FSMC_DataLatency = 0x00;
fsmcTiming.FSMC_AccessMode = FSMC_AccessMode_A;

fsmc.FSMC_Bank = FSMC_Bank1_NORSRAM1;
fsmc.FSMC_DataAddressMux = FSMC_DataAddressMux_Disable;
fsmc.FSMC_MemoryType = FSMC_MemoryType_SRAM;
fsmc.FSMC_MemoryDataWidth = FSMC_MemoryDataWidth_16b;
fsmc.FSMC_BurstAccessMode = FSMC_BurstAccessMode_Disable;
fsmc.FSMC_WaitSignalPolarity = FSMC_WaitSignalPolarity_Low;
fsmc.FSMC_WrapMode = FSMC_WrapMode_Disable;
fsmc.FSMC_WaitSignalActive = FSMC_WaitSignalActive_BeforeWaitState;
fsmc.FSMC_WriteOperation = FSMC_WriteOperation_Enable;
fsmc.FSMC_WaitSignal = FSMC_WaitSignal_Disable;
fsmc.FSMC_ExtendedMode = FSMC_ExtendedMode_Disable;
fsmc.FSMC_WriteBurst = FSMC_WriteBurst_Disable;
fsmc.FSMC_ReadWriteTimingStruct = &fsmcTiming;
fsmc.FSMC_WriteTimingStruct = &fsmcTiming;

FSMC_NORSRAMInit(&fsmc);
FSMC_NORSRAMCmd(FSMC_Bank1_NORSRAM1, ENABLE);

Такая вот инициализация. Порты на 50МГц. Дисплей 320х240. 12 бит на пиксель. Если кручу в main'е такой код:
Код
  
while(1)
{
      
for (max=0;max<76800;max++)
{
*(uint16_t *) (LCD_DATA)=y;
}
y++;
}

То частота кадров равна примерно 21 кадр в секунду.Частоту кадров смотрю по осциллографу: на один кадр приходится 1 цвет, и по этому смотрю поведение младшего бита. Он "тикает" с частотой кадров.
Если вызываю из прерывания по таймеру (настроен на сколько-то там мегагерц, что бы получить 25гц кадровую), то частота кадров становится еще ниже.

Вопрос: это с чего это вдруг так сильно пыжится процессор? Как повысить частоту кадров?
aaarrr
Цитата(Lost_Viking @ Apr 9 2014, 11:48) *
Если вызываю из прерывания по таймеру (настроен на сколько-то там мегагерц, что бы получить 25гц кадровую), то частота кадров становится еще ниже.

Сколько-то там - это сколько? И что получится, если разделить частоту ядра на эти мегагерцы?

Цитата(Lost_Viking @ Apr 9 2014, 11:48) *
Вопрос: это с чего это вдруг так сильно пыжится процессор? Как повысить частоту кадров?

Листинг ассемблерный прежде всего посмотрите.
Lost_Viking
Цитата(aaarrr @ Apr 9 2014, 12:28) *
Сколько-то там - это сколько? И что получится, если разделить частоту ядра на эти мегагерцы?

biggrin.gif Да я уже не помню сколько там миллионов... 320*240*25 = пикселей/сек . Реально работает не быстрее... около 8.33 кадров в секунду если включать цикл for, и около 10 кадров в секунду, если просто перебирать цвета по каждой точке.
Цитата(aaarrr @ Apr 9 2014, 12:28) *
Листинг ассемблерный прежде всего посмотрите.

Код
   554:     while(1)
   555:     {
   556:            
0x0800142C E016      B        0x0800145C
   557: for (max=0;max<76800;max++)
   558: {
0x0800142E 2000      MOVS     r0,#0x00
0x08001430 4911      LDR      r1,[pc,#68]; @0x08001478
0x08001432 6008      STR      r0,[r1,#0x00]
0x08001434 E008      B        0x08001448
   559: *(uint16_t *) (LCD_DATA)=y;
   560: }
0x08001436 4811      LDR      r0,[pc,#68]; @0x0800147C
0x08001438 8800      LDRH     r0,[r0,#0x00]
0x0800143A 4909      LDR      r1,[pc,#36]; @0x08001460
0x0800143C 8008      STRH     r0,[r1,#0x00]
0x0800143E 480E      LDR      r0,[pc,#56]; @0x08001478
0x08001440 6800      LDR      r0,[r0,#0x00]
0x08001442 1C40      ADDS     r0,r0,#1
0x08001444 490C      LDR      r1,[pc,#48]; @0x08001478
0x08001446 6008      STR      r0,[r1,#0x00]
0x08001448 480B      LDR      r0,[pc,#44]; @0x08001478
0x0800144A 6800      LDR      r0,[r0,#0x00]
0x0800144C F5B03F96  CMP      r0,#0x12C00
0x08001450 DBF1      BLT      0x08001436
   561:         y++;
0x08001452 480A      LDR      r0,[pc,#40]; @0x0800147C
0x08001454 6800      LDR      r0,[r0,#0x00]
0x08001456 1C40      ADDS     r0,r0,#1
0x08001458 4908      LDR      r1,[pc,#32]; @0x0800147C
0x0800145A 6008      STR      r0,[r1,#0x00]

Далее идет отсыл по условию while(1)
Если работа по прерыванию, то добавляется еще несколько команд. Сброс флага - как минимум одна команда.
p.s. кварц на 8МГц, в stm32f10x.h раздевайнена строка для HD линии, и собственно выставлен кварц на 8МГц.
p.p.s как я понимаю, процессорное время тратится на выполнение этих команд. Но как же тогда люди добиваются 25 кадров в секунду, при этом проц работает на частоте 72МГц , и разрешенка у них не ниже моей? Или я чего-то упустил в форуме?
aaarrr
Оптимизацию включите. И добавьте volatile к uint16_t в строке
Код
*(uint16_t *) (LCD_DATA)=y;


Цитата(Lost_Viking @ Apr 9 2014, 13:03) *
biggrin.gif Да я уже не помню сколько там миллионов... 320*240*25 = пикселей/сек .

Много успеет процессор, если у него между прерываниями 72M/(320*240*25)=37.5 тактов?
Lost_Viking
Цитата(aaarrr @ Apr 9 2014, 13:22) *
Оптимизацию включите. И добавьте volatile к uint16_t в строке
Код
*(uint16_t *) (LCD_DATA)=y;



Много успеет процессор, если у него между прерываниями 72M/(320*240*25)=37.5 тактов?


Да о том и речь. Или мне показалось, что тут на форуме на 72МГц делали для 320х240 развертку в 25Гц , и даже более ?
aaarrr
Сделать можно, но уж точно не прерываясь на каждый пиксель. Делайте прерывание с периодом строки, в нем загружайте одну строку с максимально допустимой скоростью.
Lost_Viking
Цитата(aaarrr @ Apr 9 2014, 14:11) *
Сделать можно, но уж точно не прерываясь на каждый пиксель. Делайте прерывание с периодом строки, в нем загружайте одну строку с максимально допустимой скоростью.

Так я и так не использую прерывание . Точки рисую в основном цикле программы . Выше 21 кадра в сек не было .
Я понимаю, что работать надо с DMA. Но опять же: скорость обновления информации в памяти будет на уровне 20кадров в сек. А то и меньше, если будут промежуточные расчеты. Как быть?
aaarrr
Оптимизацию включили?
Lost_Viking
Цитата(aaarrr @ Apr 9 2014, 15:18) *
Оптимизацию включили?

Не успел. Завтра гляну.В Keil вроде бы по дефолту стоит оптимизация. Да и что она даст? 1920000 пикселей в сек все равно придется через процессор перелопачивать, а это как минимум 1920000 операций в секунду, не думаю что как-то можно что-то сделать, если , допустим я хочу еще читать данные из ацп, фильтровать их через фильтр ЭСС (а там коэффициент либо вещественный, либо как минимум делается сдвигом ). Как-то печально всё. Не сделать мне хитрый осциллограф-интегратор с фильтром на входе. Ведь хочу еще сетку рисовать. Думал на пиксель использовать два бита. Один бит на сетку (есть/нет), другой - на сигнал (есть/нет). Тогда можно было бы в озу держать буфер размером в 320*2/8 байт на 240*2/8 , то есть 4800 байт. Но фишка в том,что для "декодирования" буфера потребуется как минимум 4 операции сравнения , содержащие в себе хитрые условия. Кажется, что я слишком размечтался sm.gif)
aaarrr
Цитата(Lost_Viking @ Apr 9 2014, 17:21) *
В Keil вроде бы по дефолту стоит оптимизация.

Не стоит.
Lost_Viking
Цитата(aaarrr @ Apr 9 2014, 17:47) *
Не стоит.

Эммм.. 05.gif
Ок. Гляну завтра что получится. Спасибо. Но все же не думаю, что смогу реализовать то, что я хочу
aaarrr
Цитата(Lost_Viking @ Apr 9 2014, 17:56) *
Эммм.. 05.gif
Ок. Гляну завтра что получится. Спасибо. Но все же не думаю, что смогу реализовать то, что я хочу

Могу показать сейчас:
Код
>>> MAIN\#19         while(1)
>>> MAIN\#20         {
>>> MAIN\#21                 for (max=0;max<76800;max++)
   00008528     2100  MOVS     r1,#0
>>> MAIN\#22                 {
>>> MAIN\#23                         *(volatile uint16_t *) (LCD_DATA)=y;
   0000852A     8010  STRH     r0,[r2,#0]
   0000852C     8010  STRH     r0,[r2,#0]
--- MAIN\#22                 {
--- MAIN\#23                         *(volatile uint16_t *) (LCD_DATA)=y;
   0000852E     1C89  ADDS     r1,r1,#2
   00008530 F5B13F96  CMP      r1,#0x12c00
   00008534     D3F9  BCC      0x852a                     <MAIN\#23>
>>> MAIN\#24                 }
>>> MAIN\#25                 y++;
   00008536     1C40  ADDS     r0,r0,#1
--- MAIN\#24                 }
--- MAIN\#25                 y++;
   00008538     B280  UXTH     r0,r0
   0000853A     E7F5  B        0x8528                     <MAIN\#21>


Сравните длину цикла с предыдущим листингом.
Lost_Viking
Цитата(aaarrr @ Apr 9 2014, 18:21) *
Сравните длину цикла с предыдущим листингом.


да Вы волшебник ! =))

Сейчас стоит "Level 0"
Как я понимаю, надо повысить уровень.
Optimize for Time сделать
Что еще посоветуете?
aaarrr
Повысить уровень до -O3 -OTime, в критичных по скорости местах развернуть циклы вручную:
Код
for (max=0;max<76800 / 4;max++)
{
    *(uint16_t *) (LCD_DATA)=y;
    *(uint16_t *) (LCD_DATA)=y;
    *(uint16_t *) (LCD_DATA)=y;
    *(uint16_t *) (LCD_DATA)=y;
}

В предыдущем листинге видно, что компилятор развернул цикл, но только на две итерации.
Lost_Viking
Да все равно я не пойму как при такой нагрузке можно добиться 25гц кадров , при этом еще выполнять фильтрацию сигнала АЦП, работу с видео -буфером, интегрировать данные АЦП (так как сигнал представляет собой производную от физической величины), управлять шаговым двигателем, делать замер периода входного сигнала (частота сигнала от 5 до 20 гц), сравнивать амплитуду на каждой частоте, усреднять амплитуды для n-замеров на конкретной частоте, запоминать это усреднение в памяти.

Размечтался ли я? =))
aaarrr
Цитата(Lost_Viking @ Apr 9 2014, 20:00) *
Размечтался ли я? =))

Считать надо. Но экран на внешней шине с программным формированием картинки "на лету" все несколько усложняет, конечно.
Lost_Viking
Цитата(aaarrr @ Apr 9 2014, 20:12) *
Считать надо. Но экран на внешней шине с программным формированием картинки "на лету" все несколько усложняет, конечно.

Уррра! если по одному цвету выводить без расчетов, то получилсь 55 кадров в сек. Может быть и больше можно. Но не пробовал. С расчетами гораздо меньше, но для моих целей хватит теперь Время на расчеты осается, а это главное. Сигнал до 20 гц будет.

Если использовать для АЦП ДМА, и поработать над алгоритмом работы, то думаю, что можно будет еще увеличить скорость отрисовки.
toweroff
А использовать DMA для EMC не получится? пусть аппаратно гонит на внешнюю шину
Lost_Viking
Цитата(toweroff @ Apr 10 2014, 07:13) *
А использовать DMA для EMC не получится? пусть аппаратно гонит на внешнюю шину


что за ЕМС?
toweroff
Цитата(Lost_Viking @ Apr 10 2014, 09:40) *
что за ЕМС?

External Memory Controller sm.gif
я же так понимаю, дисплей сидит на именно этом контроллере?
Lost_Viking
Цитата(toweroff @ Apr 10 2014, 14:58) *
External Memory Controller sm.gif
я же так понимаю, дисплей сидит на именно этом контроллере?

А какая разница? Все равно видео буфер нужно обновлять 25 раз в секунду. А обновление - это расчет что рисовать - сетку осциллографа или семпл.
toweroff
Ну так это будет нужно делать программно 1 раз против 2-х!
Сейчас получается, что вы будете 2 раза программно работать с этой видеопамятью - сначала изменение, потом - вывод в дисплей.
А при DMA выводе можно использовать и 2 страницы... пока одна аппаратно выводится, модифицируем вторую, потом переключаем туда DMA и т.д.
Lost_Viking
Цитата(toweroff @ Apr 11 2014, 09:41) *
Ну так это будет нужно делать программно 1 раз против 2-х!
Сейчас получается, что вы будете 2 раза программно работать с этой видеопамятью - сначала изменение, потом - вывод в дисплей.
А при DMA выводе можно использовать и 2 страницы... пока одна аппаратно выводится, модифицируем вторую, потом переключаем туда DMA и т.д.


Логично.
Читаю, сравниваю, модифицирую, вывожу
vs
Читаю, сравниваю, модифицирую.

Надо подумать над Вашим предложением =)))

Тогда такой вопрос: как лучше всего очистить сетку от нарисованного сигнала? Есть уйма вариантов, но может быть есть стандартный и самый экономичный?
toweroff
Цитата(Lost_Viking @ Apr 11 2014, 11:01) *
Тогда такой вопрос: как лучше всего очистить сетку от нарисованного сигнала? Есть уйма вариантов, но может быть есть стандартный и самый экономичный?

а не проще готовую сетку уже хранить, чем ее рисовать заново? И модифицировать, если нужно, в моменты переключения режимов/разрешения?
можно еще один канал DMA параллельно завести на буфер, который будет потом модифицироваться, заполнить сеткой, модифицировать и отдать DMA для вывода
VDLab
Цитата(Lost_Viking @ Apr 11 2014, 10:01) *
...Тогда такой вопрос: как лучше всего очистить сетку от нарисованного сигнала? Есть уйма вариантов, но может быть есть стандартный и самый экономичный?

Самый экономный способ перерисовки уже давно придуман - сигнал прорисовывается заново, но уже цветом фона. Ну а сетка... Если там просто сетка, а не причудливое хитросплетение какое - перерисовать ее займет от силы пару миллисекунд. С таким заданием даже 16й ПИК когда то 40-50 раз в секунду справлялся, и без всяких DMA, SDRAM, а ногодрыгом да с восьмибитной шиной.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.