Производители железа не умеют писать софт?

Бытует мнение... и думаю это действительно так. Щас докажу. :)

Работаю, как уже писал, с одной ARM'овой железякой от EmbeddedArtists. Ну начать наверное стоиит с того, что они положили в коробку с железякой...

В корорбке лежит CD, на котором записан exe файл, который представляет из себя 7z архив...

В архиве лежит образ vmware c устаановленным дебианом, в домашнем каталоге пользователя по умолчанию развернуты исходники uClinux, версии 20051014, уже пропатченные и настроенные на сборку. Справедлливости ради отмечу, что там все нормально собирается.

На сайте можно скачать патч, который, почему-то, не хочет накладываться на вышеозначенную версию uClinux. И который, помимо существенных изменений, касающейся данной борды, или хотя бы всех бордов данного производителя, содержит еще множество изменений в других подсистемах (преедпололжительно hsc патч и coldfire патч).

Кстати, ядро имееет версию 2.6.11.8 - использовать более новое ядро пока вообще представляется почти невозможным. Но не стоит рассчитывать и на то, что ядро 2.6.11.8 удастся успешно пропатчить, на первых порах придется довольствоваться ихним предустановленным.

В приннципе я ссогласен с тем, что готовая система для vmware - это оправданный шаг, ибоо сборка на других системах весьма не тривиальна. О чем щас тоже расскажу...

Но начатть стоит с того, что в крросскомпиляциях а уж тем более в ARM я не силен. Но и от своей любимой Gentoo отказываться не намерен. Берем crossdev и начинаем делать свои собственные toolchain. uclilbc почему-то вообщее не хочет собираться, может быть не любит ядро 2.6.23, инклюды от которого система ему подсовывает? arm-elf вполне успешно собрался (binutils, gcc-3, newlib), но с ним не захотел собираться busybox, который сказал примерно следующее:

/usr/libexec/gcc/arm-elf/ld: ERROR: /usr/lib/gcc/arm-elf/3.4.6/libgcc.a(_muldi3.o) uses hardware FP, whereas busybox uses software FP

Не совсем понимаю чем ему не нравится hardware FP. Ядро ведь должно его эмулирировать (поддержка включена), или на ARM'ах это не прокатывает?

Ладно, arm-softfloat-elf собрал все, да только очередной затык... все модули в системе получились elf, в то время, как ядро без MMU не может поддерживать ELF. :(

Начал разбираться а почему они собственно не Flat? дык очень просто. Для того, чтобы они стали flat, в binutils необходим дополнительный пакет - elf2flt, который через use флаги не активизируется, и на зеркалах нигде не лежит. Пришлось перековырять ebuild, благо кроссчейны лежат в оверлее... и наконец таки я собрал то, что они предоставили по умолчанию...

## Starting application at 0xA0008000 ...
Linux version 2.6.11.8-hsc0 (dron@mdf2007) (gcc version 3.4.6 (Gentoo 3.4.6-r2 p1.5, ssp-3.4.6-1.0, pie-8.7.10)) #5 Thu Dec 13 17:14:08 MSK 2007
CPU: Philips-lpc24xx [24000000] (ARMv3)
Machine: LPC24xx, NXP
...
init: Booting to single user mode
#

Кто-то скажет, что стоило ли столько мучится, тем более что в виртуальной машине все собирается... но мне в любом случае требовалось наладить свою сборку, мне в дальнейшем придется это менять, возможно дописывать модули.

ARM

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

Новость первая заключается в том, что на работе меня подключили к новому проекту. Этот проект по созданию поточного шифратора USB. Делается это на базе контроллера с ARM'ом на борту. Я раньше никогда не имел дела с армами, хорошая возможность попробовать, тем более область использования армов весьма велика (портировать систему?).

Пока что балуемся с такой железякой. Компактная надо сказать железяка. процессорный модуль (представленный на изображении) имеет размеры 66х80мм при этом содержит 32 мега SDRAM, 128 мег (или правильно говорить меб?) флеша. Ну еще несколько флешей по мелочи (4 мега и 512 кил в чипе). Насколько я понимаю, вся эта память располагается в одном адресном пространстве, разница только в скорости доступа. Пока там крутится ucLinux, старый... не знаю что будет крутиться дальше, может свое что-то соберем. Там куча уникального оборудования, не поддерживаемого стандартным линуксом. Причем это только прототип, если прототип заработает, то будем делать другую железяку, конфигурация которой скорее всего будет отличаться от этой борды.

Но от столь интересного занятия меня безжалостно оторвали, говорят в старом проекте че-то не работает, сижу вот, туплю второй день... продукт тестируется, но я еще ни одного исправления не внес, ибо незачем. Отрицательно в проекте то, что мея привлекали в качестве экстренной помощи, и приходилось вдвоем ковыряться в одном проекте, больно он монолитный. 16 бит, msc++ 2.0, памяти постоянно не хватает - жесть... как только люди раньше жили.

Сегодня с утра друг hedgehog порадовал ссылочкой. Хочу такой субноут, но пока боюсь мне не до того. :) Судя по описанию ничего революционного с линуксом они не сделали, думаю Gentoo встанет без проблем, а ярлыки на стол я и сам могу поставить.

