Здравствуйте! Понадобилось реализовать "быстрый" канал по Ethernet на str912. Нашёл много упоминаний о openTCP, lwIP, даже какие-то тестовые результаты скорости по TCP. Однако нигде не нашёл исходников используемых портов. (общий C код есть, однако хочется с примерами на конкретном железе). Кто может поделиться такими реализациями? (обязательное условие - без операционки).
Заранее благодарю.

NicheLite, на ST не сгодится?

Как у него со скоростью? Может и сгодится

Скорость - понятие весьма относительное. Опишите свою задачу, тогда люди что-нибудь дельное посоветуют. Описание типа "погуще, потолще, посильнее" не годится.

Порты относятся к опарационкам, вы же хотите без нее, так какой тут порт ?, для LWIP нужен только драйвер для MAC контроллера и все. Примеры есть на сайте ST но они не оптимизированные. И какую вы хотите скорость от STR912? 100% загрузки канала на TCP не получите, максимум 60-70% это на чистом стеке, тобиш проц ничего не делает кроме обслуживания стека и пакеты гоняет в никуда в одну сторону, чисто на чтение загрузка канала порядка 85% - 90% но принятые данные никак не обрабатываются. Также пропускная будет зависеть от количества выделенной вами для стека памяти.

Прошу прощения за неточность формулировки. я имел ввиду именно стэк с драйвером и всеми настройками типа DMA и т.д.

Задача проста: нужно взять из Ethernet поток и запихнуть его в EMI с максимальной скоростью... и соответственно наоборот из EMI запихнуть поток в Ethernet. Предполагаю обрабатывать пакеты в прерываниях соответствующих и заряжать там DMA. Процессор никакими рассчетами не занят, памяти тоже свободной хватает. Так что хочется найти пример максимально быстрого стека практически не замарачиваясь на ресурсы... Максимальный размер пакета в ethernet спецификации вроде 1.5к, значит на него не нужно много памяти... Обрабатывать как-то параллельно что-то или вроде того не планирую вовсе. Кроме того хочу сгребать все tcp пакеты, независимо от порта. Вобщем есть что упростить и прооптимизировать...

Из довеска к TCP нужно только DHCP.

Это, простите, как? TCP соединение устанавливается между двумя конкретными портами.

Очень просто: "слушать" сразу все порты т.е. 1024-65535 и обрабатывать их одинаково...

А смысл какой открывать до 64K соединений?

Никто не собирается открывать 64к соединений, соединений будет не более 2х. Однако какие порты при этом будут участвовать - не важно. т.е. это будет сервер, который будет доступен по любому из портов протокола TCP.
Грубо говоря это просто некий широкий канал обмена между другими частями системы (которые висят на EMI) и PC.
При этом поскольку EMI у нас всего 1, то и соединений нам много не нужно.

Сомнительное "упрощение", ну да ладно.


Так может и TCP не нужен, если нужна скорость, а PC рядом? Накрутите просто свой протокол поверх UDP.

Свой протокол поверх UDP не хочется городить т.к. тогда понадобится писать драйвер для этого сетевого устройства, иначе программисты PC будут ругаться, плеваться и т.д. Хочется что-то стандартное, возможно упрощенное. Да и в целом TCP достаточно удобно сделан для соединений с гарантированой доставкой: вроде бы ничего лишнего. Однако в моем случае можно будет ещё упростить его тем, что пакеты будут приходить в верном порядке.

+1
Если все происходит в одной физической локальной сети, без маршрутизаторов. TCP точно не нужен. UDP сэкономит и время и место.
В TCP много лишнего - измерение скорости канала и т.п. что в локальной сети абсолютно лишнее.

Если "программисты PC" плюются, когда слышат о непонятном протоколе UDP, то значит это совсем даже не программисты.


Если все же решите использовать TCP, то лучше воздержитесь от таких "упрощений" хотя бы на начальном этапе.

Нет, я имел ввиду не UDP непонятный, а надстройка будет самодельная и из-за неё будут проблемы.
Ну, раз все настаивают - буду лобировать сей вопрос завтра

