Jump to content

    

__inline__

Участник
  • Content Count

    978
  • Joined

Everything posted by __inline__


  1. Хорош порожняк гнать в тему! Потому что программа разрабатывалась под ПК где монитор 60 Гц. При 120 FPS всё идёт быстро в 2 раза )))
  2. Я не рассказываю полный бред. Своим глазам я верю больше, чем анонимам с форума. Я сюда пришёл с конкретными вопросами, а получил кучу флуда, которого от вас больше всего. Это говно. Держал такой в руках, в динамике картинки с артефактами. Мне вот как раз есть чем заниматься. А вам с DASM'ом похоже, что нет. )) И как интерфейс подключения влияет на качество картинки матрицы LCD? Бред написали. Провели эксперимент. Показали движущиеся картинки с дисплея приставки SEGA MD Portable нескольким людям. Всех всё устроило, а меня нет. Из замеченных мною недостатков были: 1) малые углы обзора 2) белёсость чёрного 3) смазывание пикселов на мозаичных(шахматных) элементах 4) ненасыщенные цвета 5) "золотой" оттенок изображения 6) Полоски при движении Лишь только пару человек смог убедить в половине недостатков, остальным всё идёт. Так что если быдло хавает дерьмо, почему я должен согласиться с тем что дисплеи IPS хороши? Кота в мешке не собираюсь покупать. Всегда смотрю дисплеи в действии на телефонах - если устраивает - выковыриваю. И кстати, дисплей тоже с контроллером Ilitek !!! (надо же! и тут совпадение! ))) все дисплеи с белой пластмассовой каёмкой и удобопаяемым гибким шлейфом вместо разъёма - Г О В Н О ! ! ! Что такое "нормальные контроллеры" ? Дайте определение. Есть ли такой инженерный термин вообще? Есть параллельная шина, допускающая подключение дисплеев по ней. Особенно когда есть DMA и сопроцессоры. Совершенно верно. На повестку дня выношу затерянный в дебрях флуда актуальный вопрос:
  3. Это как-то не стыкуется с вашим утверждением в первом посте: Зачем так извращенствовать? Выход ЦАП через разделительный конденсатор 0,01 - 1 мкФ (неполярный) на вход этого УНЧ. Нужна регулировочная громкость? - поставьте переменный резистор вместо Rf=20 кОм на схеме - через ОС будете управлять громкостью. Делал так в своих поделках, отлично работает. Кстати. Может будет интересно в плане схемотехники и позаимствования сорцов декодеров звука и вывод на ЦАП STM32. Мой проект nanoPlayer с открытыми исходниками: https://vrtp.ru/index.php?showtopic=29688 Если что, печатные платы от него у меня ещё есть - для самостоятельной сборки. Пишите в личку. Будет и видео и звук. )) Схема: https://vrtp.ru/index.php?act=Attach&type=post&id=772221 В действии:
  4. У меня интересы чисто хоббийные: найти телек на местной барахолке не составляет никаких проблем - было бы желание! Это в назидание страждущим, кто думает что ЭЛТ умерли. Не дождутся! )) Вот совсем недавно зарелизил игровую консоль BlackPrism Portable: Дисплей LCD в ней от телефона LG GX 500. Смотрится красночно и ярко. Не то что илитековские матрицы с которыми приходилось иметь дело: Дисплей поддерживает до 128 Гц кадровой развёртки и возможно переключение между фреймовой инверсией и строчной. Поставил первую, чтобы картинка была хорошей. Ну и отзыв ещё одного человека, кто подключил этот дисплей: http://arduino.ru/forum/apparatnye-voprosy/arduino-i-displei-ot-sotikov-mobilnykh-telefonov?page=53#comment-495611 Это как раз тот случай, когда качество картинки меня удовлетворяет. А полосы убираются удвоением частоты развёртки + включением фреймовой инверсии вместо строчной. Сейчас продумываю концепт десктопной версии - BlackPrism DeskTop. И там будет видеовыход на ТВ.
  5. Знаю. Но проследил такую закономерность: если чип от Ilitek, значит матрица - говно. Потому что китайцы. А они очень любят Ilitek )) С чего это вдруг? Активно используем для получения гладкого движения изображений! Что касается IPS, то : На этом можно поставить крест: для моих целей не годится. Только для вывода статичных голых баб, как подметил DASM :)
  6. Глянул дисплеи по приведенным вами ссылкам - они все на базе Ilitek'овского контроллера, а это - говно по определению. Я уже вдоволь нажрался илитековского говна в ардуино-шилд-дисплеях: не устроило качество картинки - под разными углами плохо показывает, цвета белёсые, уровень чёрного хреновый и - те же полоски что в начале темы. Дисплей от GX500 который использую намного лучше вышеозначенных. Илитеком недоволен в плане оптики - качество изображения годится разве что для индикации в технических приборах. Смотреть видео или играть в игры на таких дисплеях я бы не хотел и другим не рекомендую. Статья про IPS и AMOLED. https://www.iphones.ru/iNotes/amoled-protiv-ips-v-kraskah-primerah-i-testah-05-26-2019 В общем, дерьмо эти IPS.... ЭЛТ лучше будет!
  7. Мне бы что-нибудь с шиной 8 или 16 бит как интерфейс SRAM P.S. Проблему решил: оставил развёртку 120 Гц + 2 VSYNC для процессинга 60 FPS. Всё работает ниче не мерцает полоски ушли. Я доволен, но пришлось немного попотеть )))
  8. Да не за что )) Вы можете это проделать сами очень легко - ничего сложного !
  9. Пирамида Маслоу... Жажда к творчеству. Бабы её не заменяют. ))) Ничто не помешает. Вылезет какой-нить артефакт типа смазывания картинки при движении или в полосках всё будет. Ну и какова скорость обмена данными с таким дисплеем? Мне надо не ниже 60 кадров в секунду отрисовывать на 400x240, при этом цвет не хуже 16 бит.
  10. Сомнительно, что IPS будет отлично казать вот такую вещь (с 960-й секунды): https://www.youtube.com/watch?v=VlaP-7SIHz0&t=960
  11. Вы видать незнакомы с аркадными автоматами начала 80-хх - конца 90-х ))). 320x240 там не нужна чёткость, наоборот, небольшое размытие там даже на руку ибо квадраты не видны. Сомневаюсь, что вы их взяли чтобы спрайты гонять. ))) На просмотре видео эффект не будет себя проявлять. Только если будет скролл картинки по горизонтали
  12. Ещё бы знать какой IPS окажется нормальным :) Много дисплеев разных покупал, оставался доволен только OLED'ами, так как они как-будто созданы для 2D-анимации. Мне нужно, чтобы нарисованные на дисплее спрайты двигались плавно на +1 пиксел за 1 VSYNC. При этом если спрайт начинает: шлейфить, мазать, кривиться или мерцать вертикальными полосками (как в сообщении в шапке темы), то дисплей объявляю неподходящим для моих целей. А голых баб статичных выводить может каждый LCD, другое дело, что будет с картинкой, если её начать плавно крутить по горизонтали на +1 пиксел за 1 рефреш дисплея?
  13. Потестировал этот GCC, получил листинг. Параллельность есть, но она слабенькая в отличие от TI CC. Команда: c6x-uclinux-g++ -S -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -march=c674x -O3 -fomit-frame-pointer -ffast-math -fno-rtti -fno-exceptions -Dc6745 -DNDEBUG -c PPU16.cpp Код: #include <stdlib.h> #include "PPU16.h" #define VRAM_BUFFER 0xC0800000 /* Bank1 SDRAM */ #define VIDEO_CACHE 0x11800000 /* 240 x 400 pixel buffer */ #define PRUSS_VideoBuffer (*(IO u32*)(PRU1_Data+0x0000)) #define SROM16 (*(u16*)SROMOffset) #define VRAM16 (*(u16*)VRAMOffset) u8 *VRAMBuffer=(u8*)VRAM_BUFFER; const u8 *SROMBuffer; //SROM Buffer - Pointer u32 SPRITE_PITCH=2048; //Default Sprite Width: 1024 pixel #define _amem8(x) (*(x)) #define _mem8(x) (*(x)) void PPU16_ClearVRAM(u16 Color) { u64 c=Color|(Color<<16); c|=(c<<32); u64 * __restrict vb=(u64*)VRAMBuffer; // #pragma UNROLL(4) for(int i=0;i<(SCREEN_WIDTH*SCREEN_HEIGHT)>>2;i++)_amem8(&vb[i])=c; } void PPU16_OutOLED(void) { for(int y=0;y<(SCREEN_HEIGHT<<1);y+=8) { u64 * __restrict vc=(u64*)(VIDEO_CACHE+y); u64 * __restrict vb0=(u64*)&VRAMBuffer[((SCREEN_WIDTH-4)<<1)+(SCREEN_WIDTH*y)]; u64 * __restrict vb1=vb0+(SCREEN_WIDTH>>2); u64 * __restrict vb2=vb1+(SCREEN_WIDTH>>2); u64 * __restrict vb3=vb2+(SCREEN_WIDTH>>2); for(int x=0;x<(SCREEN_WIDTH>>2);x++) { _amem8(&vc[(3*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16) _amem8(&vb0[-x]) ))|((u64)((u16) _amem8(&vb1[-x]) )<<16)|((u64)((u16) _amem8(&vb2[-x]) )<<32)|((u64)((u16) _amem8(&vb3[-x]) )<<48); _amem8(&vc[(2*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16)(_amem8(&vb0[-x])>>16)))|((u64)((u16)(_amem8(&vb1[-x])>>16))<<16)|((u64)((u16)(_amem8(&vb2[-x])>>16))<<32)|((u64)((u16)(_amem8(&vb3[-x])>>16))<<48); _amem8(&vc[(1*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16)(_amem8(&vb0[-x])>>32)))|((u64)((u16)(_amem8(&vb1[-x])>>32))<<16)|((u64)((u16)(_amem8(&vb2[-x])>>32))<<32)|((u64)((u16)(_amem8(&vb3[-x])>>32))<<48); _amem8(&vc[(0*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16)(_amem8(&vb0[-x])>>48)))|((u64)((u16)(_amem8(&vb1[-x])>>48))<<16)|((u64)((u16)(_amem8(&vb2[-x])>>48))<<32)|((u64)((u16)(_amem8(&vb3[-x])>>48))<<48); } } } Даёт такой листинг: Слабовато. И _mem8, _amem8 не знает, пришлось задефайнить разыменовыванием указателей, что не совсем верно.
  14. Помню, работал на ПК в начале 2000-х, был монитор ЭЛТ ViewSonic G55 с нативным разрешением 800x600 85 Гц. Хороший был монитор! Картинка чёткая, ничего не мерцало. И самое главное - плавность движения была просто великолепная как на всех ЭЛТ мониторах! LCD до такого далеко и сейчас. Что касается ТВ, то их кинескопы моргают ощутимо, если краем глаза смотреть. Стараюсь использовать NTSC вместо PAL где возможно. И там есть такой артефакт: при резких сменах яркости монотонных участков большой площади, происходит "разбухание" фрагмента изображения - он мог слегка искривлять изображение или выходить за пределы кадра (неравномерность свечения люминофора) На счёт "эффекта памяти" в LCD в курсе. Был такой дисплей MTF-T022 (контроллер S6D0129) - он мог отключать все эти инверсии, картинка была превосходной. Но за это пришлось расплатиться тем, что если картинка оставалась долго неподвижной, то при смене картинки появлялся рельеф от старой и был какое-то время :) Поэтому приходится выбирать компромиссы: 1) либо полоски с низкой частотой обновления 2) либо отсутствие полосок, но с мерцанием 3) отсутствие полосок и повышенная частота обновления 4) отсутствие полосок и эффект памяти (деградация) дисплея 5) радикальный переход на ЭЛТ P.S. Ещё не родился на Земле тот глобал, который придумал бы LCD с превосходным качеством анимации картинки с точностью +1 пиксел ))
  15. Статья на русском: http://lcdtech.info/data/lcd.technologies.htm Короче, делаю вывод, что со времён изобретения электронно-лучевой трубки, ничего лучшего человечество не придумало (для воспроизведения плавнодвижущихся объектов). Все эти LCD - фигня, по сравнению с ЭЛТ.
  16. Интересная статья про LCD на тему: http://machineryequipmentonline.com/video-equipment/liquid-crystal-display-lcdpolarity-inversion/ Перевод ключевых моментов: Вот как оказывается! Инверсия кадра приводит мерцанию с частотой в 2 раза ниже частоты обновления. Проще говоря, 60 кадров в секунду дисплея мерцают с частотой 30 Гц - отсюда противные ощущения при просмотре. Поэтому только повышать частоту кадров до 120 Гц, чтобы мерцание было на 60 и незаметным. Так как инверсии точек данный LCD не поддерживает, а инверсия линий приводит к мерцающим полоскам при движении. Дисплей снят с мобильника, где была портретная ориентация кадра и в пейзажный режим, да и ещё с плавной анимацией ихображения - не планировался в принципе )))
  17. Спасибо ответившим! Есть ли какой-нибудь способ сделать интервал процессинга программы равным 60 FPS (интервал 16,667 мс) при условии, что частота смены кадров 90 FPS (11,111 мс), при этом кадр отрисовывать с учётом ожидания по VSYNC ? Я делал замером времени с помощью счётчика тактов CPU, да - в итоге процессинг был на 60 FPS, но изображение подёргивалось, так как 1 VSYNC пропускался. Или второй вариант - когда ждал принудительно VSYNC, но FPS упал до 45 , так как 45 = 90 /2 . В итоге, пришлось повысить частоту смены кадров в 2 раза: 120 FPS, а процессинг программы - 60 FPS - это просто надо ждать 2 VSYNC'а. При таком раскладе - картинка движется гладко и не дёргается и с частотой 60 FPS, хотя дисплей на 120. Так как на 60 дисплей мерцает :) Тоесть нашёл решение сделать процессинг 60 FPS при условии что дисплей имеет частоту обновления в целое число раз больше процессинга. А вот как быть с дробными соотношениями? Когда процессинг требует 60 кадров в секунду, а дисплей предположим: 90 или 100 ? :) При условии, что кадр должен рисоваться с VSYNC?
  18. Цитата из первого сообщения: 2) Есть несколько вариантов несложного сжатия: 1) IMA ADPCM - сжатие 4:1 - из двух 16-битных семплов делает 1 байт. На слух даже звучит неплохо 2) 2-битный ADPCM из G.726 (конкретно g726_16) - сжатие 8:1, но уже есть небльшие артефакты в виде легкого шума, но терпимо. 3) кодек CELT с высокой скоростью кодирования-декодирования - сжатие 8:1 - 10:1. Фрейм распаковывается около 0,6 секунд на 450 МГц (длина распакованного фрейма выставляется, битрейт регулируется, полоса частот тоже). Версия 9 или 10. Всё что выше - будет притормаживать из-за Опусных нововведений. Качество не уступает MP3 на тех же битрейтах и более гибкий в настройках (битрейт, размер фреймов, частота дискретизации). 4) Архиваторы (типа ZLIB) или RLE-сжатие не рекомендую использовать для сжатия звука без потерь: в лучшем случае будет сжатие в 1,5 раза, что ни о чём 5) A-law, u-Law - сжатие 2:1, что хуже ADPCM Со всеми пятью лично игрался, в сборке очень просты - как детские кубики. Достаточно отрассировать штатный MAKE в команды GCC и сделать порт на любую 32-битную архитектуру. 1) Не загрузит практически, если выполнить ряд оптимизаций (в основном это касается кодека CELT в режиме плавающей точке) , для целочисленной реализации ничего оптимизировать не надо. Дуть можно в штатный 12-битовый ЦАП STM32. 12 бит использовались при проигрывании музыки с CD, меломаны терпели :) УНЧ можно взять LM4871 - 1 ватт на 8 Ом будет честно выдавать при питании от 3,3 V. К тому же мостовой, а значит помех он не боится и минимум обвеса - без цепей Цобеля и больших разделительных конденсаторов. Подключать сразу с выхода ЦАП STM. Нет таких библиотек (читай: готовых решений под ключ). Все библиотеки работают с буферами источника и приёмника - в первый кладём что пожать, со второго берём пожатое. Или наоборот при декодировании. Дальше решаем сами что делать с данными.
  19. Звучит обнадёживающе... Всегда считал, что аппаратный кодек - это чип, который жмёт при записи и разжимает при воспроизведении. Пусть даже со своим DSP ядром внутри. А программный кодек - софт-вариант прошивки в управляющем контроллере, который реализует сжатие-разжатие программно. Остальное - просто АЦП и ЦАП, но называть их кодеком - всё-равно что называть ракетой жестянку без реактивного двигателя.
  20. Чего там привлекает? Тупо АЦП-ЦАП без аппаратного декода сжатых форматов. Такого добра полно. Без I2S и DMA можете про него забыть. Вот вариант чисто ЦАП 1 канал ничего лишнего: UDA1334BTS. Самый экономичный по энергопотреблению, ниже уже не найдёте.
  21. Доброе время суток. Столкнулся с особенностью LCD - при горизонтальном движении картинки (движение вдоль бОльшей стороны, развёртка кадра в дисплее - идет вдоль меньшей стороны) появляются едва уловимые вертикальные полосы, которые являются косметическим дефектом и немного портят картинку в движении. Виновником оказался - Display inversion mode control register. По умолчаниию был задан режим - Line inversion Если его установить в режим - Frame Inversion, то полосы уходят, но дисплей противно мерцает (справа на лево). Следующим шагом было повышение частоты смены кадров - с 60 Гц до 120 Гц. Мерцание счезло. Даташит разрешает максимально ставить до 128 Гц включительно. Разрешение 400 x 240 портретный режим Объясните, зачем надо делать инверсию кадра или линии в LCD? Картинка ниже. Влияет ли высокая частота обновления на долговечность дисплея? (по сути ускорилось чтение картинки из видеопамяти контроллера дисплея )
  22. Никому теперь ничего платить не надо. Истёк патент на MP3 и его отдали в свободное плавание... К тому же в VS1053, 1063 есть свободный OGG Vorbis
  23. Не намного, чтобы с 8.3.5 слезть на 8.0.4. Под DSP скомпилянная программа такого рода: 1) Декодирование аудио, пожатого кодеком CELT - 48 кбит/c через 1 канал McASP 2) Отрисовка графики, её поворот в видеобуфере на 90 градусов. Буфер 400x240 пикселей 16 бит 3) Перенос буфера в LCD с VSYNC с помощью PRU #2 4) Опрос кнопок PRU #1 5) Считывание файлов с SD карты в High Speed Mode через 1-битный SPI 6) Распаковка сжатых данных ZLIB 7) Поддержка файлов FatFs 8) Расчёт физики (столкновения объектов, взаимодействие с твёрдым телом) с помощью физ-движка на вещественной арифметике 9) Микширование на 8 каналов звуков (WAV PCM) + 1 канал музыка (декод CELT пункт 1) В Linux я работаю крайне редко, при условии, если линуксоеды просят что-нибудь портировать на эту Ось ))
  24. 64 разряда Да! ))) кое-как себя убедил на Win7 перейти, к сожалению на WinXP было более удобнее. Скачал 8.04 и 8.2.8. Мне показалось, что проект собирается быстрее. C++ 03 Mode хватило. Правда, компилятор ругнулся на _nassert'ы (пришлось задефайнить их в ничто) и не нашёл функцию memset (пришлось <string.h> явно подрубить в сорец). Скорость работы программы(скомпилянной для DSP) во всех 4-х версиях (8.0.4 , 8.2.8, 8.3.3 и 8.3.5 ) остаётся одинаковой!