Только как бы это сделать попроще? Без файловой системы, для чистоты эксперимента? Там ведь объёмы в сотни килобайт\мегабайты

JPEG в качестве теста пробовал. На МК без внешней памяти исходную картинку кладем во флеш, результат в RAM. Сотен килобайт не нужно, достаточно пары десятков.

Может у вас с частотой чего не того? Что-то совсем грустно получается

Ну а исходники можно попросить выложить? Если они не коммерческие, конечно?

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

Спасибо.
А можно пример использования? Для сжатия картинки?

ЗЫ: "гнутые" - имеется ввиду GCC? А под ИАР долго затачивать, интересно?

Да там просто все - вызвать encode(), указав откуда, куда, в каком формате и какого размера. С decode() аналогично.


Пардон, хотел сказать GPL'ные. Обычный plain C, без каких-либо специфических фишек, даже не 99.

Это вот такие поддерживаются форматы на входе?

Ну вот в каком формате, например, должна быть исходная картинка для функции: rgb24trPyuv420?
Что значит Y00 Y01 Y10 Y11 Cb Cr?

Тут понятно только, что 24 бита на пиксель, а дальше все эти Yxx...

Я бы понял, к примеру, такое описание: 24 бита на пиксель, сначала идёт красный (R, 8 бит), затем зелёный (G, 8 бит) и голубой (B, 8 бит).

зы: а, наверное, там задаётся как входной, так и аыходной формат?
Тогда всё понятно.
Можно попробовать взять маленькую фотку размером, скажем, 150х150 пикселей в RGB24 и...

RGB24. Где что по компонентам - не помню, но вариантов всего два.


Y - яркостная составляющая, Cx - цветоразностные.


Пример:

Вернет длину получившегося jpg.

Спасибо, всё понял, кроме параметра quality из Вашего примера. Думал, что это целое число в диапазоне от 1 до 100, но в примере получаются огромные цифры вплоть до 51000...
Это нормально?

Нормально. Это как раз приведение диапазона 1..100 к тому, который требует на входе энкодер. Почему именно так - не помню, хоть убейте.

с клоком все ок. почему так мало я уже писал.

Провел тест на mp3 декодере (от helix). В цикле 10 раз декодировал mp3-файл.
Библиотечные функции не использовались. inline assembler в декодере не использовался (только intrinsics).
Код на 3х компиллерах одинаков

gcc -Werror -Wall -Wextra -mcpu=cortex-m3 -mthumb -O3 -fomit-frame-pointer -ffreestanding -fno-common -fwide-exec-charset=UTF-16LE -fshort-wchar -g
39 сек
общий размер кода 196907

armcc --thumb -O3 -Otime --cpu=Cortex-M3 --bss_threshold=0 --c99 --strict --wchar16 --diag_error=Warning
39 сек
общий размер кода 181675

iccarm -thumb --cpu Cortex-M3 --aapcs std --aeabi -Ohs -r -e
44 сек
общий размер кода 166795

самый красивый код судя по бегло просмотренным листингам инересных функций у RVCT.
на размер кода особо не смотрите, линкеры rvct и iar повырезали некоторые неиспользуемые функции (mp3 это не касается)
Стек GCC жрет больше, чем rvct. Скажем вся самая большая ветка от main к самой глубокой функции у gcc 650 байт, у rvct 624 байт. IAR прочесать не смог, какой-то не стандартный у него elf или я что-то протупил

исходник,бинарки и пример использования (main.c) прилагаю.
Если будете собирать - на всякие непонятные вам функции (типа svcCreateThread) забейте(убейте), интересно только то, что в цикле.
Код пахал под моей осью, но системный таймер остановлен, других тредов не запущено,прерывания никакие не дергаются, тобышь весь алгоритм выполнялся линейно
Будет возможность, проверьте плиз на NXP, или я позже проверю

Блин, с энкодером облом вышел, функции преобразования цвета подобные rgb24trPyuv422 перезаписывают исходную картинку, то есть если она лежит во флеш сразу получаем исключение
И так с трудом влез в 20к оперативки STM32f103RBT6, а теперь ещё такое

Преобразуйте картинку заранее на PC.

LPC1768, 100 MHz, IAR 6.20.3, High Optimization, Speed: 28,5 секунд, 311 фреймов * 10 циклов.
Размер кода ~ 158022 байта.

свершилось...... LPC1830-LPC1850 уже в продаже
http://search.digikey.com/scripts/DkSearch...ame=568-6683-ND
http://search.digikey.com/scripts/DkSearch...ame=568-6682-ND

Да, для не PRO версий они его уродуют . Для PRO, все совместимо.

А вот кстати, в посте где-то на две страницы ранее увидел, что, якобы декодирование MP3 320kbps занимает на NXP 30%, SAM3U 50%, а STM32F - 100%.
Хотелось бы стросить sonycman, проценты относительно к чему? То есть, как понимать, скажем, 100% загрузки?

