[serg`o 0]

Кто нибудь сталкивался с таким зверем как UCLinux - что это за зверь и для чего оно надо???

Как блекфин с ним работает? На сколько я понял отладочные комплекты для него свои. Однако не совсем понятно когда его стоит использовать, и на сколько он тормозит процессор. Все таки BlackFin не очень любит условных переходов, коих обычно в операционках дофига...

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

[Doka 4]

И еще хотелось бы знать насколько он отличается от нормального линукса.

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

 

Как со средами программирования (если что либо подобное Visual DSP).

сайт был.. то ли blackfin_uclinux_org толи uclinux_blackfin_org - но только сейчас ни тот ни другой не отвечает

(вобщем там предлагают gcc c gdb (если память верна) для BF)

[serg`o 0]

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

сайт был.. то ли blackfin_uclinux_org толи uclinux_blackfin_org - но только сейчас ни тот ни другой не отвечает

(вобщем там предлагают gcc c gdb (если память верна) для BF)

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

(вобщем там предлагают gcc c gdb (если память верна) для BF)

 

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

[hobgoblin 0]

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

А сайт blackfin.uclinux.org работает, только что проверил :) Инфы там хватает.

 

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

Изменено 20 апреля, 2007 пользователем hobgoblin

[MIkler 0]

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

[Ruslan1 17]

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

Дввно дело было, 2 года назад. Разочаровался я тогда в этом микроЛинуксе.

Собственно не получилось у меня прокачивать в реальном времени потоки данных с ПЛМ в BF533.

Собственно что нужно было: с ПЛМ приходит сигнал, по которому 533-й забирает из нее пакет данных по параллельной шине. Проблема в том, что время реакции на сигнал было огромным и непредсказуемым.

Ладно. Написал драйвер, теперь реакция на сигнал была на уровне ядра, драйвер забирал их в свой буфер и далее посылал сигнал пользовательской программе. Но мне не удалось добиться гарантированного времени доставки сигнала от драйвера в пользовательскую программу, это зависело от других задач и пятен на солнце.

Практика полностью совпала с теорией. Какую-то реалтаймовость от этой операционки получить не удалось. Забросил тогда СТАМП в шкаф.

Сейчас руки чешутся на второй круг пойти. Не с Линуксом, а поставить на него какой нибудь микроСи/ОС-2. И подозреваю, что эта связка полетит - не догонишь! :)

[MIkler 0]

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

[Ruslan1 17]

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

То есть работали с потоком 2мегабита * 64 канала E1 = 128 мегабит?

Решали на уровне ядра или передавали из драйвера в пользовательскую программу что-то?

[MIkler 0]

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

[Ruslan1 17]

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

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

[MIkler 0]

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