Здравствуйте.

Проблемка, не могу найти как сдеалть. Микроконтроллер периодически (раз в 1с) посылает UDP пакет, все работает. Но надо за один раз посылать порядка 20 разных отдельных пакетов. Буфер для формирования пакетов один. Как определить что предыдущий пакет уже отправлен и можно формировать и отправлять следующий? Определить что именно отправлен, обработан модулем Eth и выдан в линию связи (а не принят адресатом).

Спасибо.

По определению.
Если изернет стэк это не делает - меняйте(правьте) нафик стэк.

UDP - гарантирует ОТПРАВКУ пакета. Т.е. если вам вернулось управление после вызова функции send - то пакет 200% ушёл в сеть.


(круглый)

Там бывает буферизация, если ARP ещё не выяснил MAC. В общем, надо нырять в стек и смотреть. Самому сейчас лень.

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


(круглый)
ЗЫ
с ходу в рфс ничего конкретного не нашёл...может смотрел не дотошно - хз...

А какая разница — потеряли пакет в стеке или в сети? Без подтверждения доставки это одно и то же.

Это с чего бы это не должно быть? Еще как должно быть, даже обязано быть. По UART когда отправляем, тоже данные буферизуем (по-хорошему). Чем Ethernet-то отличается? Тем более когда разговор о UDP. Если следовать Вашей логике, функция отправки не должна отдавать управление до тех пор, пока фрейм не будет отправлен. Тогда уж жуткие тормоза и околонулевая скорость потока гарантирована.


И ничего оно не гарантирует. Если места в буфере будет недостаточно - никакой отправки не произойдет, а если учесть, что разговор идет о LwIP, функция udp_sendto() вернет ошибку.

1) юарт - не определяет протокол, формат и взаимодействие по нему. Вы можете сами выбирать разрядность, чётность, и т.д.. А уж по формату фрэйма - вообще что угодно и как угодно.
UDP определён в конкретном документе. Если Вы изобразите нечто отличное от этого определения - то это уже будет не UDP...увы и ах... В этом собственно и отличие.
2) Это не моя логика. Это есть такая фигня как RFC768 (из разряда, а мужики то и не знали)...
3) В RFC написано... This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. Это из описания собственно. сэнд мэссэдж - собственно передача сообщения. ПЕРЕДАЧА. Не буфферезирование, а ПЕРЕДАЧА. Конечно-же можно как угодно трактовать слово "сенд".... но вот так вот написано само определение.
4) Про обработку ошибочных ситуаций не было речи - не теряйте фокус... Естественно речь идёт об успешном ответе при передачи UDP. Так вот, если стэк протокола ответит OK и при этом забуфферизирует данные и не разрешит MAC адресацию то собственно это уже будет не совсем UDP (по описанию)...

как то так
(круглый)

Автор вообще пользу из этого пустого спора вынесет?

Буфер один, а в LwIP же динамически память выделяется (в моем по крайней мере так) для каждого отправляемого/получаемого пакета

а дальше
udp_sendto -> udp_sendto_if-> ip_output_if-> ip_output_if_opt-> (netif->output)
там уже где-то Low_level_output(..) где копируется в ДМА буфера.
Можно отследить эту ошибку "err =", но это только гарантия того, что данные передали для ОТПРАВКИ. А дальше они уже улетят так же (как говорили выше) как в UART

автор забыл про отпуск перед написанием вопроса и ушел туда но уже вернулся :-)

Вопрос именно про конкретную реализацию а не про сферический в вакууме RFC. Что сейчас наблюдается: используя udp_sendto раз в секунду посылается 28 пакетов. Пробовал как подряд в цикле так и с паузой 20-200 мс. Но глюк один и тот же. Иногда последний пакет из пачки задерживается и приходит как первый при начале посылок за следующую секунду. Задержка именно в LwIP, смотрел траффик по Wireshark. Так что где то внутри буферизация есть и возврат из udp_send не означает физическую отправку пакета. Собственно вопрос тот же, как правильно отправлять последовательность пакетов по UDP используя LwIP?

Спасибо.