[Andry333 0]

Здравствуйте уважаемые участники форума, подскажите пожалуйста, как настроить SSC таким образом, чтобы он при записи данных в регистр SSC_THR тактирование шло только в течение передачи одного байта да еще и с frame sync вначале передачи?? всю ночь просидел, голова пухнет... но проблема в том, как только разрешаю передачу, устанавливаю AT91C_SSC_PERIOD регистра SSC_TCMR так он без передачи байт начинает тактировать и выдавать импульсы frame_sync.. что делать??? очень нада... заранее спасибо

[leen 0]

тактирование шло только в течение передачи одного байта да еще и с frame sync вначале передачи??

Не знаю, про какой конткретно контроллер речь, поэтому заглянул в ман по SAM7S.

Тактирование в передаче - регистр SSC_TCMR. Поле CKO = 0x2 задает тактирование только во время передачи данных. Дополнительно можно разрешать маскирование (или как это там правильно - поправьте: "Transmit Clock Gating selection") клоков линией TF (режимы тактировать всегда; тактировать если TF=0; тактировать если TF=1). Это поле CKG.

Если надо передавать сначала FrameSync, а потом данные, то можно в том же регистре SSC_TCMR поставить длительность задержки, равную длине синхроимпульса - поле STTDLY.

В регистре SSC_TFMR видим такие настройки:

DATLEN - длина данных в кадре. 2 - 32.

FSLEN - длина синхроимпульса (в периодах TK). Длина равна FSLEN + 1. 1 - 16. Данные берутся из регистра SSC_TSHR (Transmit Sync Data REgister).

Есть в регистре SSC_TFMR поле FSOS. Определяет поведение вывода TF. Может быть никаким, отрицательный фронт по старту данных, положительный фронт по старту данных, 0 во время передачи данных, 1 во время передачи данных, переворачиваться во время каждого старта.

Кстати, 0 и 1 во время передачи данных можно соотнести с маскированием линии тактов. Если ведомы будет синхронизироваться по фронту - вроде потянет.

Примечание - все данные почерпнуты из мануала AT91SAM7S preliminary complete. На практике не проверял. (не житага, нет осцилла), все выводы сугубо из теории.

Удачи.

[Andry333 0]

ага, речь шла о sam7s. вы угадали, спасибо за внимание.. попробую еще раз потыркаться, мож что и получится... а вообще ужо думаю о том, что SPI нада прикручивать к этому делу а frame sync формировать программно.. цель завести мп3 декодер vs1001k.

[leen 0]

Ну как я понял, SSC гораздо гибчее SPI. Проблема в изучении. Он хоть эмулируется кейлом. А если есть осциллограф - то сладить думаю можно. У меня щас нет ни житага, ни осциллографа, так бы повозился пока спать не лег...

ЗЫ. К сожалению, я не столь продвинут, чтобы только по ману понять, как правильно работать с железякой, надо эксперименты:(

[Andry333 0]

да там похоже баг какойто... никакой реакции, когда устанавливаешь в поле FSOS значение 2 или 1, хотя при установке занчений 3, 4, 5 все прекрасно работает данные передаются, и нога FS дергается, но мне нужен как раз положительный импульс (значение ФСОСА = 0x2), который бы начинался за 2 такта до начала передачи и захватывал бы 1 такт клока (1 бит тобишь).... длительность импулься TF задаю в FSLEN... чет либо лыжи не едут либо я... :-)

[leen 0]

Да нет, просто зима была лютой... В общем, все работает. Вот чего я нащупал с помощью С1-114 (верный друг, товарищ и еда:):

- для того чтобы клоки на линии были только во время данных, поле CKO = 0x2, как и предполагалось;

- для формирования кадра синхронизации (далее FS) надо помудрить:

1 Определяем с какой скоростью поступают данные data_period (в периодах тактирования шины),

2 ставим период формирования FS в поле PERIOD регистра TCMR как (data_period/2) - 1,

3 ставим в TFMR нужный вид импульса (я не заметил разницы межлу falling & rising фронтами, хотя она наверно есть),

4 ставим в TCMR поле start в нужное нам положение - старт по заднему фронту,

5 ставим задержку вывода данных (если надо выводить данные после окончания FS) в поле STTDLY,

6 ставим длину данных - 1 (для одного байта за раз поставил DATLEN=7; DATNB = 0),

7 ставим длину FS: FSLEN = 0.

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

Успехов.

ЗЫ: если не все объяснил - пишите.

ЗЫЫ: вышел (новый) datasheet по SAM7S, rev. G, 11/06. Багов в SSC не убавилось. Такое впечатление, что сляпали, народ не возмущается - они и не правят.

Изменено 2 июля, 2007 пользователем Leen

[Andry333 0]

Да нет, просто зима была лютой... В общем, все работает.

О, пасиб, попробую... правда я ужо понял, что мне на самом деле этого не нада.. :) декодер, с которым я работаю оказывается, вопреки всем даташитам, способен работать, когда FS находиться в 1 в течение всего периода передачи байта! а этого получилось добиться без значительной кровопотери..

Но, я обязательно попробую Ваш метод.... просто я столько могу высушил, пока его запускал, что теперь запустить SSC по человечески - просто дело чести:)

[leen 0]

Гы, да не за что, сам хоть разобрался, а то смотрел на этот SSC, как баран на новые ворота :beer: Мне во время экспериментов пришло в голову, что эту фичу придумали специально для передачи стабильного по времени потока данных, т.к. грузить можно асинхронно, а уходят данные синхронно тикам передатчика. Очень между прочим полезно, я даже знаю, куда эту вешь смогу у себя в железяках засунуть

[Andry333 0]

я не заметил разницы межлу falling & rising фронтами, хотя она наверно есть

 

