Всё правильно. Вчера оптимизировал код, максимум удалось получить 12.7 кадров в секунду, не хватает времени контроллеру, а дисплейчик явно способен на большее.
А если взять допутсим АРМ и сжать видео в жпег формате? З.Ы. если кто незнает то есть такой формат видео где все кадры сжимаются в жпег. Помоему этот формат самый простой и не потребудется много времени для декодировки. Зато места будет занимать в десятки раз меньше... Вот только проблема как написать декодер или где взять готовый код для декодирования этого формата... З.Ы. ЗЗЗЗЗ.ЫЫЫЫЫЫ...: Хотя кстати тут в теме ктото писал что АРМ потянет декодиролвку видео...
_________________ Шуруп забитый молотком держится намного лучше чем гвоздь закрученный отверткой!
Открыта удобная площадка с выгодными ценами, поставляющая весь ассортимент продукции, производимой компанией MEAN WELL – от завоевавших популярность и известных на рынке изделий до новинок. MEAN WELL.Market предоставляет гарантийную и сервисную поддержку, удобный подбор продукции, оперативную доставку по России.
На сайте интернет-магазина посетители смогут найти обзоры, интересные статьи о применении, максимальный объем технических сведений.
чтоб видео по юсб слать это еще и для компа нужно прогу какуюто типа захвата экрана или чтото типа а это тоже гемор. и еще не стоит забывать что сжатое видео уменьшает скорость потока. Мне когдато давно заказывали сделать видеоролик. Просьба заказчика была - сделать полные несжатые кадры. Так у меня это видео с 720 пикселями по горизонтали на старом компе так тормозило ужасно. А дело в том что поток большой. На сжатое видео нужно больше процессорного времени зато поток будет намного меньше. Я так понял на контроллерах еще никто не пробовал декодировать видео? Мне кажется стоит попробовать какойто формат попроще...
_________________ Шуруп забитый молотком держится намного лучше чем гвоздь закрученный отверткой!
Продукция MOSO предназначена в основном для индустриальных приложений, использует инновационные решения на основе более 200 собственных патентов для силовой электроники и соответствует международным стандартам. LED-драйверы MOSO применяются в системах наружного освещения разных отраслей, включая промышленность, сельское хозяйство, транспорт и железную дорогу. В ряде серий реализована возможность дистанционного контроля и программирования работы по заданному сценарию. Разберем решения MOSO
подробнее>>
Avarges
Заголовок сообщения: Re: Дисплеи от мобильных телефонов- осцилограммы работы
Я так понял на контроллерах еще никто не пробовал декодировать видео? Мне кажется стоит попробовать какойто формат попроще...
Так попробуй Обычная вычислительная задача, главное чтоб контроллеру хватало ресурсов на распаковку. Не обязательно даже сразу за MJPEG браться, можно и что попроще: индексированные цвета, RLE.
Разобрался с дисплеем LPH9135-3 теперь: из телефона Siemens C72, 16 битный цвет выводится, размер экрана 128*128 отличия в инициализации небольшие, можно и в 12 битном цвете использовать, кино с SD карты сразу пошло в уголок выводится, без переделок. Цветопередача мне понравилась намного больше - желтый цвет почти то, что надо.
А вот подсветку от 5 вольт не запитать, подключал 12 вольт через 1.5кОм резистор.
Распайка из гугла правдивая: Pin number Pin name Pin Description I/O 1 LCD_CS Chip Select (active low) O 2 LCD_RESET Module Reset (active low) O 3 LCD_DC Data / Control Indicator O 4 LCD_CLK Serial Clock O 5 LCD_DATA Serial Data O 6 VDD Power Supply 2.9V DC O 7 GND GND O 8 LCD_ID LCD ID (usually not used) I 9 BL_A Backlight Anode O 10 BL_K Backlight Cathode O
а не могли бы вы поподробней рассказать каким образом вам удалось вывести видео на экран, какой формат видео использовали, и каков алгоритм программы
_________________ Мечтатель - не тот, кто сидит на диване и думает о несбыточном, а тот, кто всеми силами стремится воплотить несбыточное в реальность.
Уже же описали это всё - кадры несжатые были, т.е. просто набор пикселей Что еще не понятно? Какой алгоритм? Три вложенных цикла - кадр, строка, столбец - это даже алгоритмом сложно назвать.
Foks, немного не так - без вложенных циклов, порядок такой:
1. Подготавливается файл с потоком пикселей в формате RGB 444. 2. Инициализируется дисплей в режиме цветов - 12 бит. 3. Задаём дисплею размер квадрата и дальше непрерывно выгружаем подготовленный файл с пикселами: читается 1 байт по SPI с SD карты и сразу отправляется в дисплей.
// Командой 2С сообщаем дисплею, что пикселы пойдут Send_to_lcd( CMD, 0x2C );
// Отправляем в дисплей пикселы в любом количестве // рисуются они попиксельно слева направо и сверху вниз // когда кадр отрисуется то начинает рисоваться следующий поверх Send_to_lcd( DAT, color ); // Вывод первого пиксела Send_to_lcd( DAT, color ); // второго Send_to_lcd( DAT, color ); // третьего ....
Делая так в 8 раз ускоряется вывод 1 пиксела, потому что на один пиксел вызываем Send_to_lcd только 1 раз, а не 8
Появилась у меня одна шальная мысль. Ведь эти дисплеи требуют последовательной загрузки данных, а что если взять внешнюю мс 74HC165, её тактировать от 32 МГц, к мк она подключается по параллельному интерфейсу, а выгружает последовательно. На базе атмеги8 нарастить в 2-3 раза FPS чтобы.
Сам сейчас подключил через чип CP2102 мк к компу, получил 1Мбит канал по USB. Но чтобы отрисовать один кадр 128*128 нужно передать 32768 байт, то есть в теории 2.7 фпс по такому каналу, на практике без оптимизации сразу получил жалкие 1.8 фпс Думал раньше, что чип CP2102 способен выдать честные 12Мбит USB Full-Speed, ошибся.
Ну допустим. А что с синхронизацией? Как осуществлять тактирование HC165-й? Кто будет давать контроллеру сигнал о передаче следующего байта? Контроллер самостоятельно эти операции не проделает (скорость маловата будет), давать такт на HC165 с внешнего источника бессмысленно - не будет синхронизации с МК. Тут бы с ПЛИСиной поэкспериментировать..
Avarges писал(а):
Думал раньше, что чип CP2102 способен выдать честные 12Мбит USB Full-Speed, ошибся.
А я раньше думал, что CP2102 - преобразователь UART->USB. Вы документацию на CP2102 смотрели? Там черным по белому написано: " Baud rates: 300 bps to 1 Mbits"
_________________ pavel_cydenov: Вобще я праAVRославный человек. Но и про ислARM слышал много хорошего ) MrYuran: Самые ортодоксальные — это PICудеи ) Katz: Не, 51-ники. )
Features USB 2.0 compliant, full-speed (12 Mbps) No external crystal required Up to 1024 Bytes of EEPROM or EPOM User-programmable custom Baud rates Supports all modem interface signals Baud Rates: up to 2 Mbps Industrial temp –40 to +85 °C
_________________ RETI ;рети-рети интеррапт, через шины данных тракт, через память, через порт, возвращайся в главный код @hobbyelectronics
Ну и что? Этого можно было даже не приводить. А теперь заглянем сюда: http://www.sparkfun.com/datasheets/IC/cp2102.pdf Asynchronous Serial Data BUS (UART) z All handshaking and modem interface signals z Data formats supported: - Data bits: 5, 6, 7, and 8 - Stop bits: 1, 1.5, and 2 - Parity: odd, even, mark, space, no parity z Baud rates: 300 bps to 1 Mbits z 576 Byte receive buffer; 640 byte transmit buffer z Hardware or X-On/X-Off handshaking supported z Event character support z Line break transmission
_________________ pavel_cydenov: Вобще я праAVRославный человек. Но и про ислARM слышал много хорошего ) MrYuran: Самые ортодоксальные — это PICудеи ) Katz: Не, 51-ники. )
Ясно. Но Avarges, видимо, все же рассчитывал на все 12М..
_________________ pavel_cydenov: Вобще я праAVRославный человек. Но и про ислARM слышал много хорошего ) MrYuran: Самые ортодоксальные — это PICудеи ) Katz: Не, 51-ники. )
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
Что еще не понятно? Какой алгоритм? Три вложенных цикла - кадр, строка, столбец - это даже алгоритмом сложно назвать.
