Часовой пояс: UTC + 3 часа




Куратор(ы):   zauropod   



Начать новую тему Новая тема / Ответить на тему Ответить  Сообщений: 399 • Страница 19 из 20<  1 ... 16  17  18  19  20  >
  Пред. тема | След. тема 
В случае проблем с отображением форума, отключите блокировщик рекламы
Автор Сообщение
 
Прилепленное (важное) сообщение

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
Первое знакомство с микроконтроллерами Atmel, STM и другими.

Первый рассказ
Предэксплуатационный ремонт отладчика Atmel AVR Dragon
Цветное изображение на монохромном LCD
Конвертер растровой графики для монохромного LCD (128х64)
Дизеринг для монохромных LCD и конвертер растровых изображений
ZP-STM32 и беспроводной последовательный порт
Куда уходят миллисекунды? Способ повышения FPS
Open Logic Sniffer в действии
AVR XMEGA – разгон, вольтмод и производительность SDRAM


Последний раз редактировалось zauropod 15.12.2010 0:33, всего редактировалось 6 раз(а).


Партнер
 

Junior
Статус: Не в сети
Регистрация: 25.12.2012
Забавное устройство, на меге :?:


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
LWW
Ага. Первая моя платка с внешней памятью. Аж целых 128КБ (17-й адрес через gpio), все прекрасно работает от 3.3V, хотя память рассчитана для 4.5 мин.
Уже в музее.

Приехала LPC-Link2 с несуществующим процессором LPC4370. Может, ей повезет больше - я два раза покупал LPCExpresso, но как-то они (дебаггерные части) быстро дохли, я так толком с продукцией LPC и не пообщался в то время. Платка интересная, кроме отдельного дебаггера она может быть и отладочной для процессора LPC4370, он может грузиться со встроенного spifi, а помимо JTAG/SWD/ETB для 4370, есть и 24-пиновая колодка с его периферией, но так как процессор еще не анонсирован, все это и bsp пока не открывается разработчиком. Пока она предлагается как чистый дебаггер, на сайте написано, что работает с тремя образами - как LPC-Link, Segger и DAP, хотя в конфигурационной утилите только два - для Segger и DAP. Непонятно, как вернуться потом к образу LPC-Link.Поэтому решил пока не перепрограммировать, сеггеровский отладчик у меня и так есть.


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
Появилась официальная инфа про LPC 4370 на сайте NXP. По сравнению с LPC4350 добавлено третье ядро, М0, сопроцессорам добавлена выделенная память 18КБайт. Появился дополнительный 6-канальный 12-битный ADC со скоростью 80(!)MSPS, похоже, это рекорд для МК. Навскидку вроде все, даташита пока нет.


LWW писал(а):
Они вроде итак греются как плиты

Ядра М0 в сравнении с остальной начинкой холодные (должны быть, хотя никто, кроме NXP, их с частотой в 200МГц не выпускает, может на такой частоте и греются). Кстати, на одной плате у меня стоит память самсунг, она хоть и старая разработка, но почти хлодная на клоке 113МГц (М4 на 226), в отличие от Микрон.

Если вдруг скоро появятся камни типа LPC4377 и у них ноги совместимые будут с 4357, может, доработаю свою плату ZP_4357DB под него, там как раз надо несколько мелочей доработать, переходить на 6 слоев, вывести шину SGPIO на ZIF-разъем, поставить пару лдо и еще один разъем под камеру. Навигаторы оказались не очень удобные для моих больших пальцев, надо переделать на микроджойстики, вместо маленького OLED поставить небольшую "электронную бумагу" и WiFi модуль взять поновее, от Ti (хотя против ровингского-микрочиповского RN-171 ничего не имею, с Mousera они уже идут с прошивкой 4.0.x по умолчанию со встроенным софт-AP, все коннектится, файлы пересылаются, веб-сайты считываются, данные можно постить и т.д.). Ну и можно VGA выход на HDMI заменить.


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
Нашел камень для своей следующей игрушки.
Только сейчас заметил, что младшие фрискейловские Vybrid VF3xx будут в LQFP176 корпусах. Cortex-A5 266MHz, NEON, FPU поддерживает double, полтора мегабайта 133MHz SRAM на борту. Доступ к памяти 64-битный, что дает 1GBps. Внешней шины памяти у него нет (нет для RAM - но есть NAND, два QSPI). Конечно, VF6xx поинтересней, 500MHz, поддерживает DDR3-800, имеет второе ядро Cortex-M4 etc, но он уже в BGA-364.
А LQFP176 на двуслойке разведется на раз-два, тем более с памятью возиться не надо.
Разумеется, у фрискейла доступен полный мануал на камень.
VF3xx на Farnel прибудет в сентябре, постараюсь сделать плату к этому времени. Тем более Rowley заканчивает доработку своего тулчейна и вот-вот обновится до версии 3.0, в которой эти камни поддерживаются.


 

