Форум РадиоКот

Добрый день.

Разрабатываю небольшое устройство на МК Atmega644P. Кроме всего прочего, оно должно воспроизводить звук. Качественно.
Поэтому ШИМ вариант я отбросил. Хочу использовать 16 бит ЦАП.

Прикидки:

• МК - Atmega644P
• Питание - 5в
• Кварц на 18,432МГц (см. ниже)
• ЦАП - микросхема PT8211(аналог TDA1311) двухканальный ЦАП с SPI управлением на 16 бит
• Хранение - SD-ка на SPI, юзаю FatFS
• Выходной тракт - НЧ фильтр и усилок на LM386 с динамиком 8Ом 1Вт.

Как я вижу решение. Имеем несжатый WAV, где на каждую выборку приходится 16 бит (от -32768 до 32767). Чтобы правильно проиграть файл с дискретизацией 48кГц, мне надо раз в период отправлять эти 16 бит на ЦАП. Делать это я планирую в обработчике прерывания по совпадению таймера 1 со значением 12 (если прескаллер таймера 32). Собственно, кварц выбран именно для получения целого числа для сравнения. Получаем: 18432000/32/12 = 48000Гц (как вариант с делителем 17: 18432000/32/17 = 32000Гц, тоже используемое) К сожалению, типовая частота 44.1кГц не выйдет - делитель получается не целый (13,060...), а если его округлить до 13, то получим ~44.31кГц - боюсь, поплывёт скорость воспроизведения.

По поводу скорости. На одну выборку уходит 2 байта, при дискретизации 48кГц надо передавать на ЦАП данные со скоростью 2*48000/1024 ~= 94Кб/c.
RAM у МК всего 4кб. Вопрос - куда буфферизировать чтение с карты? Ставить микросхему SRAM под это дело? И справится ли SD в принципе с такой скоростью чтения?

Собственно вопрос - правильно ли я понимаю суть? Осуществимо ли такое?
Спасибо.

подскажите, а какие функции должно выполнять устройство, кроме воспроизведения звуковых файлов?

Вообще на нём будет поднят небольшой WEB сервер (на ENC28J60). Задача - по приходу нужного пакета проигрывать звуковой файл и управлять парой потребителей (через MOSFETы). Ну и иногда опрашивать пару датчиков освещённости и температуры. По I2C там ещё RTC на DS1338 висит.

имхо, веб-сервер - это как раз задача для ARM... вот как всякие 7-сегментные индикации на ARM-е через DMA делать, так советчиков море, а когда задача соответствующая - как в воду все канули... и звук воспроизводить качественный ARM лучше сможет, тем паче что во многих и DAC есть приличный...

Я честно смотрел на ARM, и даже набросал вторую схему в Eagle под него, НО...
Во-первых, я просто не знаком с ним и тратить время на этом проекте не хотелось бы. AVR же я знаю неплохо.
Во-вторых, чисто из бюджета - только для прошивки и JTAG отладки того же STM32 надо штуковину за 1000р, а на AVR у меня весь проект укладывается в эту сумму (а шью через Arduino)
В третьих, я недостаточно крутой электронщик, чтобы сразу делать всё в железе - я отлаживаю схему в Proteus'e. С ARM такое не прокатит, а покупать всякие stm32f4discovery для железной отладки я не хочу.
Ну и, наконец, там какие то заморочки с кодом и отладкой. Я вот под AVR пишу в VS, любимый редактор, компилю avr-gcc. А для STM32 какие-то танцы с бубном надо устраивать для этого, половина продуктов условно бесплатные, не дают компилить больше 32кб кода. Короче сплошные грабли.

Но это не отменяет факта, что ARM, возможно, тут бы подошёл лучше. Просто не сейчас )

Кстати, DAC там "всего" 12 бит. Вот DMA бы пригодилось, да.

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

Немного не вяжутся следующие части:

16bit/48kHz
...
воспроизводить звук. Качественно.
...
Выходной тракт - НЧ фильтр и усилок на LM386 с динамиком 8Ом 1Вт.

По железной части примерно тоже, что у карманного хрипящего китайского радио.

RAM у МК всего 4кб. Вопрос - куда буфферизировать чтение с карты?

Зачем его буферизовать? Разве нельзя файл играть сразу с карты?
Ну маленький буфер звукового потока 256-512 байт в ОЗУ вроде должно нормально хватить.

И справится ли SD в принципе с такой скоростью чтения?

В режиме SPI карта справится и с бОльшей скоростью. Я для пробы просто читал файл с FAT16, мега88, примерно 300кБ/сек @ 16МГц, но не FatFS. Без FAT загрузка процессора ниже и скорость ещё больше.
А вот сама атмега - зависит от загрузки посторонними(по сравнению с воспроизведением) задачами.
Но ИМХО 48КГц стерео для атмеги - либо жесткая оптимизация проги, либо уменьшить аппетит скажем до 22КГц.

