Проблема с SSC в AT91SAM9260 Опции

[Albun]

Столкнулся со следующей проблемкой при работе с контроллером SSC (в AT91SAM9260).
Конфигурация платы такая:
- ножка TK0 соединена с ножкой PB0, которую я перевел в режим вывода, т.е. программно устанавливая на ней 0 или 1 я эмулирую тактовые импульсы на вход ТК0; TК0 конфигурируется как периферия А и сам блок SSC трансмиттера предполагается чтоб использовал эту ножку в качестве тактовых импульсов;
- TF0 не используется, остается как обычная I/O в режиме входа;
- с ТD0 снимаются данные, ножка конфигурируется как периферия А;
- на RD0 поступают данные, конфигурируется как периферия А;
- RK ножка используется для вывода тактовых импульсов трансмиттера; конфигурируется как периферия А; сам блок ресивера в качестве испульсов использует TK_clock;
- RF не используется, остается как обычная I/O в режиме входа;
В документации сказано, что можно в качестве TX_clock выбрать из трех сигналов, один из которых - внешний с ножки TF0, что я и делаю (прописывая CKS поле). Далее сказано, что на ножку RK0 можно выводить RX_clock, плюс этот сигнал может выводиться только в период когда активен прием, что я и делаю (СКО поле). Ставлю STTDLY = 0 для трансмиттера и ресивера, т.е. не использую синхронизационные фреймы. Признак начала (START) для трансмиттера ставлю CONTINUOS а для ресивера - TRANSMIT_START, т.е. трансмиттер должен начать передачу данных сразу же после записи в регистр THR и ресивер начать прием как только начнет работать трансмиттер. Выставляю длину данных - 8 бит (DATLEN=7 для трансмиттера и ресивера).

Вот код конфигурирования непосредственно SSC:
#define AT91C_SSC_CKS_TK_PIN 0x02

AT91C_BASE_SSC0->SSC_IDR = 0xFFFFFFFF;
AT91C_BASE_PMC->PMC_PCER = 0x01 << AT91C_ID_SSC0;

AT91C_BASE_SSC0->SSC_CR = AT91C_SSC_SWRST;
AT91C_BASE_SSC0->SSC_CR = AT91C_SSC_RXDIS | AT91C_SSC_TXDIS;
AT91C_BASE_SSC0->SSC_TFMR = AT91C_SSC_DATDEF | AT91C_SSC_MSBF | AT91C_SSC_FSOS_LOW;
AT91C_BASE_SSC0->SSC_TCMR = AT91C_SSC_CKS_TK_PIN | AT91C_SSC_CKO_NONE | AT91C_SSC_START_CONTINOUS;
AT91C_BASE_SSC0->SSC_RCMR = AT91C_SSC_CKS_TK | AT91C_SSC_CKO_DATA_TX | AT91C_SSC_CKI | AT91C_SSC_START_TK;
AT91C_BASE_SSC0->SSC_RFMR = AT91C_SSC_MSBF;
AT91C_BASE_SSC0->SSC_PTCR = AT91C_PDC_RXTDIS | AT91C_PDC_TXTDIS;
AT91C_BASE_SSC0->SSC_CR = AT91C_SSC_RXEN | AT91C_SSC_TXEN;

AT91C_BASE_SSC0->SSC_TFMR = (AT91C_BASE_SSC0->SSC_TFMR & (~AT91C_SSC_DATLEN)) | (0x08 - 0x01);
AT91C_BASE_SSC0->SSC_RFMR = (AT91C_BASE_SSC0->SSC_RFMR & (~AT91C_SSC_DATLEN)) | (0x08 - 0x01);

Дальше записываю данные в THR (THR = 00) и вручную тактирую TK0 ножку устанавливая 0 и 1 на PB0 ножке. И теперь странно - тестером меряю ножку TD0 - по идее на ней должен сразу же выводиться мой нолик который я записал в THR, на практике же он появляется там только на 4-й (!) тактовый импульс. Первые 3 такта на TD0 стоит единица. После этого (4й импульс) начинает выдвигаться число что я записал в THR (т.е. 0х00) и после 8-го бита TD0 возвращается в 1 (DATDEF я ставлю в 1) и уже остается в таком положении сколько бы тактов не подавать (что есть логично). Т.е. по документации должны СРАЗУ выйти 8 бит (ведь передачу синхронизации я выключил) а выходят первые три 1-цы и только потом уже 8 бит данных. Что не так???
Второе - меряю ножку RK0, которая по идее, в соответствии с документацией должна бы выводить сигнал только в момент когда активен прием (т.е. восемь тактов). Но на практике - на RK0 постоянно идет тактирование, т.е. истекли 8 тактов, ресивер по идее принял данные и уже должен остановиться - но нет, RK0 ножка, все равно, выводит тактовые импульсы бесконечно, как будто и не поставил я в CKO ресивера (CKO = AT91C_SSC_CKO_DATA_TX ) выводить импульсы только в момент когда трансакции активны. Ну что не так??????
Кто может что дельное подсказать, прошу откликнитесь. Первый раз работаю с SSC, не исключено что что-то упускаю.

[aaarrr]

Дальше записываю данные в THR (THR = 00) и вручную тактирую TK0 ножку устанавливая 0 и 1 на PB0 ножке. И теперь странно - тестером меряю ножку TD0 - по идее на ней должен сразу же выводиться мой нолик который я записал в THR, на практике же он появляется там только на 4-й (!) тактовый импульс. Первые 3 такта на TD0 стоит единица.

ИМХО, тут все логично. Никто не обещает, что данные начнут выдвигаться немедленно на первом же клоке внешнего сигнала. На синхронизацию, загрузку сдвигового регистра и т.п. нужно несколько тактов.

Но на практике - на RK0 постоянно идет тактирование, т.е. истекли 8 тактов, ресивер по идее принял данные и уже должен остановиться - но нет, RK0 ножка, все равно, выводит тактовые импульсы бесконечно, как будто и не поставил я в CKO ресивера (CKO = AT91C_SSC_CKO_DATA_TX ) выводить импульсы только в момент когда трансакции активны. Ну что не так??????

Трансмиттер лопатит постоянно, старт ресивера привязан к трансмиттеру - почему его клоки должны остановиться?

[Albun]

Трансмиттер лопатит постоянно, старт ресивера привязан к трансмиттеру - почему его клоки должны остановиться?

Так ведь в документации написано:
CKO Receive Clock Output Mode RK pin
0x0 - None Input-only
0x1 - Continuous Receive Clock Output
0x2 - Receive Clock only during data transfers

0х2 - клок только в течении транзакций. Иначе какая разница между опциями 0х1 и 0х2?

Почему же трансмиттер лопатит постоянно? Я настроил его чтоб он выдал только 8 бит один раз и все (поле DATNB по умолчанию тут стоит 0, т.е. колчество слов на один трансфер равно 1). После этого трансмитеру нечего передавать, трансфер закончен. Да, на его вход постоянно идут тактовые импульсы ну и что? На SPI к примеру тоже идут постоянно тактовые импульсы, но ведь после выдачи слова тут все прекращается успешно, а в SSC - затык. Конечно же SSC не SPI, но согласно документации - поведение его отличается от того что должно бы было быть.

По поводу RK - ведь это выход,т.е. тут импульсы должны присутствовать непосредственно тактовые, иначе какой же это Синхронный Последовательный Контроллер? Ваше предположение что может потребоваться несколько тактов на инициализацию трансфера - логично, но это не должно влиять на выходные тактовые имульсы генерируемые контроллером для других устройств (в доке написано что это позволит более гибко организать цеопчку разных устройств). В одном устройстве нужно будет 100 тактов на загрузку сдвигового регистра, в другом - 3, бред получится. Поэтому и ожидаю на выходе более логичных данных. Да и в документации клоки жестко расписаны, приведены диаграммы - с первого же клока.

Вот из документации:
The receiver can also drive the RK I/O pad continuously or be limited to the actual data transfer.

Ну как их по другому понять?

Сообщение отредактировал Albun - Oct 5 2009, 20:18

[aaarrr]

Почему же трансмиттер лопатит постоянно? Я настроил его чтоб он выдал только 8 бит один раз и все (поле DATNB по умолчанию тут стоит 0, т.е. колчество слов на один трансфер равно 1). После этого трансмитеру нечего передавать, трансфер закончен. Да, на его вход постоянно идут тактовые импульсы ну и что?

А то, что Transmit Start у Вас настроен как Continuous. То есть абсолютно не важно, загружено что-нибудь в THR, или нет - передача все равно идет.

В одном устройстве нужно будет 100 тактов на загрузку сдвигового регистра, в другом - 3, бред получится. Поэтому и ожидаю на выходе более логичных данных. Да и в документации клоки жестко расписаны, приведены диаграммы - с первого же клока.

Просто крайне не логично пытаться использовать SSC в слейв-режиме без фреймсинков. Результат практически непредсказуем.

Вот из документации:
The receiver can also drive the RK I/O pad continuously or be limited to the actual data transfer.

Ну как их по другому понять?

Так передачи-то у Вас идут постоянно.


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

[Albun]

А то, что Transmit Start у Вас настроен как Continuous. То есть абсолютно не важно, загружено что-нибудь в THR, или нет - передача все равно идет.

Так ведь у них написано что это значит что передача начнется как только будет запись в THR. Конечно не сказано и что она закончится как THR опустеет, но мне кажется что это будет бред, смысл тогда всех этих установок количества битов и особенно количества слов в трансфере. А если я выбрал не внешний клок а внутренний от МСК - что же тогда получится, зазевался, не успел вовремя подгрузить в трансмитер новые данные и он по кругу пока суть да дело гоняет то что есть? Нет, не логично.

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

Самыми простыми словами - нужен SPI мастер только с возможностью того чтоб можно было его тактировать извне. А тот SPI что в атмеле тактируется только кратной частотой от MCK

Сообщение отредактировал Albun - Oct 5 2009, 20:52

[aaarrr]

Так ведь у них написано что это значит что передача начнется как только будет запись в THR.

Данные начнут выпихиваться немедленно, а вот клоки будут и до и после.

Конечно не сказано и что она закончится как THR опустеет, но мне кажется что это будет бред, смысл тогда всех этих установок количества битов и особенно количества слов в трансфере.

Почему же бред? Битстрим какой-нибудь выпихнуть, FPGA, например, загрузить - очень даже подойдет. Смысл установки приобретают при использовании FS.

А если я выбрал не внешний клок а внутренний от МСК - что же тогда получится, зазевался, не успел вовремя подгрузить в трансмитер новые данные и он по кругу пока суть да дело гоняет то что есть? Нет, не логично.

Будет гонять то, что записано в DATDEF. Это все же не SPI, идеология другая. Когда данные идут на кодек, например, "зазевываться" ну никак нельзя.

Самыми простыми словами - нужен SPI мастер только с возможностью того чтоб можно было его тактировать извне. А тот SPI что в атмеле тактируется только кратной частотой от MCK

SPI мастер с тактированием извне - это SPI слейв. Может, его и использовать?