Member
Статус: Не в сети
Регистрация: 26.01.2011
zauropod писал(а):
А LQFP176 на двуслойке разведется на раз-два, тем более с памятью возиться не надо.

Модули SAMA5D3x-CM в шаговой доступности не нашел, а вот с этим камушком можно поиграться (начать уничтожение ARMов).
Boot ROM у них с завода прошит?


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
max0000000 писал(а):
Boot ROM у них с завода прошит?

Ессно, на то он и ROM.
Кстати, у Фарнелла в наличии сейчас эти камни в инженерном предрелизном исполнении, но сейчас с ними некогда играться. Подождем серийных.

Если ты так и не слез с восьмибиток, то этот камень - не самый лучший выбор для перехода, особенно если нет подходящего тулчейна, так как камень посложнее кортексов-м, помимо набора инструкций Thumb-2 выполняет и простой Thumb и нативный ARM код. Кстати, со старашим Vybrid фрискейловская борда идет со специальной версией DS-5 (ограничение - 256К кода), которая будет работать год, даунлод и ключ активации есть на сайте ARM, не знаю пока, можно ли это приспособить к DIY-борде с младшими камнями. Хотя можно какие-нибудь кикстарты IAR etc на 32КБ использовать, но я бы тогда посоветовал начать с самого простого и дешевого наборчика под любой арм на кортексе М0/1/2/3/4.


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
Наконец получил последний элемент для ZP_LPC4357DB - 4x канальный двунаправленный шифтер TXS0104. Он для VGA выхода сдвигает на 5В уровни синхроимпулсов и I2C для EDID монитора. Я при разработке поставил TXB0104, не дочитав даташит до конца :), а он оказывается не предусмотрен для шины I2C да и подтяжка не должна быть менее 50К. Я поначалу не понял, что это за хрень на VGA-разъеме вместо синхроимпульсов и почему шина I2C умирает. Хорошо, что такой же конструктив у "правильного" TXS0104, все заработало.

Но режим VGA (640х480х24bpp) на LPC4357 сильно не обрадовал. То есть статичную труколорную картинку красиво показывает, но любой доступ к памяти (например, фон путем memcpy для следующего фрейма при двойной буферизации) ведет к Round Robin на шине AHB и емкости FIFO DMA не хватает, чтобы на каждый пиксельный клок попал правильный пиксель. Возможно и проблемы с настройкой памяти и контроллера памяти - уж очень многие жаловались на работу SDRAM на макс частотах у LPC43xx.

Как бы то ни было, загрузка AHB приводит к срыву синхронизации по горизонтали. Попробовал поднять клок процессора до 228MHz и снизить пикселклок с 25 до 22.7MHz, совсем старый LCD вышел в OUT OF TIMINGS, не совсем старый вьюсоник 2735 (1900х1200) поднатужился и выдал картинку, правда, пришлось тайминги поднастроить, смотреть уже можно, хотя пиксел стал не квадратный (ширше).