uk8amk, спасибо за отклик

uk8amk писал(а):По железной части примерно тоже, что у карманного хрипящего китайского радио.

В имеете в виду выходной каскад или само кодирование 16bit/48kHz? Я просто взял, честно сказать, типовую схему усилка.
Если есть варианты лучше, подскажите, пожалуйста.

Спойлер

uk8amk писал(а):Зачем его буферизовать? Разве нельзя файл играть сразу с карты?
Ну маленький буфер звукового потока 256-512 байт в ОЗУ вроде должно нормально хватить.

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

uk8amk писал(а):Без FAT загрузка процессора ниже и скорость ещё больше.

Помимо проигрывания звука работа с картой ведётся так же и другими способами (но не одновременно, конечно). Поэтому удобный интерфейс FatFS мне привычнее.

uk8amk писал(а):А вот сама атмега - зависит от загрузки посторонними(по сравнению с воспроизведением) задачами.
Но ИМХО 48КГц стерео для атмеги - либо жесткая оптимизация проги, либо уменьшить аппетит скажем до 22КГц.

ВО время проигрывания звука по идее она ничем больше не занимается. А почему 44кГц - это много, если системный клок аж на ~18МГц?

Имею в виду что LM386 ни разу не HIFI, в документации TI приводятся параметры для THD=10%. THD 0.2 только для 100мВт.
Динамик 1Вт тоже вроде HIFI не предполагает.

Короче вы туда можете вкачивать сколь угодно много битов и килогерцев, но звучать сильно лучше схема от этого не станет.

ВО время проигрывания звука по идее она ничем больше не занимается.

Во время проигрывания звука веб-сервер остается же. Туда может прийти какой угодно запрос и его следует адекватно обработать.
Для простого играния музыки с карты 256-512 байт буфера потока скорей всего достаточно. Если параллельно есть другие задачи, то сооствественно увеличивать.

С железной частью вы похоже определились. Поэтому при нехватке ресурсов сможете понизить самплрейт.

А, у вас же моно сигнал. Тогда по идее должно хватить.

alexg-nn писал(а):К сожалению, типовая частота 44.1кГц не выйдет - делитель получается не целый (13,060...), а если его округлить до 13, то получим ~44.31кГц - боюсь, поплывёт скорость воспроизведения.

можно использовать таймер 1 - он 16 бит, делитель 1, top 418
18432000/1/418=44095,7

alexg-nn писал(а):По поводу скорости. На одну выборку уходит 2 байта, при дискретизации 48кГц надо передавать на ЦАП данные со скоростью 2*48000/1024 ~= 94Кб/c.

я делал WAV+IMA плеер на XMega (FreeRTOS вывод в ЦАП через ПДП) 2 буфера по 512 байт
при тактировании МК 32МГц и потоке стерео 44100 загрузка около 30%
при 18МГц будет около 50%

И все таки, расскажите, зачем вам там качество CD? У меня есть проект, в котором нужен вывод звука. Динамик там вот такой:



Вывод ШИМ, 16 кГц/8 бит (несущая ~32 кГц), выходной каскад класса D, мостовой. И знаете, на слух неотличимо от 44.1 кГц/16 бит на таком же динамике.

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

Так что если функция проигрывания музыки у устройства не основная, то там однозначно применим ШИМ-вывод. Звучит очень пристойно, интегрируется невероятно дешево. Для каких-нибудь "динь-дон" при событии - так вообще нет смысла заморачиваться на что-то еще.

Разумеется, при переходе от 16 бит к восьми битам необходима соответствующая компрессия сигнала.

YS, так или иначе, я вывел наружу OCRы первого таймера (16битного), так что в случае чего можно использовать и его.
Но я свято верю, что разницу можно услышать Пока буду надеяться, что ЦАП приедет таки из Китая.

ЗЫ
Не подскажет ли уважаемое сообщество заодно и вот ещё что.
В приборчике рядом с платой стоит DC мотор. Он достаточно сильно магнитит отвёртку в радиусе сантиметра от него.
Спрашивается, какие компоненты из перечисленных можно ставить рядом безболезненно, а какие лучше убрать подальше.
- RTC микросхема и часовой кварц
- сам МК и его кварц
- микросхема ENC28J60 ethernet контроллера
- DC/DC импульсный преобразователь и его обвязка (дроссель, в частности)
- аудиотракт, начиная с ЦАП и заканчивая усилителем
- дроссели развязки SD-карты и АЦП МК

Ясное дело, что в идеале убрать всё бы надо, но всё не получится. Так что в порядке убывания значимости, что ли.

Но я свято верю, что разницу можно услышать

