Попытка стандартизации разъёмов цифровых интерфейсов ЦАП

[energetik]

Предлагаю обсудить возможность организации единого разъёма состыковки разрабатываемых на Веге ЦАП с входными цифровыми интерфейсами разрабатываемыми тут же.
Поскольку для стыковки ЦАП и транспортов (других цифровых интерфейсов) одного разъёма i2s недостаточно, давайте обсудим варианты разъёма управления, либо объединение разъёма i2s и управления в один разъём.

[Turbo_man]

Надо бы ещё интерфейс индикации тоже "устаканить".

---------- Добавлено в 00:04 ---------- Предыдущее сообщение в 00:04 ----------

А у "кого" будет юзер интерфейс?

Не понял.

[Wired]

все должно работать прозрачно и незаметно для пользователя.

я именно об єтом

---------- Добавлено в 23:10 ---------- Предыдущее сообщение в 23:08 ----------

было бы наличие балластных резисторов на плате и необходимых линий питания.

а как же вариантьі под разньіе светодиодьі, одним один ток нужен - другим другой, кому-то ярче надо или наоброт...

[Turbo_man]

Достаточно (imho) было бы наличие балластных резисторов на плате и необходимых линий питания.

Пожалуй, да. Этот интерфейс не между изделиями разных людей, поэтому непринципиально.

Offтопик:


Я буду делать индикацию по SPI через контроллер VFD-дисплея M66004P. А есть ещё такие типа uPD16312, 15, 10, LC75712E итп.

[Wired]

боюсь с моей подачи, мьі как то не туда забрели, речь идет об интерфейсе зваимодействия 2-х устройств. а не о человеке. светики и кнопочки єто наверное в отдельную темку.

[Djemshut]

я именно об єтом

тогда я тоже не понял.
между цапом и юзером никакого интерфейса не надо. В источнике- юзаем интерфейс источника.

Offтопик:
я вот сделал в цапе два светодиодика- и те, больше технологические, индикация наличия питания 5 и 3.3 вольт на микруху цап, не любят они когда одно из питаний отваливается- а у меня оно от отдельных обмоток, было дело- выскочил провод из недожатого клеммника...

[Wired]

тогда я тоже не понял.

Да, я и сам не пойму чего єто я. Сплю уже наверное

[dortonyan]

А не проще вывести I2C от ЦАП-а наружу?

Лучше SPI, не важно откуда. Пускай на провод больше, зато гораздо проще в использовании, особенно если без контроллера.

в чём суть идеи?

Ну суть как в применении любого диф. интерфейса, что будет полезно при передачи высокочастотных сигналов - тех же мастерклоков.

[Audiomaniac]

Стандартизировать надо в первую очередь именно i2s, т.к. именно эта линия самая излучающая, значит надо, чтобы она легко и красиво делалась плоским шлейфом с чередованием земля-сигнал без всяких перекрутов и прочего.
Остальные сигналы (управление) - уже таких требований не предъявляют, их можно любыми проводками как угодно подключать, это пох.
Никакой необходимости отказываться от колодок IDC не вижу - никаких проблем с ними нету.
Я за то, чтобы разделить разъем i2s и разъем управления. Попытки стандартизировать второй ни к чему не приведут

[aal]

Я выскажу свою мысль и в дискуссии принимать участие не буду Всё ниже приведённое ИМХО.

1. Генератор(ы) ставятся в ЦАП или рядом с ним и в первую очередь подключаются к нему. Режим Slave для генов нужен в редком случае (но и тогда лучше воспользоваться ASRC и перейти на гены ЦАПа). Если уж он необходим, то я выбрал ISO150 для его ввода - минимум добавленного джиттера. Для транспорта значение джиттера мастер клока особого значения не имеет. Поэтому его отправку в транспорт можно делать как угодно (диф например), но так как у нас это внутренний интерфейс, то особого смысла его наворачивать нет. Единственный + уменьшение помех, но помехи синхронные с мастер клоком не слышны - стало быть и этот аргумент можно смело отмести. Остаётся TTL - его хватает. Другое дело что линию надо согласовывать и вот здесь возникает вопрос нагрузочного резистора в транспорте - его стоит стандартизовать.