Но все равно это нестандарт и на пределе возможностей камня (memcpy 640х480х24bpp т.е 1.2 мегабайта, занимает 35мс при 16-битной памяти при клоке 228/114, битность-то можно уменшить, а с пикселклоком как быть?), режим 1024x768 засинхронизировать не удалось - я пикселклок беру производный от основного (12*x/y), надо бы попробовать с точными, можно настроить аудио PLL на любую дробную частоту. Но как-то выходит, что самой простенький 517-й видеоконтроллер EPSON с внешней памятью сам дает мне на фрейм несколько десятков миллисекунд, если фон у него в памяти и никаких срывов. У него даже есть фича - при увеличении разрешения растет производительность (если проц быстрый). Ну да ладно, наверное, чересчур много хочу от этого МК. Или туплю где-то.

Кстати, вот как моя ZP_4357DB выглядит:

#77

Фото намеренно переэкспонировано, так как мыльница никак не хочет показывать нужный динамический диапазон, без вспышки OLED все забивает, но что на нем изображено не видно, светодиоды яркие, и на микросхемах надписей не видно. Сделал 30 разных снимков, надоело :).


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
Небольшое дополнение к предыдущему посту по выводу картинки с LPC4357.
Стандартный пикселклок на VGA-режимах - 25.175MHz, что при видеобуфере (32bit word/pixel) требует стрим из внешней памяти 100.7 мегабайт в секунду. Емкость и ширину FIFO учитывать нет смысла, так как он предназначен для выравнивания небольших перерывов по подаче данных, мы же работаем на пределе.
Слегка оверклокнутый до 228MHz (мой камень выше не берет при 3.3В и шаге 12) дает реальную пиковую производительность (псп) 16-битной RAM 212 мегабайт в секунду. Это замеряем оптимизированным мемсетом до инициализации всего, кроме процессора, системного таймера и памяти. На мониторе 1900х1200 для поддержания нужного aspect ratio ширина 640 пикселов предполагает 400 пикселов высоты, что прекрасно подходит под 70Гц стандарт (HS- VS+). При этом требуемый видеобуфер ровно 1 мегабайт. Мемсету требуется 4.7 мс, что и дает 212 мегабайт в секунду.
После инициализации видеокотроллера, он начинает неперерывно выводить на экран содержимое буфера по DMA, при этом из практически возможных 212 мегабайт в секунду всему остальному остается до 111.3 мегабайт в секунду. Мемсет на очистку теперь 9.4 ... 11 мс. Round Robin легко обслужит два конкурирующих запроса, т.е. возможна одновременная работа программы с массивами во внешней памяти, но продолжительный третий запрос (в моем случае - DMA-чтение с SD-карты) поделит канал AHB уже на троих, давая каждому по 71 мегабайт в секунду. Что и будет визуализироваться как "срывы горизонтали" на мониторе. Поскольку документированного доступа программисту к каналам DMA у LCD и SD нет, выход один - уменьшать пикселклок или увеличивать псп памяти. Пикселклок уменьшать некуда ( в нашем случае он 228/9 = 25.33Mhz, на 0.6% выше), тем более в ттд LPC4357 типовым считается 50MHz, проц на макс частоте, - то выход один - переход на 32-битную память. По краеней мере, режимы 640x xxx будут без помех. Хотя при 228MHz и пикселклоке 228/9 = 25.33Mhz уже почти нормально, помехи только изредка, в отличие от стандартных 204MHz и пикселклоке 204/8 = 25.5Mhz, при котором уже два постоянных запроса AHB дают канал для LCD менее 100.7 мегабайт в секунду и весь экран коллапсирует и нормализуется лишь в моменты, когда внешняя память никому не нужна, кроме как DMA LCD.

А вот с 32-битным доступом у меня пока какая-то бяка, надо разбираться и драйвер переписать. Причем это не зависит от частоты, даже в мегагерцовых тактах. Может, где-то накосячил, хотя разодку уже несколько раз перепроверял. Надо будет протестировать GPIO-вывод на D15-D31, может шар какой незапаян или кз, хотя вроде на кз между собой - земля - питание проверял.

