Библиотека SSD1289

[Cyber_RAT]

rd на чем висит?
поставьте по парочке nop между wr для увеличения длиннны WR.
а lpc не надо включать периферию и др? (в sam7s так там и тактирование перефирии надо врубать и еще пачку телодвижений делать надо)
гляньте в .lst (или как он у вас называется (листинг ассемблера)) не викидывает ли оптимизатор чего (паузы например)

и еще - везде в примерах SCS |= 1; а вы везде | выкидываете... не силен в СИ - но может это критично? (выкидываете е только в этой строчке)

startup у вас подключен вообще? который перефирию заводит клоки и тд?

и еще... чего у вас unsigned long ? (по моему это 64 бита будет (ну или 32 минимум)) у yarunt было так
typedef unsigned char BYTE;
typedef unsigned short WORD;
typedef unsigned long DWORD;
typedef unsigned int BOOL;

void WrCmd(BYTE cmd);
void WrDat(WORD data);

а у вас
void WrDat(unsigned long int data)
void WrCmd(unsigned long int cmd)
ну и тд... может и тут чего... но это вопрос к гуру по С
p.s. и что насчет нестабильных уровней rs и wr ?

[Galogramer]

А это нормально . что void SetReg описывается после LcdInit?

[andrik.us]

Подскажите, как включить альбомную ориентацию. Записываю в регистр 0х14, а=0 по даташиту, все-равно остается вертикальная ориентация. Или я не правильно делаю?

[011119xx]

мля... казалось бы, если инитится - значит пайка ОК... а оказалось D7 - непропай... вот до 127 и рисовало а дальше нет
вот итог пропайки


Uragan90: замедлите скорость вывода на дисплей - ибо очень длинные провода у вас... может помехи ловить. джитаг есть? если есть идите по шагам, ресет подали - преверили - есть он на дисплее или нет, потом cs rs wr... выставьте на данных 0101010101010и и тд... а потом наоборот 0 с 1 поменяйте и тоже тестером пройдитесь... (сразу будет понятно все ли еденицы и нули на месте)... все получится!!!

На шрифт можно посмотреть?

[vovan_zh]

Решил тоже наконец то занятся этим дисплеем на PIC18. Дисплей из первой партии отсюда. https://kazus.ru/forums/showthread.php?t=19448
Сначала использовал исходник и инициализацию из первого поста этой темы. Функция FillScreen() перерисовывает только 1/5 экрана (полоска слева правильного цвета). Изменения начала координат (SetAddress(100, 100) )смещают полосу вправо, а по вертикали так и остается во весь экран. Не подскажите куда копать?
Железо рабочее проверял на этом проекте http://www.techtoys.com.hk/PIC_board...4550-Rev4A.htm , все ОК! Там правда под ili9235, за основу взял инициализацию от сюда и чуть пришлось пошаманить с регистрами R01h и R11h (неправильно чертил).

[x-files72]

поройся здесь...
http://radiokot.ru/forum/viewtopic.p...4185&start=100
x-files - выкладывал (это я)
работает 100%

[vovan_zh]

Спасибо за еще один исходничик. Проблема оказалась как я и подозревал в разных типах данных для разных компиляторов (использую Mplab C18 ). Компилятор не правильно обрабатывал строку counter‹(320*240);, надо было counter‹(320L*240L); . Поставил counter ‹ 76800; и все пошло.
Удручила медленная скорость заливки экрана 950mS. 1 такт моего PIC18F4550 происходит за 83nS. Можно выжать из этого проца большей скорости прорисовки или выход 16 разрядные МК или ARM?

[st_1]

Удручила медленная скорость заливки экрана 950mS. 1 такт моего PIC18F4550 происходит за 83nS. Можно выжать из этого проца большей скорости прорисовки или выход 16 разрядные МК или ARM?

16 разрядные МК или ARM...
Не... можно Хайтэк попробовать, С18 тормозной... можно пооптимизировать... но результат будет отличаться несильно...

[vovan_zh]

То есть для даного ПИКа это нормально?
Кста ти да, Хайтек стоит попробывать, тем более что это мой первый проект для PIC18. А Хайтек PICC16 юзал с удовольствием. Но всеравно наверно надо ARM ставить, хотелось бы незаметной перерисовки окон (рисование\ удаление визуальных объектов).
По поводу оптимизации. Вот все выложенные здесь исходники дергают CS в каждой функции записи команды или записи данных, а можно просто забрать по CS, выполнить ппрорисову функции, а потом закрыть CS.
Возвращают значение RS после записи, зачем? Достаточно перед записью выставить нужное значение. Хотя для ARM это может и не актуально.

[pinco]

Быстрее можно только если сделаешь на дисплее который без внутреннего контроллера , просто с вводом параллельно пикселей 18 бит за один такт с 25 Мгц частотой к примеру , чтобы отбражать весь экран за 25 ms (обычная скорость обновления 40-50 Гц) , а не за 950ms , шустрых контроллеров и ARM даже не надо - берешь ПЛИСку , к ней шустрое ОЗУ по емкости = колич пикселей на размер экрана , а вот уже управление всем этим хозяйством уже не имеет значения с какой скоростью микроконтроллер ,можете использовать какие там у Вас самые отработанные и известные с какими привыкли работать, хоть самые древние PIC-и и AVR- ки , и все летает , а то так получается что отображение в мониках со встроенным контроллером продирается дважды - сначала в скорости вывода из Вашего ARM-а или еще какого , LPC например ,во встроенный контроллер , а затем из встроенного контроллера в собственно сам ЖКИ - но самое узкое место - в скорости обмена от Вашего проца к встроенному контроллеру ,и это при том что ему прежде чем просто вывести саму картинку , что требует нехилых ресурсов - её еще и сформировать прежде надо , что тоже весьма неслабо по затратам времени, ну в общем лишние задержки и загогулины получаются , факт .А с ПЛИС кой все просто - нужный пиксель выставил - координату , цвет 18 бит , и за 1 такт записал в ОЗУ и всё , он тут же отобразился на дисплее , и никаких там инициализаций и танцев с бубном , и быстро , и глазу приятно и плавно , так что рекомендую , да и дисплеев без встроенных контроллеров - гораздо больше чем моделей с встроенными контроллерами , а значит безконтроллерные еще проще найти на рынке , чем ккорячиться (уё еще то ) программировать те что с встроенными контроллерами , хотя возможно кому-то как раз наоборот - интересно возиться с такими как SSD1289 например , но даже если будет связка Ваш "быстрый" проц + встроенный контроллер дисплея - то все равно это медленно , и еще придется приложить немало усилий чтобы получить от таких дисплеев хоть какое то приемлемое для работы быстродействие .