stm32 LwIp, Как работать с фреймами Ethernet Опции

[TolikG]

Использую STM32F4 + FreeRtos + LwIp.
Возникла задача принимать некоторые фреймы Ethernet, обрабатывать их не пропуская в стек LwIp, после обработки посилать в Ethernet. При этом не нарушить работоспособность стека LwIp.
Подскажите в каком месте следует перефатывать принятые фреймы, и как передать свой фрейм. Разобраться в исходниках ядра не смог - натыкаюсь на бесконечные переопределения, указатели, семафоры, очереди.
Вобщем не смог проследить путь от netconn_write() до места где данные уходят наружу, там мог бы и подменить буфер с фреймом.

[Log_in]

Вот пример от терраэлектроники как они реализуют прием и отправку по Ethernet. Можно попытаться сделать разграничение по двум типам приема: в ручную и стеком. http://forum.promelec.ru/index.php/topic,1828.15.html

Сообщение отредактировал Log_in - Jan 22 2014, 06:03

Прикрепленные файлы

 _______.rar ( 1.61 мегабайт ) Кол-во скачиваний: 71

 

[scifi]

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

Если прямо кадры Ethernet - то в так называемом "драйвере" STM32 Ethernet MAC. Драйвер написан кодерами-индусами из ST, так что разбираться тоже будет непросто. Кстати, мой самописный драйвер имеет размер всего 450 строк.
Если достаточно перехвата пакетов IP, то в lwip для этого есть штатные средства.

[TolikG]

Если прямо кадры Ethernet - то в так называемом "драйвере" STM32 Ethernet MAC. Драйвер написан кодерами-индусами из ST, так что разбираться тоже будет непросто. Кстати, мой самописный драйвер имеет размер всего 450 строк.
Если достаточно перехвата пакетов IP, то в lwip для этого есть штатные средства.

В lwIp я не шибко силен - читал что есть raw-функции, которые можно использовать если не используется многозадачность. Я так понял, что либо FreeRtos без lwip - либо lwIp без многозадачности?

[scifi]

Я так понял, что либо FreeRtos без lwip - либо lwIp без многозадачности?

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

[kolobok0]

...размер всего 450 строк...

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

[Golikov A.]

В lwIp я не шибко силен - читал что есть raw-функции, которые можно использовать если не используется многозадачность. Я так понял, что либо FreeRtos без lwip - либо lwIp без многозадачности?

это не про LwIP просто, а про LwIP на софтварных процах микроблайза. Там LwIP завернут в библиотеку, и у него 2 режима работы. Raw и Socket, первый без операционок, а второй требует операционки. Но это все про ксалинкс, плис, и их микроблайз.

Для АРМ и прочего может быть не так, если вы только ихнюю же библиотеку как то не прикрутите, или вам не попались их исходники, или в LwIP для армов изначально тоже все это есть...

[scifi]

Для АРМ и прочего может быть не так, если вы только ихнюю же библиотеку как то не прикрутите, или вам не попались их исходники, или в LwIP для армов изначально тоже все это есть...

При чём тут плис и арм?
lwip - вполне себе нормальная библиотека, написанная на языке Си. Работает одинаково как на армах, так и на софткорах. Процессор - он ведь и в Африке процессор.
Полистайте для разнообразия исходники lwip. Возможно, развеются какие-нибудь заблуждения.

[Golikov A.]

При чём тут плис и арм?

ТС сказал "читал что есть raw-функции, которые можно..." такого рода деления я видел в реализации LwIP для плис, в смысле где режим полинга по таймерам называли Raw. И провел некую цепь размышлений, возможно она была не верной... извиняюсь...

[MALLOY2]

Вобщем не смог проследить путь от netconn_write() до места где данные уходят наружу, там мог бы и подменить буфер с фреймом.

1. Вам нужно найти место где инициализируется структура

Код

  ethif->output     = etharp_output;
  ethif->linkoutput = EthernetOutput;   //EthernetOutput - Это и есть вывод фремом естесно у Вас она может по другому называться скажем так low_level_output
  ethif->input       = tcpip_input;         //tcpip_input - Сюда принятые фреймы засовываются если используется ОС и ethernet_input - если неиспользуется ОС
  ethif->mtu         = 1500;        
  ethif->flags        = NETIF_FLAG_BROADCAST|NETIF_FLAG_ETHARP; //broadcast capability

P.S. Странный подход у Вас вам нужны вреймы а вы их пытаетесь проследить от netconn_write(), не стой стороны копаете, копайте со стороны драйвера МАС.

[kolobok0]

...режим полинга по таймерам называли Raw..

как бы роу - в контексте стэка, имеется ввиду сырые пакеты. т.е. юзверь стэка может формировать
сам пакеты и сказать - а теперь передатчик съешь это всё. это становится понятно, когда загляните в исходники lwip - там прямо
такие кейсы и встретите по коду
SOCK_RAW
LWIP_RAW
MEMP_RAW_PCB
PBUF_RAW
NETCONN_RAW