Ну это так, мысли вслух.
Вывод: если кто хочет использовать LPC43xx с панелью больше, чем 480х272 - нужно обязательно ставить 32-битную память.


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
Финальный вывод по видеовыводу на LPC43xx.
Откатился на 16-битный цвет, при этом, конечно, плавность градиентов потеряна, но это заметно только на определенном материале, есть ряд фоток, где в 16-битном цвете смотреть просто невозможно. Но зато теперь никаких проблем как минимум с тройным робиным и 16-битной памятью до SVGA 800x600 включительно. XGA 1024x768 в статике ОК, если программе нужна AHB - помехи. Получается, что режим 1024x768 не будет работать и с 32 битной памятью и возможен только с палетизированным цветом, впрочем 256 цветов во многих случаях будут вполне приемлимым решением.


 

Member
Статус: Не в сети
Регистрация: 26.01.2011
zauropod писал(а):
Финальный вывод по видеовыводу на LPC43xx

использовать шину в проце на пределе? Чем мне нравится дисплеи с видеопаметью бросил и забыл, а для контроля и мигающего светодиода хватит.
zauropod писал(а):
Если ты так и не слез с восьмибиток

И не собираюсь, повторюсь, если устройство не на орбите, то БИТОВО проца с 256 значений за глаза.
Но Cortex-A5 паралейно начну изучать, 8 битки тут ну никак.


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
max0000000 писал(а):
использовать шину в проце на пределе? Чем мне нравится дисплеи с видеопаметью бросил и забыл, а для контроля и мигающего светодиода хватит.

На то оно и железо, чтобы его использовать на пределе. А я показал, какой режим возможен, чтобы робин обслужил три одновременных долговременных запроса к шине AHB, что дает возможность работать пользовательским программам без помех на экране.
И покажи мне контроллер со встроенной памятью на даблбуфер под хотя бы 800х600х16bpp, а мне нужно минимум четыре. Нет таких.

max0000000 писал(а):
повторюсь, если устройство не на орбите, то БИТОВО проца с 256 значений за глаза

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

Кстати, запустил таки 32-битную шину у SDRAM памяти на ZP_LPC4357, там в драйвер от LPC была ошибка в инициализации burst mode. Подправил, все работает как часы. Даже посмотрел на режим 1024х768х16, уже постоянных срывов нет, но помехи проскакивают. Но для пикселклока 65 MHz приходится понижать частоту до стандартной 204, те пикселклок = 204/3.
Зато прирост скорости от 32битов на 800х600х16 порадовал, очистка экранного буфера 4мс в рабочем режиме, GIF анимация стала быстрее аж в два раза, теперь крупногабаритные (напр. 600х400) ролики декодируются с 10% отставанием только, если меньше, то уже с запасом, а совсем маленькие и раньше проигрывались как положено. JPEG стал быстрее на 15-20%, PNG - на 10%. Это я все пока без второго ядра балуюсь. С ним можно и MPEG-4 попробовать адаптировать. Но это лучше уже на A5 делать, для него (вернее для его мультимедийного сопроцессора NEON) и готовые неоптимизированные мультимедийные кодеки на сайте ARM беспошлинно предлагаются. Да и по части формирования картинки он на порядок покруче. Но с ним мы чуть позже. Пока можно для своей платки какой нибудь интернет-браузер написать, без javascript, типа скачивать картинки и прочий контент. Пока это все неавтоматизировано и не собрано в кучу у меня.


 

Member
Статус: Не в сети
Регистрация: 26.01.2011
zauropod писал(а):
Но ARMы уже в самом нижнем сегменте дешевле, производительнее и экономичнее всех проприетарок.

На farnell ATxmega32E5 1+ €2.03; STM32F050K6U6A 1+ €2.74
Чтоб подергать парой ножкой и моргнуть светодиодиками производительность особо не нужна.
А бит-бэнд у CORTEX-M3,4 (не знаю как у М0) мне не понравился.
А чтоб не проспать буду издеваться над CORTEX-А5.


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
max0000000
Чего ты к МК с ногодрыганьем пристаешь? Твоей сварке нужно на пине 200МГц? Для этого FPGA используют.

