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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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