Вы документацию на CP2102 смотрели? Там черным по белому написано: " Baud rates: 300 bps to 1 Mbits"
Как начал с ним заниматься конечно скачал даташит. Я чип этот полтора года назад купил, тогда мне всё, что выше программного USB (со скоростью 6400 бод) было за счастье, потому что устройство было не ради видео.
Кислый писал(а):
в полудюплексном режиме он работает до 2М
Попробую, если сработает - уже лучше, хотя получается внештатный режим. Как атмега8 на 3 вольта и 16мгц
Кислый писал(а):
Baud Rates: up to 2 Mbps
Я понял откуда эта цифра взялась, на той странице ведь не про CP2102 конкретно, а про линейку чипов, начал глядеть их отличия, нашёл что CP2104 по даташиту даёт эти самые up to 2 Mbps.
SubDia писал(а):
Avarges, видимо, все же рассчитывал на все 12М
Ага, в следующий раз буду внимательнее. Хотел не глядя купить AT91USB или ARM7, теперь сначала почитаю даташит - на какой скорости они с USB дадут работать.
SubDia писал(а):
Ну допустим. А что с синхронизацией? Как осуществлять тактирование HC165-й?
Глупая идея, конечно. Мне лишь бы в магазин за более мощным чипом не ехать
Мне лишь бы в магазин за более мощным чипом не ехать
Знакомая ситуация. Самому нужно съездить за кварцевым генератором на радиорынок, а я в отпуске, и последние несколько дней дальше магазина в соседнем доме не хожу. =) Что ж, желаю удачи в экспериментах.
_________________ pavel_cydenov: Вобще я праAVRославный человек. Но и про ислARM слышал много хорошего ) MrYuran: Самые ортодоксальные — это PICудеи ) Katz: Не, 51-ники. )
Удалось поднять FPS при выводе видео на дисплей, на неожиданную для себя величину: с 12.8 кадров в секунду до 17.9. Поэтому продолжу писать про оптимизацию алгоритма, может кому-то потом пригодится.
Вот тут
Цитата:
Код:
// Отправляем в дисплей пикселы в любом количестве // рисуются они попиксельно слева направо и сверху вниз // когда кадр отрисуется то начинает рисоваться следующий поверх Send_to_lcd( DAT, color ); // Вывод первого пиксела Send_to_lcd( DAT, color ); // второго Send_to_lcd( DAT, color ); // третьего
byte_to_send = data; LCD_CLK=0; LCD_DATA=0; if ((RS_old != RS) || (!RS_old && !RS)) { // проверяю старое значение RS и тут (мол если прутся одни команды то дергаем CS) LCD_CS=1; LCD_RS=RS; LCD_CS=0; } for (mm = 0; mm < 8; mm++) { //собсно цикл передачи данных LCD_DATA = (byte_to_send >> 7); LCD_CLK=1; // защелкиваю в дисплей byte_to_send = (byte_to_send << 1); LCD_CLK=0; // готовлю к следующей защелке } RS_old=RS; // запоминаю значение RS LCD_DATA = 0; }
Пикселы идут всегда с первым параметров для процедуры Send_to_lcd( DAT, ... сразу можно убрать проверку эту " if ((RS_old != RS) || (!RS_old && !RS))", вместо этого один раз перед выводом пикселов:
Код:
// Обнуление LCD_CLK=0; LCD_DATA=0;
// Сообщаем что данные пойдут LCD_CS=1; LCD_RS=1; LCD_CS=0;
Дальше лучше процедуру Send_to_lcd вообще не использовать, потому что каждый вызов процедуры это RCALL и RET команды, по даташиту 3 и 4 машинных такта теряем на каждый пиксел. Поэтому лучше сразу вытащить вывод пиксела прямо в код:
Код:
unsignedchar mm, cc, color; ... cc = color; for (mm = 0; mm < 8; mm++) { //собсно цикл передачи данных LCD_DATA = 0; if (cc > 127) { LCD_DATA = 1; }
LCD_CLK=1; // защелкиваю в дисплей cc = (cc << 1); LCD_CLK=0; // готовлю к следующей защелке }
Но после этого всего я получил только 12.8 FPS, а 17.9 после того как последний кусок превратил в прямой код (без цикла):
Подглядывал как WinAVR это компилирует в ассемблер, в файле .lss получается красивый код на базе SBRC, SBI, CBI команд. И вот такой код уже даёт 17.9 FPS на том же самом видео из Терминатора-2.
госпола.. а загляните в описалово к mpeg. там передается не сама катринка, а приращение. там где его нет или оно очень маленькое - его просто аннулируют и вставляют биты пропуска.. попробуйте на примере того же 3gp
_________________ RETI ;рети-рети интеррапт, через шины данных тракт, через память, через порт, возвращайся в главный код @hobbyelectronics
Компания MEAN WELL пополнила ассортимент своей широкой линейки светодиодных драйверов новым семейством XLC для внутреннего освещения. Главное отличие – поддержка широкого спектра проводных и беспроводных технологий диммирования. Новинки представлены в MEANWELL.market моделями с мощностями 25 Вт, 40 Вт и 60 Вт. В линейке есть модели, работающие как в режиме стабилизации тока (СС), так и в режиме стабилизации напряжения (CV) значением 12, 24 и 48 В.
Побаловалссо тут маленько с камерой от Siemens C-72.
В правой части платы, конечно, бардак - там я временно устанавливал ПЛИС (был проведен ряд неудачных экспериментов). Камерой управляет ARM-контроллер STM32F100C4T6B. Камера у Семена C-72 собрана на сенсоре PO2030N (это девайс от PixelPlus). Этот же сенсор установлен в CF75. Из полезных особенностей отмечу возможность включения в VGA, QVGA и QQVGA режимах разрешения (640х480, 320х240 и 160х120). Картинку вывожу на дисплей от Nokia 6100 (контроллер Epson S1D15G10) разрешением 130х130 точек. Вот изображение, сделанное при тусклом освещении (пыльная лампочка 60 Вт, висящая далеко в углу))). Свет от настолки на качество съемки здесь не влияет, т.к. не падает на камеру.
_________________ pavel_cydenov: Вобще я праAVRославный человек. Но и про ислARM слышал много хорошего ) MrYuran: Самые ортодоксальные — это PICудеи ) Katz: Не, 51-ники. )
госпола.. а загляните в описалово к mpeg. там передается не сама катринка, а приращение. там где его нет или оно очень маленькое - его просто аннулируют и вставляют биты пропуска.. попробуйте на примере того же 3gp
А мужики то не знали... И что это дает? То, что весь ключевой кадр нужно держать в памяти, на ходу распаковывать и, сравнивая с ключевым, восстанавливать исходный...Тут все как прежде, АРМ не всякий, и не при любом разрешении справится. Это MPEG1, с современными форматами все куда интереснее, в малобюджетных решениях типа MP4-плееров производители продвигают свои форматы, оптимизированные под конкретный чип, в более дорогих решениях типа КПК и смартфонов, все зависит от мощности процессора и качества софтового кодека. Короче, Меге, да и простеньким АРМам, здесь делать нечего.
Кислый, вроде уже обсуждали недавно что контроллер не потянет распаковку mpeg. Как передается картинка в таком формате думаю тоже все знают. Я уже писал насчет формата mjpeg. Он попроще намного и с ним еще можно поэксперементировать. Правда контроллер лучше помощнее брать З.Ы. В любом случае какойбы небыл формат к нему еще декодер нужно писать
_________________ Шуруп забитый молотком держится намного лучше чем гвоздь закрученный отверткой!
А если допустим засылать отличия мелкими квадратами, вместе с координатами? Естественно не mpeg, а свой кодек написать. Жалко нет прозрачного пиксела или мы его ещё не нашли.
О, mpeg1.. на пятом курсе этот формат отправил меня на пересдачу по Основам телевидения. Ну да ладно.
Avarges писал(а):
если допустим засылать отличия мелкими квадратами
Я думаю, что разницы не будет. Просто будет больше телодвижений для контроллера. Возможно, ошибаюсь.
Avarges писал(а):
Жалко нет прозрачного пиксела или мы его ещё не нашли.
Его не существует.
_________________ pavel_cydenov: Вобще я праAVRославный человек. Но и про ислARM слышал много хорошего ) MrYuran: Самые ортодоксальные — это PICудеи ) Katz: Не, 51-ники. )
Я думаю, что разницы не будет. Просто будет больше телодвижений для контроллера. Возможно, ошибаюсь.
Не ошибаетесь, а разница будет только в том, что все будет еще медленнее и печальнее, это ж придется распаковав текущий "квадрат" подгружать соответствующий участок ключевого кадра, а это немалая потеря времени. Да и засылаются они именно "мелкими квадратами", внимательно посмотрев на экран телевизора, особенно при просмотре содержимого с невысоким битрейтом это отчетливо видно.
_________________ На любой вопрос даю любой ответ
Последний раз редактировалось VDLab Сб ноя 05, 2011 20:55:41, всего редактировалось 1 раз.
А зачем ключевой кадр подгружать, я же и говорю, что рисовать поверх, потому и непомешал бы "прозрачный пиксел" (автоинкремент без рисования пиксела). На малодвижущейся картинке определенно будет выгода. Вообще лучше бы посмотреть что в себе 3gp несёт кроме ZIP сжатия и как там инженеры мобильников выкручиваются, перед ними та же задача стояла.
Подгружать его как раз и нужно потому, что "прозрачный пиксел" - это виртуальное понятие, реализуемое за счет вычислительных средств МК. Да и не в этом дело. Подгружать как раз и придется те участки, которые требуется изменить. Ведь чтобы вычислить разницу нужно знать, что было в оригинале... Короче, не пытайтесь изобрести велосипед. А инженеры мобильников начали встраивать запись видео в своих телефонах только после того, как вычислительная мощность процессоров, встраиваемых в них, позволила на лету сжимать и расжимать видео этого формата, опять же, разработанного под относительно слабенькие процы телефонов того времени.
Эх, как я надеялся не услышать этот вопрос ни от кого. Фреймрейт весьма и весьма фиговенький. Я не проводил точного измерения, но примерно около 5 кадров в секунду. Поясню почему. Во-первых, максимальная тактовая частота контроллера - 24 МГц. Во-вторых, дисплей с последовательной шиной данных. В-третьих, дисплей не способен воспринимать 16-битные данные, вследствие чего мне приходится проделывать определенный алгоритм преобразования принятых от камеры данных. А именно прием первых четырех байт данных от камеры (это данные двух пикселей - по 16 бит на каждый) и преобразование четырех байт в 3 байта 12-битных данных. Отсюда и низкая скорость. Сейчас хочу попытаться запустить дисплей от Nokia N71 (320x240). Проблема в том, что я сломал разъем, но попробую приладить на тонких проводках. У дисплея параллельная шина данных, а также способность воспринимать 16-битный цвет, то есть необходимость преобразования отпадает - можно будет транслировать данные от камеры прямо на дисплей.
_________________ pavel_cydenov: Вобще я праAVRославный человек. Но и про ислARM слышал много хорошего ) MrYuran: Самые ортодоксальные — это PICудеи ) Katz: Не, 51-ники. )
А почему собственно сразу ARM всплывает когда речь идёт о этих дисплеях? Ведь есть например PIC18F2550 на 48МГц работает, USB аппаратный - должен с запасом потянуть.
Одно но, если на этих 48МГц будет 48MIPS, то есть в 3 раза быстрее можно будет на порт выставлять данные. А то мало ли что означают эти 48 МГц, может микрочиповцы такие же хитропопые, как разработчики CP2102 у которых 12Mbit означают реально в 12 раз меньше Пока читаю даташит, слово "MIPS" не ищется в нём.
А почему собственно сразу ARM всплывает когда речь идёт о этих дисплеях?
Потому что это самая распространенная архитектура среди современных МК и МП, которые смогут осилить работу с видео. Есть, конечно же, МК и других архитектур.
Цитата:
Ведь есть например PIC18F2550 на 48МГц работает, USB аппаратный - должен с запасом потянуть.
Одно но, если на этих 48МГц будет 48MIPS, то есть в 3 раза быстрее можно будет на порт выставлять данные. А то мало ли что означают эти 48 МГц, может микрочиповцы такие же хитропопые, как разработчики CP2102 у которых 12Mbit означают реально в 12 раз меньше Пока читаю даташит, слово "MIPS" не ищется в нём.
У 8-битных ПИКов машинный цикл составляет 4 такта, поэтому на 48МГц у него максимальная производительность 12 MIPS. А 12Мбит/сек не будет ни с одним МК, потому как в эти 12мегабит входит и служебные данные, поэтому скорость полезного потока может лишь в большей или меньшей степени приближаться к этой цифре, эта степень зависит не только от мощности МК но и от качества софтовой части. Реально на этих МК добивались скорости полезных данных что то около 700-800 кБайт/сек.
Ключевой кадр полюбому нужно подгужать рано или поздно. mpeg кодеки все работают с ключевыми кадрами. Без этого никак. А вот как часто подргружать ключевой кадр это уже другой вопрос. Альфа канал (прозрачный пиксель) это не что иное как вычесление предыдущего пиксела с следующим посредством значения альфа. Тоесть это тоже функция а следовательно трата времени. в 3gp тоже используются ключевые кадры. Сам ключевой кадр тоже сжат и на его распаковку тоже нужно время Chettuser, pic32 вроде на 40 мгц работает если не ошибаюсь. С этим контроллером думаю можно поигратся. К томуже у него вроде встроенный аудиовыход уже есть. Мне кажется на таком контроллере можно уже думать насчет распаковки видео. Только ненужно изобретать велосипед насчет декодера. Декодер видео лучше сдереть готовый. Это уже давно придумано до нас. Остальное - дело техники
_________________ Шуруп забитый молотком держится намного лучше чем гвоздь закрученный отверткой!
Сейчас этот форум просматривают: Majestic-12 [Bot] и гости: 9
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