Кстати о FPGA. В преддверии дизайна по выбритому третьему фрискейлу поискал, чем ему память ОЗУ расширить, это только можно через SPI/QSPI, ну или городить параллельную шину, что изврат. Попался австралийский сайт http://www.dimitech.com, там человеки SPI-модуль памяти на 16 Мегабайт только выпустили, в корпусе PLLC68 (у них такой формат под свои борды с гнездами). Просят 50 баксов, замного. Глянул что там внутри - 84-ногий FPGA от Lattice с буткой и пара PSRAM от ISSI, по ценам Маузера четыре микрушки обойдутся под 15 евро. Так как интерфейс у PSRAM от статики, то делов то разработать свою прошивку почти и нет. Аж захотелось купить маленькую платку от Lattice для попробовать, 40-я серия стоит копейки. И тулчейн бесплатный. Может, отодвину пока проект на выбритом до выяснения всех деталей. Тем более, возжа под хвост попала, может, попробую на свою ZP_LPC4357DB Linux поставить. Но поскольку я в нем совсем никакой (пару раз под виртуалкой собирал ядро), без помощи не обойтись.


 

Member
Статус: Не в сети
Регистрация: 26.01.2011
zauropod писал(а):
200МГц

Так высоко я ещё не улетел. 200КГц разумный предел для силовых полевиков.
Xmega на 32Мгц вполне разрулит.
И вообще, со своей ленью, я к avr года три подбирался, FPGA если только под пистолетом.
zauropod писал(а):
по выбритому третьему фрискейлу

Да со временем добавят в камень память.


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
max0000000 писал(а):
Да со временем добавят в камень память.

Да куда уж больше? И так рекорд для МК. Если я не изменяю памяти, в свое время AT91SAM261 скакнул из общего ряда со своими 160КБ, потом LPC3250 c 256КБ. Сейчас такой объем не редкость, но вот полтора мегабайта статики пока круто. Динамика встроенная большая есть, однако, на малине стоит. Если и будет больше статики, то через несколько лет, там места надо больше, чем у динамики. Ждем-с пикометрового техпроцесса.

А пока что почти сутки убил на написание утилитки для рисования курсора для LPC MCU. Поискал в сети, не нашел. Стал вручную биты в байты и большой ендиан в маленький миксить, да блин неблагодарное это занятие. Пришлось вспоминать, как на C# программировать, как быстро, оказывается, все забывается. Два года почти не трогал. Но сделал утилитку. Зато теперь десяток секунд - и любой 32х32 курсор. Если кому интересно, можно взять тут:

http://www.zaurosoft.com/images/ZP_LPC4357DB/LPC_CursorEditor.zip

Там в папке будет бумажка с описанием как делать, но по-англицки, хотя и так все понятно, единственно, FloodFill идет по средней кнопке или (Shift + LMB).
Попытался зарегиться на LPCware, чтобы людям дать доступ к утилитке, да хрен там. Никакой реакции, на мыло ничего не приходит. Ну и не очень-то и хотелось.

Опять же, возвращаясь к выбритому третьему фрискейлу, у него всего один порт USB. А давненько мне хотелось поиграться с хостами от FTDI, когда был VINC1, они были дорогими, ~$20 (и, как ни странно, остаются и сейчас), VINC2 уже раз в 8-10 дешевле. Вот завтра буду начинать играться с ними. Хотя, конечно, могли бы и HS делать. С другой стороны, это всего-то обычные МК (типа как VLSI "свои" аудиопроцесооры делает на базе PIC, или ALFAT со "своими" процессорами на базе STM32F2), но вот драйверная поддержка у них хороша.

Кстати, еще один центр расфокусировки концетрации, Linux, тоже все сильней дает о себе знать. Ребята с Emcraft отзывчивые оказались, получил от них пакет uCLinux для LPC4350, free of charge. Теперь параллельно курю бамбук по U-BOOT для начала, но компьютер с Ubuntoй надо переинсталлировать, а компьютер с виртуалкой, где мои полезные прибамбасы для линукса, заставлен хламом всяким. Надо решиться на подвиг и все настроить таки.


 