На нормальных динамиках разница ясна и очевидна - я слушал. На таком, как на моей картинке выше (и тех, что меньше, разумеется) - совершенно нет.

В приборчике рядом с платой стоит DC мотор. Он достаточно сильно магнитит отвёртку в радиусе сантиметра от него.

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

Если моторчик не стоваттный, я думаю, ничего страшного. Самое главное в этом случае - грамотное разделение земель, т.к. основные помехи, разумеется, будут проникать именно по шинам питания. Естесственно, не надо делать так, чтобы обратный ток мотора тек по земляному полигону аналоговых цепей, но это, я думаю, вы и сами понимаете. Хорошо будет напаять непосредственно на контакты моторчика керамический конденсатор, скажем, на 10 нФ, как в китайских игрушках. Для верности можно поставить дроссель в ветку питания цепей управления.

А так, чисто для успокоения, я бы отнес подальше RTC и цепи АЦП/аудиотракта. Генератор МК я бы переключил фьюзами в режим full swing. Остальное некритично. Цифровая техника вообще достаточно устойчива к наводкам.

YS, спасибо за ответы.

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


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

YS писал(а):Генератор МК я бы переключил фьюзами в режим full swing.

Да, именно так и включен.

Мотор подключается таким образом

Тут дело не в том, как оно на схеме, а в том, как оно оттрассировано на плате.

На тему трассировки можно начать с этого:

http://portal-ed.ru/index.php/proektiro ... kh-platakh
http://www.eurointech.ru/EDA_Expert/EDA ... _63_70.pdf
http://cxem.net/comp/comp40.php
http://wzone.vegalab.ru/faq/trace_pcb

Общий смысл в том, чтобы физические пути токов силовых устройств были отделены от токов маломощных устройств.

YS, хорошо, я постараюсь учесть это при разводке

----------

В порядке размышления. При ближайшем рассмотрении выяснилось, что присмотренный мною ЦАП PT8211 взаимодействует с миром через шину I2S (не I2C!), которую достаточно трудно программно поддержать на AVR(по отзывам в интернете). Ну то есть считать клоки и ставить nop'ы я полагаю занятием неблагодарным. Да к тому же, как это уживётся с веб сервером вообще не ясно.
Обратив таки взор к ARM узнал, что у них эта шина поддерживается нативно в не-сказать-чтобы-уж-совсем-дорогих моделях. Да ещё и SDIO будет в комплекте.

Например, такой камень есть в продаже в моём мухосранске - STM32F103RET6. Останется только прицепить к нему программный таки ethernet с тем же ENC28J60. И в нём уже есть RTC, так что одной микросхемой меньше. Да и питание от 3.3в - ещё меньше на две микросхемы (стабилизатора и согласования уровней). Красота

Но, размышляя далее, я подумал - если у этого камня два встроенных ЦАП на 12 бит, то почему не сделать один 16 битный выход, объединив их вместе? (Промолчу про возможность сделать 24 битный ЦАП, ибо явно за шумами уже не отличишь). Такое вообще практикуется? Два ЦАПа в паре, одному слать первые 8 бит, второму - вторые. Что скажете?

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

На STM32F100 я делал один девайс: подходишь к предмету, начинает играть с карты музыка(в качестве сенсора взяли парктроник от авто). Так вот, 12-битный стереоЦАП даёт довольно таки неплохой звук даже для автомобильной акустики. Конечно искушенные слушатели и аудиофилы имеют полное право забросать такую систему какашками, но для установки в шумное место вроде торгового зала или на вечеринку больше битов и не надо.

uk8amk, а в каком формате было аудио?

WAV файлы PCM 44100Гц 16 бит стерео. Но я делал перестройку скорости проигрывания(8-44), битности(8-16) и числа каналов(моно-стерео) при открытии файлов(читал чанки RIFF) для удобства самого заказчика.
Вобщем с вашей акустикой можете даже не заморачиваться о высоком качестве исходного материала.

Два ЦАПа в паре, одному слать первые 8 бит, второму - вторые.

Как вы себе это представляете?

Нет, такое не практикуется.

Не, ну чисто теоретически...
2 ЦАПа, дают сигнал на сумматор на операционнике. Сигнал с 'младшего' ЦАПа ослаблен соответственно до 1МЗР.
На практике столкнёмся со следующим:
*Разброс параметров элементов
*температурный дрейф
*нелинейность обоих ЦАП и системы в целом.

Для компенсации ошибки предлагаю сделать следующее:
*На выход ЦАПа подключаем многоразрядный качественный АЦП
*Соединяем его с компом, пишем прогу автоматического сбора и анализа данных
*Прога сканирует весь диапазон ЦАПа и создаёт таблицу корректировки. Для 16-битного ЦАП её размер 64КБ.
*Подключаем к проекту микроконтроллера эту таблицу.