Проблема е само в това да подкарам Windows и/или Linux на PIC32 А иначе няма лошо да конвертираш в wav файлове, обаче представи си ако джобния ти мп3 плеър чете мп3 файла и почва да го конвертира в wav файл на SD картата и тогава да го чете като wav и да го плейва Едно, че ще имаш няколко секунди закъснение между записите, друго че SD картата ще издъхне за няколко дни

tqi, струва ми се сложна работа да вграждам AC'97, по-скоро някое голо DAC с I2S. Ще видя тия дни ако ми остане време да по-прочета това-онова за AC'97. Определено се загледах по PCMxxxx и по TLCxxxx чиповете. Отделно се сетих, че на Audio PICtail има някакъв WM8510 ( mono ), така и така я имам и събира прах по бюрото, ще го пусна на първо време моно да видя какво ще стане, ако се събирам в таймингите ще мисля и за стерео чип.

I2S не е особено по-просто от AC97. Разгледай datasheet-а на оня чип в digikey и
ще се убедиш, няма нищо неочевидно. Е, трябва серийният порт на MCU-то да може
да се курдисва за AC97, ако не може не може.

Пуснах mp3 възпроизвеждане с PIC32MX на 80MHz , периферия на 40MHz, 22.5kHz 9 битово стерео/моно аудио през PWM на 44.1kHz, 192kbps входен поток от SD карта. Има някакъв проблем с SD картата и на повече от 15MHz не иска да проработи. Двата PWM канала се зареждат през два DMA канала, конфигурирани в режим с автоматично презареждане. Времето за четене и декодиране на 4kB входни данни е към 25ms. Има доста неща за оптимизация, на 1-во място е да сменя тромавата файлова система на Microchip с FatFs на Elm-Chan, вдигане на периферната честота на процесора на 80MHz, подкарване на SD картата на 25MHz или направо преминаване към SDHC, които позволяват работа до 50MHz, отделно във версия 1.10(b) на C компилатора Microchip са подменили много от макросите за достъп до служебните регистри с фукнции, на места процесора изпълнява по 20-30 инструкции докато достигне до дадения регистър, с макросите в предишните версии са 3-5 инструкции. Определено през външен кодек няма да мине, тъй като вдигането още на честотата на PWM води до по-малко от 8-битово изходно аудио. Имах един WM8510 моно и си мислех с него да изпробвам, но се оказа, че така както е опроводен е за dsPIC33 процеосор, и пиновете за управление при PIC32 се падат на TRACE пиновете, така че ще трябва с друг кодек да изпробвам, което ще рече, че ще се прави и печатна платка

Някой правил ли е с пръдня боя ?

Постановката е следната:
1) Разполагам с 5 PWM модула и 8 DMA канала
2) Искам да получа 16-битова разделителна способност
3) Fpwm = 44.1kHz или 48kHz, но с тази честота получавам 8 бита,
4) Идеята е да сумирам изходите на два PWM модула през 2 резистора, така че първия PWM модул да вади LSB битовете, втория MSB битовете, двата модула работят на една и съща честота. За тази цел трябва единия резистор да е 256 пъти по-голям от другия, общата им точка я сумирам на входа на ОА, на изхода на ОА се получава 16-битов PWM. ОА освен сумиране ще има и ролята на НЧФ.
5) Зареждането на двата PWM модула става чрез 2 DMA канала
6) Изхода на мп3 декодера е 28-бита, но ги орязвам до значещи 16-бита, разделям ги на LSB и MSB байт, и ги съхранявам в два различни масива. 1-вия DMA канал използва първия масив, 2-рия DMA втория масив. Дължината на масивите е еднаква и за двата канала. Стартирането на DMA каналите става синхронно в рамките на един цикъл на периферията, за тази цел стартирането им е зададено да става по прекъсването на таймера, който генерира PWM честота.
7) Тъй като DMA каналите ще използват различни области от паметта за източник на данни и различни за приемник на данни, не би трябвало да има цикли на изчакване в DMA контролера. Само 1-вия канал е инициализиран да генерира прекъсване при прехвърляне на половината/целия масив, във вектора на прекъсване се вдига флаг, с който се уведомява декодера, че половината/целия буфер е празен и е време за нова порция декодирани PCM отчети, след което DMA канала започва от втората/първата половина на буфера. С други думи, докато декодера пълни едната половина на изходния PCM буфер, DMA канала копира в PWM модулите другата половина, получава се чудесен синхрон с DMA канала, няма изоставане, няма избързване.

Та въпроса е, ако комбинирам 4-ри PWM канала, по 2 на аудио канал, за да получа 16-битова разделителна способност на DAC модула, дали ще се получи някакъв нежелан ефект от това, че 8-те LSB бита се генерират от един PWM, а 8-те MSB бита от втори PWM ? Според мен не би трябвало, но... ако някой е правил от пръдня боя, може да сподели опита си