Advanced member
Статус: Не в сети
Регистрация: 10.04.2003
Откуда: Москва
"фон путем memcpy для следующего фрейма при двойной буферизации ведет к Round Robin"
Две мысли, "не проверенные" (могут быть глупыми, нужна адаптация)
1. если массовая (программная) активность вызывает затык обмена по шине, значит надо делать "паузы в словах". Как думаешь, команда строковой пересылки (типа movs x86) при большом блоке на всё время занимает шину? Вовсе нет, специально вставляются паузы.
2. при двойном буферизировании ты копируешь буфера? Вообще-то, проще переключать =адрес= блока в контроллере вЫвода на монитор. Отсюда - резкое падение загрузки шины.


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
serj
На всякий случай, поясню - никакого конкретного устройства под техзадание не создается, иначе, если бы серьезные затыки были, была бы применена _соответствующая_ аппаратная платформа. Все мои проекты лишь массажируют мои центры удовольствия :), а ввиду того что, что мне на работу ходить не надо, начальства надо мной нет, то временем я располагаю и волен делать все, что мне захочется. В данном случае хотелось разработать с нуля и собрать работоспособное устройство чуть выше начальной сложности (0.1мм дизайн, 4 слоя) на новом Cortex-M4F, и чтобы не проявилось критических ошибок. Программные цели не стояли. Что в голову взбредет.

И примем за аксиому, что LPC4357 не предназначен для интенсивных графических задач, я его насильничаю.

serj писал(а):
надо делать "паузы в словах"

Учитывая
serj писал(а):
мысли, "не проверенные" (могут быть глупыми, нужна адаптация)


попытаемся адаптировать.
Рассмотрим LCD при 24-битном цвете (выравнено по ворду, т.е. 4 байта на пиксел) и пикселклоке в 25МГц для простоты. Те пиксел за 40нс. Пикселклок может быть асинхронен ко всем прочим клокам системы и система должна подстроить свою работу так, чтобы всегда успевать выдавать нужное количество байт на каждый пикселклок. Если не успевает - на экране мусор.

Контроллер LCD имеет аж два FIFO по 128 байт. Так как дисплей c RGB IF один, то все достается ему. Арбитр путем раунд робина чередует запросы от всех мастеров (а их может быть с десяток), каждый мастер получает по заявленному в запросе бурсту. Поскольку запросы могут быть произвольно перемешаны, затыки на экране начнутся, когда двойной FIFO опустел, а новый запрос на шину еще не обработан. Объединенный FIFO 32 x 64 бита, он заполняется, новые запросы к арбитру поступят, когда будут свободны 4 или 8 слотов. То есть, максимально он может продержаться, выводя до 28х64 бит, т.е. 224 байта или 56 пикселов. 56 х 40 нс = 2.24мкс. То есть, если арбитр может между обработкой запроса от контроллера дисплея дать совокупный грант другим мастерам , который будет длиться более, чем 2.24мкс, то появятся проблемы. А он может, тем более, если вступят мастера от Ethernеt, USB, есть и два мастера на общие операции с памятью и периферией GPDMA. А что такое 2.24 мкс с точки зрения SDRAM? Примерно полкилобайта. 64 стандартных квадобурст - запроса памяти x16. Ежели пикселклок и разрешение повыше - дело труба.

Что касается movs, точнее, rep movsx n, то упомянутый memcpy не использует блоковой пересылки, а работает со всей группой доступных регистров. Конечно, это в цикле и с приоритетом процессора.

Возвращаемся к практике.

Вот видео, как проявляется обсуждаемая проблема на LPC4357. Вывод на монитор 1024х768, фреймбуфер 1024х768х16, пикселклок 65MHz, процессор 204МГц, память 32-битная на 102МГц. В цикле с карты SD читаются (скорость чтения примерно 5 мегабайт в сек.) картинки из выбранного директория и выводятся на экран. Видеобуфер один, картинки - PNG с альфаканалом, перед выводом картинки фон с квадратиками 50х50 перерисовывается. Декодер - лодевский, требует загрузки всего файла в память, в пике динамическое выделение памяти до (7 х размер картинки). Менеджер памяти свой, трехэтажный, 4-16-256К. Финальная картинка масштабируется (в данном случае только для кота) и выводится на экран. Файл примерно 10 метров, съемка 800х600 25фпс.

http://www.zaurosoft.com/images/ZP_LPC4357DB/LPC4357_XGAx16bpp_Bandwidth_overhead.avi

