IAR 6.21.1.2846 и common components 6.3.3.1990. При компиляции просит revision.c, где его взять?

Он при компиляции создается отдельной софтиной. Можно сделать вручную из revision.tmpl, там просто строка текстовая в константу засовывается, т.е. шаблон заменить на 123, например.

И еще, собирать надо Target Release.

При этом в этом "нормальный, полнофункциональный, скоростной TCP/IP-стек" не будет MAC уровня под Ваше железо или вообще, либо MAC будет написан минимально-формально. Это вообще-то сразу вычеркивает слово "скоростной" ( по отношению к стеку, а не процессору ). В дополнение к MAC написанному для галочки скорее всего вылезут еще и проблемы минимальности-универсальности-убогости взаимодействия с MAC уровнем вообще. Захочешь реально сделать конкретную работу хорошо по любому придется либо перепахивать нечто чужое и большое, либо, как вариант, что-то более-менее обозримое и заточенное под задачу. Иначе прямой путь не глядя за ради IP стека к чему-либо типа штопанного Линукса и гигагерцам.

ИМХО, как раз LPC17xx неудачно выбран для иллюстрации уникальности стека. Если на AVR (откуда это все было портировано) с такой уникальностью еще можно было смириться, то на LPC17xx (у которого ресурсов более чем) это вызывает удивление.

Так я, если Вы заметили, именно за это и голосую обеими руками..

А именно, всё железо-зависимое нужно вынести в сетевой драйвер. В этом драйвере и будут жить все железо-зависимые функции MAC уровня, типа SGDMA, IO, MDIO, и пр. (ессно, в зависимости от возможностей процессора). При этом сам TCP/IP-стек должен быть максимально независимым от аппаратной платформы, т.е., "НЕ уникальным" и иметь четко выраженный формализованный интерфейс на основе стандартных вызовов: OpenDevice(), DeviceIOCtl(), SyncRead(), SyncWrite(), CloseDevice(). В этом случае, при переходе на другую платформу, нужно будет переписать только драйвер. TCP/IP-стек, при этом, останется без изменений.

Как-то так..

Примитивность этого формализованного интерфейса обычно и гробит возможности MAC железа сводя их к нескольким унылым примитивам. В результате чего приходится править этот самый "независимый" (от разума) стек до получения приемлимого результата за счет правильного использования MAC железа. Или наращивать мегагерцы и ядра для компенсации "унифицированного" подхода к работе.

А что там по Вашему должно быть? Очереди входящих и исходящих пакетов, функция руления линком и его параметрами - разрешение/запрет, выбор скорости, MDX, можно еще доступ к регистрам PHY для доступа к его особому функционалу. Ну у меня есть еще колбек возврата буферов после передачи для хитрой стратегии распределения памяти и квотирования. А чего еще от MAC-а нужно-то?

Там должно быть то, что позволит полностью использовать возможности конкретного железа. Вот у Вас есть то, что Вы назвали "колбек возврата буферов после передачи для хитрой стратегии распределения памяти и квотирования". Вы еще мечтаете об использовании аппаратного CRC. Как это ложится на нечто абстрактно универсальное взаимодействие с MAC уровнем массово низводимое разработчиками "универсальных" стеков в своей основной функции до передать/принять фрейм?

Ну почему же? Вполне такой себе середнячок по нынешним временам. Мейнстрим.



Ресурсов более чем? Очень странное заявление. Нет, ну если, конечно, светодиодом через веб-интерфейс мигать - тогда, конечно, да. Но заявки-то - "хотим 100M через TCP". А теперь давайте считать. Все ОЗУ там - 64кБайт. При скорости в почти 12 Мбайт/с и полностью занятым под буфера TCP ОЗУ максимальный round-trip time, с которым можно обеспечить эту самую дико желаемую всеми цифру - всего 5 миллисекунд.

В реальной жизни это означает, что три обычных неуправляемых L2-свича в гирлянде приведут к падению скорости и ничего Вы стандартным построением TCP-стека не сделаете. А если это, скажем, из подсетки в подсетку, разделенные даже адекватной Циской с L3 маршрутизацией - то все, зопа.

