Здравствуйте уважаемые гуру lwIP Видно, не выйдет из меня толкового электронщика. Почитаешь форум, тут люди за пару недель с нуля интернет прикручивают или с Осями разбираются, а я иногда месяцами на одном месте сижу... Вообщем проблема в следующем: как-то прикрутил к своему проекту на LPC1768 (под IAR) lwip неизвестной версии, столкнулся со следующей проблемой - через некоторое время при пересылке больших пакетов (>100 байт ) контроллер перестает отвечать. С маленькими (десятки байт) все стабильно. Попробовал решить эту проблему скачав и прикрутив lwIP 1.4 - заменил файлы и повис на ошибке - Error[Li005]: no definition for "ethernetif_input". Нифига не понимаю - почему IAR эту функцию не видит, ethernetif.h находит, ethernetif.с в проект включен

У lwip файлик ethernetif.c в каталоге netif идет в качестве примера - настоящий ethernetif.c лежит в каталоге port. ethernetif.h у меня вообще в проекте не наблюдается - вроде в lwip 1.4 его не было.

lwIp 1.4.0 заработал, а проблема с большими пакетами осталась. Такое впечатление, что все это как-то связано с памятью..

За пару недель интернет прикручивается при наличии опыта. У меня тоже всё это начиналось со скрипом, а сейчас кажется ерундой.


Про "связано с памятью" - это комментарий от безысходности, наверное.
Я бы не рассчитывал на то, что сейчас кто-то появится и скажет: "О! У меня это уже было! Делать нужно так и так..."
Нужно досконально разобраться в принципах работы МК, Ethernet MAC, lwip. Только так можно гарантировать, что всё это будет работать. Более того, только так можно быть уверенными, что будущие глюки будут исправлены. Ну и тщательная отладка: благо, сейчас есть средства внутрисхемной отладки, а lwip позволяет вести довольно подробную статистику.

1. LwIP проверен не одним проектом и не одной платформой стек рабочий. (Правда я его обновляю с репозитория что и вам советую).

2. Указывайте более детальную информацию хотя бы какой протокол используете с ОС или без.

3. Все проблемы на 90% находятся в драйвере MAC и от его реализации, также от его реализации сильно зависит пропускная способность.

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

5. Изучите все настройки стека их довольно много но без этого никак. В вашем случае я бы хотел обратить внимание на значение PBUF_POOL_SIZE и PBUF_POOL_BUFSIZE. Возможно их не хватает, а драйвер не умеет обрабатывать правильно ситуации переполнений или еще чего.

6. Правильно ли вы работаете в LwIP буферами (pbuf) ? Обязательно изучите их исходники они являются основой стека.

7. Если вы используете без OC убедитесь что все таймера вызываются вовремя (теже pbuf).

8. Убедитесь что у вас нет утечки памяти и все ресурсы освобождате правильно.

Ну вот такие рекомендации.




Не помню кто говорил: Если ты знаешь один язык программирования ты знаешь их все. Если ты умеешь программировать один микроконтроллер сможешь и другой. С осями тоже самое если знаешь отлично одну то и с другой быстро разберешься.

Спасибо всем большое, буду разбираться, но параллельно хотелось бы и дальше в этой теме задавать вопросы на которые я толком пока не могу найти ответа.
EMAC взял готовый из интернета. (LPC17xx_EMAC). ОС нету. До этого работал с UIP, с ним разобрался, думал LWIP тоже самое, но не тут то было (по крайней мере для меня ). За что именно отвечает PBUF_POOL_SIZE и PBUF_POOL_BUFSIZE ??? пробовал изменять значения, что-то происходит, но толком пока сказать не могу. И еще, я извиняюсь, но можете мне обьяснить на пальцах значение слова "POOL" (или "пулить"? )?? часто где его встречаю

Аха-ха-ха-ха)))
Черт, а я думала только на STM32 такая проблема, грешила на драйвер DMA изернета, что его Suspend mode не вытаскивают.
Пинги и на малые пакеты со временем умрут.
Лично у меня просто перестает подниматься прерывание от Ethernet....
Предлагаю автору в привате переговорить и провести совместно серию тестов на наших контроллерах.
Кстати PHY уровень Ethernet какой?)

UIP - это жалкое подобие TCP/IP стека, рассчитанное на 8 битники с малыми размера ми памяти, за это вы платите скорость и функциональностью.

LWIP - очень близок к серьезным стекам, он более - менее соответствует всяким RFC.


