Попробуйте аллоцировать для фотографии отдельно кусок памяти (malloc(размер_в_байтах)), в этом буфере отрисовать, а затем с помощью memcpy скопировать в область, на которую отображен файл фрейм-буфера.

Не забудьте потом освободить аллоцированную память вызовом free(указатель).

Поработав немного с фреймбуфером, понял, что через память хоть и быстрее, но все равно медленно. Если, к примеру, выводить на весь экран цветную фотографию, то ее отрисовка очень хорошо видна глазом, хотя и длится, наверное, меньше секунды. Но всё равно кажется, что долго. Наверное существует некий способ "покадрового воспроизведения"? Например, я сначала строю изображение в отдельной области памяти, а после этот блок памяти (?)целиком(?) копирую во фреймбуфер. Пока логически я так думаю что это возможно, но как это реализовать на практике...

Есть такая партия! (с)

В случае с Тионом посмотрите на файл /etc/init.d/rcS
(в общем случае этот файл может называться и по-другому, но искать его надо примерно в /etc/init.d и обращать внимание на файлы типа rc.sysinit, rcS и т.п.)

По поводу настрое СОМ порта выскажу своё мнение: если вы его один раз настроили и потом закрыли, то, конечно при повторном открытии настройки останутся те же, но лучше на это не расчитывать, а в своей программе при каждом открытии СОМ-порта его корректно настраивать.

Применю пока способ №2, а там посмотрим. Еще интересно знать куда-бы мне поместить shell-скрипт, чтоб он каждый раз при запуске системы выполнялся? Должно быть что-то типа "автозугрузки", чтобы Поместить туда все настройки, отключение энергосберегающего режима у дисплея, параметры COM-порта... и они бы автоматом выполнялись при загрузке, ну и заодно свою прогу туда записать.

я знаю 2 способа решения этой задачи:
1) написать драйвер, который действительно будет использовать прерывания, считывать данные откуда-нибудь и их выдавать.
2) написать просто программу, которая будет с помощью допустим вызова select отмерять достаточно точно время (засыпая на период неиспользования) и делать нужную работу. При этом возможность считывать то, что нужно из пространства пользователя должна быть.

Возник вопрос - как мне привязаться к таймеру реального времени. Например, мне нужно один раз в секунду считывать с переферийного устройства информацию и выводить ее на экран. Можно ли как-то отловить его прерывание?

И самое интересное - там нигде не говорится прямым текстом, что это для работы с СОМ-портом. Там на одной страничке объясняется понятие communication resource и говорится, что СОМ-порты тоже к ним относятся. А дальше идет очень долгое описание как работать со всеми этими communication resource-ами. Вобщем чтоб понять - надо или прочитать всё или заранее знать, где искать.

