Хочу сделать относительно дешёвый декодер mp3 или ogg потока по http (интернет-радио) через wi-fi модуль. Соответсвенно скорость порядка 96-192 кБит/с.

Источник где? В большом интернете? Тогда не годится, будет икать, мало места под буфера.

Расчет такой - сделайте пинг в ваше любимое радио, посмотрите время ответа - это так называемый Round Trip Time.

Допустим, мы подобрали MTU так, чтобы нам сыпалось много маленьких пакетиков с данными - пусть не очень экономно, зато можно быстро перевести сервер в состояние Fast Retransmit при потере пакета. Будем для простоты считать, что уведомление серверу о потере пакета начинает лететь сразу после этого события. Значит, повтор пакета произойдет за время Round Trip Time. Но за это время нам упадет много новых пакетов, которые необходимо сохранить, ибо они валидные. Суммарно этих данных будет ваше 96-192кБит/с умножить на RTT. Ну, скажем, RTT будет 50мс - адекватная цифра для современных интернетов. За это время упадет 5-10 килобайт данных, которые надо сохранить. Плюс, кстати, к ним еще служебная инфа.

Конечно в большом, у меня пинг от 16-75 миллисекунд в зависмости от радиостанции.
Что нужен внешний буфер это понятно. В некоторых конструкциях web-радио используются RAM или FRAM с интерфейсом SPI.
Последняя кстати у меня и живьём есть, так что планирую её поставить.
В качестве декодера VS1053.
Если не ошибаюсь на вашем стеке уже делали интернет-радоприёмник?

Да. Но почему именно LPC1114? Зачем? Я бы еще понял, если бы он был декодером. Вот только не влезет. А вот, кстати, в LPC1768 я бы весь мотлох попробовал бы запихать - декодер тоже.

В моих краях его проще достать и он дёшев (меньше 3 баксов). С LPC1768 всё намного хуже обстоит.
С точки зрения экономии конечно можно заставить декодировать mp3 кристалл из LPC17-й серии. Но в моём случае что есть под рукой, от того и отталкиваюсь.

VS1053 тоже завалялась под рукой? Ценой, кстати, под десятку баксов

Поигрался с dummynet, подправил некоторые неточности.

Ревизия 1318 -  NikeE_CM3_rev1318.zip ( 357.97 килобайт ) Кол-во скачиваний: 518

Да она есть, точнее эволюшнкит с исходниками. Как и wi-fi модуль ZeroG ZG2100M.
lpc1114 можно "занять" графическим интерфейсом пользователя на lcd от siemens S65 или аналогичного.

Сообщение отредактировал RA3WUM - Jul 30 2011, 11:59

Небольшой апдейт про "Машу"
Включил ключик компилятора для оптимизации по скорости, внес еще пару коррекций в RTOS (давно уже ждали, но руки не доходили) - в-общем, достигнуто 83.3Мбит/сек - 16 мегабайт чистых данных ушло за 1610мс. В принципе, достигалось и 86Мбит/сек - но после патча драйвера EMAC на приоритет событий отправки, при этом оно принимать при ограниченном буфере похуже будет, поэтому такой вариант я забраковал. Имхо, вполне приличный результат для полноценного универсального стека - проигрывает по скорости узкозаточенному совсем немного -10-15 процентов.
Есть еще небольшой резерв - цикл подсчета chksum/копирования исходящих пакетов я не разворачивал, но там сложная функция на асме (одна из трех для всего стека, которые от проца зависят) - лениво уже переделывать. Из печального - загрузка процессора у меня при такой массированной отправке 99% - увы, такова плата за универсальность решения. Если отправлять осмысленные данные (считаем что заберем половину проц.времени) то эффективная скорость на LPC17 - 5Мбайт/сек. Где на LPC17 взять такой реальный поток данных - непонятно, ни SD, ни USB, ни UART, ни ADC такого не дадут, выходит даже эти 5Мбайт/сек - сферический конь в вакууме, потому как их нечем загрузить.

Дак, ИМХО, глубокий смысл не в том, где взять такой поток, а в том, чтоб меньше загрузить МК.

Почему? Энергопотребление? Да там PHY потребляет само по себе стока же сколько и LPC17 в макс нагрузке. А эти 5Мб/сек - при половинной загрузке.

Ага, из суперпечального Т.е. таки два раза (даже больше), ибо у меня 43% CPU Load.



Безусловно.



Ну а у меня - при четверти

Не только. Меньше загружен МК одной задачей - больше задач можно выполнить... 2Х2

Прямое чтение с GPIO (или через DMA) вполне такой поток даст. Скрестить что-ли с JPEG-кодером ради прикола Я как-то делал вариант того веселого проекта в ARM-инкарнации на LPC2134, микросхеме SDRAM (окученной ногодрыгом) в качестве видеопамяти и SAA7113 в качестве АЦП. Уж не помню уже подробностей, но в разрешении 320*240 порядка 15 кадров в секунду Ч/Б можно было обработать (тактовая была 54МГц). На CM3 со 100МГц будет веселее и по мегагерцам и по общей производительности.

А ничего что мое решение обладает на порядок большими фичами? Можно за минуту этот стек скомпилировать на 4 совершенно разных платформы, или за 5 минут написать на его основе бридж или роутер. И свои приложения пользователям на нем попроще (мягко говоря) писать. Так что проигрыш всего 10 процентов скорости - это очень невысокая плата. Да, еще момент - мое решение заточено больше на прием, и путь данных по приему несильно от Вашего отличается (только рулежка окнами автоматическая , а еще Out-of-Order Segments и Selective ACK), передача - по остаточному принципу, что там в квотах на память останется. Так что сравнение скорости передачи - максимально невыгодное для меня. Я все-таки на досуге напишу тестовую утилиту - чтобы и прием, передача, эхо, да по нескольким сокетам одновременно, там еще померяемся .


Даст, но это тот самый случай когда REGENERATE все это зарежет на корню - надо будет заводить большой буфер и хранить в нем DMA-нутые данные до ACK-а по TCP. Ну или терять данные, но это как бы неспортивно