Управление генераторов уже несколько утряслось: 1 выход для переключения сеток. Для тех кому нужен Slave - ещё один сигнал отключения генов. Раньше я был за передачу обоих мастер клоков на транспорт, но позже переосмыслил это и не вижу особой надобности - всё можно разрулить в транспорте , а мозги там (хотя бы простенький МК) необходим. А вот в ЦАПе МК особо делать нечего - основная трабла: его тактирование. Можно изголиться и затактировать его от MCK, но для его адекватной работы надо будет на него ещё завести и сигнал переключения генов.... А после такого приходишь к мысли, что его надо переносить в транспорт .....

2. цоколёвка разъёма. Это всё мелочи, но могу сказать о своём выборе: мастер клок должен быть экранирован - поэтому он и в самой серединке. Самый слабо зависимый от наводки сигнал: LRCK - он низкочастотный и именно его я выдвинул на край.

Единственное что я считаю необходимо - вывести туда питание 5В - оптимальный выбор на сегодняшний день. Кому нужно будет другое напряжение - поставят копеечный стаб в сот 23. Основное назначение: питать развязку, но если мощи хватит, то можно запитать и маломощный транспорт (я запитывал pcm2706).

Для включения ЦАПа в диф. режим предусматривать отдельный контакт смысла нет - проще поставит в ЦАПе одни инвертор.

Другое дело, что пора вводить поддержку ЦАПов без ЦФ (частот 384/768 кгц дискретизации) (эту функцию берёт на себя транспорт) и вот здесь потребуется ещё один специфический разъём на транспорте Объединять с I2S не стоит - потенциальные траблы в развитии....

Немного особняком стоит DSD - его пока особо негде взять, нечем сформировать такой поток, нет открытого формата его хранения. Ещё меньшее кол-во ЦАПов его могут принять. С одной стороны его надо стандартизовать, но ещё пока рановато.

3. дополнительные управляющие сигналы.

а) переключение генов 44х/48х - сейчас утряслось, что "Н" - 44х, а "L" - 48х. (Для желающих Slave: "Н" - гены включены, а "L" - выключены, подтяжка вверх обязательна! Тогда не подключение этого сигнала будет штатным режимом работы.)

б) переключение ЦФ: 2х и 4х выводы - не для всех удобно, но перекрывает некоторый диапазон ЦАПов/ЦФ.

в) Деемфазис - что-то все о нём забыли Раздельным по каналам его делать не стоит - от этого отказались основные игроки на рынке микросхем.

г) SPI интерфейс как опция. (I2C поддерживает меньшинство ЦАПов и ЦФ - но и переключение на него можно предусмотреть в транспорте). Это позволит тонко настраивать ЦАПы и ЦФ. И вот здесь самое интересное начинается: все реализуют адресацию регистров по своему. Отсюда я сделал вывод, что надо придумать метаязык описания регистров и битов для конфигуратора. Скромные наработки у меня есть, но это мизер и далеко не оптимальная реализация. Это тема скорее отдельной ветки и там можно что-то выработать на эту тему. Но заложить в "Стандарт" этот интерфейс надо.

4. Надо ли объединять это в один разъём? ИМХО нет. Достаточно определить порядок следования сигналов. Кому надо, тот поставит IDC-20(24) и получит все сигналы, а кому не надо поставят 1..3 IDC-10 и разнесут их по плате в оптимальные по трассировке места.

[Nikkov]

Стандартизировать надо в первую очередь именно i2s, т.к. именно эта линия самая излучающая, значит надо, чтобы она легко и красиво делалась плоским шлейфом с чередованием земля-сигнал без всяких перекрутов и прочего.
Остальные сигналы (управление) - уже таких требований не предъявляют, их можно любыми проводками как угодно подключать, это пох.
Никакой необходимости отказываться от колодок IDC не вижу - никаких проблем с ними нету.
Я за то, чтобы разделить разъем i2s и разъем управления. Попытки стандартизировать второй ни к чему не приведут

Почти согласен. Еще надо подумать про мастер клок. А для разъема управления имеет смысл определить линии I2C и/или SPI, а остальные, логические уровни, всегда легко переконфигурировать на стороне контроллера

[aal]

Никакой необходимости отказываться от колодок IDC не вижу - никаких проблем с ними нету.

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

[Audiomaniac]

Почти согласен. Еще надо подумать про мастер клок

Мастер-клок традиционно включить в разъем i2s, как и +5в с цапа (как в линксах). Остальное - другим разъемом, как получится.

[aal]

