BratherLU

мне в свое время помогли вот эти статьи: http://processors.wiki.ti.com/index.php/GS...ing_projects_v5 http://processors.wiki.ti.com/index.php/GS...ing_projects_v5

http://www.dsplib.ru/content/allpasseq/allpasseq.html. - просто и эффективно. Еще есть книга: DAFX: Digital Audio Effects автор: Udo Zolzer. http://www.dafx.de/ http://www.music.mcgill.ca/~ich/classes/dafx_book.pdf

http://www.rane.com/note158.html - суть проблемы + варианты решений

http://cdn.intechopen.com/pdfs-wm/15192.pdf - еще по теме

http://www.micromodeler.com - недавно наткнулся

http://www.dsplib.ru/content/allpasseq/allpasseq.html - про то-же самое, что и только на русском с готовыми формулами. Wave-filter это или не wave-filter мне пока не понятно... планировал разбираться как руки дойдут. +1 за matlab

http://www.ti.com/lit/ug/spruhv7/spruhv7.pdf

Не могу сходу ответить. Надо моделировать - собирать тестовую среду именно для Ваших условий (в цифре добавить шумов, испортить АЧХ, покрутить фазу ). На мой взгляд правильный подход для оценки качества демодулятора предлагают здесь -> http://powerdsp.narod.ru/modem_v32.html

Может уже смотрели в matlab функции: 1) hilbert - реализует ПГ при помощи БПФ (можно посмотреть в исходниках hilbert.m где-то в недрах) 2) angle - фаза комплексного числа 3) unwrap - уберет разрывы фазы. Преобразование Гильберта можно реализовать при помощи КИХ-фильтра. В matlab есть инструмент FDATool - в пару кликов может дать коэффициенты соответствующего КИХ-фильтра. Это если не с чего начать.

Прошу прощения схемы сразу не разглядел. Посмотрел на времянки Вашего ST-Bus - такой frame - тяжелый случай для - MCASP. С двойными клоками - еще одна засада - нужно попасть на нужный клок при старте автомата состояний - иначе имеем ошибку 1/2 бита - что вполне может приводить к срыву синхронизации и ошибкам при приеме данных. Возможный вариант - подождать нужного фронта фрейма и затем нужного франта клока и тогда запустить синхронизацию. Пока больше вариантов не вижу...

А может лучше завести битовую синхронизацию на АHCLKR потом поделить внутренним делителем MCASP и от этих клоков засинхронизировать прием. AHCLKR/H можно даже внутри проинвертировать - в MCASP есть все тоже самое что и в MCBSP (кроме g711)

Не знаю насколько узко Вам надо, а то может и такой вариант сгодится -> http://www.dsplib.ru/content/allpasseq/allpasseq.html

В Mcasp есть регистры RCLKCHK/XCLCHK - можно их использовать для диагнотики проблем с пропажей аппаратной синхронизации. Прием поднимется после восстановления синхронизации; передача скорее всего нет (не уверен на счет передачи) - может потребоваться перезапуск передатчика.

Да. Вы обязаны писать в XBUFF(x) в каждом активном таймслоте для каждого активного передатчика поосле запуска передатчика

О причинах не запуска передачи могу сказать что XDATA выставится сразу при отпускании автомата состояния сериалайзера - об этом в доке написано. Вероятно первый вариант не запустился т.к. не известно когда вы вызвали Send() может уже underrun возник. По прерыванию вы тут же влетели в обработчик все сработало штатным образом - я так думаю (с).

С передатчиком проблема следующая - достаточно возникнуть Tx buffer Underrun событию и автомат состояний передатчика встает колом. Соответственно - лечение: не допускать underrun. Возможные варианты: 1) Гарантированно успевать CPU писать данные в TX_BUFF(x) + включать AFIFO от mcasp 2) Использовать - EDMA+AFIFO от mcasp 3) Использовать PRUSS TX AFIFO - лучше использовать даже при работе через EDMA. т.к. при определенном уровне нагрузки на EDMA связка может зависнуть. При этом ни в одной периферии ошибок не видно. Под нагрузкой имею ввиду например работу с MMCSD на том же контроллере. На форуме TI есть пара тем по данному вопросу. Как запустить AFIFO написано документации на MCASP

RSTAT.RDATA - говорит что данные готовы для ВСЕХ активных RX сериалайзеров, т.к. все они: 1) - сидят на одной синхронизации и соответственно параллельно получают данные со входов RX входов; 2) - имеют ОДИНАКОВЫЙ формат кадра. Для передающей половины все аналогично.

Подход верный. запуск связки примерно такой: 1) запретить EVENT18 в EER (на всякий случай) 2) записать настройки в 64 paramset 3) записать настройки в 65 paramset 4) записать настройки в 18 paramset 5) настроить прерывания от EVENT18 если используются ( выставить бит в IER (через IESR) - куда указывает TCC от 18 paramset ) 6) разрешить EVENT18 в EER (через EESR) 7) теперь можно { запускать spi } или { для отладки писать в ESR 1 для EVENT18 - притворяясь spi } => { пересылки должны идти + прерывания должны возникать }

При завершении задания для парамсета 18 - контроллер EDMA копирует содиржимое линка (64/65) в парамсет 18 и все продолжает работать без участия процессора. Таким образом связка ping-pong настраивается 1 раз и работает без участия CPU.

Если правильно понял вопрос... spi переинициализироать не надо - он и не знает кто его будет писать/читатать. О прарамсетах: Настройки 18-го и 65-го должны быть идентичны Настройки 64-го отличаются от 18 только линком на 65 и src/dst адресом - в соответствии с Вашей задачей В общем случае правильность работы Вашего пинг понга можно проверить не запуская spi Инициализируете парамсеты как надо и потом руками (программно) пишите 1 в соответсвующий бит в EVENT SET register в EDMA контроллере - все должно пересылаться и с отключенным spi

Если еще актуально... Возможные причины не возникновения прерываний от MCASP 0) -не разрешены прерывания глобально и неразрешен вектор NMI 1) -не разрешен соответствующий вектор в ядре (IER) 2) -не смапированы прерывания от MCASP в соответтствующий вектор - (смотреть в настройках контроллера прерываний) 3) -не разрешены источники прерываний MCASP (RINTCTL/XINTCTL) 4) - все флаги в RSTAT/XSTAT должны быть сброшены при запуске MCASP записью единиц в соответствуюшие биты 5) - в обработчике прерывания все флаги в RSTAT/XSTAT нужно сбрасывать руками записью единиц в соответствуюшие биты

http://www.dsplib.ru/content/allpasseq/allpasseq.html как вариант

Если правильно понял вопрос - нужно правильно проинициализировать 22-й ParamSet + разрешить события от 22-го ParamSet в EER + правильно наcтроить события в GPIO модуле. Дока на omap-l138 6.9.1 EDMA3 Channel Synchronization Events event - 22 ps кодом помочь не могу - не использовал GPIO для синхронизации EDMA-пересылок

В дополнение к jcxz http://electronix.ru/forum/index.php?showt...p;#entry1178688

Делал одновременные обращения к разным файлам на запись и на чтение на одном диске - все работает (версия FatFs - R0.08b). _FS_LOCK не использовал. Все делал через очередь запросов к файловой системе (была многопоточность). Низкоуровневые дисковые операции (disk_write() disk_read() ничего не знают о файлах и FAT - они работают с секторами диска. Если все в одном потоке - проблем быть не должно и при прямом обращении к функциям fatfs, без очередей.