[Albun 0]

Столкнулся со следующей проблемкой при работе с контроллером 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 63]

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

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

 

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

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

[Albun 0]

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

 

Так ведь в документации написано:

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.

 

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

Изменено 5 октября, 2009 пользователем Albun

[aaarrr 63]

Почему же трансмиттер лопатит постоянно? Я настроил его чтоб он выдал только 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 0]

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

 

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

 

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

 

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

Изменено 5 октября, 2009 пользователем Albun

[aaarrr 63]

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

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

 

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

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

 

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

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

 

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

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

[Albun 0]

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

 

Слейв не устанавливает сигналы выборки NPCS, а нужно именно чтоб на момент передачи NPCS менялся. Отдельно ножкой дрыгать тоже не получится, так как частоты будут большие и не всегда успею, а если

и привязываться к ручному "дрыганью" то это уже будет общая потеря производительности

[aaarrr 63]

Слейв не устанавливает сигналы выборки NPCS, а нужно именно чтоб на момент передачи NPCS менялся.

Так со стороны SSC уж тем более нечем дрыгать.

[Albun 0]

Так со стороны SSC уж тем более нечем дрыгать.

 

Ну как же? А сигналы TF RF - можно выбрать как угодно, поле FSOS - в том числе есть и вариант Driven Low during data transfer есть и Driven High during data transfer и еще много других, по моему более чем достаточно, и все это контроллер сам сделает. Поэтому и выбрал его, но похоже что пока не удачно

[aaarrr 63]

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

[Albun 0]

На свежую голову подумал, действительно, нигде ведь не сказано что приемник остановится как получит столько-то битов, напротив раз есть биты состояния типа OVRUN предполагается что прием будет скажем так, бесконечно долго. Да и тот же "родственный" SPI тоже так работает. Отсюда и постоянные тактовые импульсы на RK выходе, ведь для приемника "выводить тактовые импульсы в течении передачи данных" получается равносильно "бесконечно".

Учел это, и переделал слегка схему: теперь RK назначил как вход для тактовых импульсов, ресивер тактируется от этой ножки, трансмитер тактируется от RX_clock, и ножка трансмитера TK теперь как выход - на нее выдается тактовая частота (CKO = только в течении передачи данных). Померял тестером - теперь действительно, на TK выводятся тактовые импульсы ТОЛЬКО на время передачи, т.е. если я передаю 8 бит - то и меряется тоже только 8 тактов, а после - TK стоит. То что надо. Тоже наблюдается задержка - теперь правда 2 тактовых импульса (а не три) на RK проходят и только на 3-й импульс трансмитер начинает выдавать данные и такты.

Но все-равно, другая проблема выплыла - если установить ножку TF чтоб выводила низкий уровень в течении передачи данных (FSOS = AT91C_SSC_FSOS_LOW) то... ничего не происходит, на ножке TF постоянный высокий уровень. И в чем может быть проблема теперь??? :maniac:

P.S. Опять же странность, точно то же проделал паралельно с ножкой RF - на ней, при тех же установках FSOS, сигнал падает в 0 сразу же на первом тактовом импульсе от RK (несмотря на то что первые 2 имулься еще не есть передача данных)

 

P.S. Проблему c TF решил - просто банально забыл что я ее после бесчисленных тестов еще в одном месте возвращал в режим обычной I/O ножки как выход. Вернул ее на перефирию А и все стало ОК.

 

В общем тогда еще надо проверить работу ресивера - принимает ли он биты начиная с 3-го такта (смущает очень что RF падала в 0 на первом, "холостом" такте)

Изменено 6 октября, 2009 пользователем Albun

[Albun 0]

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

[aaarrr 63]

Если рассматривать атмеловский SSC, то у меня получаются такие оценки:

- связь в DSP-формате (FS в виде импульса) - хорошо, можно даже сгородить некоторое подобие TDM

- связь в I2S-формате - весьма посредственно

- Custom-применения - посредственно

 

Т.е. лучше, чем могло бы быть, но много хуже какого-нибудь McBSP от TI. Суровая правда жизни :(

[vmp 0]

Добавлю для полноты картинки (автору в его проблемах не поможет, но читателям может быть пригодится).

Атмеловский SSC можно еще использовать как SPI-передатчик, т.е. выход данных + такт.

Я в частности применял его для загрузки FPGA от Альтеры.