А еще друг SadKo намедне тоже порадовал другой ссылочкой. Must bookmark :) всем писателям операционных систем.

Модель/Вид

Потихоньку осваиваюсь с QT. Многие вещи еще не понятны, но постепенно начал въезжать в сабж от QT. Сделали они мощно.

Модель у них - это абстрактный класс доступа к данным. Хранить данные при этом можно так, как хочется. Конкретная модель в этом случае является как бы прокси классом между хранилищем данных и видом.

Пока пытался заставить свою модель работать, чуть всю голову не сломал, если бы не ModelTest. Правда некоторые непонятки еще мучают меня. Например у меня что-то не получилось поставить два шортката на один QAction... Интересно, это можно сделать?

Кроме того еще остались неисследованные темы, как то редактирование при вставке элементов, И еще хочу в названии элемента совместить иконы (несколько), имя, еще дополнительную графическую информацию... Это должно быть возможно (кастомный ItemView?).

Ну начало положено, дальше наверное будет легче. :)

Переключение задач.

Тема, по которой не прекращаются споры сторонников различных подходов.

Но вот недавно SadKo предложил интересную идею, которой я не премину воспользоваться (Если, конечно, SadKo не будет сильно возражать и настаивать на своем исключительном авторском праве :)).

Идея в принципе не нова, и заключается в том, что переключениями задач занимается отдельная задача, что, собственно, упрощает процесс менеджмента. При этом я, скорее всего, не стану полностью переводить весь ядерный API в отдельные задачи, это не оптимальный и не самый удобный способ реализации, ИМХО. Более того, даже прерывание таймера не достойно того, чтобы выносить его в отдельную задачу. Тем более, что прерывание таймера вовсе не подразумевает переключения задачи, в том смысле что переключение может и не понадобиться.

Менеджер задач будет отдельной задачей, но не будет напрямую доступен приложениям, а будет вызываться самим ядром при необходимости такого переключения.

Конечно, это будет приводить к дополнительным расходам времени (одно дополнительное переключение задачи). Да ну и пусть. Зато удобно. В старой реализации мне приходилось постоянно ломать голову над тем, как проделать над задачей какие либо манипуляции, учитывая, что она еще не покинула процессор. И приходится мучиться.

PS: И еще подумал, что на многоядерной системе вероятно потребуется сделать несколько задач - переключателей (по одной на каждый процессор), или одну задачу но с блокировкой (этот вариант наверное попроще).

Мульт.

Занимаясь с ребенком задумали снять мультфильм. Один мультфильм на 15 секунд мы уже делали, но думаю, что надо подойти к делу серьезнее.

Кадры мультфильма раскладываются по сценам. В каждой сцене список фреймов с длительностью каждого. Специальный скрипт перегоняет список фреймов с длительностью в список фреймов для mencoder. Который в свою очередь за два прохода создает качественную avi.

Озвучка для каждой сцены состоит из отдельных вавок, которые с помощью sox (опция pad позволяет сдвигать начало) миксуются в единую вавку. Которая на втором проходе кодирования видео закатывается в avi.

В корневом каталоге естественно находится Makefile, который позволяет все это автоматизировать. :)

Но че-то у меня mencoder последнее время глючит, видимо какие-то проблемы с драйвером контейнера avi, кодирую ровно минуту видео, А плейер потом показывает 4 минуты 31 секунду, а показывает всего мгновенье. Попробовал заместо lavc::mpeg4 использовать xvid - те же яйца, вид сбоку... Вероятно глючит сам контейнер. Вечером пропробую откатиться на прошлые версии mencoder. Ведь раньше я все кодировал без проблем... :( Страно это...


А еще для WorkMap и ради интереса я открыл проект на googlecode (там пока нечего смотреть). Надо сказать, что интерфейс code.google значительно проще, чем наворочанный sf... Да многим ли нужны эти навороты?