Кстати, насчёт "Lynx Audio" или "aal" - что мешает их поставить рядом - цена вопроса копейки и соединить сразу - кому какой надо, в тот и втыкает

[Ромыч]

Чтото мне кажется, что ничего конкретного из этой затеи не выйдет. Да и лично мне проще перекинуть 2-3 проводка на шлейфе на одной из сторон, чем париться над разводкой под какойто непонятный якобы стандарт. Оптимальная трассировка платы далеко не всегда позволит размещать пины по заданному стандарту, и я в этом случае всегда выберу трассировку, а не стандартизацию.

Проскочила шальная мысль вообще скомпоновать и основной сигнал, и управление в единый поток - тот же ЮСБ. А потом детектировать на плате цап. Вопрос в первую очередь в возможности реализации и в смысле такого решения вообще.

[Pyku_He_oTTyda]

LynxAudio давнее всех оппонентов присутствует, если так можно выразится, на рынке ЦАПов. Поэтому имело смысл придерживаться распиновки I2S, принятой у Дмитрия. Тогда бы не было этой темы вообще
Однако каждый пошел своим путем.
Проблема то небольшая, перекинуть проводки, но несколько некрасиво, если придираться.
Поддержу Илью, в плане того, что I2S отдельно, управление отдельно.
Переходить на колодки более 10 пинов смысла не вижу.
Хотя встречаются ситуации, когда необходимо и 16 пин. К примеру I2S дифф. сигналом + GND + Uпит + Deemf + 48/44 - уже не лезет в 10 пин, поэтому у себя я применяю 16 пин IDC.

Offтопик:

Да и лично мне проще перекинуть 2-3 проводка на шлейфе на одной из сторон, чем париться над разводкой под какойто непонятный якобы стандарт. Оптимальная трассировка платы далеко не всегда позволит размещать пины по заданному стандарту, и я в этом случае всегда выберу трассировку, а не стандартизацию.

Перекинуть пару тройку пинов на ПП гораздо легче и оптимальнее, чем перекрученные провода в шлейфе

[Ромыч]

Перекинуть пару тройку пинов на ПП гораздо легче и оптимальнее, чем перекрученные провода в шлейфе

Offтопик:
То, что даже на веге, к сожалению, преобладет стремление к понтам и цацкам в ущерб звуку - было понятно довольно давно.

[Wired]

Offтопик:
в большинстве случаев, действительно проще перекинуть пару проводков в IDC, честно говоря не вижу особой разницьі - будет оно "накручено" на ПП, или проводками перед разЬемом

[dortonyan]

Проскочила шальная мысль вообще скомпоновать и основной сигнал, и управление в единый поток - тот же ЮСБ. А потом детектировать на плате цап. Вопрос в первую очередь в возможности реализации и в смысле такого решения вообще.

Типа SPDIF?

Стандартизировать надо в первую очередь именно i2s, т.к. именно эта линия самая излучающая, значит надо, чтобы она легко и красиво делалась плоским шлейфом с чередованием земля-сигнал без всяких перекрутов и прочего.

В таком сллучае можно остановиться на двух разъемах IDC: 10-контактный для данных, и IDC 4-х контактный для доп. сигналов по SPI или I2C на выбор. Или же вместо последнего можно стандартизировать еще один 10-ти пиновый IDC по назначению пинов для управляющих сигналов, а так же для последовательных протоколов, для случаев, когда так удобнее. При этом в таком разъеме одна земля и целых 9 сигналов команд (с резервом на будущее).
Кстати сами IDC есть с шагом в 2мм, можно перейти на такие.
В темку РАЗЪЕМЫ.PDF

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

Не преувеличивайте, ничего страшного в этом нет. Зато реально удобно (без понтов) и сокращает время не только юзера, но и разработчика. Меня например монтаж распиновки абсолютно не волновал, с плисины можно развести как хочешь, а вот как назначить сигналы - вопрос.

[Audiomaniac]

в большинстве случаев, действительно проще перекинуть пару проводков в IDC

Проще, чем ЧТО? По мне, так лучше всего, когда вообще ничего не надо перекидывать. Тем более, что разработчику девайса это ничего не стоит, просто договориться один раз да и все.

[Wired]

Offтопик:

По мне, так лучше всего, когда вообще ничего не надо перекидывать. Тем более, что разработчику девайса это ничего не стоит, просто договориться один раз да и все.

так об єтом и тема, а в оффтопике просто мьісли вслух.