Jump to content

    

__inline__

Участник
  • Content Count

    791
  • Joined

Everything posted by __inline__


  1. Усовершенствованный вариант Lossless видео-кодека "PackMan" - с мульти-стратегическим конвейером. Теперь жмёт ещё лучше! Не совместим с ранними версиями ! Исходники усовершенствованного кодера/декодера, там же и билды под Win32, DOS: PackMan_r2_.zip Исходники усовершенствованного декодера для nanoPlayer: nanoPlay_PackMan2.zip Вариант печатной платы (4-слойка) герберы: nanoPlay_Gerber.zip Демонстрационное видео на ЮТУБ: http://www.youtube.com/watch?v=ZCZwsP3rf8Y
  2. должны быть, но не обязаны. Я глянул даташит на V3s что у меня есть (на английском), там расписаны времянки, но самих стробов CS, WR, адресные биты A* на выводах микроконтроллера НЕ нашёл. Таблицы мультиплексирования выводов тоже молчат. Просто приводят картинку с времянками, которая как бы намекает, что без дополнительной логики (ПЛИС, ЦПЛД,рассыпуха) не обойтись: У вас даташит другой или тоже английский? Был один головняк(SDRAM), будет два (преобразователь SDIO в i8080 для LCD :) ) А линукс и камадроид не даст ответов на этот вопрос, потому что там везде "стандартная" связка LCD с v3s по RGB-интерфейсу.
  3. Смотрел даташит на v3s и схему камдроида на нём и пришёл к 2-м печальным выводам: 1) шина там только на 8 бит 2) и только RGB, а не i8080, управляющих стробов (nWR,nRD,nCS) я не нашёл, также как и их описания в даташите. Кусок подключения LCD к v3s в камдроиде: И проиграть в помехозащищённости - гнать БИТОВЫЙ клок, который должен быть в 8- или в -16 раз больше по частоте чтобы битики в байты преобразовать (некий параллельный регистр с последовательной загрузкой). Ну и нагромождение. А один фиг тупую матрицу прийдётся цеплять на SPI или I2S, так что одним RGB-интерфейсом не отделаешься! А вот если i8080 - то это уже сказка! :) Но беда в том, что C6745 который мне так понравился в QFP содержит только 16 и 8 битную шину, а хочется 32 и 16 как в БГА :) Нашёл тут ещё кандидата - STM32H743 - у него 1 Мбайт внутренней оперативы на частоте 400 МГц- весь код эмулятора туда можно затолкать, 32 бита SDRAM - на случай если некоторвые эмуляторы не поместятся + чтение РОМ-ов для эмуляторов + спроецированная FatFS - всё в SDRAM! Ну и RGB интерфейс там 24-битный (в корпусе LQFP208 точно!) и 32 разряда на SDRAM. И ещё питание одно - 3.3V, нет дополнительного гемороя с питанием как в Оллвиннерах и C6745. Ядро Cortex-M7 с его вкусным многооперандными командами Ассемблера типа: addeq r0,r1,r2 LSL r3 - 4 действия в одном - это лучше чем BF532 на 400 МГц и его 16-битной шиной! И наличие плавающей точки! И QFP корпус. И шить можно ST-LINK-ом то бишь дискавери. И 2D- ускоритель с 2-D DMA, цвет прозрачности, BitBlt - это всё для эмуляторов нужно!! :) Одни плюсы! В общем вижу его в кандидатах на замену 532-го. :santa2:
  4. Смотрю в даташит на 6745 и вижу - 2 шины EMIF A, B, что очень радует. Но огорчила урезанность шин в 2 раза в QFP корпусе: вместо 32- и 16- имеем 16- и 8- соответственно. Посему возник вопрос. Планирую дисплей с шиной 16 бит (LCD, не тупая матрица) соединить по шине 8 бит. Можно ли сделать 16-битность дисплею таким макаром: CPU LCD D0-----D0 D1-----D1 D2-----D2 D3-----D3 D4-----D4 D5-----D5 D6-----D6 D7-----D7 BA0----D8 BA1----D9 A0------D10 A1------D11 A2 ------D12 A3------D13 A4------D14 A5------D15 A12-----Command/Data CS[]-----LCD CS nWR-----LCD nWR Pull Up----LCD nRD И обращаться к регистрам/ данным дисплея так: обращаться к памяти LCD: *(int*)(LCD_Data_Base|(Data>>8))=Data; к командам: *(int*)(LCD_Command_Base|(Command>>8))=Command; Всёравно для дисплея нужен только 1 адресный бит, более ничего на шине не будет. А SDRAM будет висеть на 16-битной шине. Пройдет или нет? Правда , ещё DMA-пересылки надо будет хорошо продумать при таком подключении
  5. Такой же DMA есть и в ADSP BF532,533. Так и называется 2D-DMA! :) Там можно приращения разные задавать по X и Y, возможнен вариант с "топтанием на месте через 1" - для растяжения пикселей по обеим осям. На счёт направлений не скажу, но в целом оставил у меня хорошие впечатления. Активно его использовал при отрисовки кадра в эмуляторах. Зеркально? :)
  6. Чтоб не быть голословным: сделал и закачал архив(ссылка ниже), в котором результаты сжатия трёх кодеков: - VP9: 18.1 МБ - Lagarith: 12.8 МБ -PackMan v.2 (мульти-стратегический): 12.6 МБ Исходное видео: 52.3 МБ что при пересчёте с 8 на 6 бит на компоненту - в эквиваленте 39.23 МБ (младшие 2 бита каждой цветовой компоненты оригинального видео =0). Там же бат-скрипты, утилита для воспроизведения ffplay и новая версия кодера/декодера PackMan (мультистратегический). На более длинных видео - результат будет ещё лучше в пользу PackMan Архив: https://dropfiles.org/2Sn пароль к архиву 13169
  7. У вас есть опыт работы с этим камнем без пингвина и ведра? Внешней шины для подключения дополнительной периферии, наподобие как FSMC у STM32 у V3s как я понял нет? Если так - прощай дисплеи с контроллерами и своей памятью .. Тот что в QFP OMAPL137-HT недоступен для заказа из-за политики США по отношению к РФ. В БГА мне неинтересно.
  8. Всё-же уделил время на VP9 и затестил его в режиме лосслесс через ffmmpeg: rem VP9 кодек Lossless конфа ffmpeg -i 0.avi -c:v libvpx-vp9 -lossless 1 output.webm Результат обнадёжил : 390 МБ против моих: Packman rev.0: 234 МБ rev. 1: 228 МБ Мультистратегический: 224 МБ Лагариф и МСУ также лучше: 242 и 247 МБ соответственно. Так что хвалёный VP9 на лосслесс оказался хуже "старых" добрых MSU и Lagarith. И жмёт ещё долго, по сравнению с PackMan и Lagarith. Выводы я сделал.
  9. Вам осталось сделать ещё один небольшой рывок - доказать, что AV1 и VP9 битэкзактны. Есть сомнения по поводу. Ну и глупо искать по нарицательным именам конкретные видеоролики, тем более версии, заточенные под 160x128. Но ваш намёк понял - вот вам моё встречное напутствие: встречного ветра и якорь вам в... :)
  10. AV1 и VP9 - не lossless. MSU - не древний, живёт и процветает до сих пор. http://www.compression.ru/video/ls-codec/ Lagarith я бы не сказал что древний
  11. Здравствуйте. Ищу процессор в QFP корпусе, который будет производительнее, чем ADSP BlackFin BF532. Цель: запуск обильного кода с 2D графикой (bitblt, colorkey, alfablending) + немножко 3D (поворот, перенос, масштабирование), тригонометрия. + эмуляция процессоров -8 и 16 бит: Z80, 6502, M68000. + декодирование видео (H264, MJPEG,...) аудио (MP3, FLAC) Пробовал собирать эмуляторы на BF532, разогнал до 700 МГц. Иногда эмуляция всей системы не достигает 60 FPS из-за отсутствия floating point, медленной производительности. В качестве кандидата на замену рассматриваю : TMS320C6745 - доступен, корпус QFP, 475 МГц, шина SDRAM 32 бита, есть floating point, VLIW до 6 команд одновременно. Вроде как лучше чем BF532 ? Или даст выигрыш по сравнению с 532-м незначительно?
  12. Что за шланг? GCC arm-noeabi ? Насколько хуже будет код GCC по скорости по сравнению с ARMCC ? Да, подвисает зараза, когда много сорцов проекта открыто. По этой причине редактирую код в Блокноте, а фишки компиляции со сборкой в проект - в Кейле. Насколько оправдан и затратен переход на GNU ToolChain? Файлы линкера и мейк-файлы писать умею.
  13. А разве не порвёт C6745 BF532 хотя-бы из-за: 1) VLIW до 6 команд одновременно - против 2 команд у BF532 //выигрыш в 3 раза 2) SDRAM 32 бит - против 16 бит у 532-го // выигрыш в 2 раза 3) Hardware floating point - против софтварных целочисленных рядов Тейлора на 532-м //выигрыш в специфических местах 4) 475 МГц - против 400 // несущественно, но приятно 5) У BF532 - скудный малооперандный ассемблер, в отличие от того же ARM. У C6745 вроде как по-лучше? В целом вижу оправданным переход на C6745. Поправьте, если ошибаюсь.
  14. Рассматривал JPEG2000 Lossless, его программная реализация (которая есть в открытом виде) - очень громоздка для переноса на МК STM32F407 и алгоритм просто не пошёл (из-за применения менеджера кучи для данных и кода). К тому же, кодек MJPEG2000 Lossless проигрывает по степени сжатия даже тому же Lagrith. Dirac - тоже жмет хуже Lagarith и требует много вычислительных ресурсов. HuffYUV - прост, но хуже всех жал. MSU - нет исходников Lagarith - хотел вначале портировать его, но мой кодек его обскакал по сжатию (в анимешных мультфильмах) Остался 1 путь - написать свой, взяв всё лучшее со всех. Я - человек науки, поэтому тут ещё дополнительно академический интерес. Жал много фильмов, мультфильмов, коэффициент сжатия был не ниже 2. Обычно от 2.8 - 3. Конечно, если жать белый шум, то выигрыша не даст :) Пробовал применить ZLIB, слишком затратно по времени на декодирование. LZH тоже. Так что только энтропийное кодирование. ---------------------------------- Я вот тут подумал и сообразил новый Мульти-Стратегический кодек. Суть его в том, что пробуются все возможные сочетания блоков конвеера на предмет сжатия. И выбирается лучшая стратегия. Если исходный сигнал у нас - это RGB, то блоков конвеера у нас 5: 1) преобразование YCbCr 2) WaveLet преобразование 3) Difference преобразование (межкадровое вычитание) 4) Huffman 5) RLE Просчитал, возможно 64 комбинации, они на рисунке ниже. Написал кодер, прогнал вариант 3): "Space Cobra": 1034.24 МБ С учётом 6 бит из 8: 775.68 МБ PackMan rev.0: 225 МБ PackMan rev.1: 211 МБ получилось 187 МБ против 211, что неплохо! Причем задача декодирования нисколько не усложняется, а наоборот даже - в некоторых случаях конвейер декода будет короче, номер стратегии пишется в хедер - каждый номер определяет жестко заданный порядок декодирования . Это немаловажно для STM32F407. Восклицательным знаком помечены те варианты, которые были распознаны как оптимальные по сжатию. (подсчитал статистику по стратегиям )
  15. В SNES-эмуляторе графическая система на floating point. Эмулятор Snes9x. Потому что : поворот, растяжение, текстурирование :) Особо упоротые реализации в CPS1/2 - синтез звука на floating point. Вот я и хочу понять, насколько осчастливят меня ARM Kinetis, или всё-же лучше взять C6745, который будет по-лучше прошлого варианта эмулятора с ADSP BF532? Если оно того не стоит, то насколько будет удачен выбор Allwinner A13, v3s для эмуляторов? (без линукса правда, в стиле баре-метал)
  16. -HT - в QFP Это хотел сказать, что нужна плавучка, а то как она реализована - в виде юнита или в составе команд основного АЛУ - уже не интересует :) В смысле, что экзамплы входят в неё или нет? Наподобие как у Visual DSP: в папке есть примеры работы с периферией Блекфина (наподобие SDK). А почему бы и нет? Ха! Эмуляция только одного графического чипа Capcom Play System-2 и его звуковой части Q-Sound + FM- синтез чего только стоят. Быстрая числодробилка напрашивается!
  17. В разработанном устройстве "nanoPlayer" и на ПК ошибок нет и быть не может (при условии, если настройка режимов ядра и периферии выполнены корректно). Если же говорить о линии связи или промежуточном агенте переноса информации (радиоволны, оптоволокно и прочее...), то в данном кодеке используется форсированная вставка ключевого фрейма - каждый 12-й кадр, что даёт время восстановления 1 секунду при 12 FPS. В новой ревизии 1 кодека, ключевой кадр может идти чаще, но не реже, чем 1 раз на 12 кадров. Ok, спасибо! Я перепробовал 4 версии кодера Хаффмана (качал с гитхаба) и все они жали по-разному. Был даже один вариант, который декодировался с ошибкой. Я выбрал тот, который при проверке не даёт ошибок и с лучшим сжатием.
  18. Хороший вопрос! :) Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет? huffman.txt Иногда, когда много пустоты в кадре из-за пустой таблицы частот приходится дожимать с помощью RLE поверх Хаффмана.
  19. OMAPL137-HT в QFP корпусе. В свете сегодняшних политических событий его вряд-ли возможно из США в Россию передать. Так сказал mouser.com. Порылся в ТиШных DSP, нашёл ещё красавца - TMS320C6745 - тоже в QFP, версия 456 МГц. Если его сравнить с BF532 на 400 МГц, то очевидно , что TMS лучше ? Заинтересовал VLIW и наличие FPU, чего нет у Блекфина. А также подключение SDRAM с шириной ШД аж 32 бита! Ну и доставаем. На счёт Code Composer Studio, поддержка TMS там на уровне? Или всё спрятано в линуксах? С БГА пичаль, мне надо чтоб без ухищрений распаять. Или всё-же долбить Allwinner? Я очень часто работаю с чужим исходным кодом и не могу позволить себе роскошь потратить время на тотальное переписывание исходных кодов эмуляторов (это не только процессор, но и периферия). Это к вопросу "Либо вы точно знаете свои алгоритмы и что в них хотите улучшить, либо не знаете" Ну и ZX эмулировать совсем неинтересно. GameBoy Color или NES куда интереснее будут! :)
  20. Я конечно могу привести таблицу, но поверят ли? Проще проверить было самому. Тесты: 1) "Винни-Пух": 211 МБ С учётом 6 бит из 8: 158.25 МБ PackMan rev.0: 59.6 МБ PackMan rev.1: 56.9 МБ Lagarith: 69.4 МБ MSU: 46 МБ 2) "Yurizan Beltran": 406 МБ С учётом 6 бит из 8: 304.5 МБ PackMan rev.0: 106 МБ PackMan rev.1: 102 МБ Lagarith: 98.5 МБ MSU: 97.7 МБ 3) "Space Cobra": 1034.24 МБ С учётом 6 бит из 8: 775.68 МБ PackMan rev.0: 225 МБ PackMan rev.1: 211 МБ Lagarith: 240 МБ MSU: 178 МБ 4) "Ashton Pierce": 877 МБ С учётом 6 бит из 8: 657.75 МБ PackMan rev.0: 234 МБ PackMan rev.1: 228 МБ Lagarith: 242 МБ MSU: 247 МБ Во втором случае кодек проиграл всем остальным по сжатию. В четвертом случае - победил всех. В большинстве случаев разработанный кодек между Lagarith и MSU по степени сжатия, при этом не уступающий в скорости кодирования-декодирования (про MSU лучше вообще не вспоминать, там где нужна скорость декодирования) Реализовал улучшенный вариант кодера: PackMan rev.1, декодер остался тем же. Когда отлажу, выложу. Я смотрел на ней[железке] весь сериал "Space Cobra" все 31 эпизодов по 25 минут каждый.
  21. Для BF532, BF533 я абстракцию писал сам :) На выходе получилось что-то вроде своего SDK (или API), делающий всю необходимые функции: установка клоков CPU, SDRAM, SPI, настройка периферии, стека , кучи... Повезло что Блекфины линуксоеды и прочие ОСо-любы не испортили :)
  22. Под этот же плеер исходники с прошивками, декодирующие: ADPCM, MP3, FLAC, MJPEG, MP4(H264): nanoPlay_IMA_MP3_FLAC_MJPEG_H264.zip
  23. Нет, GUI не нужен. Нужно просто быстрое ядро под универсальные алгоритмические задачи (эмуляция 8- и 16- битных процессоров) + обработка графики (копирование из одной области памяти в другую, копирование массива в регистр данных дисплея). DDR я как понимаю будет лучше смотреться, чем обычная PC133 SDRAM. Приобрёл 2 платы на A13: Olinuxino и SOM-модуль. И-за текущих работ не могу пока до них добраться, поэтому в режиме сбора информации. Есть ещё v3s, к счастью там не надо DDR разводить. Ничё, время лечит, думаю за пол-года-год будет SDK "чистый поток сознания", наподобие как китайцы перелопатили SPL-говнокод на "регистры" для STM32. Если нет, то сам займусь. Под железным подходом имел ввиду - не использовать HAL, OS; только хедеры регистров и их бит. Ну может ещё что-то типа SPL допускается. Не более! Никаких абстракций, только имена регистров и их биты! Ну писать только C/C++, Asm , никаких питонов, сишарпов и прочих джав. Вы как человек с опвытом можете сказать, OMAP-L137 отвечает моим хотелкам или там тоже абстракция с пингвинами?
  24. Фото плеера: Принципиальная схема (элементы, помеченные как NC - отсутствуют): Видео в действии (на мерцание экрана не обращать внимание, это из-за фотоаппарата): video1.zip и video2.zip
  25. Есть ли достойная замена STM32F... на частоте от 400 МГц, QFP корпус, внутренняя память не менее 512 кБ с железным подходом программирования?