Это все общие слова. Вы приведите пример для конкретного LPC17xx - чего он уметь-то должен?.


И что? Эта неплохая технология позволяет жить и довольно быстро меняться без потери пакетов десятку сокетов, используя всего 16К памяти. Если памяти много и квоты никого не инетересуют, то это ведь можно и отключить.


Вполне нормально ложится, есть резервное место в поле флагов в пакете (которое при желании расширяется). Если MAC умеет проверять суммы при приеме, то в поле свойств интерфейса будет стоять флажок "а смотрите как я круто умею проверять/считать суммы". И процедура приема пакетов (ессно, версия которая скомпилирована с флагами что у нее могут быть такие умные интерфейсы) просто будет смотреть и проверять во входящих пакетах на таких умных интерфейсах этот флажок, вместо тупого вызова tcp_check_sum. И с отправкой аналогично. В-общем, такой себе out-of-band канал в интерфейсе с MAC-ом должен быть, и это все не моя придумка - идеология подсмотрена в NDIS.

А я что-то плохое говорил??? Я просто отметил, что Вам стало тесно в рамках простейшего взаимодействия между уровнями. Это НОРМАЛЬНО.

Так о чем Вы это? О том, что можно добавить, углубить, расширить, улучшить.... Так я ровно о том-же, что можно, но и в первую очередь о том, что в абстрактном стеке всего этого НЕТ и придется его дорабатывать под возможности MAC. Либо НЕ дорабатывать - и так сойдет.

Это заявки оторванные от реальности. Передать-принять 100мбит/сек, допустим, у Вас получилось, и похоже таки со 100% загрузкой ядра (раз 92 мбита из 95), но кто на этом проце и всего с 64К памяти осмысленно сгенерировать или обработать 12Мбайт/сек сможет? Вы можете привести пример, когда на LPC17xx нужно 100Мбит/сек и от этого будет смысл?


Да и на Вашей реализации тоже ничего не сделаете. Как только данные станут осмысленными (а не генератор ПСЧ), то в приложении у Вас появится буфер, и упретесь в те же самые 64K.

А вот тут тонкость. Я малость оптимизировал (сократил в два раза с 30 до 15мкс) расчет IP Checksum, а результат не изменился. Так что CPU load там походу меньше 100%, но пока неясно недостижение теорпредела. Раз пошла такая пьянка, то я решил таки доделать вменяемую процедуру отправки пакета, которая не будет ждать готовности тупо в цикле. Правда, за сегодня сделать не успел, но, думаю, завтра получим нормальные данные по загрузке CPU.



Ну я понимаю, что http-сервер недостаточно осмысленные данные генерирует, но ладно Придется таки сделать читалку с SD с топовой скоростью. C 45DB даже смысла обсуждать нет, ибо там есть вообще произвольное чтение.

Хм, а разве он их генерирует, а не просто берет ресурс из флешки? Тогда это у Вас аналог буфера на 512К, просто тип буфера const

Имхо, не получится с SD по SPI ничего с нормальной скоростью прочитать. Ну в идеале будет 3Мбайт/сек - больше просто SPI не позволит. Надо ждать LPC1788 - там SD контроллер 4-битный и аппаратный, вот там можно попробовать до 100Мбит подняться.

Распаковывает на ходу и подставляет изменяемые параметры. Даже если и рассматривать флеш как буфер на 512к, у Вас-то такого нет



Да ладно, я ногодрыгом 4хбитный интерфейс сэмулирую, мне не привыкать.

Это для пакета в 1460 байт? Примерно 1 такт на байт? Можно глянуть код основного цикла подсчета? Потому как у меня полтора такта на байт выходит.

Да. Я щас не у своего рабочего компа, завтра буду у него, выложу. Хотя... Момент...

SVN - великая вещь


Ну такое, туповато, но действенно.

