jcxz

Оно же (PRUSS), как я понимаю, имеет доступ ко всему пространству памяти системы и ко всему пространству периферии? EDMA3CC имеет доступ к локальной памяти данных PRUSS? Писать можно только на асме? Думаю переложить на PRUSS разбор пакетов приходящих от McASP чтобы разгрузить ARM....

Можете взять какой-нить пример из идущих с Code Composer-ом для UART или USB к примеру (смотря по чему хотите связь организовать) для данного проца и добавить туда мигание лампочками при приёме каких-нить заданных посылок от хоста. Я думаю ему проще и дешевле было бы заплатить преподу на кафедре. А так - может он хочет всё-таки что-то сделать САМ? ;)

Курсовик горит, к гадалке не ходи ;)

А почему всё-таки не SPI? Там вроде до 40МГц обещается. Или такие большие требования к скорости потока?

Интересно, а кто-нить здесь работал с PRUSS-ядрами в OMAP-L1x? Просто интересно было-бы узнать, для решения каких задач кто их использовал....

Лучше проанализировать SPRUFM1 и "TMS320C6745/C6747 DSP Enhanced DMA Controller User's Guide" и не пользоваться библиотеками для работы с периферией. Там в общем всё достаточно просто.

Дядя сам на вас выходит после N-го количества дилетантов бравшихся за проект ;)

Можно сляпать за 2 месяца, получить бабки, свалить, а потом другие будут разгребать баги всплывшие в ходе опытной эксплуатации и переделывать ПО еще полгода. ЗЫ: Ничего личного, просто наблюдения из личного опыта..... Вполне адекватная система оплаты, когда заключается к примеру годовой договор, оговаривается общая сумма на этот срок и потом выплачивается равными частями каждый месяц. Я сейчас именно так и работаю на заокеанского дядю.

ROM - Read Only Memory. Обычно в безфлешевых контроллерах в ROM лежит загрузчик, а прикладное ПО должно грузиться извне.

Несколько лет назад делал радиомодем с примерно похожими требованиями к скорости передачи и полосе пропускания: 1200/2400/4800 бод FSK и 9600 PI/4-QPSK в полосе 7кГц. Т.е. - поток данных с UART кодировался-модулировался и подавался на звуковой вход радиостанции с полосой 7кГц. Проект давно уже работает и продаётся. Так вот, чтобы вы примерно оценили требования к аппаратуре и ПО: я писал его на асме на TI-шном C5502. Никакой ARM7/ARM9 не потянул-бы требумое количество математики (уж не говоря о меге ;) На 9600 QPSK загрузка процессора составляла около 30% при непрерывном потоке данных полным дуплексом (при тактовой ==220МГц и работе только из внутренней ОЗУ). По стоимости комплектации примерно укладывается в ваши требования: кроме DSP остальное железо ерунда - кодек да гальваническая трансформаторная развязка, флешка I2C, имп.источник питания+несколько LDO и сторожевик. Кодек - на частоте 48000кГц. Ну и основные затраты конечно - уйма потраченного времени :) Примерно на приёме был такой тракт (всё программно): полосовой КИХ-фильтр, DC-delete-фильтр, эквалайзер (для корректировки АЧХ тракта), передискретизатор (частота была не совсем 48000, а близкая к ней), далее - разбиваем на квадратуры (умножаем сигнал на sin и cos), далее - ФНЧ на каждую квадратуру и в конце - квадратурный демодулятор. Всё - половина работы по приёму выполнена ;) В этой точке получаем примерно то, что вы нарисовали на осциллограмме (для QPSK - две таких осциллограммы параллельно). Осталось только засинхронизироваться и преобразовать поток сэмплов в биты, а биты - в байты - это примерно еще половина работы приёмника (как оказалось - более сложная чем первая половина). Если это реализуете, то передатчик будет - плёвое дело, не забудьте только внести в передаваемый сигнал предискажения для корректировки АЧХ. Еще вам надо будет продумать предварительное кодирование, чтобы в передаваемых данных не было длинных последовательностей 0 или 1. А также защиту от ошибок (какой-нить CRC). Ну и канальный уровень протокола передачи. Да - и для дуплекса нужна 4-проводка, а по 2-проводке - только полудуплекс. Думаю - за годик командой при наличии свободного времени и желания можно уложиться ;) ИМХО: для вашей задачи больше подойдёт канал bluetooth если уж не хотите USB-COM за 200руб в бук воткнуть.

