VVB (14.11.2012 06:36 - 07:29, просмотров: 199) ответил VVB на Не получилось. Вызов netconn_recv() внутри моей callback приводит к останову работы стека (задача tcpip_thread блокируется, по понятным причинам: netconn_recv ждёт семафора, который должна взвести заблокированная tcpip_thread), хотя есть принятые
Придётся-таки писать промежуточный слой. Аналог tcpip_thread(). Слой нужен для вызова всех требуемых функций стека (передача данных из моих двух различных задач, вызов tcp_tmr(), вызов etharp_tmr()) из одной задачи.
Почему нет полнодуплексного режима в netconn API? Обидно.
Как-то всё не просто. Думаю, что для полного дуплекса в uIP тоже пришлось бы поизголяться.
Ну или разобраться с netconn API и понять, как можно получить данные из callback функции и как освободить занятый буфер. В любом случае очередное погружение в стек. Чего я хочу избежать.
Придумал чуть более простое решение: продолжать использовать netconn API, но в задаче, требующей полнодуплексного обмена, анализировать факт наличия данных от ПК к прибору (этот факт можно определить в моей callback функции). И вызывать netconn_recv() уже в задаче, обслуживающей это соединение.
К сожалению, в FreeRTOS отсутствует аналог OSEventPendMulti() из uCOS (функция, блокирующая задачу до появления одного из заданных событий RTOS). Также отсутствуют event, присутствующие в других RTOS (uCOS, Keil RTX), что тоже не упрощает кодирование. Придётся создавать ещё одну задачу.