Не подскажите как (гловально кодеки менчять нельзя, просто надо превратить русское сообщение функции streerror() в QString - передать сообщение об ошибке в параметр функции).

Оно как-нибудь зависит от настроек управляемых cfsetospeed()? Вернее так - эта скорость лимитируется аппаратурой, драйвером (и её можно настроить)? Можно достичь максимума соответствующего USB 2.0 или по serial device it`s impossible to be done?

Ткните неуча носом как настроить терминал в режим передачи двоичных данных а не текстовой информации?

Мне по нему тупо массивы байтов передавать/принимать при помощи read/write/select и не надо чтобы данные трактовались как строки! Где почитать про сие?

ЗЫ: с гуглом и яндексом под конец дня дружить перестал :(

На мобильном устройстве есть usb device который в системе торчит как /dev/ttyGS0. В настольную систему это устройство подключенное по usb торчит как /det/ttyACM0.

На мобильном устройстве запускаем прогу:

#include <fcntl.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/ioctl.h>

#include <iostream>

int main()
{
	int fd = open("/dev/ttyGS0", 0 );
	if ( fd == -1 ) std::cerr << "open: " << strerror(errno) << std::endl;;

	fd_set watch;

	while (true)
	{
		std::cerr << "wait in select" << std::endl;
		FD_ZERO(&watch);
		FD_SET(fd, &watch);

		int res = select(fd + 1, &watch, 0, 0, 0);
		if ( res == -1 )
		{
			std::cerr << "select: " << strerror(errno) << std::endl;
			return 1;
		}

		if ( res && FD_ISSET(fd, &watch) )
		{
			std::cerr << "Has data" << std::endl;
			int canRead = 0;
			if ( ioctl(fd, FIONREAD, &canRead) < 0 )
				std::cerr << "ioctl: " << strerror(errno) << std::endl;
			std::cerr << " size: " << canRead << std::endl;

			char array[canRead];
			res = read(fd, &array, canRead);
			if ( res == -1 )
			{
				std::cerr << "read: " << strerror(errno) << std::endl;;
				return 1;
			}
			std::cerr << " has read: " << res << std::endl;
		}
	}
}

на компе пускаем прогу:

#include <fcntl.h>
#include <unistd.h>
#include <iostream>
#include <errno.h>
#include <string.h>

int main()
{
	int fd = open("/dev/ttyACM0", O_RDWR | O_SYNC );
	if ( fd == -1 )
	{
		std::cerr << "open: " << strerror(errno) << std::endl;
		return 1;
	}
	std::cerr << "File descriptor: " << fd << std::endl;
	char array[18];
	int res = write(fd, &array, 18);
	if ( res == -1 )
	{
		std::cerr << "write: " << strerror(errno) << std::endl;
		return 1;
	}
	std::cerr << "Has write: " << res << std::endl;
	close(fd);
}

На мобильном устройстве реакции на запуск проги на настольном компе никакой! Хотя на echo 1 > /dev/ttyACM0 прога на мобильном устройстве срабатывает. И самое прикольное: если после представленной проги запустить echo 1 > /dev/ttyACM то будут пересланы все данные которые раньше якобы отсылала программа. Коточе ЧЯДНТ и чего не хватает в моих вызовах write???

Подскажите как в Qt читать из файлов устройств/именованных каналов. QFile напрямую не умеет оповещать о событиях прихода данных. Используя QSocketNotifier на дескрипторе объекта QFile можем получить сигнал activated по приходу данных, но дальше я уперся в то что не могу их прочитать! На любом вызове аля read для объекта QFile на чьем дескрипторе произошло событие приема прога безнадежно подвисает в бесконечном ожидании. Метод QIODevice::bytesAvailable() упорно возвращает для такого файла ноль!. Чего я не понимаю?

на embedded системе UDC (USB Device port от arm камня) устройство как в /dev именоваться будет при tmpdevfs?

Нужно чтобы udev к каждому /dev/ttyACMx создавал /dev/ttyUSBx что нужно вкурить в строку

KERNEL==«ttyACM*», SYMLINK+=«ttyUSB»

чтобы после ttyUSB доставлялась нужное число?

где можно прочитать как правильно формировать строки описания архитектурв (типа x86_64-unknown-linux)? Есть где список возможных?

Как заставить udev ставить 666 на доступ к таким устройствам?

В продолжение начатого (http://www.linux.org.ru/forum/development/5519881?lastmod=1289071768897)

Вот скрипт который собирает тулчейн для bfin-none-elf архитектуры из последних версий гнутых инструментов + гнутые тулзы для работы с Blackfin агрегатами. Собираются С и С++ кросс компиляторы + кросс отладчик и отладочный прокси, JTAG загрузчик, формирователь загрузочных ldr файлов. Для работы скрипта нужно чтобы в системе стоял набор пакетов разработчика достаточный для компиляции GCC 4.5 версии, а именно GMP + MPFR + MPC + PPL + CLOOG (версии можно уточнитьв мурзилке по сборке gcc). В OpenSUSE 11.3 все необходимое есть из коробки (если поставить через YAST или zypper).

Скрипт можно взять здесь: http://www.antario.org.ru/downloads/build-barematal-toolchain

Использование: ./build-baremetal-toolchain <директория установки тулчена> [get]

в директорию установки вы должны уметь писать, не в какие переменные среды её прописывать не надо. Указав вторым параметром слово get скрипт сам скочает сырцы если у вас из нет. Логи сборки с ошибками записываются в файлы build.log в соответствующих директориях. Перед сборкой никаких подкаталогов build существовать не должно!

Адаптация под другие версии утилит возможны путем замены соответствующих циферок в скрипте, если версии не сильно отличаются то скорее всего все пройдет успешно. Я тестировал на: binutils-2.20.1 gcc-4.5.1 gdb-7.2 CVS версии newlib 2010R1 вурсии тулзов для balckfin Возможно заменить и саму целевую архитектуру bfin-none-elf на что-нибудь другое что поддерживает что пускается на голом железе (но тогда не надо собирать blackfinовское барахлишко - записываем в TOOLS значение none). Для архитектуры bfin возмоно собрать elf2flt конвертор (переменная TARGET_SPECS должна принять значение flt )

ЗЫ: Вся эта деятельность навеяна тем что crosstool-ng под blackfin на baremetal так и не смог мне собрать 4.4 gcc - внутренняя ошибка промежкточного компиллера и усе. Есть конечно http://blackfin.uclinux.org/gf/project/toolchain но там староват компиллер с дополнительным велосипедостроением, а мне нужны возможности 4.5 ветки. Кому не надо не пользуйте, но вдруг кому пригодиться.

ЗЫЫ: Скрипт написан без применения вертолетостроительного шел программирования так что потенциально его понять может любой желающий.

ЗЫЫЫ: Не надо мне рассказывать что VisualDSP++ рулит, это не всегда так - основная причина это то масдай для нешей конторы умер навсегда.

Вот скрипт который собирает тулчейн для arm-linux-gnueabi- архитектуры из последних версий гнутых инструментов. Как не странно все не так сложно, потребовалось тако три небольших костылика на уровне скрипта сборки, в остальном НИКАКИХ патчей на ванильные утилиты. Собираются С и С++ кросс компиляторы + кросс отладчик и отладочный сервер для целевой архитектуры. Для работы скрипта нужно чтобы в системе стоял набор пакетов разработчика достаточный для компиляции GCC 4.5 версии, а именно GMP + MPFR + MPC + PPL + CLOOG (версии можно уточнитьв мурзилке по сборке gcc). В OpenSUSE 11.3 все необходимое есть из коробки (если поставить через YAST или zypper).

Скрипт можно взять здесь:
http://www.antario.org.ru/downloads/build-toolchain

Использование:
./build-toolchain <директория установки тулчена> [get]

в директорию установки вы должны уметь писать, не в какие переменные среды её прописывать не надо. Указав вторым параметром слово get скрипт сам скочает сырцы если у вас из нет. Логи сборки с ошибками записываются в файлы build.log в соответствующих директориях. Перед сборкой никаких подкаталогов build существовать не должно!

Адаптация под другие версии утилит возможны путем замены соответствующих циферок в скрипте, если версии не сильно отличаются то скорее всего все пройдет успешно. Я тестировал на:
linux-2.6.36
binutils-2.20.1
gcc-4.5.1
glibc-2.11.2 (для 2.12 нету портов пока :( )
gdb-7.2
Возможно заменить и саму целевую архитектуру arm-none-linux-gnueabi на что-нибудь другое что поддерживает glibc. Однако для архитектуры отличной от arm возмоно придется поправить спецификацию (переменная TARGET_SPECS, ато штука служит для прямого указания скриптам configure от glibc на наличие/отсутствие некоторых возможностей на целевой архитектуре, так как пока не собрана финальная вермися самой glibc компилер не может проверить их наличие напрямую - тесовые программы не слинкуются!)

ЗЫ: Вся эта деятельность навеяна тем что crosstool-ng 4.4 версию gcc собирают через откровенную жопу - например работоспособный busybox она собрать не в силах. 4.5 вообще пока не знают. Правды ради нужно сказать что 4.3 версия работает нормально, но старовата (не некоторых фишек от плюсов). И еще crosstool-ng занимается фигней собирая (часто через задницу) вспомогательные либы для gcc которые прекрасно можно найти и в самой системе.

ЗЫЫ: Скрипт написан без применения вертолетостроительного шел программирования так что потенциально его понять может любой желающий.

Собираю GCC так:
../configure --target=arm-none-linux-gnueabi --prefix=/home/misha/KDE/src/toolchains/arm-none-linux-gnueabi/build/gcc-core-static --with-local-prefix=/usr/local/toolchains/arm/arm-none-linux-gnueabi//sys-root --disable-multilib --disable-libmudflap --with-sysroot=/usr/local/toolchains/arm/arm-none-linux-gnueabi//sys-root --with-newlib --enable-threads=no --disable-shared --with-pkgversion=myconfig --enable-__cxa_atexit --enable-target-optspace --disable-nls --enable-symvers=gnu --enable-languages=c

При этом определены переменные
export AR_FOR_TARGET=/usr/local/toolchains/arm/bin/arm-none-linux-gnueabi-ar
export AS_FOR_TARGET=/usr/local/toolchains/arm/bin/arm-none-linux-gnueabi-as
export LD_FOR_TARGET=/usr/local/toolchains/arm/bin/arm-none-linux-gnueabi-ld
export NM_FOR_TARGET=/usr/local/toolchains/arm/bin/arm-none-linux-gnueabi-nm
export OBJDUMP_FOR_TARGET=/usr/local/toolchains/arm/bin/arm-none-linux-gnueabi-objdump
export RANLIB_FOR_TARGET=/usr/local/toolchains/arm/bin/arm-none-linux-gnueabi-ranlib
export STRIP_FOR_TARGET=/usr/local/toolchains/arm/bin/arm-none-linux-gnueabi-strip

И при конфигурации вроде эти результаты сбора binutils находится

далее
make all-gcc
make install-gcc

Попытка компиляции простенькой проги с int main() {} с помощью этого компилятора и опции -v показывает что
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: ../configure --target=arm-none-linux-gnueabi --prefix=/home/misha/KDE/src/toolchains/arm-none-linux-gnueabi/build/gcc-core-static --with-local-prefix=/usr/local/toolchains/arm/arm-none-linux-gnueabi//sys-root --disable-multilib --disable-libmudflap --with-sysroot=/usr/local/toolchains/arm/arm-none-linux-gnueabi//sys-root --with-newlib --enable-threads=no --disable-shared --with-pkgversion=myconfig --enable-__cxa_atexit --enable-target-optspace --disable-nls --enable-symvers=gnu --enable-languages=c
Thread model: single
gcc version 4.4.3 (myconfig)
COLLECT_GCC_OPTIONS='-c' '-v'
/home/misha/KDE/src/toolchains/arm-none-linux-gnueabi/build/gcc-core-static/libexec/gcc/arm-none-linux-gnueabi/4.4.3/cc1 -quiet -v test.c -quiet -dumpbase test.c -auxbase test -version -o /tmp/cch3dNsU.s
ignoring nonexistent directory «/usr/local/toolchains/arm/arm-none-linux-gnueabi//sys-root/usr/local/toolchains/arm/arm-none-linux-gnueabi//sys-root/include»
ignoring nonexistent directory «/home/misha/KDE/src/toolchains/arm-none-linux-gnueabi/build/gcc-core-static/lib/gcc/arm-none-linux-gnueabi/4.4.3/../../../../arm-none-linux-gnueabi/include»
#include "..." search starts here:
#include <...> search starts here:
/home/misha/KDE/src/toolchains/arm-none-linux-gnueabi/build/gcc-core-static/lib/gcc/arm-none-linux-gnueabi/4.4.3/include
/home/misha/KDE/src/toolchains/arm-none-linux-gnueabi/build/gcc-core-static/lib/gcc/arm-none-linux-gnueabi/4.4.3/include-fixed
/usr/local/toolchains/arm/arm-none-linux-gnueabi//sys-root/usr/include
End of search list.
GNU C (myconfig) version 4.4.3 (arm-none-linux-gnueabi)
compiled by GNU C version 4.5.0 20100604 [gcc-4_5-branch revision 160292], GMP version 4.3.2, MPFR version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 870ce7a45cb4ffc5b8eae580d040f0fc
COLLECT_GCC_OPTIONS='-c' '-v'
as -meabi=5 -o test.o /tmp/cch3dNsU.s
as: unrecognized option '-meabi=5'
Коей матери он вызывает host AS а не TARGET AS??? ЧЯДНТ??

GCC 4.4 на arm архитектуре рабоатет крайне криво и половина прог рассыпается по сегфолту. Gcc собран при помощи crosstool-ng 1.8.1, busybox 1.17.3 развалиивается практически все в том числе и ls!

Может кто скажет что не так? может glibc 2.9 для 4.4 маловат?

Берем QAbstractItemModel который потомок QObject`a и опредетяем его потомка:

