Отдали старую nokia 6101. У неё два цветных экрана, внутренний большой и внешний маленький, у маленького 10 выводов, у большого 22 вывода. Может есть у кого по ним какая информация?
Заголовок сообщения: Re: Дисплеи от мобильных телефонов- осцилограммы работы
Добавлено: Сб ноя 19, 2011 14:38:09
Нарыл англицкую книжку Лусио ди Джасио по PIC32 - там оказывается не просто есть примеры для вывода изображений, но и по видео. Кто язык знает и имеет возможность надыбать халявный PIC32 может попробовать свои силы.
Та глава с дисплеями от мобильных телефонов никак не связана. Там описана генерация композитного сигнала для вывода на обычные телевизоры (как в ZX-Spectrum).
Надеялся там увидеть распаковку MPEG2 или хотя бы какого-нибудь кодека с выводом на экранчик от мобильного. Тут был в соседней теме исходник вывода JPEG картинки на экран мобильника, так конечно скорость не супер, даже на ARM 0.2-0.3 секунды уходит на кадр, естественно 99% времени на распаковку JPEG
Отдали старую nokia 6101. У неё два цветных экрана, внутренний большой и внешний маленький, у маленького 10 выводов, у большого 22 вывода. Может есть у кого по ним какая информация?
Заголовок сообщения: Re: Дисплеи от мобильных телефонов- осцилограммы работы
Добавлено: Ср ноя 30, 2011 15:53:11
Друг Кота
Карма: 46
Рейтинг сообщений: 590
Зарегистрирован: Вт май 19, 2009 09:27:30 Сообщений: 3258 Откуда: Украина
Рейтинг сообщения:0
Здравствуйте, товарищи! Попалось стёклышко. Подскажите, пожалуйста что это, откуда, распиновку, протокол, ДШ - одним словом, можно ли его заюзать и как. Спасибо!
Судя по шлейфу похоже на дисплей от nokia5800, надо поискать по форумам ремонтников по маркировке.
Спасибо! А как подпаять, заюзать?
Схему можно найти, а вот заюзать очень трудно будет, вернее практически невозможно Там последовательный интерфейс, вернее два - LoSSI и HiSSI (скоростной дифференциальный). Где-то на vrtp.ru я об этом читал.
Удалось поднять 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.
Попробовал ваш код (ради интереса) и сравнил с апаратным SPI, небо и земля, апаратный SPI гораздо быстрей. Почему вы не используете апаратный SPI ?
Аппаратный SPI использовал для чтения данных с SD. То что сам дисплей можно подключать к SPI в первый раз слышу и вообще-то сомнительно это. Если уж у вас получилось - рапортуйте о подробностях, всем пригодится.
Удалось поднять FPS при выводе видео на дисплей, на неожиданную для себя величину: с 12.8 кадров в секунду до 17.9. Поэтому продолжу писать про оптимизацию алгоритма, может кому-то потом пригодится.
....
Попробовал ваш код (ради интереса) и сравнил с апаратным SPI, небо и земля, апаратный SPI гораздо быстрей. Почему вы не используете апаратный SPI ?
А можете исходники показать, и насколько быстро выводит.
А чего рапортовать-то, сдесь вроде тоже самое есть,
Код:
// запись одного байта в дисплей voidlcd_write8(char dat) { spi(dat); //1 байт в регистр данных SPI }
// запись двух байт voidlcd_write_(unsignedint dat) { lcd_write8(dat>>8); lcd_write8 (dat); }
voidlcd_c(void) { CS= 1; #asm("nop") CS= 0; }
// выбор регистра в контроллере дисплея voidlcd_reg(char register_name) { lcd_write8(0x74); // стартовый байт на передачу команды lcd_write_(register_name); lcd_c(); }
// отправка двух байт в графическую память дисплея voidlcd_dat8(char register_dat1, char register_dat2) { lcd_write8(0x76); // стартовый байт на запись данных lcd_write8(register_dat1); lcd_write8(register_dat2); lcd_c();
}
// то же самое, но из 16-и битной переменной voidlcd_dat(unsignedint data) { lcd_write8(0x76); // стартовый байт на запись данных lcd_write_(data); lcd_c(); }
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения