Проблема с 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, не исключено что что-то упускаю.

[Albun]

Пишу этот заключительный пост в надежде что это поможет кому то, кто еще стоит перед выбором использовать ему SSC в своих продуктах или нет.
Итак, прежде всего, SSC есть аббревиатура от СИНХРОННЫЙ последовательный контроллер, т.е. предполагается что все операции передачи данных жестко и строго синхронизированы с тактирующими импульсами. Следовательно, в определенных случаях контроллер мог бы выступать как мастером (ведущим) так и ведомым.
Прочитав документацию был приятно удивлен, так как по описанию SSC являлся очень гибкой вещью которую можно было бы конфигурировать большим количеством способов и добиваться различных режимов работы контроллера, что не могло не радовать.
Например схемы тактирования трансмиттера и передатчика позволяют выбирать для каждого по три разных источника тактовых импульсов – МСК, использовать тактирование соседнего блока (трансмиттеру такты ресивера, ресиверу – такты трансмиттера), использовать внешнее тактирование ножек TK и (или) RK. Режим трансмиттера в соответствии с той же документацией может быть как чисто передачей данных, так и передаче данных может предшествовать отправка синхронизационной последовательности битов (до 16), и т.п.
На практике все оказалось далеко от ожидаемых надежд. В первую очередь засада поджидает если доверчивый разработчик, прочитав радостно документацию, решит использовать SSC в приложении, где не нужны предшествующие передаче синхронизационные последовательности битов.

Объясню.
Ставим для трансмиттера и ресивера соответствующие поля STTDLY = 0, т.е. при любых раскладах сразу должна начаться передача/прием данных. Ножку TK назначим получать внешний синхросигнал для трансмиттера, ресивер сконфигурируем получать клоки от трансмиттера (CKS поля), поставим длину данных одинаковую для трансмиттера и ресивера 8 бит (просто для удобства): DATLEN = 8 – 1, DATNB – без разницы, например оставим одно слово, т.е. DATNB = 0. Ставим признак старта для трансмиттера – бесконечный, т.е. начинать передачу сразу же как только была запись в регистр THR (т.е. START = 0), для ресивера – стартовать вместе с трансмиттером, т.е. START = 1. Остальные поля описывать не существенно, так как уже и вышеописанной конфигурации достаточно чтоб испытать первое разочарование. После того как контроллер сконфигурирован и готов к работе, пишем в THR данные которые хотим передать, например THR = 0x00. Т.е. с этого момента контроллер получил признак старта для трансмиттера, а значит и ресивер тоже запускается. Еще замечу, что все это в соответствии с официальной документацией – сделав все как описано выше мы должны получить именно то что хотим.
Подаем тактовые импульсы на ножку TK. И что имеем? Ресивер радостно начинает вдвигать в себя поступающие биты с ножки RD начиная с первого такта, в то время как трансмиттер начинает выдавать данные только на 4-м (!!!) такте поступившем на TK. Через восемь тактов ресивер сообщит о готовности данных, в то время как трансмиттеру еще останется выдвинуть 3 бита. И это при том что в документации ни слова не сказано об этой интересной особенности.
Можно конечно сконфигурировать ресивер начать прием на 4-м такте с помощью STTDLY = 3. Но разве это поможет если с другого конца стоит устройство которое и не подозревает что его первые три тактовых импульса поданные на ножку TK ушли в пустоту???
Описанное выше была попытка использовать SSC в режиме ведомого SPI. Естественно, имея отдельный контроллер SPI (даже два во многих MCU атмела), зачем возиться с SSC? Но тем не менее, задачи бывают разные в жизни и кто знает что может понадобиться. Тем более что прочитав документацию можно сделать вывод что абсолютно никаких препятствий реализовать приведенное выше нет.

Теперь поступим по другому, сконфигурируем ресивер получать тактовые импульсы с ножки RK, трансмиттер – тактироваться от синхроимпульсов ресивера, и выдавать таковые импульсы на ножку TK только во время передачи данных (т.е. поле CKO трансмиттера = 2). Остальное как в предыдущем примере.
Подаем на RK непрерывные тактовые импульсы. Записываем в THR данные, например THR = 0x00. И что видим? Ресивер радостно начинает вдвигать в себя биты начиная с первого такта на RK ножке. Трансмиттер первые два такта мертв, т.е. на TK ножке импульсов нет, на ТD ножке – мусор. На третьем такте трансмиттер начинает выдвигать данные, ножка TK дублирует такты с RK. Итого после восьмого такта ресивер уже готов, трансмиттеру еще два такта чтоб закончить передачу. Через два такта трансмиттер останавливается (т.е. TK ножка снова неподвижна), а ресивер уже успел еще 2 бита захватить.
Конечно можно поставить для ресивера STTDLY = 2 и тогда ресивер только с третьего такта, как и трансмиттер передачу, начнет прием. А ведь в документации об этом ни слова, в документации все красиво описано, прочитав документацию человек подумает а почему бы нет? В документации приведены диаграммы для случая STTDLY = 0 где видно что данные пойдут сразу по наступлению события старт (т.е. в примере выше – по записи в THR) но нигде не сказано что, очевидно, внутренне для SSC этот старт наступит только на 3-м тактовом импульсе.
Это был пример реализовать ведущий (мастер) SPI на SSC. Зачем – ответ как и в рассуждении выше. Плюс еще одно “за” – такой SPI мастер имел бы возможность тактироваться внешним клоком, в то время как встроенный SPI тактируется только от частот кратных MCK.
В общем насколько я смог постичь, SSC пригоден для использования ТОЛЬКО в приложениях где задействованы предшествующие передаче/приему синхронизационные последовательности битов (до 16). Случаи когда STTDLY = 0 на практике бесполезны из-за описанных выше 2-х или 3-х тактовых задержек, которые просто недопустимы.


Р.S. Просьба не ругать сильно, старался как мог. Думаю данная информация будет кому то не лишней.