Falling & rising, насколько я понял относится к полю FSEDGE.. а оно детектирует либо передний фронт FS сигналла либо задний и вызывает прерывание

[Andry333 0]

Еще вопрос от Ламера... Чет не могу сообразить как работать с прерываниями ENDTX... Этот флаг, ведь всегда в еденице!! что бесконечно вызывает прерывание:-(.. Так вот вопрос.. как сделать так, чтоб прерывание выскакивало только один раз после завершения передачи байта.

 

SSC настройка стандартная, взятая откудато(не помню уже), с маленькими переадаптациями.

 

>void AT91F_SSC_Start(void)

{ // Setup ssc

AT91F_SSC_CfgPMC(); /* Enable MCK clock */

 

// pio Special configuration

*AT91C_PIOA_PDR = AT91C_SSC_TD; /* Enable TD on PA17 */

*AT91C_PIOA_ASR = AT91C_SSC_TD;

*AT91C_PIOA_ODR = AT91C_SSC_TD;

*AT91C_PIOA_PDR = AT91C_PA15_TF; /* Enable TF on */

*AT91C_PIOA_ASR = AT91C_PA15_TF;

*AT91C_PIOA_ODR = AT91C_PA15_TF;

*AT91C_PIOA_PDR = AT91C_PA16_TK; /* Enable TK on */

*AT91C_PIOA_ASR = AT91C_PA16_TK;

*AT91C_PIOA_ODR = AT91C_PA16_TK;

 

// Configure SSC in Transmit mode

AT91F_SSC_Conf(AT91C_BASE_SSC,

(MCK / (2 * SAMPLEWORDBITS * SAMPLE_RATE)) + 1, // SSC_CMR

0, // SSC_RCMR

0, // SSC_RFMR

AT91C_SSC_CKS_DIV + AT91C_SSC_CKO_DATA_TX + AT91C_SSC_START_CONTINOUS + AT91C_SSC_PERIOD, // SSC_TCMR

 

(SAMPLEWORDBITS - 1) + (((SAMPLEFRAME-1) & 0xF) << 8) + AT91C_SSC_MSBF + AT91C_SSC_FSLEN + AT91C_SSC_FSOS_HIGH + AT91C_SSC_FSEDGE ); // SSC_TFMR

 

 

//* Open SSC interrupt

AT91F_AIC_ConfigureIt ( AT91C_BASE_AIC, AT91C_ID_SSC, SSC_INTERRUPT_LEVEL, AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL , SscHandler);

 

AT91F_AIC_EnableIt(AT91C_BASE_AIC, AT91C_ID_SSC);

 

AT91F_SSC_EnableIt( AT91C_BASE_SSC, AT91C_SSC_TXEN );

 

AT91F_SSC_EnableTx(AT91C_BASE_SSC);

}<

 

Идея такая.. Когда нада передать несколько байт я просто записываю в THR первый байт из массива, а остальные байты я хочу посылать в обработчике прерывания, которое возникнет после передачи первого...

Как настроить?? чтото я Моск уже сломал....

[amw 0]

Ну SSC - это для кодеков. Там не может быть такого что данные кончились.

Данные нужно передавать всегда. В отличие от SPI например.

[Andry333 0]

Ну SSC - это для кодеков. Там не может быть такого что данные кончились.

Ну чтож так все катигорично.. вот у мя такая ситуация что при нуле на определенной ноге проца передачу нада остановить.... и возобновить, когда нога прыгнет в еденицу. Связываться пытаюсь с mp3 декодером VS1001k... а когда файл закончится, то темболее нада передачу останавливать, дабы не ввести декодер в шоковое состояние:-)

 

Так как быть то? Решил я извратиться и загружать данные в THR по таймеру:-) ресурсов не должно сильно много отнимать...

[leen 0]

В мане по SAM7S:

SSC Status Register - SSC_SR

ENDTX: End of Transmission

0: The register SSC_TCR has not reached 0 since the last write in SSC_TCR or SSC_TNCR.

1: The register SSC_TCR has reached 0 since the last write in SSC_TCR or SSC_TNCR.

Т.е. Прерывание возникает при опустошении буфера, скормленного ранее каналу ПДП (PDC) этого модуля. При этом неважно, какой буфер опустел, первый (PDC_TCR == 0) или второй (PDC_TNCR == 0). Мне больше нравится прерывание TXBUFF - ставится только при опустении первого буфера. Если во второй буфер что-то сунуть при пустом первом, и адрес, и длина немедленно проваливаются в первый канал ПДП. А вообще, с УСАРТом я поступал так: скормил данные в PDC, разрешил прерывание TXBUFF. В прерывании по TXBUFF запретил его, поднял флаг - пакет ушел. А если не запретить - да, все время будешь болтаться в прерывании.

В данном случае напрашивается следующий вариант:

- есть два буфера, работающих по очереди. Пока PDC выгребает данные из одного - набиваем второй, и наоборот.

Инициализация:

- заполнили первый буфер; чтобы не усложнять - в ПДЦ данные не отдаем;

- разрешили ПДП на передачу;

- разрешили прерывание TXBUFF.

 

Работа:

- ждем прерывания TXBUFF;

- в прерывании скормили первому каналу ПДП очередной буфер (флаг TXBUFF опустится), поменяли роли буферов - пока из текущего передаются данные, набиваем следующий;

- опять ждем прерывания TXBUFF; и т.д...

 

По запрету вывода звука можно просто обнулить регистр счетчтика передачи ПДП (PDC_TCR), и он умолкнет. При этом, после разрешения можно будет начать с того же места (снятие с паузы).

 

Извиняюсь, что немного сумбурно - без малого два ночи, а жена у родителей:) Поэтому - :beer: и :smile3046: B)