Ничего, зато у меня много чего другого есть
Кста, сегодня я коллегам (которые пишут приложения юзающие мой стек) предложил "покрутить окно руками" и нарвался на встречное предложение "покрутить мое лицо ногами" . Ну не нужны им проблемы протокола - там у них своих хватает.


А что - на PIO получится 25МГц выдать? Да и процессорного времени отожрет, ну да ладно.

Ну придется извратнуться, конечно. Главное там - не процом ждать готовности, на этот предмет есть пара идей.



Ну это кто на что учился.

А еще придется CRC16 считать для каждой из четырех линий отдельно. Не стоит овчинка выделки - сделать можно, но скорость едва ли будет выше чем при работе через SPI.

Ох ты... Этот момент я как-то просмотрел. Надо, конечно, подумать, но, боюсь, что Вы правы, зопа.

По моим расчетам скорость вытаскивания данных из SD может быть 8 мегабайт/с. Это ногодрыгом с одновременным расчетом CRC. Вроде бы, конечно, если не обсчитался.

Сделал правильный отправлятель пакетов (без тупого ожидания) и отображение загрузки CPU.

Нажмите для просмотра прикрепленного файла

Почему-то рассчитанный мной теорпредел не достигается (числа пляшут в районе 91..92Мбит/с), но мне сейчас нечем разобраться - нет достаточно быстродействующего осциллографа, чтобы рассмотреть точно паузы между пакетами.

При этом загрузка процессора - 43%.

Rst7
Сколько данный стек занимает RAM? В LPC1114 можно использовать?

Дык тут нижний уровень не такой, как на AVR, тут используется модуль EMAC в LPC17xx, никакой рукопашной, как это в том проекте. Повторять эпопею мне что-то не улыбается.

Или как Вы его хотите использовать? От этого, кстати, и требования к ОЗУ зависят.

Хочу сделать относительно дешёвый декодер 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 - Нажмите для просмотра прикрепленного файла

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

Небольшой апдейт про "Машу"
Включил ключик компилятора для оптимизации по скорости, внес еще пару коррекций в 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. Ну или терять данные, но это как бы неспортивно

Проигрыш у Вас, повторюсь, в два раза. Физический предел, будем считать, Вы тоже почти достигаете, но при загрузке в 100%. У меня в этом случае - загрузка 43%.



Буфер-то этот можно иметь и внутри проца - сколько надо (или сколько можно), столько и выделить. Это не скажется на быстродействии, тут только вопрос - какой максимальный RTT в сети возможен без падения производительности - это зависит исключительно от размера этого буфера.

А я не спорю что проигрыш, архитектура совершенно другая, и реализация обобщенная, и сравнение (на передачу) невыгодное. Было бы удивительно если универсальное решение выиграло у специализированного.


Именно что скажется - в буфер/из буфера надо будет данные копировать, а не генерировать как сейчас "на лету" - загрузка проца вырастет.

Я с одним знакомым реализовывал обработку Fast Retransmit в приемнике этого стека (не в выложенных версиях). Ну что могу сказать - работает. Для интернет-радио помогает здорово. Буфер, конечно, требуется.



