Здравствуйте. Скажите, можно ли управлять подачей фреймов на выводе TF?
импульсы формируются на выводе, сразу после конфигурации ssc. Если я настраиваю старт работы передатчика по перепаду фрейма (AT91C_SSC_START_RISE_TF| AT91C_SSC_CKO_DATA_TX в регистре TCMR), то передатчик работает постоянно, даже если в буфере и нет данных, отправляя default значение.
Я понимаю, что ssc в основном предназначен для работы с кодеками, но мне нужно организовать обмен между устройством и блоком управления для него следующим образом:
Блок управления реагирует на нажатие кнопки и отсылает пакет данных, принимает ответ и "молчит" до следующего нажатия. Управляемое устройство принимает данные по положительному перепаду фрейма, фрейм должен быть длиной в один бит - устройство готовое, закрытое и изменению не подлежит.
Можно ли формировать фрейм только, когда это нужно?

А нужен ли SSC в данном случае? Событие происходит редко, данных, как я понимаю, немного - так не проще ли руками передать/принять?

Да я бы с удовольствием передавала бы просто по spi, но все дело в том, как формировать этот фрейм длиной в один бит, по которому устройство будет принимать и передавать данные.
Я думала - можно ли как-то использовать для этого вывод NCS0?

Да я вообще имел в виду "ногодрыганье" - не подходит?

А как мне так точно синхронизовать "ногодрыганье" с аппаратными тактами? Фрейм длиной один такт, задержка между фронтом фрейма и фронтом синхроимпульса - полтакта

aaarrr, так все-таки - можно или нельзя управлять фреймами? Может, я просто не понимаю, как

Если контроллер у вас работает в режиме слейва, но при этом должен выдавать наружу FS, то это будет затруднительно. Если мастер - то какие проблемы?


Настолько гибко нельзя - все таки это вывод данных привязан к FS, а не наоборот.

Вообще, опишите подробнее интерфейс (сигналы, скорость, количество передаваемых данных и т.п.) - может, что-нибудь и придумаем.

пакет данных - 32 слова по 16 бит, устройство принимает данные по положительному перепаду фрейма ( фрейм длиной один бит), данные фиксируются по отрицательному перепаду синхроимпульса, скорость 12МГц. устройство управления - мастер, принимающее - слейв, принимает и отправляет данные по фреймам и тактам мастера. Вроде все

Т.е. передается 32 шестнадцатибитных слова, каждое из которых снабжено FS длиной в один бит, правильно?

Нет, FS в начале пакета из 32 шестнадцатибитных слов, т.е. FS подается через каждые 512 бит
Да, забыла добавить, MCK у меня 48МГц

Тогда все совсем плохо.

Нет, можно, конечно, извратиться:
- запустить первое слово с FS
- немедленно запретить и перепрограммировать передатчик
- передать оставшиеся 7 слов
- немедленно после загрузки последнего запретить передатчик

Вот только я одного не понимаю: контроллер в режиме мастер, данных кот наплакал - 512 бит "по нажатию кнопки" - зачем аппаратная передача?
Или прямо так строго 12МГц нужно выдержать (хотя это странно для синхронного приемника)? Или, возможно, слейву нужны эти клоки постоянно между передачами?

Ох. а spi нельзя использовать? и фрейм как-то с помощью NPCS делать?

Последнее. после определенной команды он должен начать отсылать данные пакетами по 512 бит постоянно, т.е. ему нужны будут постоянные клоки и фреймы через каждые 512 бит. и 12МГц тоже надо Ну и потом, устройство готовое, уже теперь не прикапаешься -" почему". надо и точка

У SPI с постоянством клока будут проблемы при подъеме CS. В приведенном выше извратном алгоритме для SSC - тоже.


Разве что какую-нибудь внешнюю логику прикрутить для вырезания 7/8 FS (вполне дешевый и сердитый вариант). Или заменить SAM на что-нибудь с McBSP

Там как раз в устройстве TMS стоит с McBSP
А, кстати, не объяcните, чем он от ssc отличается? когда проектировали плату, думали, что это примерно одно и то же, и влепили SAM с ssc

Степенью навороченности.

Кстати, наврал я вам вчера: вполне можно генерировать 1 FS на 16 слов средствами SSC (стыдно, ведь сам же этим и пользуюсь).
Только произвольно начинать останавливать передачу очень проблематично. Протокол общения со слейвом не допускает постоянного обмена?

Могу предложить такой вариант с использованием PDC:
1. Формируем пакет из 16 слов на передачу
2. Конфигурируем PDC для передачи, включаем передатчик
3. По прерыванию ENDTX выключаем передатчик
Тут главное не пролететь с реакцией на прерывание в п.3, иначе будет сформирован новый FS. На все про все 128 тактов процессора, если задействовать FIQ, то можно уложится.

