[olefil 0]

У кого нибудь есть ThreadX или VelOSity для Blackfin или любого другого процессора. Нужны исходники ОС.

[bve 1]

А может у кого есть ОС для ADSP2106x?

Ну, например, Virtuoso?

 

Интересно также, использует ли кто языки параллельного программирования

вроде 3L? Где взять и с чем их едят?

[Armen 0]

a kak ideya samim napisat'????

[ig_z 0]

У кого нибудь есть ThreadX или VelOSity для Blackfin или любого другого процессора. Нужны исходники ОС.

<{POST_SNAPBACK}>

 

Когда то старые исходники (по моему версии 3.6х) были в будках. Но вроде для последних мульти нужны более новые, иначе отладка теряет все удобство.

А у вас есть мульти для Blackfin ? Или чем вызван такой интерес

[jojo 0]

совсем недалеко лежит этот мульти под названием GR*EEN.HILL*S.BLACKFI*N.C.COMPILER.4.0.6. Но как-то радикальные отличия в плане кодогенерации от VDSP не очень-то заметны.

[olefil 0]

Блин хоть кто-то проснулся. Мужики там тема - то написана аж в декабре. Ну раз кто-то решил поговорить, так поговорим. Идея простая я уже очень давно программрую под SHARC, хотелось бы упростить работу последователям и людям пришедшим на работу. По сему нужна ОС, для упрощения работы.

На счет самим написать - написал и между прочим работает. Но эта ОС моя и она работает только потому, что я знаю ее от и до. Для любого другого человека это темный лес. Вот и хотел я взять чего - то, что используется везде, ну или обще известно (Еще конечно хочется посмотреть на ОС написанные грамотными людьми). Недавно решил портировать RTEMS ... хоть там доки и нормально написаны, но под VDSP компилировать файлы без глобальных изменений не возможно или очень сложно (кому как). По сути я компильнул уже много разных прог, но ОС'ями все хуже, там пока до конца не разбрешся че к чему, хрен собрешь.

На счет GH, там разве ОС присутствует, я скачать скачал, но еще не смотрел.

[olefil 0]

BlackFin есть но вот желание с ним работать напрочь пропало после того как JPEG на нем решил докодировать. Мрак полный программа на PC выполняется за 3 000 000 тактов, а на BlackFin с полной оптимизацией по скорости за 10 000 000. Беда полная!!! (правда код не оптимизирован для BF), но после оптимизации кода, перевода половины программы на ASM тоже не помогло. Интерес вызван портированием на этих ОС на SHARC.

[bve 1]

По моему мнению, имеет смысл вводить ОС только в многопроцессорных системах

для обеспечения межпроцессорного обмена и, желательно, автоматического перераспределения задач. Вроде-бы ( по слухам ) аналогичную работу выполняли

Parallel C и 3L C, но вот портированы ли они под ADSP2106x?

Наличие ОС для одного процессора не сильно поможет работе, скорее съест изрядно ресурсов.

[olefil 0]

Я с вами полностью согласен на счет ресурсов. И на счет процессоров тоже. Оба случая имеют место в моей работе. Таким образом я пишу программу для 2-х процессорной платы, представим себе, что это драйвер. А теперь тоже самое для одного проца. Дело в том, что хорошо если драйвер один и разрабатывает его один человек. А если их 23 штуки и работает 10 программистов? Вот поэтому я и задался проблемой написания ОС. Принципиально задачи решает VDK (не знаю как на счет много процессорности), но в частных задачах я ее использовал еще на VDSP 2.0, но потом отказался. Мне необходимы динамические библиотеки и приложения. Вариант статической компиляции ОС и программ неподходит. Вот и приходится изголятся по разному. ОС которые я упомянул, похоже тоже статические но они написаны или содержат код для DSP, а это очень интресно. Механизм переключения задач в этих ОС тоже интресен, ну и так далее.

Прошу прощения за серость, но про Parallel C и 3L C слышу не впервые, но лично я с ними не работал. Поэтому обсудить их немогу.

[bve 1]

Рад найти родственную душу.

В моих задачах ситуация похожа на Вашу, не менее 4-х процессоров и

не менее 4-х программистов. Пишем еще на смеси ассемблера и g21k.

Как замену ОС используем самописный монитор обмена, который

позволяет обмениваться пакетами между процессорами и выполняет

некоторые команды по загрузке ПО, чтению и записи переменных и

не memory-mapped регистров процессора. Такая технология программирования

приводит к большим затратам на стыковку, согласование временных диаграмм и т.п.

Поэтому и я ищу средства, позволяющие представить ВСЮ систему как один

виртуальный процессор с нашими задачами, выполняющимися в нем.

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

процессорам и организовать потоки данных. Еще идеальнее было-бы, если бы

в случае выхода из строя одного из процессоров система перераспределяла задачи по "живым" процессорам. В связи с этим я поднимал вопрос об обмене по LINK-каналам с использованием их встроенного механизма сцепления, когда информация из одного канала автоматически перенаправляется в другой самим ядром ввода/вывода без нагрузки на АЛУ. К сожалению, информация об этой возможности 'PRIVET'. Может Вам что-либо известно?

[olefil 0]

Чесно скажу с LINK каналами не работал, а точнее работал, но уже очень давно. Мог бы помочь, но неделю назад навернулся сервер, а все сво старые проекты хранились на нем. Я вот тут глянул на RTEMS, очень понравилась, но портирование ее на Sharc очень тяжкий процесс и с моей временной загрузкой практически не реален. Ну и плюс ко всему надо в ней очень хорошо разобраться в этой ОС.

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

ОС которую я написал, работает примерно также как ваш монитор обмена, есть некая задача с нечетким приоритетом, которым управляет по сути Altera, и взависимости от него программы распределяются и запускаются на разных процессорах, по заведомо известному алгоритму. Конечно это не блеск, но работает.

[Armen 0]

Блин хоть кто-то проснулся. Мужики там тема - то написана аж в декабре. Ну раз кто-то решил поговорить, так поговорим. Идея простая я уже очень давно программрую под SHARC, хотелось бы упростить работу последователям и людям пришедшим на работу. По сему нужна ОС, для упрощения работы.

На счет самим написать - написал и между прочим работает. Но эта ОС моя и она работает только потому, что я знаю ее от и до. Для любого другого человека это темный лес. Вот и хотел я взять чего - то, что используется везде, ну или обще известно (Еще конечно хочется посмотреть на ОС написанные грамотными людьми).  Недавно решил портировать RTEMS ... хоть там доки и нормально написаны, но под VDSP компилировать файлы без глобальных изменений не возможно или очень сложно (кому как). По сути я компильнул уже много разных прог, но ОС'ями все хуже, там пока до конца не разбрешся че к чему, хрен собрешь.

На счет GH, там разве ОС присутствует, я скачать скачал, но еще не смотрел.

<{POST_SNAPBACK}>

 

Skoree vsego OC budet no otkompilirovanniy... polzi malovato... xotya ....

Kstati mne nujna os dlya StarCore... iz za nedostupnosti vsego i platnosti reshil sam napisat...

Kak trenirovku pereklyuchenie zadach realizoval na 5510.. vrode idei rabotayut...

[olefil 0]

Была у меня ОС для StarCore (помойму она офицально предоставлена на сайте, но лежит в закрытых архивах). Принципиально нормальная вещь, но из-за ее оптимизированности под данный проц, она мне стала не интересна. Ну и еще она статически компилируется с программой, а мне такой вариант не подходит.

[bve 1]

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

Как говорилось, будем искать......

[olefil 0]

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