В описании WinAPI для работы с СОМ-портом много подробностей, касающихся 1) синхронизации (есть там специальные т.н. overlapped структуры, которые (точно уже не помню) содержат кажется дескриптор объекта синхронизации, через который можно поток усыплять, к примеру, пока операция не завершилась 2) настроек СОМ-порта касательно data-flow-control (аппаратный, софтверный или без управления, какие On-Off символы использовать и т.д.). Но там действительно очень размыто (мне хватило запалу распечатать всё на бумаге, перевести полностью, а потом на основе этого перевода уже сварганить работающий код, который после нескольких упрощений стал совсем хорошим - работал без глюков и кочевал у меня из программы в программу, если интересно, могу поискать его и поделиться с вами. Писал тоже на Дельфи. Там можно совсем по-простому - так же как в Linux-е - открыть файл и писать в него и читать. Конечно, управляющие линии изменять уже сложнее. Но вроде бы для дельфи написали какой-то компонент для этих целей уже достаточно давно - чтоб совсем не думать.

Про uboot я не стал вникать, на шнуре сопли были, грешил на плохой контакт, потом пробовал - неработал с hyperterminal из винды, загрузил ubuntu, попробовал с minicom - все работает. Не знаю с чем это связано. Потом вообще отпала необходимость что-то править в КФС тиона, ну я и забыл про это.
Про права, я подзревал, что существенная разница конечно есть, но опять же не вникал. Как-то пытался писать прогу по работе с COM-портом под винду - запарился читать мануалы! Windows API - дремучий лес. Множество примеров, написано на эту тему много разного, интерфейс вроде не самый сложный, но подружить его с виндой - это жесть. В общем в конце концов вроде удалось создать рабочее приложение, но мелкие глюки все равно были! И я так и не разобрался до конца. У меня не хватает терпения разбираться, когда не работает в соответствии с написанным. Это было в ХР. В 98 все было гораздо проще - в дельфях вставил фрагмент ассемблера и через регистры с прерываниями все прекрасно работало. Собственно, именно поэтому я сейчас и выбрал линукс, посчитал, что она более приспособлена для таких вещей, и думаю что не ошибся, пока меня все устраивает. Выбрал еще и потому, что дома тоже поставил года два назад Ubuntu, сейчас нисколько не жалею, даже с пользовательской точки зрения - вполне приемлимая система. Лицензионную винду с читой душой стёр после нескольких месяцев обитания в убунту, так как понял, что дома она мне уже совсем не нужна! Сейчас "кармик коала" (9.10) стоит, все прекрасно. Один раз настроил - и забыл, работает без сбоев, не надо постоянно поддерживать систему в рабочем состоянии, как винду.

Да пустое, интернет штука такая - никогда не знаешь на кого нарвешься)

Ясно... ну вот, а я вам нравоучения про UART читал... мне даже стыдно теперь :) Разобрались, почему у вас тогда не получалось в U-Boot зайти?

С Qt наверно, конечно интереснее было бы... но вообще, ваш пример еще раз доказывает, что Linux - очень удобная для программиста система. Вот допустим в Windows смогли бы вы напрямую писать в фрейм-буфер? Можно сказать, конечно, что это плохо, когда каждый кто хочет куда хочет пишет. Но в Linux-е ведь не кто хочет и не куда хочет, а только тот, кто имеет право и только в том случае, если соотв. файл не занят уже кем-то. Т.е. бардак исключается.

И по поводу системы прав тоже... вот я сначала, когда узнал как в Unix-е права назначаются, долго был озадачен. Сравнивал с Windows NT, выходило, что Unix-овая парадигма (пользователь-группа-остальные) менее гибка, чем NTFS-ная, где можно каждому файлу назначить пользователей, которые будут иметь к нему доступ. Ну и понимая это ждал, когда же я наткнусь на ситуацию, что мне понадобится так сконфигурировать права доступа разных пользователей к разным файлам, что не хватит максимально разрешенного числа групп, в которых может состоять один пользователь.
В реальности оказалось, что мне ни разу не приходилось даже в две разные группы включать пользователя (не то что в 8 или 16) с целью разграничить доступ к файлам. Т.е. Unix-овая модель прав оказалась очень компактной, лёгкой для понимания и при этом достаточно гибкой, в отличие от модели NTFS, где расшаривание ресурсов иногда для меня превращалось в танец с бубном (особенно если для этого надо было звать админа, который понимал не лучше меня в этом обилии окошек и чекбоксов).

Просто я недавно начал осваивать подобный уровень программирования, так что для меня это немного сложно. До этого писал только для контроллеров, преимущественно на ассемблере.

Нет, сильно не отличается, просто фреймбуфер имеет свою структуру, что связано с кол-вом бит на пиксель, определяющих цвет пикселя, с разрешением дисплея. Короче свои мелкие особенности имеет, хотя ничего "из ряда вон". В общем-то всё просто, как всегда оказывается, когда разберешься.

Это здорово. А что работа с тем же фреймбуфером через файл устройства, отображенный на память, сильно отличается от просто работы с файлом, отображенным на память? В любом случае если поделитесь - думаю, лишним не будет.

Разобрался, с
1. Работа с файлом устройства через память
2. Принципы работы с фреймбуфером
3. Работа с тачскрином

Немного освоюсь и опишу подробнее, если надо.