PBUF_POOL_BUFSIZE - размер входящего буфера, если входящий пакет будет больше чем этот размер, нужно буфера обьеденять в цепочку (если это неумело сделать то эффект может быть такой как у вас), что приводит к петере производительности но у величивает расход памяти, эсли памяти до черта идеальный размер 1540 (1532) в зависимости от MAC.

PBUF_POOL_SIZE - указывает количество вхjдных буферов для входящих фреймов. Если буферов будет мало пакеты начнут теряться что в случае TCP приведет ку резкому снижению пропускной способности (а то и вобще к неработаспособности в зависимости от настроек других параметров), в случае UDP это привет к потере данных.

как то так MY_BUFF[ PBUF_POOL_SIZE ][ PBUF_POOL_BUFSIZE ];



Это 100% кривой драйвер MAC.
Если вы используете STM32 и LwIP без ОС, вам вообще не нужны прерывания от мак контроллера.

Вообщем я, похоже, нашел причину : в opt.h стояло значение TCP_SND_BUF меньше, чем я указывал в tcp_write(...) , увеличил и все починилось , хотя, можно было и несколькими пакетами я так понимаю отправить. Подскажите пожалуйста, зачем нужен TCP_QUEUE_OOSEQ ???

В ваших краях гугл сломался?
Tuning TCP

Прочитал, спасибо Но с английским туго, как ни стараюсь. Понял то, что эта весчь нужна когда когда есть опасность потерять пакет в большом объеме. Правильно?
Подскажите, пожалуйста FTP сервер для LWIP какой не сильно сложный и не очень замудреный лучше использовать?? я скачал отсюда:
FTP , сижу разбираюсь, пока вышел затык с Фифо и файловой системой (???). Начал сомневаться что я с правильного конца начал.

Ну и зря. Без знания английского поднимать lwip - это мазохизм.


Без знания TCP поднимать lwip - это совсем неприлично.
Почитайте про TCP. Первоисточники - это всяческие RFC. Но и на русском тоже много написано. Хотя бы тут:
TCP

Я сам писал. готового под LwIP и FATfs нету.

Уважаемый scifi, мне право не удобно, такое чувство, что я на очень авторитетном для меня форуме задаю какие-то мегаглупые вопросы. По английски я как-то читаю, но вот мозгов у меня не хватает понять правильно (или корректно перевести???) следующую вещь:
Queueing out-of-sequence packets (TCP_QUEUE_OOSEQ)
Strictly, queueing out-of-sequence packets is only necessary when packet loss is expected, since can prevents resending all packets (e.g. packets 2, 3, 4) when only one packet is lost (e.g. packet 2 is lost but 3 and 4 have been received correctly: with TCP_QUEUE_OOSEQ disabled, packets 3 and 4 would be discarded as they are out-of-sequence and would have to be resent in-sequence by the remote host once packet 2 got through). However, even in environments where packet loss isn't expected, it might still happen, so enabling this is recommended.
Поэтому и спросил. Думал, может кто на пальцах объяснит. Параллельно пытаюсь разобраться сам. TCP считал что знаю, раньше UIP к LPC17xx прикручивал, разбирался и в физике и в Дункеле. По крайней мере та ссылка которую вы мне дали для меня не нова. Считаете, нужно вернутся к истокам?)) Типа "смотрю в книгу - вижу фигу"??? ))))
Сейчас еще ситуация сложилась, что в ограниченное время нужно разобраться со многим. Поэтому и начал сюда писать.



А прилично будет попросить у вас показать исходники?

Да могу, но это код работает с FREERTOS, LwIP и FATfs, реализует не все команды FTP (только которые мне нужны были), и не поддерживает пассивный режим FTP.

Ладно, зря я наехал. Просто лень было выступать переводчиком.


Буферизация пакетов, приходящих вне очереди.
Строго говоря, буферизация таких пакетов необходима только тогда, когда ожидается потеря пакетов, так как буферизация предотвращает повторную посылку всех пакетов (например, пакетов 2, 3, 4) когда только один пакет потерян (например, пакет 2 потерян, но 3 и 4 получены корректно: при отключенном TCP_QUEUE_OOSEQ пакеты 3 и 4 были бы выброшены, так как они пришли вне очереди, и они должны были бы быть посланы повторно удалённым узлом в порядке очереди после того, как пакет 2 будет принят). Однако, даже там, где потеря пакетов не ожидается, она всё равно может происходить, поэтому включение этой опции рекомендуется.

Кажется, исчерпывающее объяснение. Понятно, что вся эта радость не бесплатна: буферизация расходует память. Так что смотрите сами.