Аудиокодек OGGVorbis на CM3, пробовал ли кто? Опции

[uk8amk]

Кодек Vorbis, страница разработчика:
http://xiph.org/vorbis/
Декодер Tremor с уменьшенными требованиями к ресурсам проца(целочисленные алгоритмы):
http://svn.xiph.org/branches/lowmem-branch/Tremor/
По возможностям что-то вроде MP3.

1)Интересует, справится ли CortexM3, какой-нибудь типичный STM32 на 20-70МГц?
Везде только общие слова, без хотя бы примерного футпринта по килобайтам ОЗУ,флеш и без MIPS-ов.
Хочу попробовать играть моно звук с качеством 30-60кбит. Пробовал Speex, но он хорош только для речи, звуки и подобие музыки - ужас.

2)И если кто-то вдруг пробовал, то наберусь наглости спросить пример(кусок) embed проекта.
Сам пытался натянуть Vorbis Tremor, но в файле codebook.c слишком много ошибок в Keil MDK сыплется. А вникнуть во все ребусы - знаний пока маловато.

Спасибо.

[SII]

Интересует, справится ли CortexM3, какой-нибудь типичный STM32 на 20-70МГц?

Не справится однозначно. Помнится, в своё время мой отец вынужден был перейти с 80486-100 на Пентиум-3 как раз из-за того, что на его ПК не хотели воспроизводиться MP3-файлы -- не хватало производительности. Понятно, что на ПК прилично времени под себя жрёт система и т.д. и т.п., однако и производительность 80486 при одинаковой тактовой частоте будет существенно выше, чем большинства ARMов (кроме разве что Cortex-A, и то вопрос дискуссионный). Дело тут в том, что на выполнение одного и того же действия для ARMа нужно больше команд, чем для IA-32 (например, вполне типичная операция -- инкремент или декремент переменной -- требует одной команды на IA-32 и трёх на ARM, причём в последнем случае ещё и свободный регистр для самой операции нужен, плюс нужно загрузить базовый адрес переменной в другой регистр, что может потребовать увеличения числа команд). В общем, думается, Cortex-M по своей производительности будет примерно соответствовать 80386 с близкой частотой.

Что касается целочисленной и вещественной арифметики, то в тех процессорах, где последняя поддерживается аппаратно, разницы в скорости их выполнения, по сути, нет. Более того, вещественное деление может выполняться быстрей целочисленного -- за счёт меньшей разрядности делимого и делителя. Вот в древних машинах, имеющих поддержку плавающей запятой, скорость выполнения этих операций могла быть существенно меньше, чем скорость выполнения целочисленных -- но там всё упиралось в количество транзисторов, не позволяющее сделать отдельное вещественное АЛУ и прочую поддерживающую его логику.

[jcxz]

однако и производительность 80486 при одинаковой тактовой частоте будет существенно выше, чем большинства ARMов (кроме разве что Cortex-A, и то вопрос дискуссионный). прочую поддерживающую его логику.

Весьма спорное утверждение. Уверен что в реальных задачах дело обстоит как раз наоборот.
Вот Вы тут на инкремент переменной в памяти ссылаетесь. У Вас программа вся из таких инкрементов состоит?
Как правило - таких операций очень мало (если компилятор нормальный и оптимизирует код).
А ну-ка - рассмотрите операцию например: a = b << 9 | c;
Сколько будет у ARM и сколько у x86
И учтите что у ARM регистров куда как больше чем было у 80486 и большинство переменных при оптимизирующем
компиляторе, находится в регистрах.
И это уже не говоря о том что на 80486 ещё было мало однотактных команд, а на ARM они почти все однотактные.
И это не говоря о том что современные ARM-контроллеры как правило имеют довольно большой объём внутренней
памяти с доступом на частоте ядра, в то время как в 80486 - всего-лишь небольшой L1-кеш.
И в 80486 нет никакого условного выполнения (как в ARM/Cortex), а только вермишель из условных переходов.
И т.п. Можно долго породолжать.

Код похоже очень интенсивно использует кучу(HEAP). А вот как интенсивно - под вопросом. Но на каком-то сайте сегодня вычитал, что поболее чем MP3 т.к. статических данных меньше. Выходит, что надо RAM>20KB.

Вы же сами написали: Total RW Size (RW Data + ZI Data) 7192 ( 7.02kB)
Куча, если используется, то находится где-то внутри этого объёма.
И использует-ли вообще???
Сам по себе никакой кодек не требует динамической памяти.
Её требует только некомпетентность разработчика. имхо