Исправить
Пакет - это одна UDP datagram'а, желательно размером не больше Ethernet фрейма (за вычетом заголовков Ethernet/IP/UDP). Т.е. около 1-1.5К (Можно меньше)

Если N=4, этого будет достаточно как Вы думаете ?
5 буферов по 1-1.5к найдутся во внутренней памяти.

А это зависит от параметров вашей сети и требований на задержки при передаче данных.

Возможно их понадобится раза в 2 больше Или придется делать весьма нетривиальные алгоритмы по перераспределению буферов в процессе приема/выдачи на ЦАП.
Кроме того, надо предусмотреть управление скоростью потока передаваемых данных - она должна строго совпадать с скоростью выдачи данных на ЦАП.

В общем задача не простая

Немного расширили мою тему)...
Товарищи, я ищу для микроконтроллера серии stm32F подходящий стек TCP/IP, погуглив налел неплохую статью по поводу стеков для этих микроконтроллеров.

Имеются стеки :

Производитель - Стек

1) CMX Systems - CMX-TCP/IP
2) Express Logic - NetX
3) IAR - PowerPac TCP/IP
4) InterNiche - NicheLite
5) Keil - RL-TCPnet
6) Micrium - uC/TCP-IP
7) Micro Digital - smxNS
8) RTXC-Quadros - RTXC
9) Segger - embos/IP

В большинстве случаев стеки могут идти отдельно от ОС...
Дело в том, что стек нежен на ОС, использоваться будет возможно в коммерческих целях. Выходит плясать у выборе стека нужно исходя из операционной системы, которая будет использоваться. Если кто-то может, что-то посоветовать пишите. Так как для проекта будет использоваться ОС, то разумеется он будет не простым, планируется реализация http и lftp. Хотелось бы реализовать проект на условно-бесплатной ОС , а стек докупить...но на сколько я понял все высшее перечисленные ОС есть платными...

Сообщение отредактировал Twen - Sep 9 2011, 11:56

Ну я предполагал два буфера - в один идет прием, с другого выдача в ЦАП.




Тут не очень понятно. Я предполагал так:
- скорость приема больше скорости выдачи в ЦАП
- принимаем с LAN в один буфер, и останавливаемся по его заполнению.
- со второго буфера выдаем в ЦАП.
- когда все выдали, переключаемся на выдачу с первого буфера
- прием с LAN преключаем на второй буфер и начинем прием до его заполнения.
- и так по кругу.

Если требуется какая-то обработка, то понадобится 3 буфера: в первый принимаем, по заполнению переписываем с обработкой во второй, из третьего выдаем в ЦАП. Потом 2-й и 3-й меняются местами.
Т.е. 1-й буфер понадобится размером с "сырые данные" (до исправления), 2-й и 3-й - размером с "чистые данные".
Гнать в ЦАП можно без участия CPU - по DMA, с автосменой буферов (LLI) и прерыванием по их смене.

Или сервер будет тупо передавать пакеты, невзирая на клиента, и его не "поставить на паузу" ?
Я как уже говорил, мало понимаю в TCP/IP, но мне казалось там есть какое-то подобия квитирования.

Именно.
В TCP есть, в UDP нет.

Значит, UDP не годится.
Но как-же тогда работают вообще протоколы пеердачи на основе UDP? Они предполагают, что приемник "всегда готов" Т.е. что он заведомо быстрее передатчика ?

Они ничего не предполагают
Да

Не совсем. Либо скорость потока данных определяется именно передатчиком (как во всяких multimedia стримерах), либо вводят синхронизацию скорости в протокол

Значит отнозначно TCP - в этом проекте квитированием и скоростью (которая может быть и раной) должен рулить МК.

На что основное стоит полагаться при выборе API для LwIP. Реализация примеров приложений верхних уровней с использованием LwIP под stm32f207 на FreeRTOS сделана на 2 разных API:

- Netconn API is a high-level sequential API that requires the services of a real-time
operating system (RTOS). The Netconn API enables multi-threaded operations.
- BSD Socket API: Berkeley-like Socket API (developed on top of the Netconn API)

Какие можно выделить преимуществе одной по отношению к другой?

Netconn API - это родное API в LwIP
BSD Socket API построено поверх Netconn API

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

Спасибо за внятное разъяснение. На сколько я знаю BSD soket используются в ОС Unix и как бы для большей унификации иногда поверх определенного иного api(в нашем случае Netconn API) пишут еще один уровень API, к которому будут привязываться (в нашем случае BSD Socket API).
Теперь стало понятно зачем в демке есть два примера под разные API.
Я не работал и не привязываюсь к каким-то модулям программы, в которых используются BSD socket. По этому с целью экономии ресурсов(памяти) действительно лучшее выбрать Netconn API.