|
|
Хорошая и очень глубокая тема. Здесь все совсем не просто насчет RTOS для DSP. Выделить 0.00х% ресурса на RTOS не проблема, казалось бы, например, для С6х, а вот в реалии все гораздо сложнее.
Исходно поставленная задача для DSP здесь не конкретна, поэтому можно только предполагать, но основные постулаты примерно следующие (пример приведен для С6х, хотя его можно продлить и на другие DSP с оговрками):
1. Если у Вас код для С6х написан о оптимизован на ASM, то в подавляющем большинстве случаев надо забыть об RTOS.
2. Если ко написан на С и загрузка процессора составляет не более 25..40%,и при этом нет критичных участков кода (по времени исполнения и/или по принципу монополизации ресурса CPU), то Вы можете подумать об RTOS (!! только подумать, и не более).
3. DSP/BIOS II в CCS - это бывший хорошо известный SPOX от Spectron Microsystems, и является страшно "тяжелым" в программировании и исполнении. Загрузка ядра очень высока. Это очень неудачный вар-т.
Вся проблема DSP/BIOS в ее multi-layered структуре, что ведет к большим временам переключения задач. Гораздо лучше другие следующие решения:
1. 3L Diamond (www.3L.com), которая является простешим подобием RTOS и редизует только простешие аттрибуты RTOS (семафоры, events, threads). Эта простота приводит к главному рез-ту: предсказуемости задержек, что самое важное для RTOS. Главное преимущ-во Diamond - это поддержка мультипроцессорных приложений, где ни DSP/BIOS , и ни кто другой (за исключением м.б. старого Virtuoso) ничего не могут.
2. ThreadX от ExpressLogic, что является старым и хорошо известным Nucleus от Accelerated Technology. THreadX имеет главный плюс - это поставка в исходных текстах, а также опции по поддержке FAT32 файловой системы и TCP/IP (все также в исходниках). THreadX и Nucleus обе имеют хорошо отлаженное ядро, а наличие исх.кода позволяет его оптимизировать. Все времена отлично предсказуемы и настраиваются через системный отладчик (не путать с отладчиком CCS). Однако, Nucleus поставляется только для C3x/C4x/C54x, а ThreadX для С6х. Обе системы - однопроцессорные.
Сейчас для C6x есть версия Linux (фирма Softier), однако это очень неудачный вар-т, непонятно где его применять. Его видимый плюс - это автоматическая поддержка TCP/IP, USB, и т.п., но главная проблема - никаких гарантий по временам, т.к. Linux - это не RTOS для втроенных приложений с гарантированными временными параметрами, а прежде всего "операторская/диалоговая/пользовательская" RTOS для работы с компьютером. Вобщем, для С6х - красивая игрушка, и не более.
ПОддержка TCP/IP непосредственно в DSP, это палка с двумя концами, но главный конец - этого надо избегать при всякой возможности, т.к. TCP/IP - это очень многоуровневый софт, требующий больших ресурсов. Самый правидьный вар-т - это его реализация извне, как в OMAP.
Так что все не так просто насчет RTOS...
Еще один вопрос тут прозвучал - это как подсоединить DSP к host-CPU? Здесь опять проблема, и все зависит от скорости выходного потока данных из DSP в host-CPU. Казалось бы - HPI-порт для C6х - решение всех проблем. Дудки... ПРоблема в том, что HPI-порт для C6х работает через aux-DMA, который по приоритету ниже CPU, а из-за конвейризации процессора, его VLIW-архитктуры и разности скоростей внешней шины и ядра процессора - реальные задержки по HPI-порту могут составлять до нескольких мкс, а иногда HPI-порт вообще может и не получить доступа, - все в зависимости от исполняемого кода в DSP. Так что сначала надо проанализировать все потоки данных и код процессора, а уж только потом делать интерфейс с host-CPU.
С уважением,
Павел
E-mail: 
info@telesys.ru