Видно, что картинка рвется в момент чтения с SD и в моменты перед выводом следующего изображения. Если memcpy заменить на обычный вариант
Код:
*dst++ = *src++;

то второй срыв исчезает.

Минимальный бурст для SD 4*32, пробовал менять на все другие значения, лучше не станосится. FAT FS не использует memcpy.

Вывод: пауза помогает, когда у шины есть запас и контроллер дисплея не голодает. Если же шина перегружена, то "паузы" а ля serj требуют фантастического по быстродействию контроля за очередью арбитра шины и умение суперскоростной вставки своей хотелки в очередь запросов. Что есть фантастика.

Или есть другие варианты где, как и каким образом вставить паузы? Аналогий с другой архитектурой не надо. Конкретно для ARM-V7m.
Каким образом понять, что настал подходящий момент для запроса шины и встрять со своей хотелкой, без задержек, именно в этот момент?

serj писал(а):
при двойном буферизировании ты копируешь буфера? Вообще-то, проще переключать =адрес= блока в контроллере вЫвода на монитор. Отсюда - резкое падение загрузки шины.


Чет ты не туда загнул.
Разумеется, буфера переключаются сменой адреса. Но смена адреса сама по себе не обновляет содержимого видеобуфера. Для получения эффекта анимации или 3Д, бэкбуффер заполняется фоном, далее рисуется нужный контент, и затем этот буфер становится фронтом. Который был фронтом, становится бэком, заполняется фоном, и т.д. Для 2Д обычно перерисовывается только область, которая изменилась, в 3Д перерисовывается все. Мне нужно перерисовывать бэкграунд полностью. Кстати, это не равнозначно "копируешь буфера", правильнее говорить о заполнении. Например, анимированный бэкграунд типа nexus, который есть на любом андроиде, можно рисовать программно маленькими тайлами, тайл может занимать несколько байт всего. Вполне хватает M4 дпя 15 больших иконок с альфой и десяти бегающих во все стороны отрезков-градиентов с альфаканалом и светящейся головой, на WQVGA 30-40 фпс держит без оптимизации. Но если выделить бэкграунд буфер и сначала заполнить тайлами его, то будет быстрее. Затем этот буфер все время копируется в бэкбуфер сразу после переключения адреса.


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
Разумеется, вопрос про паузы в предыдущем посте ответа не имеет. "Пауза" - это уменьшение длины бурста и других ее вариантов в рассматриваемой проблеме нет. Нет возможности контролировать работу арбитра другим способом, кроме как заданием длины бурста.
То есть, для процессора, это бурст SDRAM, и соответствующий бурст для мастеров DMA. К размеру бурста DMA LCD контроллера доступа нет, и вообще, реализация армовской спецификации AMBA - дело имплементатора, в данном случае NXP, там может быть много нюансов, включая то, что арбитр может прерывать уже начатые передачи, лишая гранта кого бы то ни было. Но видно, что бурст DMA LCD динамический, вероятно 4 - 8 - 16 или 8-16 в зависимости от ватермарка, единственного регулируемого параметра в DMA LCD (т.е. генерация запросов к арбитру при 4 или 8 свободных слотах). Этого совершенно не видно по временным засечкам на 640x480, но заметно на максимальных поддерживаемых разрешениях для LPC4357.

Я попробовал 1024x768x16 bpp при разогнанном до 228МГц камне и пониженном пикселклоке 228/4 = 57МГц. При этом все показанные выше артефакты исчезают и система вполне работоспособна. Но, конечно, такой режим не может применяться для реального изделия да и четвертый мастер на шине опять все испортит. Но заполнение экрана фоном уже занимает порядка 40мс, что не оставляет времени для анимированного бэкграунда и прочих экранных эффектов. Хотя для какой-нибудь фоторамки или CNC-контроля подойдет. Эти 40 мс явно не пропорциональны в сравнении с 640x480x16, где при меньшем более чем вдвое пикселклоке и меньшего в 2.5 раза числа пикселов время заполнения примерно 10 мс и как раз могут объяснятся тем, что на больших разрешениях FIFO LCD опустошается быстрее и к моменту получения гранта формируется максимальный бурст. Соответсвенно, при трех мастерах псп делится не в пропорции (1:1:1), а, к примеру (2:1:1) или (4:2:1), на самом деле, если арбитр умный, его алгоритм вообще будет полным секретом NXP.