Но всё-таки хотелось бы получить ещё и lwIP, openTCP примеры для STR912

Конечно! Если у вас пакет проходит по разнородным каналам с разной скоростью и MTU, через маршрутизаторы...
То да - ничего лишнего там нет

Это как-бы это помягче, не упрощение, а чистый геморрой своими руками . Просто Автор имеет совсем поверхностно-идеалистические представления об TCP/IP. Для начала даже самую общую задачу не сформулировал



Или наоборот - еще бОльшие проблемы из-за TCP.

А какими средствами достигается контроль такой сложной системы? просто номер пакета и ACK. Звучит круто, а реальных накладных расходов на это не так уж и много... Сложно следить сразу за кучей соединений и процессов, которые хотят достучаться до сети, а когда нужно соединение типа точка-точка (но, правда, через некоторое количество коммутаторов), то большинство проблем и накладных расходов не требуется...

... особенно, когда, например, через многие десятки секунд программисты на PC узнают, что все,что они посылали никуда не дошло.
Ну а на контроллере обратный канал будет забиваться ACK а неподтвержденные придется буферизировать и перепередавать, не забывая о том, что новые сыпятся. Для сколь-нибудь реального времени TCP это хреновое решение и даже не из-за стороны контролера (где можно поработать, хотя Вы хотите готовую халяву ), а из-за стека на PC (хоть Win, хоть Lin) и обработки ошибок на низком уровне, на которую все, начиная с разработчиков драйверов, забили - пусть TCP все разгребает, как может.

Это да. Помнится, лет восемь назад мне очень изрядно попортила кровь реалтековская сетевая карта со своими замечательными драйверами - внутри ethernet-фреймов периодически проскакивали пары нулей: <данные пакета><00 00><продолжение данных пакета>. Стоит ли говорить, что причину возникновения этих нулей я очень долго пытался найти у себя. Случайно только обнаружил, что при подключении к этой карте другого компьютера на нем подозрительно начинает ползти счетчик ошибок контрольных сумм TCP-пакетов.

И ведь действительно разгребает и вытягивает

Я хочу не найти готовую халяву, а взять "стартовую точку" повыше... Естественно придётся всё самому дорабатывать и корректировать, онако с чего-то начинать нужно.

Тут, эээ...., дело такое, чем выше точку возьмете, тем в большем количестве мусора придется разбираться, сносить, выносить сор....
Вам хочется быстрее устроить "праздник первого пинга"? Ну так возьмите первое попавшееся под руку.
А для приличного, по любому начинать придется медленно и печально с того-же железа, ибо, не знаю, правда, какая ситуация с STR9xx, но по ~20летнему опыту работы с разнообразнейшии MACами, 99:1, что ничего приличного для высокопризводительных решений, даже для уровня драйвера в интернете нет .

Я себе всё примерно так и представляю, однако, ввиду малого опыта конфигурирования STR912 (а на мой взгляд конфигурирование у него до жути корявое), мне нужно что-то на чём всё править. Т.е. собираюсь взять готовый драйвер, готовый стек (хоть сколько нибудь пригодный для правок), запихнуть в уже существующую программу. Далее первый этап оптимизации - изменение драйвера на свой толк: DMA, прерывания по фрэймам и т.д.
Если при этом у меня не будет стека будут трудности с проверкой этого дела. Снифер конечно поможет, но всё-таки могут выясниться попутно какие-то ограничения на переделку драйвера. Вобщем хотелось бы править "на живую", чтобы не пришлось потом всё переделывать, когда в конце пути выяснится, что изначально в концепции была ошибка где-то...

Так это только оверхед по данным в пакете!!!
По такому подходу вы и можете сделать протокол повер UDP - и все будет просто и бытсро работать!
А в TCP все намного сложнее почитайте про -
медленный старт
алгоритм нагла
выбор размера окна...
таймеры, которые использует TCP

Пожалуй соглашусь всё-таки... буду делать свой протокол поверх UDP. Всем спасибо!