Кто пользовался этими стеками посоветуйте на чем лучше остановится,какие плюсы-минусы?

При большом мультикастовом потоке UIP заливает. Он начинает дропать пакеты. Поэтому использую hardware стек.

hardware - это чтото типа withnet?

Wiznet 3150A, если быть точным.

Хочу вступиться за uIP. Вы говорите о мультикастовом (о бродкастовом скорее всего) потоке, а он имеет место быть в Ethernet, следовательно, перед стеком имеется ещё прослойка драйвера Ethernet-контроллера, вот его-то и "заливает". В инете много фришного кода таких драйеров, но редкий код содержит процедуру корректной обработки ситуации переполнения кольцевого буфера.
Использую uIP с версии 0.5, то есть с первой его публикации.

Если под микрочиповским понимается тот, который идет "в комплекте" с их железом типа 28J60, то недавний просмотр уровня работы с железом (верхние просто не читал интересовало только железо) оставил тяжелое впечатление от криворукости их программистов. Особенно неизгладимое впечатления оставила "обработка" аппаратных ошибок - большинство игнорируются, зато по некоторым (например по приходу фрейма с неправильной CRC!) производится reset хоста. Дальше исходники не вычитывал, но меня терзают смутные сомнения о целесообразности связыватся с таким софтом.

Интересует как раз стек с использованием MAC+PHY на 28J60. Т.к. видел несколько портов uIP на этом железе и интересует такое сравнение. Мне просто интересно что будет лучше портировать микрочиповский стек( планируется использование на ARM,AVR,PIC24) или лучше сразу взять uIP. Да и как обстоят дела с поддержкой uIP(макрочиповцы вроде как поддерживаю свой стек постоянно)?

Если нашлись какие либо ссылки на материалы по нюансам железа просьба намекнуть! Ибо то, что встетилось мне представляло еще более усеченные вырианты микрочиповского оригинала , начисто лишенные даже намеков на обработку ошибок и выходы из ситуаций вызванных реальными условиями работы.

Я, в данный момент, разрабатываю проект с RTL8019AS. Хотелось бы услышать сравнение с ENC28J60, если кто может провести таковое. Корпус, конечно, на много привлекательней. А вот возможности по сравнению с приведенным мною выше чипом?

RTL8019AS тянет 6pps (честные 10Mbps). Паралельная шина позволяет в частности AVR'ке работать с ним напрямую как с внешней памятью.

Насчет ENC 10Mb/s SPI это неплохо для ARMa у которого есть SPI DMA, т.к. без DMA (в режиме прерываний) проц будет вынужден все время отвлекаться на SPI чтобы не потерять данные.. На обработку просто не останется времени. Понятно что можно настроить фильтры внутри EMAC'а, но все равно это не есть гут когда девайс можно будет положить обычными ping'aми.

С точки эрения железа RTL8019 это чистый как слеза 8390 (Ака NE2000) цельнотянутый (ну jumperless и PnP сбоку прикрутили) за 20 с лишним лет отработанный чип. Даже документация 1:1 с National-а тянутая. Неожиданностей в нем НЕТ НИКАКИХ. Ну а про Micrichip - через недельку может что и скажу, поскольку только сегодня пришла железка с данным чипом.




Прерывания от SPI не нужны как класс - там массовая операция тупое последовательное вычитывание
блоков. На скоростях SPI в 25MHz вполне терпимая по времени операция. По поводу DMA на чипах
без кэша писал уже не однократно. Если действительно заче-то нужна скорость, то тут прямая дорога на чипы со встроенным MAC. У свежих LPC, кстати, DMA для MAC работает с с отдельным банком памяти и в отличие от большинства остальных весьма эффективна.

Меня интересует связка именно с AVR-ом (М128), а у него максимум 8 МГц тактовая частота SPI, то бишь теоретически можно получить 1 мбпс

Меня всегда интересовало почему кого-то волнуют мегабиты для работы с мелкими контроллерами....
Собсвенно тактовая частота SPI особого значения не имеет - все равно опрос SPI который прервыается прерываниями и другими более приоритетными задачами. Контроллер - master, буфер до 8K на прием может быть испольльзован. Никаких особых проблем.

Именно меня волнует из за работы с мелкими контроллерами ... И не возможности, в данный момент, поставить более крупный

SPI 25Mhz... байты будут поступать с частотой 25Mhz/8 = ~3Mhz. Проц без кеша в среднем работает на частоте 50-60Mhz. В итоге SPI DMA займет (3 / 60) * 100% = 5% шинного времени..

Я ведь удивляюсь не необходимисти работы с Ethernet мелким контроллером а тем, что часто одновременно имеется горячая озабоченность тем а как 100Mbit обеспечивает используемый MAC.

Котроллер DMA займет шину на все время пересылки указаннной ему порции информации. Порцией для
SPI Ethernet является не байт (Нет, Вы конечно можете DMA и побайтно дергать, но накладные расходы првысят все разумные пределы). Одно из решений проблемы я уже поминал - отдельный банк памяти под DMA. Еще один вариант - за SPI стоит не только DMA, но и перед ним FIFO, что позволяет теоретически организовать освобождение шины между накоплениями порций размером с FIFO.
Голый DMA сам по себе в общем случае не блещет эффективностью.