П.П. PWM модулите на PIC32 имат един съществен недостатък, нямат postscaler, което създава известни неудобства. Примерно Fpwm=44.1kHz, възпроизвеждания мп3 е с 22.05kHz, т.е. на два цикъла на Fpwm се прави едно опресняване на коефициента на запълване. Но тъй като няма postscaler, трябва или PWM да генерира прекъсване на всеки цикъл и вътре с един брояч да следя кога да опреснявам ( което обаче изключва употребата на DMA канал ), или да пусна втори, samplerate таймер ( което правя ), на 2, 4, 8 и т.н. по-ниска честота от PWM таймер и DMA канала да се синхронизира по samplerate таймера. Timer1 е заптисан като RTCC, Timer2 & Timer3 са за DAC ( PWM и samplerate ), и остават свободни само Timer4 & Timer5....

На времето правих 15 битов PWM с 10 битовия такъв на PIC18. Исках да го ползвам като много евтин вариянт на DAC за симулиране на напреженията на термодвойки. Както се досещате - честотата на ПВМ-ма не е решаваща, тъй като целта ми е да получа DC изходно напрежение, а не както в случая се гони AC аудио сигнал. Резултатите които получих бяха повече от приемливи. (разбира се използвах външни ключове "клатени" от PWM-ma на пика, както и стабилно опорно).

Идеята ти ми се струва работеща на пръв поглед. Наистина е неприятно, че няма постскалер на PWM таймерите, но пък с цената на още един таймер си решил проблема.

Пробвал ли си да изчислиш,запишеш и възпроизведеш някаква синусоида (директно, а не през MP3) и след това да закачиш спектрален анализатор на изхода на филтъра ти? (Даже ако нямаш анализатор - донякъде и аудиовхода на звуковата ти карта би свършил работа). Мисля, че това е единственния начин по който можеш да изтестваш идеята си.

Иначе точността на резисторите обединяващи PWM-ите също е от значение. Трябва да са наистина точни, за да не ти вкарат "нелинейност". Може би това е по-сериозния проблем.

В моя дизайн съм пуснал PWM-a на възножно най-високата честота (примерно 96KHz) и го презареждам през 8KHz.
Така високата честота на PWM-ма по0лесно я филтрирах и донякъде се подобри качеството на звука.
Мсиля си, че в идеалния случай честотата на PWM_ма трябва да е кратна на честотата на опресняването му.

Не съм пробвал още младшите 8-бита да са от един PWM, а старшите от друг. Всъщност, оказа се, че не съм правилно инициализирал ядрото и периферната ми честота е била в пъти по-ниска отколкото я смятах. Сега ядрото и периферията работят на една и съща честота и с един PWM на канал вадя 11 бита разделителна спсобност. Ако стане номера с 2 PWM на канал ще се получи 22 бита, което си е колкото един скъпо струващ кодек.

За резисторите е ясно, че трябва да са точни, 0.1% ще се намерят сравнително лесно, но мисля и че с 0.5% - 1% ще мине номера. Ще ми се целия плеър да е само от процесор, захранване, НЧУ и SD карта.

Получиха се интересни сметки за натоварванията на PIC32 ядрото спрямо bitrate на входните MP3 файлове. Примерно при входен стерео поток 320kbps и samplerate 44.1kHz натоварването при различните песни варира между 42% и 55% ( при включена оптимизация за скорост ), а ако пусна стерео 64kbps samplerate 8kHz процесора се натоварва до 95%. Или аз бъркам нещо ? По скоро трябва да са наопаки цифрите, при 320kbps да е много по-натоварен процесора. Поне това съм чел за ARM LPCxxxx реализации, че при 320kbps процесора се натоварва яко и накъсва от време на време ( май tgi ще се окаже прав с неговата версия за 32-та регистъра )

Или при 64kbps да е много голяма компресията и затова да се налага повече време за декомпресия ??

Тази вечер, ако се сетя, ще направя едно видео на плеъра и ще го кача някъде

Не.

Мда, най-вероятно тогава става нещо с таймера ми. Ама не би трябвало да се препълва, пуснал съм го в 32-битов режим.

Между другото кода на плеъра го качих тук: http://mp3pic32.sourceforge.net/ . Засега чете всички мп3 файлове и ги възпроизвежда един след друг. Като направя платка и закача графичен дисплей с бутони ще добавя още код.

Хмм, да не би на ниската скорост да чака нещо баба си с цел синхронизация и затова
да отива повече. Не че имам идея какво става де.

Тъкмо мислех да те помоля да постнеш колко мощност къде отива и ти взе, че го направи - мерси .

Самото MP3 декомпресиране сам ли го писа или е някакъв готов модул? Не съм правил още
такова чудо и ми е любопитно (в рамките на "а бе някой ден и това искам да направя" ).

Ми няма разлика в кода м/у нисък и висок bitrate, при 80MHz таймера ми би трябвало да се препълва на ~53.7 секунди, фрейма на 8kHz samplerate и 64kbps bitrate мисля се възпроизвежда за къде 72ms. Може би sprintf функцията нещо се дъни, резултата го пиша на дисплея, не съм гледал какво има в RAM-а. Знам ли, ще видя довечера, може и баба му на PIC-а да се е намесила

