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

Сообщение отредактировал _fun_ - Mar 13 2012, 05:01

У 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" (или "пулить"? )?? часто где его встречаю

Сообщение отредактировал _fun_ - Mar 13 2012, 10:37

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

Сообщение отредактировал ReRayne - Mar 13 2012, 12:04

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 прикручивал, разбирался и в физике и в Дункеле. По крайней мере та ссылка которую вы мне дали для меня не нова. Считаете, нужно вернутся к истокам?)) Типа "смотрю в книгу - вижу фигу"??? ))))
Сейчас еще ситуация сложилась, что в ограниченное время нужно разобраться со многим. Поэтому и начал сюда писать.



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

Сообщение отредактировал _fun_ - Mar 14 2012, 12:24

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