А как еще? Именно так. Только бояться не надо, ничего сложного.

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



Угу, для Вас несложно, для меня несложно, а для человека, незнакомого с протоколом TCP - вполне себе может быть проблемой.

Так надо тогда профессию сменить на грузчика. А нам, профессионалам, денег будет больше.



Именно. Более того, оптимальный стек с ppp-транспортом должен строиться по другим принципам.

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

Ага, вот тут и встает наш Главный холиварный Вопрос: "Что делать, - каждый раз заново переписывать кривой уникальный TCP/IP-стек под каждый новомодный нанопроцессор, или доплатить денег, и купить более подходящий по ресурсам микропроцессор, в который без лишних телодвижений влезет нормальный, полнофункциональный, скоростной TCP/IP-стек + RTOS + Ваше_Любимое_Приложение?"

Да порочный это подход. Если следовать таким рассуждениям, то вообще нельзя использовать EMAC в контроллерах класса рассматриваемого.

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.