Пользовали пару лет назад, только на LPC2378 - работал прекрасно. Брал из экзамплов для LPC2378. А в чём проблема-то?

Мне нужно stand-alone. Вы знаете какие-нить доки по PRUSS? Ну или на худой конец - исходники, но не линуховые?

Кто-нить работал с сабжем (за исключением использования оного для запуска ARM-ядра DSP-ядром)? Думаю прикрутить его для расчёта CRC или перепаковки пакетов в потоке данных чтобы разгрузить ARM-ядро. Что-то док по нему кот наплакал, вот и интересует кто имел с ним дело.

А что это за странное определение???: extern void mcaspUserInit(void) { ... } по-моему у компилятора от него крышу снесло :) Определение функции в си или си++ (даже в си уже можно void в списке аргументов опускать в современных компилёрах): void mcaspUserInit() { ... } Далее, если хотите вызывать её из других файлов, то в хидере объявляете её: void mcaspUserInit(); и вставляете include с данным хидером везде где надо (и перед определением тела функции тоже) всё! Если у вас си, то в obj-файл попадёт имя функции: _mcaspUserInit Если C++: _mcaspUserInit__Fv (к имени добавляются спец-символы, указывающие на тип принимаемых и возвращаемых аргументов, что необходимо для механизма перегрузки функций си++). Если хотите вызывать свою функцу через соглашения вызова более другие, чем по умолчанию для вашего проекта, то можно объявить так: extern "C" void mcaspUserInit(); тогда, даже если исходники компилятся в режиме си++, то всё равно в obj попадёт _mcaspUserInit , но тут никаких уж перегрузок, не обессудьте. а ещё можно так: extern "pascal" void mcaspUserInit(); :) ЗЫ: А вообще - полезно читать pdf-ы на процессор, особенно разделы типа "Run-Time Environment".

Точно не устанавливается - много раз проверил. Но возможно проблема в процессорах (они с буквой X) или в композере. Сейчас такая же беда началась и на evalboard+XDS100 с прошивкой, присланной из TI. Хотя с моей прошивкой в evalboard - всё ок. В настоящий момент общаюсь с поддержкой TI - надеюсь ситуация прояснится.

У меня с ним тож - проект то нормально компилится, то потом (без всяких изменений) начинают вылазить какие-то левые ошибки. Очень кривой.

Так я уж давно написал :)

Написать свою процедуру БИХ-фильтра :)

