Кто нибудь сталкивался с таким зверем как UCLinux - что это за зверь и для чего оно надо???
Как блекфин с ним работает? На сколько я понял отладочные комплекты для него свои. Однако не совсем понятно когда его стоит использовать, и на сколько он тормозит процессор. Все таки BlackFin не очень любит условных переходов, коих обычно в операционках дофига...
Вообщем если кто работал - поделитесь впечатлениями. И еще хотелось бы знать насколько он отличается от нормального линукса, Как со средами программирования (если что либо подобное Visual DSP). А главное, можно ли подключать сделанные в Visual DSP либы????

По словам специалиста русскоязычной поддержки ADi: поскольку проц без MMU, то отличие фактически лишь в замене вызовов fork на vfork.


сайт был.. то ли blackfin_uclinux_org толи uclinux_blackfin_org - но только сейчас ни тот ни другой не отвечает
(вобщем там предлагают gcc c gdb (если память верна) для BF)

А как интересно работает вызов vfork. У меня есть несколько потенциально тяжелых задачь - фильтрация, фурье и т.д. Скорость которых критична. И если я делаю vfork то каким образом они будут выполняться одновременно???? Или если если они просто запускаются, то будет ли ядро сильно тормозить фильтры????


Т.е. все фактически из коммандной строчки???? Я обожаю VDSP за то что там можно в отладчике посмотреть осцилограмму, спектрограмму, фурье образ сигнала и т.д. Никакой gdb тут не поможет. неужели нет нормальной софтины????

Из семинаров по uCLinux и нескольких статей (на практике, к сожалению, времени нет покопаться, хотя STAMP наличествует) получил представление о том, что для решения задач, критичных ко времени исполнения, просто uCLinux не подходит. Есть два варианта - использовать двухъядерный BF561, где одно ядро будет отводиться как раз под real-time обработку, либо использовать схему с двумя планировщиками - стандартным планировщиком uCLinux и планировщиком реального времени ADEOS.
А сайт blackfin.uclinux.org работает, только что проверил Инфы там хватает.

Для себя сделал вывод о том, что ИМХО если и стоит применять uCLinux, то только если нужна поддержка сети или других вещей, которые самому писать запарно, а в uCLinux поддержка есть, и если не требуется hard real-time.

Сообщение отредактировал hobgoblin - Apr 20 2007, 10:49

Фильтры можно драйверами сделать в ядре. Софтина достаточно удобная называеться GCC Если с линуксом не имели дело лучше не начинать. vfork просто копирует память всего процесса, выполняется псевдо параллельно.

Дввно дело было, 2 года назад. Разочаровался я тогда в этом микроЛинуксе.
Собственно не получилось у меня прокачивать в реальном времени потоки данных с ПЛМ в BF533.
Собственно что нужно было: с ПЛМ приходит сигнал, по которому 533-й забирает из нее пакет данных по параллельной шине. Проблема в том, что время реакции на сигнал было огромным и непредсказуемым.
Ладно. Написал драйвер, теперь реакция на сигнал была на уровне ядра, драйвер забирал их в свой буфер и далее посылал сигнал пользовательской программе. Но мне не удалось добиться гарантированного времени доставки сигнала от драйвера в пользовательскую программу, это зависело от других задач и пятен на солнце.
Практика полностью совпала с теорией. Какую-то реалтаймовость от этой операционки получить не удалось. Забросил тогда СТАМП в шкаф.
Сейчас руки чешутся на второй круг пойти. Не с Линуксом, а поставить на него какой нибудь микроСи/ОС-2. И подозреваю, что эта связка полетит - не догонишь!

Незнаю достаточно хорошо работает с TDM, перекладывает из eth в TDM и обратно данные, потерь пакетов нет, скорость можно разогнать до 64 каналов TDM E1. Сейчас занимаюсь другими вещами где прерываться надо 125мкс и 2 мс каждые, конечно ядро линукса почит смертью храбрых от такого так что бесконечный цикл

То есть работали с потоком 2мегабита * 64 канала E1 = 128 мегабит?
Решали на уровне ядра или передавали из драйвера в пользовательскую программу что-то?

Счёт не правильный есть 4 потока работающие на 8 мегабит и зних берём 64x64кбитс . получаем 4 мегабита. Решали на уровне ядра. Это всё могло работать по 8 -ми независимым направлениям+поддержка vlan

Ну, всю задачу драйвером в ядре решить- это неспортивно

Кстати получилось классическое решение