Jump to content

    

__inline__

Участник
  • Content Count

    1012
  • Joined

Everything posted by __inline__


  1. Были, есть: OMAPL137BPTPH на 300+300 МГц (DSP + ARM) даташит omap137-ht.pdf, страница 201: Написал в личку. Почему сняли? На сайте TI статус "active" (зелёный) : http://www.ti.com/product/OMAPL137-HT
  2. Появились новые платы для TMS320C674x + SDRAM + видеоконтроллер Epson. По вопросам приобретения плат/комплектации пишите на е-mаil: repstosw2018 [сoбaкa] gmail [ТOЧКA] com
  3. Мда... А без этой бредятины OPMAP-L137 в QFP невозможно приобрести? В BGA оно как-то не очень. Так. Теперь всё ясно. Открою секрет: остатки со складов не попадают под санкции ))) если на территории РФ. Но это может для очень мелких и не очень знаменитых контор. С Компелом и Электронщиком такое не прокатит.
  4. Смотрим цену со складов. Это вообще нормально? Или может ошибка какая?
  5. Можно подумать, что МК со встроенным микроконтроллером устранит оптические недостатки матрицы LCD :) Тему закрываю по причинам: флуд, недостаточная компетенция участников форума, вопрос решён.
  6. Мне тоже очень хочется многое. Только в отличие от вас, я не терроризирую форумчан дурацкими вопросами, а читаю соответствующую литературу. Здесь за вас никто не будет делать вашу работу. Берите в зубы буквари и статьи из интернета, даташиты микросхем, каталоги магазинов - и вперёд!
  7. Хорош порожняк гнать в тему! Потому что программа разрабатывалась под ПК где монитор 60 Гц. При 120 FPS всё идёт быстро в 2 раза )))
  8. Я не рассказываю полный бред. Своим глазам я верю больше, чем анонимам с форума. Я сюда пришёл с конкретными вопросами, а получил кучу флуда, которого от вас больше всего. Это говно. Держал такой в руках, в динамике картинки с артефактами. Мне вот как раз есть чем заниматься. А вам с DASM'ом похоже, что нет. )) И как интерфейс подключения влияет на качество картинки матрицы LCD? Бред написали. Провели эксперимент. Показали движущиеся картинки с дисплея приставки SEGA MD Portable нескольким людям. Всех всё устроило, а меня нет. Из замеченных мною недостатков были: 1) малые углы обзора 2) белёсость чёрного 3) смазывание пикселов на мозаичных(шахматных) элементах 4) ненасыщенные цвета 5) "золотой" оттенок изображения 6) Полоски при движении Лишь только пару человек смог убедить в половине недостатков, остальным всё идёт. Так что если быдло хавает дерьмо, почему я должен согласиться с тем что дисплеи IPS хороши? Кота в мешке не собираюсь покупать. Всегда смотрю дисплеи в действии на телефонах - если устраивает - выковыриваю. И кстати, дисплей тоже с контроллером Ilitek !!! (надо же! и тут совпадение! ))) все дисплеи с белой пластмассовой каёмкой и удобопаяемым гибким шлейфом вместо разъёма - Г О В Н О ! ! ! Что такое "нормальные контроллеры" ? Дайте определение. Есть ли такой инженерный термин вообще? Есть параллельная шина, допускающая подключение дисплеев по ней. Особенно когда есть DMA и сопроцессоры. Совершенно верно. На повестку дня выношу затерянный в дебрях флуда актуальный вопрос:
  9. Это как-то не стыкуется с вашим утверждением в первом посте: Зачем так извращенствовать? Выход ЦАП через разделительный конденсатор 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 В действии:
  10. У меня интересы чисто хоббийные: найти телек на местной барахолке не составляет никаких проблем - было бы желание! Это в назидание страждущим, кто думает что ЭЛТ умерли. Не дождутся! )) Вот совсем недавно зарелизил игровую консоль 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. И там будет видеовыход на ТВ.
  11. Знаю. Но проследил такую закономерность: если чип от Ilitek, значит матрица - говно. Потому что китайцы. А они очень любят Ilitek )) С чего это вдруг? Активно используем для получения гладкого движения изображений! Что касается IPS, то : На этом можно поставить крест: для моих целей не годится. Только для вывода статичных голых баб, как подметил DASM :)
  12. Глянул дисплеи по приведенным вами ссылкам - они все на базе Ilitek'овского контроллера, а это - говно по определению. Я уже вдоволь нажрался илитековского говна в ардуино-шилд-дисплеях: не устроило качество картинки - под разными углами плохо показывает, цвета белёсые, уровень чёрного хреновый и - те же полоски что в начале темы. Дисплей от GX500 который использую намного лучше вышеозначенных. Илитеком недоволен в плане оптики - качество изображения годится разве что для индикации в технических приборах. Смотреть видео или играть в игры на таких дисплеях я бы не хотел и другим не рекомендую. Статья про IPS и AMOLED. https://www.iphones.ru/iNotes/amoled-protiv-ips-v-kraskah-primerah-i-testah-05-26-2019 В общем, дерьмо эти IPS.... ЭЛТ лучше будет!
  13. Мне бы что-нибудь с шиной 8 или 16 бит как интерфейс SRAM P.S. Проблему решил: оставил развёртку 120 Гц + 2 VSYNC для процессинга 60 FPS. Всё работает ниче не мерцает полоски ушли. Я доволен, но пришлось немного попотеть )))
  14. Да не за что )) Вы можете это проделать сами очень легко - ничего сложного !
  15. Пирамида Маслоу... Жажда к творчеству. Бабы её не заменяют. ))) Ничто не помешает. Вылезет какой-нить артефакт типа смазывания картинки при движении или в полосках всё будет. Ну и какова скорость обмена данными с таким дисплеем? Мне надо не ниже 60 кадров в секунду отрисовывать на 400x240, при этом цвет не хуже 16 бит.
  16. Сомнительно, что IPS будет отлично казать вот такую вещь (с 960-й секунды): https://www.youtube.com/watch?v=VlaP-7SIHz0&t=960
  17. Вы видать незнакомы с аркадными автоматами начала 80-хх - конца 90-х ))). 320x240 там не нужна чёткость, наоборот, небольшое размытие там даже на руку ибо квадраты не видны. Сомневаюсь, что вы их взяли чтобы спрайты гонять. ))) На просмотре видео эффект не будет себя проявлять. Только если будет скролл картинки по горизонтали
  18. Ещё бы знать какой IPS окажется нормальным :) Много дисплеев разных покупал, оставался доволен только OLED'ами, так как они как-будто созданы для 2D-анимации. Мне нужно, чтобы нарисованные на дисплее спрайты двигались плавно на +1 пиксел за 1 VSYNC. При этом если спрайт начинает: шлейфить, мазать, кривиться или мерцать вертикальными полосками (как в сообщении в шапке темы), то дисплей объявляю неподходящим для моих целей. А голых баб статичных выводить может каждый LCD, другое дело, что будет с картинкой, если её начать плавно крутить по горизонтали на +1 пиксел за 1 рефреш дисплея?
  19. Потестировал этот 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 не знает, пришлось задефайнить разыменовыванием указателей, что не совсем верно.
  20. Помню, работал на ПК в начале 2000-х, был монитор ЭЛТ ViewSonic G55 с нативным разрешением 800x600 85 Гц. Хороший был монитор! Картинка чёткая, ничего не мерцало. И самое главное - плавность движения была просто великолепная как на всех ЭЛТ мониторах! LCD до такого далеко и сейчас. Что касается ТВ, то их кинескопы моргают ощутимо, если краем глаза смотреть. Стараюсь использовать NTSC вместо PAL где возможно. И там есть такой артефакт: при резких сменах яркости монотонных участков большой площади, происходит "разбухание" фрагмента изображения - он мог слегка искривлять изображение или выходить за пределы кадра (неравномерность свечения люминофора) На счёт "эффекта памяти" в LCD в курсе. Был такой дисплей MTF-T022 (контроллер S6D0129) - он мог отключать все эти инверсии, картинка была превосходной. Но за это пришлось расплатиться тем, что если картинка оставалась долго неподвижной, то при смене картинки появлялся рельеф от старой и был какое-то время :) Поэтому приходится выбирать компромиссы: 1) либо полоски с низкой частотой обновления 2) либо отсутствие полосок, но с мерцанием 3) отсутствие полосок и повышенная частота обновления 4) отсутствие полосок и эффект памяти (деградация) дисплея 5) радикальный переход на ЭЛТ P.S. Ещё не родился на Земле тот глобал, который придумал бы LCD с превосходным качеством анимации картинки с точностью +1 пиксел ))
  21. Статья на русском: http://lcdtech.info/data/lcd.technologies.htm Короче, делаю вывод, что со времён изобретения электронно-лучевой трубки, ничего лучшего человечество не придумало (для воспроизведения плавнодвижущихся объектов). Все эти LCD - фигня, по сравнению с ЭЛТ.
  22. Интересная статья про LCD на тему: http://machineryequipmentonline.com/video-equipment/liquid-crystal-display-lcdpolarity-inversion/ Перевод ключевых моментов: Вот как оказывается! Инверсия кадра приводит мерцанию с частотой в 2 раза ниже частоты обновления. Проще говоря, 60 кадров в секунду дисплея мерцают с частотой 30 Гц - отсюда противные ощущения при просмотре. Поэтому только повышать частоту кадров до 120 Гц, чтобы мерцание было на 60 и незаметным. Так как инверсии точек данный LCD не поддерживает, а инверсия линий приводит к мерцающим полоскам при движении. Дисплей снят с мобильника, где была портретная ориентация кадра и в пейзажный режим, да и ещё с плавной анимацией ихображения - не планировался в принципе )))
  23. Спасибо ответившим! Есть ли какой-нибудь способ сделать интервал процессинга программы равным 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?
  24. Цитата из первого сообщения: 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. Нет таких библиотек (читай: готовых решений под ключ). Все библиотеки работают с буферами источника и приёмника - в первый кладём что пожать, со второго берём пожатое. Или наоборот при декодировании. Дальше решаем сами что делать с данными.
  25. Звучит обнадёживающе... Всегда считал, что аппаратный кодек - это чип, который жмёт при записи и разжимает при воспроизведении. Пусть даже со своим DSP ядром внутри. А программный кодек - софт-вариант прошивки в управляющем контроллере, который реализует сжатие-разжатие программно. Остальное - просто АЦП и ЦАП, но называть их кодеком - всё-равно что называть ракетой жестянку без реактивного двигателя.