Здравствуйте уважаемые участники форума, подскажите пожалуйста, как настроить SSC таким образом, чтобы он при записи данных в регистр SSC_THR тактирование шло только в течение передачи одного байта да еще и с frame sync вначале передачи?? всю ночь просидел, голова пухнет... но проблема в том, как только разрешаю передачу, устанавливаю AT91C_SSC_PERIOD регистра SSC_TCMR так он без передачи байт начинает тактировать и выдавать импульсы 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. На практике не проверял. (не житага, нет осцилла), все выводы сугубо из теории.
Удачи.

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

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

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

Да нет, просто зима была лютой... В общем, все работает. Вот чего я нащупал с помощью С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 не убавилось. Такое впечатление, что сляпали, народ не возмущается - они и не правят.

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

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

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

Еще вопрос от Ламера... Чет не могу сообразить как работать с прерываниями 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 первый байт из массива, а остальные байты я хочу посылать в обработчике прерывания, которое возникнет после передачи первого...
Как настроить?? чтото я Моск уже сломал....

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

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

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

В мане по 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), и он умолкнет. При этом, после разрешения можно будет начать с того же места (снятие с паузы).

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