Здравствуйте. Есть аудио-кодек PCM3794. Управляется по I2C или SPI. Обмен данными - по I2S.
У меня в процессоре(AT91SAM7x)нет I2S и никогда им не пользовалась Посмотрела в даташите описание протокола, решила, что можно передавать по SPI. В режиме slave, фреймы кодека(LRCK) заведены на NPCS0 SPI. Пишу данные только в один канал, когда LRCK в низком уровне.
В качестве теста передаю отсчеты синуса угла(через 10 градусов), старший байт, потом младший. на выходе кодека - непонятный шум
Подскажите, можно ли использовать вместо I2S SPI? Может, кто-нибудь кинет ссылку, где про этот протокол почитать?
Может, нужен какой-то особый формат данных?
Очень жду ответа

Для работы с I2S нужно было задействовать SSC. Почитайте вот этот документ, все должно стать понятно.

А писать-читать только в один канал нельзя? если на выход потом подается дифферинциальный моносигнал.
К сожалению, SSC уже занят у меня...

Можно попробовать извратиться с использованием одного левого канала, только вот LRCK в I2S уходит вниз на один клок раньше начала передачи. А какой кодек используется?

я когда-то так и делал на lpc2294. а в прерывании шевелил нужной ногой. только наименование кодека не помню, с ними аккуратнее надо, а то там есть два стандарта: нормальный и японский ( ну так он в доке на один проц звался - "japanese"). Вроде японский и есть , как в предыдущем посте написано. В общем, совет: внимательно посмотрите на времянки из даташита

Кодек PCM3794
Там вроде есть четыре режима: I2S, Лево-выровненный, право-выровненный(вроде так) и DSP. DSP однозначно не подходит, там LRCK длительностью в один бит только. А вот эти лево-... вроде бы по даташиту соотвествуют SPI, там данные начинают передаваться одновременно с появлением высокого уровня на LRCK. Инвертирую этот вывод с помощью внешней логики и вроде должен был получиться SPI, как и у меня в проце. Только если игнорировать второй канал. Но на выходе синусоида какая-то рваная. и частота подаваемого сигнала явно не соотвествует частоте выходного.
Пытаюсь сделать "петлю" - кодек принемает от внешнего источника синусоиду, передает процу с DOUT, а проц отсылает ему обратно на DIN, в итоге на выходах наушников HPOL/HPOR должна получиться такая же синусоида. но проблема, как сделать такую петлю по SPI в режиме slave
А вообще кодек дельта-сигма - это что такое? Может это японский как раз и есть?
Вообще какие бывают стандарты?

Не надо делать петлю. Попробуйте для начала выдавать просто биты на нужных позициях (0x8000, 0x0001 и т.п.), и проконтролируйте правильность выдаваемых данных осциллографом.

А что такое дельта-сигма модуляция?
В кодеке ЦАП и АЦП - дельта-сигма фильтры

Такой способ размена разрешения (разрядности) на время (скорость). Иллюстрация к принципу неопределенности.

аааrrr, большое спасибо! После долгих мучений с SPI все-таки переделала на SSC, как здесь сказано, и все получилось!
Только вопрос - почему, если надо читать два канала, используют второй млдуль SSC(у меня второго нет)?
RF и RK берут с TF и TK - почему нельзя так же завести их в одном модуле? и читать не по положительному фронту фрейма, а по перепаду?
Пробовала, получилась фигня. Но не понятно почему
но все равно, главное работает

Вообще, ноги у этого ограничения растут из ерраты на RM9200 (а пример написан именно для него):

На SAM'ах этой ошибки нет, так что должен работать прием для двух каналов.

Здравствуйте.
Такая проблема - работают два модуля, SSC с кодеком и SPI0 с внешним устройством.
Обмен данными должен идти асинхронно, на разной частоте. но непрерывно.
обмениваюсь через pdc. Прерывания PDC по каналам SPI имеют более высокий приоритет, и мешают обмену с кодеком по SSC
Можно ли как-то перенастроить приоретет прерываний, или запрещать прерывания по каналам SPI во время прерывания от SSC? кто что посоветует?
Еще вопрос - приходит прерывание по ENDTX, когда счетчик TCR достигает ноля. хочу прямо в прерывании, не останавливая pdc, переписать TPR и TCR. TPR переписывается, а TCR почему-то нет Приходится сначала записать TXDIS в PTCR, потом переписать, а потом TXEND. но мне нежелательно останавливать обмен. и непонятно, почему нельзя записать новое значение TCR, не останавливая.
вот такие дилетантские вопросы - может, кто поможет?
очень жду!

Можно, конечно. Но лучше увеличить размер буферов и использовать двойную буферизацию - без нее PDC для непрерывных потоков мало приспособлен. В этом случае приоритет прерываний может быть вообще не важен.

То есть писать адрес нового буфера данных и размер все время в TNPR и TNCR?

Да, именно так.

Может, не по теме, но продолжение задачи
Кто-нибудь может скинуть алгоритм работы фильтра с конечной импульсной характеристикой?
Короче просто свертку(быстрое преобразование Фурье) Надо быстро сделать, а зачем изобретать велосипед?
Буду очень благодарна!