Запустил minigui на новом драйвере - мне понравилось. Думаю стоит обратить на него внимание, особенно скорость. Если честно - fltk на моем экране сливает ему по полной :) Одно плохо - непонятна ситуация с лицензией, сейчас есть gpl версия но такое ощущение что они делают скрипя сердцем и запросто могут прекратить поддержку gpl ветки. В аттаче edillo. В интернет я пока не заходил с него - не дома сейчас, клавиатуру с собой не стал брать :) А вообще - все нормально собирается с uclibc.

У меня к плате подключен 320x240 LCD ( 18-bit цвет).
В LCD уже есть видео-контроллер. С аппаратной точки зрения
видно две ячейки памяти. Одна для записи адреса( IR),
вторая для записи данных(DR).
Т.е. для изменения одного пикселя надо сделать следующее

Код

volatile int* ir=0x..; // указатель на index register
volatile int* dr= 0x..; // указатель на data register
// Установить X координату
*ir = X_REGISTER;
*dr = X; // 0..319
// Установить Y координату
*ir = Y_REGISTER;
*dr = Y;//0..239
// записать цвет пикселя
*ir = COLOR_REGISTER;
*dr = COLOR; // 18-bit value

Как лучше реализовать механизм работы для Linux драйвера ?
Насколько я понимаю работу framebuffer, то изображение
формируется в непрерывном массиве памяти.
А потом надо настроить пересылку из памяти SDRAM в память видео-контроллера. В теории это возможно и пересылка
будет работать быстро потому, что при записи COLOR регистра
будет работать автоинкремент адреса.
Примерный код для пересылки массива из framebuffer в LCD

Код

for ( ndx =0; ndx < 320 * 240 ; ndx++) *dr = framebuffer[ndx]

Но насколько я понимаю в AT91SAM9260 нет контроллера ПДП для пересылки память-память.

Да и незачем гонять данные беспрерывно.
Наверное будет лучше писать прямо в память видео-контроллера?

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно MiniMax 04.03.2009 г. в 14:33:43

framebuffer драйвер позволяет писать данные непосредственно в память видеоадаптера. В моем случае создается виртуальный framebuffer содержимое которого непрерывно синхроннизируется с дисплеем. Это не очень эффективно если честно но лучше чем ничего, но у меня без вариантов потому что интерфейс однонаправленный - я ничего не могу читать с реальной видеопамяти - только запись. В вашем случае я не знаю. Нужно посмотреть на примере готовых драйверов как поступают - я не специалист в этом, просто нужно было попробовать и я занялся этим. Еще вариант - писать драйвер под что-то конкретное, например для nano-x требуется реализовать помоему всего 4 ф-ции: нарисовать точку в указанных кординатах, прочитать точку по координатам, нарисовать горизонтальную линию и вертикальную линию. Все остальное nano-x сделает сам. Имхо в вашем случае эффективнее реализовать эти ф-ции. В моем случае опять же прочитать точку не получится и нужно городить огород с виртуальной памятью - в общем тот же виртуальный фреймбуффер. minigui помоему тоже позволяет что-то подобное. Какой у вас дисплей , имеется ввиду наименование ? Может погуглить на предмет готовых драйверов ? Контроллеров lcd не так много и часто это клоны какого то известного, большая вероятность что кто-то уже делал для подобного драайвер.

Хорошо. Я попробую. Сообщу результаты.
А зачем читать ?
Мне надо было читать в некоторых проектах с последовательным односторонним интерфейсом только, когда
одним байтом кодируется несколько пикселей.

Мой дисплей MTF-TQ24NN731-LB
http://www.microtipsusa.com/product_pdfs/Color%20TFT/MTF-TQ24NN731-LB_Ver.B_18-bit_20071126.pdf

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно MiniMax 04.03.2009 г. в 22:46:22

Цитата

А зачем читать ?

для драйвера framebuffer требуется ф-ия fb_read - чтение заданного количества байт с заданной позиции видеопамяти, для драйвера nano-x требуется ф-ция чтение точки. Для чего это нужно им - это их внутренние потребности и я не знаю :)

Посмотрел драйверы для похожих lcd правда с 8 битным интерфейсом 8080 - тоже делают виртуальный framebuffer в RAM, а потом периодически пересылают данные в видеопамять. В вашем случае думаю будет достаточно быстро работать даже без pdc. Например у меня перед пересылкой по spi сначала заполняется специальный буфер а потом только данные отправляются. У меня вариант с параллельным потоком который непрерывно в цикле гоняет данные 130х130х1 байт съедает примерно 5 % cpu при частоте spi 6 МГц (данные переправляются непрерывно так что своеобразной задержкой служит как раз синхронная передача их по spi - процесс засыпает в ожидании окончания пересылки через механизм completion в spi_sync)

Код

static int pcf8833_thread(void *param)
{
int i;
struct pcf8833_par *par = (struct pcf8833_par *)param;

// set_user_nice(current, 5);

while(!kthread_should_stop()) {
for(i = 0; i < MEM_LEN; i++)
par->screen[i*2] = par->buffer[i];

spi_sync(par->spi, &par->msg);
}

return 0;
}

(PS par->screen[i*2] = par->buffer[i]; i у par->buffer съедает cms) в spi их отправляет pdc так что процессор занят только заполнением буфера тоесть примерно вашим циклом

Код

for ( ndx =0; ndx < 320 * 240 ; ndx++) *dr = framebuffer[ndx]

но 1300. Если делать обновление например с частотой 10Гц то процессор будет практически ненагружен а если еще добавить теневой буфер и делать сравнение и пересылать только при изменении то в моменты простоя можно вообще не нагружать процессор но с другой стороны если есть изменения будет делаться двойная работа :) Например так

Код

static int pcf8833_thread(void *param)
{
struct pcf8833_par *par = (struct pcf8833_par *)param;
int i;

while(!kthread_should_stop()) {
/* Optimize refresh: transfer image only when it has changed */
if(memcmp(par->shadow, par->buffer, MEM_LEN)) {
memcpy(par->shadow, par->buffer, MEM_LEN);

for(i = 0; i < MEM_LEN; i++) {
/* write some stuff */
}
}
schedule_timeout_interruptible(REFR_TIME);
}

return 0;
}

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно sasamy 05.03.2009 г. в 20:55:31

А никто не пробовал прикрутить USB LCD? Что-нибудь вроде этого: LCT 4300U

Вот и подтверждение моего недовольства качеством и скоостью драйверов spi у атмела:
http://www.at91.com/samphpbb/viewtopic.php?f=12&t=5607&sid=df0572ada80a77ea5675a61b8e50884e