Так проще всего не разобравшись (стоило только более внимательно прочитать все предыдущие посты, чтобы понять - о чём идёт речь) сказать, что это "мрак". Оба варианта примерно одинаковы и просты в реализации, Вам нравится Ваш, мне - мой.


В чем собственно непрофессионализм - в использовании Linux? Вы сначала попробуйте принять примерный поток на ПК под управлением Windows - потом будете говорить о непрофессионализме.



На данный момент никак не связан со студенческими курсовыми, поэтому не могу знать что именно может претендовать на зачёт и т.д., говорил только о том, что знаю и что работает в реальных системах. Это допустимо даже в очень нестуденческих проектах. Нет необходимости использования TCP для передачи данных от АЦП для дальнейшей обработки.


Если Вы так опираетесь на стандарт, с которым никто и не спорит, тогда посмотрите ещё и на длины соединений между отдельными узлами сети для которых этот стандарт выполняется, на прохождение данных через всевозможные сетевые устройства. Я точно могу сказать на каком расстоянии друг от друга находятся блоки системы (это не киллометры и даже не сотни метров), через какое количество коммутаторов должны пройти данные, могу проверить работоспособность системы, процент потери пакетов и на основании всего этого сделать заключение - UDP вполне подходит для данных целей.

FIFO
1. Размер отправляемого пакета - любой задается через порог фифо не пусто. В любой момент можно изменить, даже на лету.
2. Число буферизуемых пакетов без потерь - ограничен только объемом памяти, число пакетов меняется на лету с их размером
3. Потери памяти (используемая физически, но не используемая для хранения данных) 0. Все пакеты лежат друг за другом байт в байт, выравнивания не требуется
4. Адрес чтения данных - один
5. Автомат управления адресом чтения - отсутствует

Вариант с 2 буферами
1. Размер отправляемого пакета - минимум ограничен заполняемостью буфера, если поставите 1 байт то оба буфера будут забиты. Второе ограничение ширина шины адреса, она определяет максимальную длину пакета
2. Число буферизуемых пакетов без потерь - 1. Чтобы их стало больше необходимо ставить еще блоки памяти. Усложнять мультиплексор выбор блока. На лету изменить с изменением размера пакета невозможно.
3. На каждый буфер вы используете один брам 18К, весь хвост 18К - размер пакета у вас не используется.
4. Адрес чтения пакета сменный, и зависит от размера пакета, с изменением размера пакета необходимо менять диапазон адресов
5. Необходим автомат управления адресом при чтении очередью, либо программные циклы с инкрементом

Достаточно или есть еще вопросы почему FIFO однозначно лучше? 2 буфера - решение для простоты, но если есть готовое FIFO надо брать его и использовать.



Нет, непрофессионализм - это на основе своего частного мнения и конечного числа экспериментов выдвигать нарушающие стандарт утверждения.



В очень не студенческих, но крайне плохих проектах. Проблема не в использовании UDP, проблема в неправильном его использовании. Кто мешает в UDP пакет вместе с данными положить заголовок с определяющий положение данных? Нет необходимости крутить тяжелый ТСР, но считать что UDP пакеты всегда будут идти друг за другом и никогда не потеряются - преступно!


Потому можете сколько угодно трясти готовыми проектами которые так работают. Я не изменю своего мнения. Проект построенный на таких допущениях - барахло!

Вы, как всегда, не так поняли, я не выдвигал нарушающих стандарт утверждений, я всего лишь сказал, что для решения поставленной задачи UDP будет вполне достаточно и качество передачи данных будет достаточно надёжным. Сама система приёма/передачи данных реализовывалась с помощью советов знающих людей с данного форума (за что им и спасибо), которые уже проходили этот путь. Так что утверждать о субъективном мнении и ограниченном числе экспериментов не стоит.

Ваша оценка здесь неуместна, другие люди решают хорошо оно сделано или плохо. Заголовок для данных используется, но он не помогает восстановить данные, просто используется как информация о потере данных и всё.

Про допущения я уже всё пояснил, читайте пожалуйста внимательней. Мне кажется, лучше "трясти" готовым, что работает и проверено, чем голословно без всякой проверки утверждать - всё очень плохо (замечал такое за Вами).

Размер отправляемого пакета известен заранее, можно выбрать необходимый размер RAM или FIFO для хранения необходимого количества данных. Менять размер накапливаемых данных в сторону уменьшения возможно в обоих случаях,
в сторону увеличения везде столкнёмся с ограничением, которое задали при создании IP-ядра. Но в изменении длины накапливаемых данных и нет необходимости. По поводу того, что два буфера памяти могут заполниться одновременно,
объяснять Вам не буду, читайте выше. С шиной адреса тоже проблем не вижу, естественно, закладываем такую, чтоб обеспечить адресацию всех накопленных данных.

Хранение/передачу данных в обоих случаях можно организовать без потерь, объяснять как Вам не буду, смотрите выше.

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

Один раз выбирается длина данных с которой хотим работать и больше ничего менять не надо.

Вы опять о чём-то своём. Говорим DMA адрес буфера данных и на этом наше участие в формировании адресов заканчивается, для FIFO DMA не инкреметирует адрес, для RAM - инкремитирует. Всё просто в обеих случаях.
Если процессор использовать то цикл чтения будет и для FIFO и для RAM, для вычитки RAM ещё можно memcpy использовать и тогда совсем никаких циклов не видно и адрес инкреметировать не нужно.

Все Ваши доводы неубедительны.