"Заполнение экрана фоном" - это пересылка битмапа. Что характерно, для 640x480x16 memset до и после инициализации LCD работают примерно в одно время (1.9 против 2.0-2.1 мс), в то время как для 1024x768x16 bpp это 2 против 9-10мс.
Кстати, неоптимизированная версия memcpy в полтора раза медленне оптимизированной, поэтому я ее не применяю.

Так что для моих игр придется работать на разрешении 640x480x16.


 

Advanced member
Статус: Не в сети
Регистрация: 10.04.2003
Откуда: Москва
Делать паузы в словах - означает вставку умышленных пауз в операциях доступа к устройству. )) Если процессор затыкает обмен, значит сам обмен надо выполнять либо привязанный к обмену "другого" устройства, либо просто цикл записи (или чтения) выполнять блоками малой длины с последующим переходом программы к другому роду деятельности (паузе). Не хочу лезть в тонкости реализации конкретного железа, поэтому теоретизирую.
Вариант исполнения - повесить прерывание/event/... на событие передачи блока контроллером на дисплей и по нему выполнять передачу n байт по шине. Число n выбирается таким, чтобы не "забить" контроллер.

"Заполнение экрана фоном" - если фон однотонный, то может его вообще заливать аппаратно? Ставишь DMA пересылку из "регистра" в "память++", устанавливаешь в регистре цвет - и пусть развлекается.


 

Куратор темы
Статус: Не в сети
Регистрация: 16.11.2006
Откуда: Всегда!
serj писал(а):
Делать паузы в словах - означает вставку умышленных пауз в операциях доступа к устройству.

Заходим на второй круг?
Ты опять исходишь из опыта x86, который здесь совершенно неуместен, с видео там отдельная песня, а процессор - царь зверей.
Устройство - это внешняя SDRAM, в которой находятся буфера экранной памяти, их надо заполнять-пересылать. Память доступна через шину AHB. Доступ может получить процессор, второе ядро, мастера на шине, организующие DMA-пересылки, включая мастер контроллера LCD, SD, etc. Арбитр шины дает грант на доступ в один момент времени только одному устройству. Точный алгоритм его работы - секрет фирмы, базовая концепция - раунд робин по запрашиваему бурсту. Похоже, что бурст у LCD динамический, контроль за ним есть только путем установки одного из двух значений ватермарка как триггер на запрос к DMA. Какой реально будет запрос бурста, неизвестно, так как хз сколько слотов освободится к моменту получения гранта. Но производитель камня, а не ARM, определяет логику работы арбитра и это есть самый сложная задача в шинном управлении.

Обескровить пиксельный фифо может либо наличие DMA-потоков на AHB, даже не связанных с SDRAM, так и банальная нехватка псп SDRAM, так как на всех не хватает, а если контроллер LCD увеличил бурст - то он сам себе в том числе и подрезает крылья, не только другим, что и было показано.

serj писал(а):
"Заполнение экрана фоном" - если фон однотонный, то может его вообще заливать аппаратно? Ставишь DMA пересылку из "регистра" в "память++", устанавливаешь в регистре цвет - и пусть развлекается.

Да какой бы фон ни был. Шина памяти одна на всех. DMA канал он что, по особым линиям пересылает данные?
Вот на 640x480 уже можно реализовать тройной фреймбуфер, очищая первый ушедший с фронта по DMA или сопроцессором, тем самым экономя время на работу с тем бэком, который в следующем переключении станет фронтом.
А на 1024х768 при тройной буферизации эти каналы вызовут перегруз шины и никакие паузы не помогут для хотя бы десятка фпс.


Показать сообщения за:  Поле сортировки  
Начать новую тему Новая тема / Ответить на тему Ответить  Сообщений: 399 • Страница 19 из 20<  1 ... 16  17  18  19  20  >
-

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Перейти:  



Лаборатория














Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB | Kolobok smiles © Aiwan