Я сделал тут WAV/MP3 плейер на SAM3U (96MHz) и померял осциллографом, сколько надо на декодирование одного фрейма MP3 320kbps (то есть, один вызов MP3Decode). Получалось от 9 до 11.5мс (чем "басее" звук, тем дольше). Как известно, результат вылетает в DAC за 26мс. То есть, с этой точки зрения загрузка менее 50% (проц. мог бы декодировать два полных фрейма, пока один проигрывается). Неужели STM32F нужно полные 26мс, чтобы сделать то же самое?!

Я приводил обобщённые данные загрузки для 320 kbps MP3, то, что видел на форумах.
100% для STM32 получилось со слов некоторых форумчан, сказали, что есть подтормаживания. Это говорит о 100% загрузке процессора.

Но сам на практике STM32 в роли декодера не испытывал.

Предполагаю, что тот, кто писал о подтормаживании, что-то неправильно в программе сделал.
Перекину проект на STM32F103RC, расскажу. Пусть не в тему тут. Хотя упомянутый мной SAM3U4E на SAM3U-EDK я взял, чтобы разобраться как раз с HS USB.

Я тоже сразу на это указал, но меня уверили, что всё в порядке, код один и тот же для всех контроллеров - тормозит именно STM32.


Очень интересно

Ну а какие впечатления от HS USB? Каких скоростей удалось добиться? Код основан на каких либо примерах, или самописанный?

Пока никаких, т.к. руки не дошли.
Писать с нуля USB весьма непросто. Разобраться, конечно, можно, но зачем изобретать велосипеды? - будем юзать примеры.
Правда, где ATMEL, а где разумные библиотеки... В этом смысле ST гораздо дружественнее.

Продумываем потихоньку один проектик, а посему вопрос к тем кто пробовал - реально получить надежную скорость чтения (в балке с USB Flash через FatFS) 8 мбит/с на LPC17хх, или искать что-то с HS ? 8мбит/с, (точнее 7.9) это необходимый минимум.

~600-650 кбайт/сек. LPC1758, 72 Мгц, FatFS, MP3 файл с SDHC.

Понятно, т.е если мне надо не 0.65 а 1 мбайт/с, то вместо 72мгц надо минимум 110мгц, возможно со 120мгц 1769 получится?
А что именно у Вас тормозило, USB или все остальное ?
SDHC была подключена через USB ?

А Вам надо читать обязательно с USB флешки, то есть LPC будет выполнять роль USB хоста?

STM32 в режиме MSС девайса с SD карты на компьютер передаёт данные со скоростью до 950 кБ\с, в среднем 800 кБ\с.
В режиме хоста, имхо, будет ещё медленнее.
Думаю, гарантированных 8 мегабит с USB флешки через USB FS не получить

Да. Через usb картридер. С 16Гиг usb флэхи примерно такая же скорость получилась.
Да - читал блоками по 4 кб ( кратными 512 байт).

Да. И это может быть не только флешка, но и винчестер.



Наверное Вы правы, я сейчас попробовал на компе с USB1.1 скопировать в ФАРе большой файл(фильм) в nul, так скорость плавала от 0.96 до 1.1 МБ. Учитывая что нам надо гарантированных 0.98, то с USB FS скорее всего не получится даже на 120мгц кортексе.

Ох, дались Вам эти мегагерцы, честное слово! Чтобы забить полностью полосу USB 1.1 столько и близко не нужно.

Другое дело, что для получения гарантированной скорости чтения 0.98 крайне желательно иметь приличную буферизацию и некоторый запас по скорости интерфейса. В случае USB FS этот запас получается небольшим, хотя и его должно хватить в случае использования носителя на флеш, где возможные задержки при чтении относительно невелики.
Кроме того, реализация файловой системы должна быть достаточно интеллектуальна, чтобы не дергать носитель лишними обращениями к FAT. Не знаю, как тут обстоят дела у FatFS.

Тут вопрос был "где бутылочное горлышко". Поскольку получить гарантированно то что мне нужно (лучше конечно с запасом), не удалось даже на полуторагигагерцовом Р4, то....

Горлышко в низкой пропускной способности самого интерфейса USB FullSpeed - частота клока всего 12 МГц.
В теории получается около 1.5 мегабайта\сек, но на практике минус накладные расходы - передача команд MSC и т.п. - остаётся около мегабайта без запаса вообще или даже ещё меньше.

Ну, была надежда что хоть до 1.1 МБайт дотянет (т.е. 73% от клоковых 12Мгц), но увы. Будем расчитывать на что-то с HS,
а пока, боссы просят в демонстрационных целях сделать образец хоть с чем-то. У нас там на имеющейся плате с 1768 предусмотрена установка PHY эзернета, боссы надемо с кабелем "добро" дают.
Вот я подумал - чисто в демо-целях, временно, может вместо USB пока шнурочком к компу подключить? Эзернет все-же побыстрее чем USB FS.
Практически, чтобы было попроще, идея такая - на девасе поставиь IP-стек и FTP-клиент, на компе - FTP-сервер.
Тут наверное с гарантированным 0.98МБайт не должно быть проблем?

Однозначно не должно.