template<typename T> myclass : public QAbstractItemModel {....};

Естесно MOC шаблоны не понимает и этот myclass не может содержать Q_OBJECT и MOCом не обрабатывается, но в нем (myclass) переопределяются тока чисто виртуальные функции от QAbstractItemModel не сигналы/слоты я в myclass не трогаю, интернационализацию тоже, тока если объектную иерархию пользую (ту что указатель на parent в конструкторе).

Короче такое работать будет (компилироваться оно компилится) или я велосипед Qt наглым образом обманываю и он мне этого не простит?

Чего-то я туплю, но

diff -u -r original-linux-kernel/ my-linux/kernel/

выдает мне кучу строчек типа:

Только в linux-2.6.33.2-myolimex: .version

А как сделать так чтобы эти файлы в патч включались?

Какой устройство соответствует Atmel SSC?

Где для этой штуковины задать DPI экрана (используется системная freetype2 там как встроенная не жизнеспособна)?

Как минимальный спектр устройств в /dev нужен для работы маленикого embedded дистра. Что обязательно должно быть в /dev для запуска udev (и вообще успешной загрузки системы с busybox)?

Такое возможно или нет?

Как Linux дружит с сонивскими масшинками? как там дела с acpi горячии кнопки, синийзуб? конкретно по модели вот это: Sony VPC-S11V9R/B Intel Core i5-540M 2.53