2013-09-24 3 views
0

Я разрабатываю высокоскоростную видеокамеру высокого разрешения для приложений для робототехники. По различным причинам мне нужно принять гигабитный ethernet (1Ge) или 10Ge для подключения моих камер к ПК. Либо мне, либо мне нужно разработать свою собственную PCIe-карту, которую я предпочитаю не делать (больше работы, плюс тогда мне придется создавать драйверы).Требования к низкому уровню для рамки ethernet в linux

У меня есть два вопроса, о которых я не уверен, после чтения документации по Linux.

# 1: Мой желаемый кадр Ethernet является:

8-byte interpacket pad + sync byte 
6-byte MAC address (destination) 
6-byte MAC address (source) 
2-byte packet length (varies 6KB to 9KB depending on lossless compression) 
n-byte image data (number of bytes specified in previous 2-byte field) 
4-byte CRC32 

Вопрос заключается в том, будет Linux принять этот пакет, если приложение сказать Linux ожидать AF_PACKETs (предполагается, что приложения могут сказать линукс это)? Это приемлемо, если приложение, которое управляет камерой (отправляет ей пакеты) и получает данные изображения в пакетах, должно выполняться с правами root.

# 2: Какой будет быстрее:

A: linux sockets with AF_PACKET protocol 
B: libpcap application 

Скорость имеет решающее значение, так как пакеты будут прибывать с небольшим пространством между ними, так как каждый пакет содержит один горизонтальный ряд пикселей в моем собственном формате сжатия без потерь (если Я могу найти лучший алгоритм, который также может быть реализован в FPGA в режиме реального времени). Между кадрами будет пауза, но это будет после 1200 или более горизонтальных строк (пакетов фреймов Ethernet).

Поскольку приложение является робототехникой, каждая горизонтальная строка будет немедленно распакована и сохранена в простой упакованном массиве из RGBA-пикселей, как и OpenGL принимает как текстуры. Таким образом, программное обеспечение робототехники может сразу же проверять каждое изображение, поскольку изображение поступает по строкам и, возможно, реагирует так быстро, как бесчеловечно.

Данные для первого пикселя RGBA в каждой строке сразу же следует за последним пикселем RGBA в предыдущей строке, поэтому в конце последней горизонтальной строки пикселей изображение завершено и готово к передаче на графические процессоры и/или сохранение на диск. Каждая горизонтальная строка будет кратной 16 пикселям, поэтому «отступы» не требуются.

ПРИМЕЧАНИЕ. Камера должна быть подключена непосредственно к разъему RJ45 без маршрутизаторов или других устройств между камерой и ПК.

ответ

0

Думаю, вам придется изменить формат фрейма Ethernet, чтобы использовать первые два байта после MAC-адреса источника и dest как тип, а не длину. Длина старого стиля должна быть меньше 1536, вместо этого все большее значение рассматривается как поле типа IEEE. Поскольку вы хотите 6K или более, есть вероятность, что получатель Ethernet-чипа/Linux-пакета обработает ваши фреймы, потому что они плохо отформатированы.

Что касается исполнения, Золотое правило является мерой, не угадывайте. Выберите тот, который прост для программирования и попробуйте.

Надеюсь, это поможет.

+0

(На самом деле это «меньше 1500», значения в диапазоне от 1501 до 1535 недействительны вообще - я предполагаю, что 1536 было выбрано в качестве первого действительного значения типа, поскольку оно равно 0x0600 на аккуратной шестигранной границе.) –

+0

" Поскольку вы хотите 6K или более, есть вероятность, что получатель Ethernet-чипа/Linux-пакета откажется от ваших фреймов, потому что они плохо отформатированы ». Предположительно, ссылаясь на то, что спецификация Ethernet говорит, что максимальный размер кадра составляет 1518 байт, включая заголовок Ethernet и FCS; большинство адаптеров Ethernet, как вы заметили, вероятно, отбросят рамки, большие, чем плохие, поэтому вам нужно будет включить поддержку «jumbo frame» для адаптера (и использовать адаптер, поддерживающий большие рамки) для этого приложения. –

+0

Почему было бы проблемой включить «jumbo frames»? – honestann

Смежные вопросы