Да, забыл: весьма вероятно, что драйвер тупо игнорирует ошибку и не передаёт код наверх. Часто эти драйверы пишут левой ногой. Так что попробуйте в нём разобраться.

ОНО самое!!! Функция udp_send утыкается в функцию low_level_output() (порт STM32).

В общем ждать она не ждет, и всегда отсылает ОК.
Увеличил размер буфера до 1200 байт, чтоб мой килобайт влез, и не надо было разбивать его на части. low_level_output() научил для начала возвращать ошибку. Стало почти хорошо. пакеты теряются один раз из 6 000-10 000, но сразу по несколько. Итого на 100МБайт теряется 100-200К. Поток 93 Мбит\сек.

Если это видео может как то сжимать его перед отправкой.

Да не. С исправленным драйвером вроде все ОК. около 90Мбит\с выдает без потерь.

а всё-таки, только так? Вызвать udp_send и проверять по коду ошибки? Может, есть какой-то флаг готовности?
Посмотрел свой low_level_output, проверка есть: пытается распихать в пакет по буферам DMA и при невозможности возвращает ошибку. Конкретно в моём примере выделено 4 буфера размером 1524 байта. Значит, больше никак не узнать, только проверять есть ли место.
Может кто разбирался, еще вопросик: эти 4 буфера под 4 ЛЮБЫХ пакета? 4 пакета по 1500 байт, или 4 пакета по 100 байт...

Сообщение отредактировал TU-104 - Apr 14 2016, 12:34

согласно RFC функция передачи юдп гарантирует отправку. Т.е. если вам вернули код ошибки ОК - то пакет гарантировано дошёл до трансформатора
Вашего передатчика. Так по стандарту.

Буфера - тут такое дело. По идее размеры резервирования прописываются в конфигураторе(как тут уже прозвучало). Т.е. зарезервируете 4 по 1000 = будет всего 4 кила.

С буферами в основном засада на приёме. Выделять память в драйвере - накладно очень. Но можно а) использовать заголовки ПДП старые
б) делать резервирование таких блоков - для драйвера.

(круглый)

Ну-ну. Осталось понять, читал ли аффтар кода эти стандарты. Угадайте, каковы шансы?

когда писал - хотел дать мысль, что реализация реализацией, но существует стандарт пользовательского(с точки зрения стэка) интерфейса.
А прочтёт если захочет по уму, от печки.

ну где то так
(круглый)
ЗЫ
Элемент иронии если только чуть-чуть

Неее, никто такой гарантии не даст, что прям до трансформатора дошло. В примере lwip stm32 - дошло да DMA и всё, а там в MII. А там еще физика....


Поотправлял пакеты, похоже, что там(всё в том же примере драйвера) на 4 кадра зарезервировано(не важно какого размера кадр).


А что такое ПДП? На приёме в драйвере аналогично организовано 4 буфера, каждый на 1 кадр, максимальный размер ~1500.

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

если присмотритесь как устроено(STM32F4xx), то там выделяются заголовки описательные(которые ставятся в очередь dma) и сами буфера выделенные под это дело.
причём на приёме автоматически разруливается наполнение этих входных буферов поставленных в кольцо. И Вы при анализе выбираете только те, которые обозначены как
уже отработанные. По коду ошибки и состоянию флагов Вы имеете цепочку пакетов с полезными данными(либо один пакет - не суть). Вам требуется
заменить эти буфера - вот именно в этом месте Вам необходимо решать следующие задачи - тупо копировать данные, либо уменьшать объём
буферов на приёме, либо заменять на новые освободившиеся блоки памяти под буфера.
Лично сам тупо заменяю блоки памяти. А беру их из специальной очереди для драйвера. Заполненные буфера - так и уходят на верхний уровень.
т.е. нет операций копирования совсем. А заголовки так и остаются стоять в кольце (после обработки естественно флаги им выставляем правильные).

как то так - давно рисовал, по памяти сейчас изложил.
(круглый)

Сообщение отредактировал kolobok0 - Apr 15 2016, 08:52