а как это обслуживает стэк - поллинг или прерывания или там сбоку подпрыгивает - пофигу...

[sergey sva]

Разбираюсь с исходниками lwip, настроек очень много, на какие стоит обратить внимание в первую очередь?

[MALLOY2]

как бы роу - в контексте стэка, имеется ввиду сырые пакеты. т.е. юзверь стэка может формировать
сам пакеты и сказать - а теперь передатчик съешь это всё. это становится понятно, когда загляните в исходники lwip - там прямо
такие кейсы и встретите по коду

Не стоит путать сырые пакеты IP с фреймами изернет где могут передаваться фреймы отличные от IP протокола, а RAW сокеты работают с IP пакетами.

[TolikG]

1. Вам нужно найти место где инициализируется структура

Код

  ethif->output     = etharp_output;
  ethif->linkoutput = EthernetOutput;   //EthernetOutput - Это и есть вывод фремом естесно у Вас она может по другому называться скажем так low_level_output
  ethif->input       = tcpip_input;         //tcpip_input - Сюда принятые фреймы засовываются если используется ОС и ethernet_input - если неиспользуется ОС
  ethif->mtu         = 1500;        
  ethif->flags        = NETIF_FLAG_BROADCAST|NETIF_FLAG_ETHARP; //broadcast capability

P.S. Странный подход у Вас вам нужны вреймы а вы их пытаетесь проследить от netconn_write(), не стой стороны копаете, копайте со стороны драйвера МАС.

Устройство должно выполнять следующие задачи:
- WEB - cтраничка для оперативного управления
- FTP-сервер для удаленного обновления
- маршрутизация (пересылка некоторых фреймов в необработанном виде) в другие (не Eternet!) интерфейсы (UART, SPI...) и обратно из других интерфейсов в Eternet.

Покопался в исходниках LwIp со стороны обработчика прерываний - вышел на функции low_level_input(), low_level_output(). Думаю получится.

[scifi]

- маршрутизация (пересылка некоторых фреймов в необработанном виде) в другие (не Eternet!) интерфейсы (UART, SPI...) и обратно из других интерфейсов в Eternet.

Пересылка голых кадров Ethernet? Зачем? Через UDP было бы удобнее.

[Golikov A.]

ну да. Вам и контрольную сумму посчитают, и мак адрес проверят, зачем эту работу самому то делать? А главное чего вы выиграете, только стэк сбивать будите.

Сделайте доп порт UDP, а лучше TCP. И все что льется на него просто транслируйте в другие интерфейсы, стэк все равно крутиться...

[TolikG]

Пересылка голых кадров Ethernet? Зачем? Через UDP было бы удобнее.

Чтобы не зависеть от протокола - отбор кадров по МАС адресу источника.

[scifi]

Чтобы не зависеть от протокола - отбор кадров по МАС адресу источника.

Ни капли ясности не прибавилось. Какая такая "зависимость от протокола"? Чем это плохо? Весь мир зависит от ARP, IP, TCP и т.д. - и не тужит.

[Golikov A.]

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

Даже если представить что у вас сеть состоит из нормальной ТСР, и ваших устройств где вы не хотите морочиться со стэком для обмена между устройствами, то уж UDP пакет собрать вообще ничего не стоит, контрольную сумму то к данным всяко добавлять надо, как и адрес назначения.

[kolobok0]

..то уж UDP пакет собрать вообще ничего не стоит, контрольную сумму то к данным всяко добавлять надо, как и адрес назначения.

это пока какой нить (программно настраиваемый) свитч не порежет IP по 100 байт
вот тогда все костыли идут лесом...

[scifi]

это пока какой нить (программно настраиваемый) свитч не порежет IP по 100 байт
вот тогда все костыли идут лесом...

Между прочим, lwip умеет как разбивать IP пакеты на кусочки, так и собирать их обратно.

[kolobok0]

Между прочим, lwip...

апсолютно верно (если скомпилировали с опцией реассемблирования).
Вы бы хоть почитали реплику на которую я так ответил

[TolikG]

Ни капли ясности не прибавилось. Какая такая "зависимость от протокола"? Чем это плохо? Весь мир зависит от ARP, IP, TCP и т.д. - и не тужит.

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

[Golikov A.]

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

Мне трудно представить хоть какое-то готовое устройство с Езернет подключением, у которого на выходе был бы свой какой-то неизвестный протокол. Это кто же такое сделает, и как оно работать то будет?

Обратите внимание вашего верховного программиста что ему не предлагают делать свой протокол, просто в качестве транспорта данных (капсулы для них) разумно использовать стандартный протокол, поддержанный стэком, с обеспечением целостности данных и прочего. Процессор получает пакет, извлекает из него данные и не думаю что там шлет их дальше. Полученные данные из вне, также не думаю заворачивает в UDP и шлет обратно. Да все так делают...