Дисплеи от мобильных телефонов- осцилограммы работы

Avarges

Всё правильно. Вчера оптимизировал код, максимум удалось получить 12.7 кадров в секунду, не хватает времени контроллеру, а дисплейчик явно способен на большее.

Реклама

Зукс

А если взять допутсим АРМ и сжать видео в жпег формате?
З.Ы. если кто незнает то есть такой формат видео где все кадры сжимаются в жпег. Помоему этот формат самый простой и не потребудется много времени для декодировки. Зато места будет занимать в десятки раз меньше... Вот только проблема как написать декодер или где взять готовый код для декодирования этого формата...

З.Ы. ЗЗЗЗЗ.ЫЫЫЫЫЫ...: Хотя кстати тут в теме ктото писал что АРМ потянет декодиролвку видео...

Реклама

Foks

Да, этот формат называется MJPEG (Motion JPEG).
Можно взять опенсоурсный.

Avarges

А если взять допутсим АРМ и сжать видео в жпег формате?

Какой смысл? Ты раньше правильно писал: разжимать на компе и посылать по шине USB, это самое реальное.

Хотя кстати тут в теме ктото писал что АРМ потянет декодиролвку видео...

Современные форматы MPEG4 видео и H264 не потянет, особенно если ARM7

Реклама

Зукс

чтоб видео по юсб слать это еще и для компа нужно прогу какуюто типа захвата экрана или чтото типа а это тоже гемор. и еще не стоит забывать что сжатое видео уменьшает скорость потока. Мне когдато давно заказывали сделать видеоролик. Просьба заказчика была - сделать полные несжатые кадры. Так у меня это видео с 720 пикселями по горизонтали на старом компе так тормозило ужасно. А дело в том что поток большой. На сжатое видео нужно больше процессорного времени зато поток будет намного меньше. Я так понял на контроллерах еще никто не пробовал декодировать видео? Мне кажется стоит попробовать какойто формат попроще...

Реклама

Avarges

Зукс писал(а):Я так понял на контроллерах еще никто не пробовал декодировать видео? Мне кажется стоит попробовать какойто формат попроще...

Так попробуй

Обычная вычислительная задача, главное чтоб контроллеру хватало ресурсов на распаковку. Не обязательно даже сразу за MJPEG браться, можно и что попроще: индексированные цвета, RLE.

Реклама

Зукс

в ближайшее время буду начинать заниматся этим. Хотя меня больше интересует воспроизведение видео через юсб

Avarges

Разобрался с дисплеем 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

БАТАРЕЙКУС

Avarges писал(а):Научился я все-таки на атмеге8 кино гнать на этот экранчик,
на ютубе видео выложил:

http://www.youtube.com/watch?v=PqPR8k5EV-A

а не могли бы вы поподробней рассказать каким образом вам удалось вывести видео на экран, какой формат видео использовали, и каков алгоритм программы

Foks

Уже же описали это всё - кадры несжатые были, т.е. просто набор пикселей

Что еще не понятно? Какой алгоритм? Три вложенных цикла - кадр, строка, столбец - это даже алгоритмом сложно назвать.

Avarges

Foks, немного не так - без вложенных циклов, порядок такой:

1. Подготавливается файл с потоком пикселей в формате RGB 444.
2. Инициализируется дисплей в режиме цветов - 12 бит.
3. Задаём дисплею размер квадрата и дальше непрерывно выгружаем подготовленный файл с пикселами: читается 1 байт по SPI с SD карты и сразу отправляется в дисплей.

Bonio

Avarges писал(а):Научился я все-таки на атмеге8 кино гнать на этот экранчик,
на ютубе видео выложил:
http://www.youtube.com/watch?v=PqPR8k5EV-A

А не могли бы вы исходники показать?

Avarges

Bonio писал(а):
Avarges писал(а):Научился я все-таки на атмеге8 кино гнать на этот экранчик,
на ютубе видео выложил:
http://www.youtube.com/watch?v=PqPR8k5EV-A
А не могли бы вы исходники показать?

Они у меня уже переправлены под дисплей 9135, там всё в кучу. Могу в личку кинуть "как есть".

Если вопрос в том как получить максимальный FPS, тогда ответ прост.

Эту процедуру вывода одного пиксела...

Код: Выделить всё

void LCD_Pixel(char xPos, char yPos, char color) {
   Send_to_lcd( CMD, 0x2A );
   Send_to_lcd( DAT, xPos );
   Send_to_lcd( DAT, 127 );

   Send_to_lcd( CMD, 0x2B );
   Send_to_lcd( DAT, yPos );
   Send_to_lcd( DAT, 127 );

   Send_to_lcd( CMD, 0x2C );
   Send_to_lcd( DAT, color );
}

...использовать ТОЛЬКО для вывода одного пиксела.

Чтобы посылать кадр на весь экран делать лучше так:

Код: Выделить всё

   // Сначала задается размер квадрата
   Send_to_lcd( CMD, 0x2A ); // по горизонтали
   Send_to_lcd( DAT, 1 ); // координата левого угла
   Send_to_lcd( DAT, 100 ); // правого

   Send_to_lcd( CMD, 0x2B ); // по вертикали
   Send_to_lcd( DAT, 1 ); // верхнего
   Send_to_lcd( DAT, 80 ); // нижнего

   // Командой 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

Bonio

Спасибо, Avarges. Если не трудно, скните исходник в личку.

Avarges

Скинул.

Появилась у меня одна шальная мысль. Ведь эти дисплеи требуют последовательной загрузки данных, а что если взять внешнюю мс 74HC165, её тактировать от 32 МГц, к мк она подключается по параллельному интерфейсу, а выгружает последовательно. На базе атмеги8 нарастить в 2-3 раза FPS чтобы.

Сам сейчас подключил через чип CP2102 мк к компу, получил 1Мбит канал по USB. Но чтобы отрисовать один кадр 128*128 нужно передать 32768 байт, то есть в теории 2.7 фпс по такому каналу, на практике без оптимизации сразу получил жалкие 1.8 фпс

Думал раньше, что чип CP2102 способен выдать честные 12Мбит USB Full-Speed, ошибся.

SubDia

Ну допустим. А что с синхронизацией? Как осуществлять тактирование HC165-й? Кто будет давать контроллеру сигнал о передаче следующего байта? Контроллер самостоятельно эти операции не проделает (скорость маловата будет), давать такт на HC165 с внешнего источника бессмысленно - не будет синхронизации с МК. Тут бы с ПЛИСиной поэкспериментировать..

Avarges писал(а):Думал раньше, что чип CP2102 способен выдать честные 12Мбит USB Full-Speed, ошибся.

А я раньше думал, что CP2102 - преобразователь UART->USB.
Вы документацию на CP2102 смотрели? Там черным по белому написано: " Baud rates: 300 bps to 1 Mbits"

Кислый

Я вас поздравляю.
А давайте заглянем сюда :
http://www.silabs.com/products/interfac ... ridge.aspx

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

SubDia

Кислый писал(а):USB 2.0 compliant, full-speed (12 Mbps)

Ну и что? Этого можно было даже не приводить.
А теперь заглянем сюда: 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

Кислый

в полудюплексном режиме он работает до 2М

SubDia

Ясно. Но Avarges, видимо, все же рассчитывал на все 12М..