Параллельные доступные 16-битные цапы

**a1812** · 21.07.2009, 22:58

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

Порекомендуйте пожалуйста 16 битный цап с параллельной загрузкой данных. Из тех, которые доступны и стоят в районе 10-20 американских денег. И из тех которые звучат не хуже PCM2702 и PCM2707+1793+OPA2132 - сравнение проистекает из моего скудного опыта, кроме этого я ничего не делал, но хуже мне однозначно не надо

Параллельный интересует в связи с желанием сделать ридер WAV файлов c SD карты без использования плисин в качестве преобразователя в i2s... Т.е. хочется обойтись одной атмелиной без излишеств.

заранее спасибо.

**nazar** · 22.07.2009, 00:29

ti.com

**aal** · 22.07.2009, 09:30

Сообщение от a1812

без использования плисин в качестве преобразователя в i2s

А как же джиттер - плиска позволяет его здорово уменьшить, по сравнению с софтовым выводом, или будет 16битный паралельный регистр пересинхронизации?

**Mic Dragon** · 22.07.2009, 09:35

Если Вы ориентируетесь на мой проект проигрывателя, то без ПЛИС не получится прежде всего потому что вывод данных с процессора синхронизируется от ПЛИС по прерыванию и имеет сильную временнУю нестабильность (джиттер), порядка сотен наносекунд, ПЛИС не только преобразует формат но и обеспечивает пересинхронизацию данных. И в Атмегах, даже если задействовать внутренний таймер, от джиттера на выходе не избавиться без пересинхронизации. То есть обязательно нужен внешний регистр, с внешним или внутренним (на том же таймере с прямым выводом на ногу процессора) делителем. Делать их на ПЛИС или жесткой логике (регистр 2 корпуса, все вместе с преобразованием формата где-то 5 - 6 корпусов 74 серии) - в принципе без разницы, мне на ПЛИС было проще. А тогда уже можно ставить любой ЦАП.

**a1812** · 22.07.2009, 18:55

Если Вы ориентируетесь на мой проект проигрывателя, то без ПЛИС не получится прежде всего потому что вывод данных с процессора синхронизируется от ПЛИС по прерыванию и имеет сильную временнУю нестабильность (джиттер), порядка сотен наносекунд,

проект видел, но пока на него не ориентируюсь, так как не хочу связываться с плисинами. Если все таки придется - тогда за основу конечно же пойдет он. Но пока я не понимаю, откуда в атмеле возьмется джиттер порядка сотен наносекунд... Если не сложно - поясни. Я смотрю с той точки зрения, что таймер вполне адекватно делит тактовую, процедура вывода в порт легко реализуется с равным количеством тактов. Откуда там появляется джиттер порядка сотен наносекунд. Впрочем даже если он там есть - поделить тактовую на 256 и выводить в порт по внешнему прерыванию тоже легче, чем возиться с плисиной. Особому джиттеру тоже вроде неоткуда взяться... Или я что-то не понимаю и логика плисины работает с сигналом принципиально по другому в сравнении с логикой атмела? Где косяки зарыты? Исходим из того, что тактовая 11280600 или 16 с чем-то (лень считать 44100*384)? Заранее спасибо за пояснения, если таковые будут...

плиска позволяет его здорово уменьшить, по сравнению с софтовым выводом

тот жу вопрос - за счет чего и в чем разница работы логики плисины и атмела в описанных мной выше вариантах?

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

**Mic Dragon** · 22.07.2009, 21:33

Главный источник джиттера в процессоре при внутренней синхронизации вывода данных (прерывание от таймера действительно адекватного) - неоднозначность времени реакции процессора на прерывание в зависимости от длительности текущей команды, прерывание может быть обработано лишь послее ее завершения. В процессе воспроизведения никакие другие прерывания, которые могли бы увеличить время реакции, я естественно не использую. Время выполнения одной короткой команды (типа R-R) в атмеге составляет 1/Ft то есть примерно 90 нс при 11 МГц, длинной команды (вызова подпрограммы и возврата) - в 5 раз больше, отсюда и такие значения нестабильности. При внешнем несинхронном прерывании, если кварцы на разные частоты - добавляется время реакции на прерывание в зависимости от фазы сигнала прерывания относительно тактовой частоты процессора, при единой синхронизации оно стабильно и не влияет на джиттер. Плюс следует учесть что атмега - восьмиразрядный процессор и поэтому младший и старший байты 16-битного слова выдаются в порт неодновременно. Чтобы устранить все эти эффекты и нужен регистр пересинхронизации. Что же до ПЛИС то это просто замена кучи микросхем жесткой логики в одном кристалле и работа ее ничем не отличается от работы аналогичного устройства на микросхемах скажем 74HC или AC серий, но при этом она значительно компактнее экономичнее дешевле и проще в использовании. Никаких заморочек с ней нет, я с нуля освоил за пару дней, к тому же все прошивки я выложил. Тем более что для звука сейчас за разумные деньги ничего лучше хороших ДС не найти, а они все с I2S. Если есть возможность попробуйте AD1853 или AD1955, они заметно лучше PCM1793. Плату под 1955 я выложил, инициализация ее по последовательному порту в программе присутствует.

**a1812** · 22.07.2009, 22:47

Mic Dragon, может я опять таки чего не понимаю и заблуждаюсь, но... В свое время, лет эдак 7 назад, приходилось реализовывать задачу генерации сигнала по таймеру, на чем-то дешевом, типа какого-то тини, сейчас и не упомню какого именно. Требования к точности там были аж никакие, но время у меня было, задание было оплачено и я, изложив для себе все те аргументы, что прочел сейчас в твоем посте (извиняюсь, но я за последние лет 10 общения на форумах привык к обращению на "ты", если это затрудняет - не вопрос - буду использовать "вы"), озаботился решением проблемы точного вывода. Нашел регистр текущего состояния таймера/счетчика... Т.е. в процедуре обработки прерывания затягиваем работу по выводу значения в порт пока значение счетчика не станет равным, к примеру, 8 (либо, в случае, если используется пределитель тактовой минимум на 16 - ждем значение 1). Мы находимся УЖЕ в прерывании, нам ничего не мешает ждать и мы четко знаем количество тактов на все операции. Тогда я это сделал и, записывая по 16 значений таймера в регистры (чипы были без памяти, только регистры) при входе в прерывание - отправлял их в терминалку компа. Значения предсказуемо были иногда неодинаковыми, что убедило меня в своих предположениях и выводах, детальнее не проверял... Я в чем-то ошибался и такой способ точного временного вывода не подходит?

Добавлено через 2 минуты

Если есть возможность попробуйте AD1853 или AD1955, они заметно лучше PCM1793.

попробую, когда руки дойдут

сейчас своей очереди ждет 1794

Добавлено через 6 минут
взял из соседней ветки...

Получаем 2 микросхемы. Весто трех. Это плюс. Весьма дорогой ЦАП с хз какой переходной характеристикой, вместо дешевой дельтасигмы и очень дешевой ПЛИС, сложный фильтр на выходе (мы гордые без оверсэмплинга работаем) - это минус. Звук в результате - хуже чем у дельтасигмы. Оно нам надо ?

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

**Mic Dragon** · 23.07.2009, 07:05

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