ra3wum 0 29 июля, 2011 Опубликовано 29 июля, 2011 · Жалоба Или как Вы его хотите использовать? От этого, кстати, и требования к ОЗУ зависят. Хочу сделать относительно дешёвый декодер mp3 или ogg потока по http (интернет-радио) через wi-fi модуль. Соответсвенно скорость порядка 96-192 кБит/с. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 29 июля, 2011 Опубликовано 29 июля, 2011 · Жалоба Соответсвенно скорость порядка 96-192 кБит/с. Источник где? В большом интернете? Тогда не годится, будет икать, мало места под буфера. Расчет такой - сделайте пинг в ваше любимое радио, посмотрите время ответа - это так называемый Round Trip Time. Допустим, мы подобрали MTU так, чтобы нам сыпалось много маленьких пакетиков с данными - пусть не очень экономно, зато можно быстро перевести сервер в состояние Fast Retransmit при потере пакета. Будем для простоты считать, что уведомление серверу о потере пакета начинает лететь сразу после этого события. Значит, повтор пакета произойдет за время Round Trip Time. Но за это время нам упадет много новых пакетов, которые необходимо сохранить, ибо они валидные. Суммарно этих данных будет ваше 96-192кБит/с умножить на RTT. Ну, скажем, RTT будет 50мс - адекватная цифра для современных интернетов. За это время упадет 5-10 килобайт данных, которые надо сохранить. Плюс, кстати, к ним еще служебная инфа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ra3wum 0 29 июля, 2011 Опубликовано 29 июля, 2011 · Жалоба Источник где? В большом интернете? Тогда не годится, будет икать, мало места под буфера. Расчет такой - сделайте пинг в ваше любимое радио, посмотрите время ответа - это так называемый Round Trip Time. Конечно в большом, у меня пинг от 16-75 миллисекунд в зависмости от радиостанции. Что нужен внешний буфер это понятно. В некоторых конструкциях web-радио используются RAM или FRAM с интерфейсом SPI. Последняя кстати у меня и живьём есть, так что планирую её поставить. В качестве декодера VS1053. Если не ошибаюсь на вашем стеке уже делали интернет-радоприёмник? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 29 июля, 2011 Опубликовано 29 июля, 2011 · Жалоба Если не ошибаюсь на вашем стеке уже делали интернет-радоприёмник? Да. Но почему именно LPC1114? Зачем? Я бы еще понял, если бы он был декодером. Вот только не влезет. А вот, кстати, в LPC1768 я бы весь мотлох попробовал бы запихать - декодер тоже. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ra3wum 0 29 июля, 2011 Опубликовано 29 июля, 2011 · Жалоба Да. Но почему именно LPC1114? Зачем? Я бы еще понял, если бы он был декодером. Вот только не влезет. А вот, кстати, в LPC1768 я бы весь мотлох попробовал бы запихать - декодер тоже. В моих краях его проще достать и он дёшев (меньше 3 баксов). С LPC1768 всё намного хуже обстоит. С точки зрения экономии конечно можно заставить декодировать mp3 кристалл из LPC17-й серии. Но в моём случае что есть под рукой, от того и отталкиваюсь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 29 июля, 2011 Опубликовано 29 июля, 2011 · Жалоба Но в моём случае что есть под рукой, от того и отталкиваюсь. VS1053 тоже завалялась под рукой? Ценой, кстати, под десятку баксов ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 30 июля, 2011 Опубликовано 30 июля, 2011 · Жалоба Поигрался с dummynet, подправил некоторые неточности. Ревизия 1318 - NikeE_CM3_rev1318.zip Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ra3wum 0 30 июля, 2011 Опубликовано 30 июля, 2011 (изменено) · Жалоба VS1053 тоже завалялась под рукой? Ценой, кстати, под десятку баксов ;) Да она есть, точнее эволюшнкит с исходниками. Как и wi-fi модуль ZeroG ZG2100M. lpc1114 можно "занять" графическим интерфейсом пользователя на lcd от siemens S65 или аналогичного. Изменено 30 июля, 2011 пользователем RA3WUM Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 30 июля, 2011 Опубликовано 30 июля, 2011 · Жалоба Небольшой апдейт про "Машу" :) Включил ключик компилятора для оптимизации по скорости, внес еще пару коррекций в RTOS (давно уже ждали, но руки не доходили) - в-общем, достигнуто 83.3Мбит/сек ;) - 16 мегабайт чистых данных ушло за 1610мс. В принципе, достигалось и 86Мбит/сек - но после патча драйвера EMAC на приоритет событий отправки, при этом оно принимать при ограниченном буфере похуже будет, поэтому такой вариант я забраковал. Имхо, вполне приличный результат для полноценного универсального стека - проигрывает по скорости узкозаточенному совсем немного -10-15 процентов. Есть еще небольшой резерв - цикл подсчета chksum/копирования исходящих пакетов я не разворачивал, но там сложная функция на асме (одна из трех для всего стека, которые от проца зависят) - лениво уже переделывать. Из печального - загрузка процессора у меня при такой массированной отправке 99% - увы, такова плата за универсальность решения. Если отправлять осмысленные данные (считаем что заберем половину проц.времени) то эффективная скорость на LPC17 - 5Мбайт/сек. Где на LPC17 взять такой реальный поток данных - непонятно, ни SD, ни USB, ни UART, ни ADC такого не дадут, выходит даже эти 5Мбайт/сек - сферический конь в вакууме, потому как их нечем загрузить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
prottoss 0 30 июля, 2011 Опубликовано 30 июля, 2011 · Жалоба Небольшой апдейт про "Машу"... ...где на LPC17 взять такой реальный поток данных - непонятно, ни SD, ни USB, ни UART, ни ADC такого не дадут, выходит даже эти 5Мбайт/сек - сферический конь в вакууме, потому как их нечем загрузить.Дак, ИМХО, глубокий смысл не в том, где взять такой поток, а в том, чтоб меньше загрузить МК. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 30 июля, 2011 Опубликовано 30 июля, 2011 · Жалоба Дак, ИМХО, глубокий смысл не в том, где взять такой поток, а в том, чтоб меньше загрузить МК. Почему? Энергопотребление? Да там PHY потребляет само по себе стока же сколько и LPC17 в макс нагрузке. А эти 5Мб/сек - при половинной загрузке. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 30 июля, 2011 Опубликовано 30 июля, 2011 · Жалоба Имхо, вполне приличный результат для полноценного универсального стека - проигрывает по скорости узкозаточенному совсем немного -10-15 процентов. .... Из печального - загрузка процессора у меня при такой массированной отправке 99% - увы, такова плата за универсальность решения. Ага, из суперпечального Т.е. таки два раза (даже больше), ибо у меня 43% CPU Load. Дак, ИМХО, глубокий смысл не в том, где взять такой поток, а в том, чтоб меньше загрузить МК. Безусловно. А эти 5Мб/сек - при половинной загрузке. Ну а у меня - при четверти ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
prottoss 0 30 июля, 2011 Опубликовано 30 июля, 2011 · Жалоба Почему? Энергопотребление?Не только. Меньше загружен МК одной задачей - больше задач можно выполнить... 2Х2 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 30 июля, 2011 Опубликовано 30 июля, 2011 · Жалоба Где на LPC17 взять такой реальный поток данных - непонятно, ни SD, ни USB, ни UART, ни ADC такого не дадут Прямое чтение с GPIO (или через DMA) вполне такой поток даст. Скрестить что-ли с JPEG-кодером ради прикола ;) Я как-то делал вариант того веселого проекта в ARM-инкарнации на LPC2134, микросхеме SDRAM (окученной ногодрыгом) в качестве видеопамяти и SAA7113 в качестве АЦП. Уж не помню уже подробностей, но в разрешении 320*240 порядка 15 кадров в секунду Ч/Б можно было обработать (тактовая была 54МГц). На CM3 со 100МГц будет веселее и по мегагерцам и по общей производительности. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 30 июля, 2011 Опубликовано 30 июля, 2011 · Жалоба Ага, из суперпечального Т.е. таки два раза (даже больше), ибо у меня 43% CPU Load. А ничего что мое решение обладает на порядок большими фичами? Можно за минуту этот стек скомпилировать на 4 совершенно разных платформы, или за 5 минут написать на его основе бридж или роутер. И свои приложения пользователям на нем попроще (мягко говоря) писать. Так что проигрыш всего 10 процентов скорости - это очень невысокая плата. Да, еще момент - мое решение заточено больше на прием, и путь данных по приему несильно от Вашего отличается (только рулежка окнами автоматическая , а еще Out-of-Order Segments и Selective ACK), передача - по остаточному принципу, что там в квотах на память останется. Так что сравнение скорости передачи - максимально невыгодное для меня. Я все-таки на досуге напишу тестовую утилиту - чтобы и прием, передача, эхо, да по нескольким сокетам одновременно, там еще померяемся :). Прямое чтение с GPIO (или через DMA) вполне такой поток даст. Даст, но это тот самый случай когда REGENERATE все это зарежет на корню - надо будет заводить большой буфер и хранить в нем DMA-нутые данные до ACK-а по TCP. Ну или терять данные, но это как бы неспортивно Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
