Помогите разобраться с AD1853

[Grundig]

Есть проблема по стыковке AD1853 c шиной 48 Bclk (RJ16). Разбираясь с диаграммами приема 1853 сделал вывод, что достаточно сдвинуть вправо SDATA на 8 тактов Bclk и 1853 их верно примет. Есть вопрос в том, что до смены LRclk число импульсов Bclk составит не (32-16=16) как должно быть для 1853 при 64Bclk, а (24-16=8) так как шина выдает 48Bclk. Будет ли правильный прием у 1853? Ведь в даташите 1853 черным по белому 64Bclk/Fs!
Знающие теоретики или опытные практики выскажитесь!

[dortonyan]

Есть проблема по стыковке AD1853 c шиной 48 Bclk (RJ16).

А софтовый конфигуратор у AD1853 есть? Потому что по умолчанию у AD1853 по входу RJ24.

Разбираясь с диаграммами приема 1853 сделал вывод, что достаточно сдвинуть вправо SDATA на 8 тактов Bclk и 1853 их верно примет.

Совершенно верно.

Есть вопрос в том, что до смены LRclk число импульсов Bclk составит не (32-16=16) как должно быть для 1853 при 64Bclk, а (24-16=8) так как шина выдает 48Bclk.

Это - пофигу. 1853 отсчитает после положительного перепада LRCK 8...16 клоков (в зависимости от выставленной входной разрядности) и начнет принимать данные. А клоков может быть сколько угодно: как в большую, так и в меньшую сторону, лишь бы данные нормально принимались.
Это значит, что 1853 можно и в режиме 24RJ скормить 16RJ данные (придержав данные на 8 клоков от LRCK), но в таком случае после данных цапу нужно скормить еще 8 клоков с нулевыми данными, иначе входной регистр данных цапа не заполнится до конца.

[Grundig]

Пардон! Походу Остапа(то есть меня) занесло...Допустим режим приема 1853 RJ16.Регистр приема 1853 отсчитывает 16 импульсов Bclk ,затем включается прием DATA-еще 16 бит.Уже получается в сумме 32 ,а значит сменился LRclk,регистр приема 1853 начинает следующий отсчет Bclk для второго канала-следовательно 8 младших бит DATA (текущего канала) будут просто потеряны...Вывод-простыми средствами преобразовать RJ16 48/RJ16 64 нельзя?
Остается вариант -1853 RJ24 .Тогда сдвигать ничего не нужно (после перепада LRclk в варианте RJ16/48 и в 1853 RJ24 отсчет значащих бит SDATA начинается с 8 импульса Bclk).
Получаем два вопроса: 1. что (0или1) в незначащих битах SDATA после 16 информационных ? 2. поймет ли 1853 что ее кормят 16 битами ведь вес 1 бита в дискретизации 16 и 24 бита-разный!А мы поставили режим 24 бит...Другими словами мы хотим чтобы 1853 работала в режиме приема 24 бит а обрабатывала информацию 16 бит-так я думаю неможно...Когда выравнивание правое -1853 сама определяет битность,но сейчас мы ей указали-24!
Задавал вопрос по конвертеру 48/64 АДВ в личке, но своими наработками он делиться не захотел,а в своих ЦАПах он 1853 кормит в RJ-ИМХО...

[dortonyan]

Grundig, все правильно пишете.

Остается вариант -1853 RJ24 .Тогда сдвигать ничего не нужно

Но тут нужно добавлять еще клоки, а некуда. Птому это все делать если только на CPLD.

что (0или1) в незначащих битах SDATA после 16 информационных ?

Можно и то и другое, но лучше нули: единицы создадут постоянку.

поймет ли 1853 что ее кормят 16 битами

Разумеется нет. Обработка будет идти как для 24-х разрядных данных. Отличается ли она от обработки 16-ти разрядных - я хз.

Задавал вопрос по конвертеру 48/64 АДВ в личке, но своими наработками он делиться не захотел,а в своих ЦАПах он 1853 кормит в RJ-ИМХО...

Так в соседней ветке Алексей (AAL) вроде как даже исходники выложил на конвертор 48 to 64.

[Turbo_man]

Проще ваш LRCLK (НЕ ДАННЫЕ - SDATA) задержать на 8 тактов (или на 7 и проинвертировать) (например, при помощи 74HC595), превратив данные в 16LJ (или 16I2S). И 1853 тоже перевести пинами 20 и 21 в режим LJ (или I2S), тогда больше ничего не нужно будет делать (в смысле добавлять недостающие клоки).

[aal]

Проще ваш LRCLK (НЕ ДАННЫЕ - SDATA) задержать на 8 тактов (или на 7 и проинвертировать) (например, при помощи 74HC595), превратив данные в 16LJ (или 16I2S). И 1853 тоже перевести пинами 20 и 21 в режим LJ (или I2S), тогда больше ничего не нужно будет делать (в смысле добавлять недостающие клоки).

Проще то проще, но некоторые сд контроллеры (дсп не назвал, так как поймут не правильно) могут тиражировать бит в область не определённую в RJ16 48BCK. Т.е. при таком алгоритме у вас может появится кодозависимый шум.

[Turbo_man]

могут тиражировать бит в область не определённую в RJ16 48BCK.

Если можно, тут поподробнее.

[aal]

В случае 48bck 16rj может получится, что первые восемь бит могут содержать как знаковый бит сэмпла, так и последний бит предидущего сэмпла. Могут быть и в "0", но этого ни кто не обещает. Т.е. при простом сдвиге LRCK относительно битового потока и/или при приёме этого сэмпла как 24-х битного младшие 8 бит будут иметь кодово зависимый мусор.
Т.е. при всех операциях в этом случае желательно занулять не задействованные биты входного сэмпла.

[Turbo_man]

Понятна мысль, на время задержки LRCLK требуется сделать мьют данным. Элемент "2И" справится с этим? Точнее "2И", и "исключающее ИЛИ с инверсией" для управления "2И".

[aal]

Понятна мысль, на время задержки LRCLK требуется сделать мьют данным. Элемент "2И" справится с этим? Точнее "2И", и "исключающее ИЛИ с инверсией" для управления "2И".

"ну где-то так: сэмь-восэм"

[Grundig]

В моем случае CXD3017 первые 8 бит содержат непрерывный 15(MSB) передаваемого канала...