Почему Вы так упорно называете мое решение "специализированным"? Два дня на порт с AVR (между прочим, с софтовым MAC'ом) на LPC (EMAC железный) - это жесть какая специализация, все надо было с нуля переписать



Ну, если по байтику носить - то, конечно, зопа. Намекаю - допустим, из периферии у Вас в буфер данные достает DMA. Считаем, что CPU load равен нулю. Вменяемый memcpy из этого буфера - это даже быстрее из расчета на байт, чем текущий генератор рандомов:

При приеме я сталкивался с реализациями TCP где FR реализован весьма своеобразно - например в QNAP NAS (на базе линуха). Вот он фигачит поток на все окно, невзирая на то как там приходят ACK-и, есссно, пакеты начинают "по дороге" пропадать (не всякий свич спокойно пропускает 125Мбайт/сек), и если не реализован SACK, то наступает зопа.


Дело не в порте и не в архитектуре - хотя, если тут перейти на RTOS, то это свою плату возьмет и может стать не так весело. Специализировано потому что заточено на одну конкретную среду передачи и жестко привязано к набору Ethernet/ARP/IP/TCP. И чтобы получить, например, другую среду, или мультинтерфейсность то надо это решение капитально дорабатывать. Но самое неприятное, имхо, колбеки - это далеко не самый простой и удобный вариант для разработки приложений (приходится делать то что нужно, а не то что хочется ), все проблемы буферизации и синхронизации вынесены на сторону приложения, к тому же еще требуется обслуживать проблемы протокола - то есть в общем случае вопрос протокола TCP этим кусочком кода полностью не закрыт.


OK, согласен.

P.S. Кстати, а не хотите сделать функцию которая копировала бы данные в передающий буфер и одновременно считала IP_checksum - такую себе замену memcpy. И сохранять эту сумму где-нить в сокете. При отправке смотреть - 0 - значит приложение копировало или генерировало само, а не 0 - значит это сумма payload-а и можно только досчитать сумму заголовков и все.

Не пора ли завязывать есть эти кактусы, кстати? Опять я каждый раз слышу - "а мне надо под RTOS/будет сильно медленнее". Не читайте перед обедом советских газет пользуйтесь RTOS, пишите свои фреймворки с вменяемым быстродействием. У меня в последнее время вообще желание пропало - все равно машины состояний в прерываниях с верно выбранными приоритетами эффективнее. На худой конец есть setjmp/longjmp - это чтобы организовать поток по быстрому/по местному. На CM3, кстати, опять можно эффективно использовать.

Про быстродействие malloc/free (особенно тех реализаций, которые доступны вместе с исходниками обычно используемых RTOS) - отдельный разговор. Вопрос, вызывающий обычно батхерт у RTOSописателей и RTOSопользователей (средней продвинутости, умные - те всякими пулами памяти пользуются и всякие изобретения изобретают) - "На сколько максимально времени ваш malloc (или free) блокирует шедуллер"?



Зато эффективный в условиях недостатка ресурсов и куда более гибкий. Конечно, посложнее в использовании, хотя мне, например, уже давно пофиг, я не беру в работу проекты, в которых во главу угла поставлено "time to market".

Конечно, пионер предпочтет по байтику вызывать send или recv - у меня были такие заказчики и у них были свои "программисты высокого уровня" (дословно), пришлось их заставить читать из стека по одному байту для получения строки до \n. Иначе они не могли, не получалось у них сделать вменяемую буферизацию, при этом обычная отмазка у них была такая - "Ваш прибор присылает неправильные данные". Хотя, понятное дело, в telnet'е все было верно, но это же не показатель для таких супер-специалистов

Нет, понятно, за пару десятков килопрезидентов я бы написал им адекватный код для большого брата. Но ведь "нет ручек - нет и апельсинчиков" (цэ)

Кстати, а как Вы организовываете http-сервер и разбор входящих строк? Не многовато ли буферов используете в общем зачете?

Я, понятное дело, строки разбираю прямо в пришедшем пакете машиной состояний. Никаких накладных расходов.



Я тоже рассматривал вопрос реализации SACK. Вот только не помню, какой-то узкий момент отложил имплементацию. Уж не помню какой. Надо освежить в памяти соответствующий RFC и, наверное, заимплементить.



Мысль, конечно, интересная и здравая. Если крепко придавит - реализую.

Написание и использование RTOS (кстати, ои очень очень разные встречаются) абсолютно не накладывает никаких ограничений на использование каких-либо других средств, ЕСЛИ в этом есть необходимость. И malloc/free предоставляют возможность разрешить проблему нехватки памяти. Написание чего-либо уникального, на самом деле тоже не проблема, поскольку используются наработанные приемы и кубики, но в общем случае достаточно бессмысленное занятие, поскольку важны узкие места и время лучше тратить на их расшивку. И еще, даже при наличии опыта и заготовок изготовление некой штучной "системы" тем не менее черевато неочевидными системными ошибками , а оно это надо?

Да я не протестую против использования RTOS. Я протестую против бездумного использования. Фраза "будет сильно медленнее" именно из-за этого вызывает ненависть. Ну и вообще, общедоступного "портабельного и читаемого" гуано на эту тему в интернетах не меньше, чем TCP-стеков.

Никаких кактусов, кста . Когда в проекте за полмиллиона строк и на их базе нуна пару раз в месяц генерить релизы для разных заказчиков на разных платформах, то поневоле задумаешься как это все структурировать-стандартизировать и чтобы не то что легче жить стало, а чтобы это все банально не загнулось. Ессно, работают несколько человек - и взаимодействие между ними тоже надо в какие-то рамки укладывать. Все это уже на практике проходили. И на асме проиложения 20 лет назад писали, перешли на C- получили скачок в скорости и качестве разработки. И машины состояний на прерываниях делали - потому как ресурсов не было, появились ресурсы - перешли на RTOS, и снова скачок в качестве и скорости разработки.


Смотря что считать эффективнее - если больше успеешь сделать, при этом меньше устанешь да и в кармане будет больше звенеть, то вот это и есть эффективность. Например, машину на прерываниях для управления ударным печатающим механизмом я писал примерно три недели - шаговые двигатели с разгоном-торможением, управление кареткой, графика/текст, взаимодействие с основной программой. А в отдельной задаче RTOS - три дня. 12 рабочих дней - мой чистый профит. Ну да, оно взяло чуток больше памяти и проц времени, но ТЗ и time-to-market удовлетворило. В-общем, я лет 15 не слазил с этих машин на прерываниях, оно конечно приятно и красиво - штучный товар, при разработке получаешь удовольствие, но хрен Вы меня на них обратно с RTOS-а сдернете. Мож я просто старый и ленивый стал


Угу, все именно так. Поэтому malloc/free у меня и нету - только пулы. Но там у меня много навернуто - референс каунтеры (из стека не то что сокет - интерфейс можно асинхронно удалить - например при выдергивании USB такое может быть), квоты, оповещения интерфейсов/сокетов/приложений о появлении памяти. Сейчас, кста, по прошествии времени видно что кое-что из этих задумок лишнее, надо будет пооптимизировать/под флаги компиляции убрать. Глядишь и я wire-speed достигну .


Ну значит Вы счастливчик, что можете это себе позволить. Но ресурсы нынче дешевы, их тоже многие могут себе позволить и выполнить "презренный time-to-market" не будучи таким виртуозом как Вы.


А в том же сегменте где пришел и разбираю. То есть - MAC кладет в цепочку приемных сегментов - эта же цепочка попадает приложению HTTP, и в них и идет анализ. Закончился - вернули буфера обратно стеку. От Вашей ситуация отличается только тем, что разбор идет не в колбеке где даже почесать себя нигде нельзя, а в отдельном потоке и никто при этом в спину не дышит (ну кроме market-а ).

Приятно видеть адекватного профессионала Я, собственно, выше на пост zltigo отвечал, там отметил, что протест вызывает бездумное использование. Рад, что Вы в курсе дела. Тогда мне непонятно, почему Вам кажется, что при использовании RTOS сильно упадет производительность?

Я не сказал "сильно медленее", я сказал - "возьмет свою плату". Какую - мне пока не ясно. Будет время - я попрофайлю свой стек, потому как не совсем понятно куда время процессорное ушло. Дополнительное копирование 10Мбайт/сек могло отожрать ну 10% от 100МГц, но не 60% же. RTOS тоже по идее не должна бы - 16 мегабайт это примерно 12тыс исходящих и 6 тыс входящих пакетов, ну пусть 20тыс всего, по два переключения контекста по 2мкс - 40мс из 1600мс. Тоже отнюдь не 60%. Надо зарытую собаку искать, поэтому тут не тока спортивный интерес с моей стороны.