|
|
|
непонятки с Synchronous Serial Controller, как отправлять отдельно по байтам, типа, как SPI тока с frame sync |
|
|
|
Jun 30 2007, 09:46
|
Частый гость
Группа: Свой
Сообщений: 172
Регистрация: 5-08-06
Из: Владивосток
Пользователь №: 19 343
|
Цитата(Andryha @ Jun 30 2007, 17:00) тактирование шло только в течение передачи одного байта да еще и с 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. На практике не проверял. (не житага, нет осцилла), все выводы сугубо из теории. Удачи.
|
|
|
|
|
Jul 1 2007, 08:49
|
Участник
Группа: Участник
Сообщений: 34
Регистрация: 6-04-07
Пользователь №: 26 805
|
ага, речь шла о sam7s. вы угадали, спасибо за внимание.. попробую еще раз потыркаться, мож что и получится... а вообще ужо думаю о том, что SPI нада прикручивать к этому делу а frame sync формировать программно.. цель завести мп3 декодер vs1001k.
|
|
|
|
|
Jul 1 2007, 13:04
|
Участник
Группа: Участник
Сообщений: 34
Регистрация: 6-04-07
Пользователь №: 26 805
|
да там похоже баг какойто... никакой реакции, когда устанавливаешь в поле FSOS значение 2 или 1, хотя при установке занчений 3, 4, 5 все прекрасно работает данные передаются, и нога FS дергается, но мне нужен как раз положительный импульс (значение ФСОСА = 0x2), который бы начинался за 2 такта до начала передачи и захватывал бы 1 такт клока (1 бит тобишь).... длительность импулься TF задаю в FSLEN... чет либо лыжи не едут либо я... :-)
|
|
|
|
|
Jul 2 2007, 07:19
|
Частый гость
Группа: Свой
Сообщений: 172
Регистрация: 5-08-06
Из: Владивосток
Пользователь №: 19 343
|
Да нет, просто зима была лютой... В общем, все работает. Вот чего я нащупал с помощью С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 не убавилось. Такое впечатление, что сляпали, народ не возмущается - они и не правят.
Сообщение отредактировал Leen - Jul 2 2007, 07:22
|
|
|
|
|
Jul 3 2007, 02:41
|
Участник
Группа: Участник
Сообщений: 34
Регистрация: 6-04-07
Пользователь №: 26 805
|
Цитата(Leen @ Jul 2 2007, 14:19) Да нет, просто зима была лютой... В общем, все работает. О, пасиб, попробую... правда я ужо понял, что мне на самом деле этого не нада.. декодер, с которым я работаю оказывается, вопреки всем даташитам, способен работать, когда FS находиться в 1 в течение всего периода передачи байта! а этого получилось добиться без значительной кровопотери.. Но, я обязательно попробую Ваш метод.... просто я столько могу высушил, пока его запускал, что теперь запустить SSC по человечески - просто дело чести
|
|
|
|
|
Jul 3 2007, 05:28
|
Частый гость
Группа: Свой
Сообщений: 172
Регистрация: 5-08-06
Из: Владивосток
Пользователь №: 19 343
|
Гы, да не за что, сам хоть разобрался, а то смотрел на этот SSC, как баран на новые ворота Мне во время экспериментов пришло в голову, что эту фичу придумали специально для передачи стабильного по времени потока данных, т.к. грузить можно асинхронно, а уходят данные синхронно тикам передатчика. Очень между прочим полезно, я даже знаю, куда эту вешь смогу у себя в железяках засунуть
|
|
|
|
|
Jul 4 2007, 13:16
|
Участник
Группа: Участник
Сообщений: 34
Регистрация: 6-04-07
Пользователь №: 26 805
|
Цитата(Leen @ Jul 2 2007, 14:19) я не заметил разницы межлу falling & rising фронтами, хотя она наверно есть Falling & rising, насколько я понял относится к полю FSEDGE.. а оно детектирует либо передний фронт FS сигналла либо задний и вызывает прерывание
|
|
|
|
|
Sep 25 2007, 06:44
|
Участник
Группа: Участник
Сообщений: 34
Регистрация: 6-04-07
Пользователь №: 26 805
|
Еще вопрос от Ламера... Чет не могу сообразить как работать с прерываниями 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 первый байт из массива, а остальные байты я хочу посылать в обработчике прерывания, которое возникнет после передачи первого... Как настроить?? чтото я Моск уже сломал....
|
|
|
|
|
Sep 25 2007, 15:57
|
Участник
Группа: Участник
Сообщений: 34
Регистрация: 6-04-07
Пользователь №: 26 805
|
Цитата(amw @ Sep 25 2007, 22:33) Ну SSC - это для кодеков. Там не может быть такого что данные кончились. Ну чтож так все катигорично.. вот у мя такая ситуация что при нуле на определенной ноге проца передачу нада остановить.... и возобновить, когда нога прыгнет в еденицу. Связываться пытаюсь с mp3 декодером VS1001k... а когда файл закончится, то темболее нада передачу останавливать, дабы не ввести декодер в шоковое состояние:-) Так как быть то? Решил я извратиться и загружать данные в THR по таймеру:-) ресурсов не должно сильно много отнимать...
|
|
|
|
|
Sep 28 2007, 14:53
|
Частый гость
Группа: Свой
Сообщений: 172
Регистрация: 5-08-06
Из: Владивосток
Пользователь №: 19 343
|
В мане по 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), и он умолкнет. При этом, после разрешения можно будет начать с того же места (снятие с паузы). Извиняюсь, что немного сумбурно - без малого два ночи, а жена у родителей Поэтому - и
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|