Отностно мощността, ако нямам грешка в таймера е това, на някои песни отива пиково натоварване до къде 65% при 320kbps, на всеки фрейм опреснявам дисплея, средно се върти към 42-45% като че ли, не съм правил точна статистика.

О не, декомпресирането е порт на LibMAD библиотеката , използва дробни числа с фиксирана запетая и е пригодена като за микроконтролери, въпреки че се компилира и работи и на Unix/Win/Mac . Там ми е мътна Индия с лицензите им и щуротиите им, за да почнеш от нулата трябва да изразходиш бая време да търсиш само документацията. Моята идея беше не да се пробвам дали мога или не мога да си напиша сам декомпресирането а да видя възможностите на процесора. Резултата е, че съм много доволен от това животно наречено PIC32. Като цяло след като си направя читава платка ще добавя и други формати, а защо не да се изпробва и mp3 компресия, тя поне ще покаже става ли за нещо PIC32 Иначе декодера харчи много памет, не си поплюва, реално би се вместил и в 32kb RAM, но тогава ще трябва да е с хардуерен кодек. Гледах един друг декодер, Helix, той харчел под 20kb RAM, ще го видя ако мога и него да го подкарам. По принцип LibMAD бълва 1152 на брой 4-байтови числа на канал, оттук става 4608 байта при моно, 9216 байта при стерео, и аз правя двойно буфериране само, че с 16-битов размер на клетка, общо става 9216 + 9216 = 18 432 байта само PCM буфериране. 2048 входен буфер за mp3 потока, ето ти 20480 байта, стек още 2048, динамична памет още 2048, FAT16/FAT32 още към 2-3k, 1132 байта за play list, останалото дето се харчи отива в декодера.

Засега съм се спрял на TLV320AIC23B или WM8731. На първо четене на документацията изглеждат 100% съвместими, и по крака, и по програмиране. Само още не ми е ясно кой точно SPI режим на PIC32 ще пасне на аудио интерфейса им. То по принцип всеки режим ще стане, но искам да използвам DMA каналите с максимално големи буфери, така че един ден да мога да закача към проца и някой малък графичен дисплей.

Набързо погледнах тексаския кодек, дето си си харесал , ами той може май всичко, каквото
и разните AC97, дето съм гледал. Май AC97 могат всичко по един интерфейс, докато
на тия контролният им е отделен; в някои ситуации е предимство, в други не е (ако е
борба да се вкара в пътя интерфейсът), всъщност като цяло ми се види все тая, ако работи.

Предполагам, че на 80 MHz MIPS ядро ще му стигнат силиците за MP3 компресия в реално
време, ама не знам всъщност, не съм писал такава. Но като гледам колко записващи
евтини MP3 player-и има дето и не харчат нищо като ток, може и да не е кой знае какъв
зор. Ама не знам, само ми е любопитно та затова се обаждам.

Не съм още сигурен дали ще намеря подходящ начин да използвам така SPI на PIC32,
че да позволява DMA канала сам да си зарежда данните в кодека. Процесора ще се намесва
само когато DMA изпразни буфера. Има някакъв frame режим, който май е точно това, което
ми трябва, но докато не напиша код и не тествам ще си е само голи приказки.

При AC'97 всичко върви на една шина, ако не намеря подходящ режим на SPI най-вероятно
ще се оплеска всичко. Това ме накара да се огледам за I2S, или по-простите кодеци, на които
управлението им е отделно от шината за данни.

Ако Microchip не са писали още във "features" частта на данните си, че може AC97,
най-вероятно не може или поне не са го мислили да може.
Тия "frame"-ове вероятно са за серии от данни в рамките на един цикъл от клоци,
примерно 16 бита за ляв и 16 бита за десен канал с един строб (то вече не е баш
SPI, кодек някакъв се води навярно).
Инак с DMA-ченето за тоя род приложения това, което искаш е нормата. Ако паметта
му е с повечко латентност, трябва да има някакви FIFO-та на серийния интерфейс и
DMA-то да се пуска/спира по нива на запълване на тия FIFO-та (така е в MPC5200 примерно,
и в много други FReescale-чави неща); ако пък паметта е с ниска латентност, може
и директно да пише в нея DMA-то, така е в DSP-тата, дето знам. Май говориш в
килобайтове, т.е. паметта ти е вътре в MCU-то само, вероятно вторият вариант ще
да е. Ама навярно ще е битка де, ще има какво да постваш .

Microchip са пуснали официален AN http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en551513 на тема MP3 с PIC32. Използват Helix MP3 библиотеката, която както бях постнал преди харчи значително по-малко RAM. По скоро ми е интересно дали Helix MP3 ще тръгне и на dsPIC33м би трябвало да се вмести целия код в 32kB