хм... на этом встроенном XDS100 я такого сигнала не наблюдаю. Вот все сигналы, которые идут от JTAG-контроллера через изоляторы на этой evalboard: TDI, TRSTn, TCK, TMS, RX, TX, TDO, EMU0, EMU1 (TX, RX - идут на UART0). Видно это очередной глюк CCS. См. прицепленный скриншот - это этот ccxml-файл открытый в CCS. Блин, если в нём такие баги, то вообще непонятно какие он параметры реально использует.... :( Да, применяю. Они общие в обоих случаях и входят в проект. gel-файлы взяты TI-шные, я в них вроде ничего не правил (прицепил сюда). gel.zip

А Вы учитываете сколько времени выполняется условный переход в конце цикла и время на перезагрузку конвеера при срабатывании перехода?

Вы где эти задержки меряете? На GPIO? Ну тогда это у вас задержка GPIO. Ну не предназначен он для таких временных интервалов. Если уж пишете о %, то элементарно проверьте на больших величинах задержки. Если ошибка не пропорциональна величине задержки, а является константой - это явно из-за частоты работы GPIO.

Мы сразу тоже подумали на этот TRST с XDS100 - посмотрели его скопом - но во время загрузки кода XDS100 он не дёргается. Также нет и выходного reset с процессора (нога XRS на проце - это in/out с ОК - т.е. может быть выходом), хотя ПО грузится и стартует нормально. Да, вроде всё остальное SAU510 делает - грузит программу в RAM и FLASH, читает/редактирует содержимое регистров/периферии/памяти, делает halt/run обоим ядрам, отрабатывает бряки и т.п. Есть только эта разница между встроенным XDS100 и SAU510. На всякий случай цепляю файлы конфигурации SAU510 и XDS100 из нашего проекта. ccxml.zip

Перед загрузкой кода процессор в состоянии suspend (в состоянии running загрузка кода даже не стартует), после - в состоянии running. В свойствах debug установлено "restart after program load" (как-то так примерно - по памяти).

К сожалению, как я и опасался, возникли проблемы :( Имеем: CCS 4.2.4.00034 + SAU510-USB ISO Plus + F28M35H52C1. Также имеем 2 опции: 1. отладочную плату F28M35xx ISO controlCARD от TI с F28M35H52C1 и со встроенным JTAG XDS100v2 (isolated). 2. макет устройства с F28M35H52C1 и подключенный к нему SAU510. Запускаем на опции 1 проект скомпилённый для работы из ОЗУ - выполняется нормально, независимо от состояния boot-пинов. Также если компилим проект для выполнения из FLASH - тоже выполняется нормально, независимо от состояния boot-пинов. Если то же самое попытаться проделать на опции 2, то загрузить проект в ОЗУ возможно, но после этого отладчик так и не выходит на main (в конфигурации всё прописано нормально чтобы выходить на main после загрузки), а остаётся в состоянии "running". Если остановить процессор, то видно что выполнение передаётся в соответствии с boot-пинами, но мы заложили в макет только возможность выбора или загрузки из FLASH или из serial надеясь, что SAU510 будет работать также как и встроенный. Вобщем - компилится и грузится в ОЗУ нормально, но не стартует (выполнение остаётся в области bootROM). Можно вручную потом выставить регистр PC процессора на точку входа и стартануть - тогда всё начинает работать, но это не дело. Разводку линий JTAG для своего макета взяли с данной отладочной платы - всё аналогично. В чём может быть проблема? Можно заставить SAU510 запускать прошивку с точки входа указанной в out-файле (как делает XDS100v2), а не в соответствии с boot-пинами?

Что Вы подразумеваете под "загрузчиком"? И зачем он нужен? Если у вас есть некое рабочее ПО, которое должно грузиться и запускаться из флеш, то нужно скомпилять из него файл загрузочного образа в формате который понимает bootloader из ROM процессора (например - *.ais), записать его во флеш любым способом и обеспечить на boot-GPIO-пинах процессора необходимый код для выбора источника загрузки. Для записи в эту флеш прошивки можно использовать либо готовые прошивальщики (например для OMAP-L137 среди сэмплов есть SPI-flash-writer, который умеет шить в разные типы SPI-флеш), либо написать свой, либо включить функцию обновления ПО в состав рабочего (как делаю я). Читать файл образа прошивки можно лиюо через отладочный интерфейс (эмуляция stdio-потока в gel-файлах - не очень разбираюсь в этом так как не использовал), либо через какой-либо свой сервисный интерфейс, либо через рабочий интерфейс. Сформировать файл образа прошивки для многих DSP-ядер и OMAP можно при помощи например AISGen (вроде входит в состав CCS). Если же нужен именно "загрузчик", т.е. - отдельное ПО, которое загружает Ваше рабочее ПО из флеш (либо ещё откуда) и запускает его на выполнение, то Вам нужно изучить формат загрузочного образа AIS (описан в spraak5.pdf) и написать парсер его, который включить в состав загрузчика. Такой загрузчик также может находиться в той же флеш и грузить рабочее ПО, находящееся в другой области той же флеш. Это нужно например для обеспечения безопасного обновления ПО при возможности сбоев связи или питания в процессе обновления, чтобы при этом не было выхода из строя устройства (во флеш хранятся две копии рабочего ПО и указатель на новую копию, при прошивке обновляется только одна из копий, загрузчик никогда не обновляется).