Всем привет!
Задача, понятно, не новая. Нужно непрерывно передавать пакеты UDP напрямую из одной точки А в точку В через LAN91C111, который входит в DK-NIOS. У меня, конкретно, DK-NIOS-2S60N (точка А), а компьютер (точка В) на расстоянии не дальше 50 метров.
Склоняюсь писать свой soft для LAN91C111 на основе hard-примера, из серии NiosII_standard, т.е. не применяя uC/OS-II и NicheStack. Отмечу только, что как пример веб-сервера, DK-NIOS работает нормально, но разобраться в пакете программ uC/OS-II и NicheStack и применить их под свою задачу не удалось.
По этому стоя у начала этой дороги, хотел бы спросить, что ждет там впереди, у тех, кто уже по ней возвращается (оборот мною заимствован). То есть, хотел бы знать, как эти и подобные проблемы решали другие.
Спасибо за ответы.

Ну если с uC/OS-II и NicheStack у вас всё плохо было, то значит и с ecos(rtos +tcp stack любой другой) тоже будет плохо
Если же у вас точки А и В не будут менять "своё положение" - IP адреса, подсеть и т.д., то всё хорошо
в этом случае стек думаю и не нужен будет. Но такое решение - "решение для одного дня"

To Postoroniy_V
Спасибо за ответ. Ethernet-100 нужен однонаправленный, непрерывный с максимальной скоростью, в обратном же направлении он используется, но редко. До этого была плата с PCI-интерфейсом, а теперь нужно вынести все аналоговые узлы из системного блока, уж очень много там помех: АЦП на 20МГц и 8 разрядов уже не хватает, требуется АЦП 40МГц на 14 разрядов. Да и аппаратной ЦОС хватит на долго.
В проблеме Ethernet-100 смущает то, что, в тексте основного Verilog-модуля, в данном случае NiosII_stratixII_2s60_RoHS_standard.v, обнаруживается следующее. У контроллера LAN91C111 есть достаточно много входов управления (см. например, стр.2-13 в mnl_nios2_board_stratixII_2s60_rohs.pdf), но в списке входов-выходов основного модуля часть этих управляющих входов не значится, они как бы висят в воздухе, но управлять то ими все равно надо, если софт писать самому. В то же время готовые тестовые программы «Web-Server» и «Simple Socket Server» на данном DK-NIOS успешно проходят, но это при работе в uC/OS-II.
Думаю, LAN91C111 применяется во многих DK-NIOS, да и аналогичная задача с точками А и В уже наверно встречалась. Как и каким способом ее решили? Только ли с помощью OS и стеков?

У меня схожая задача и я тоже реально присматривался к DK-NIOS в качестве отправной точки для проектирования. Результаты неутешительные. Если с OS, стеком, да и вообще с NIOS, то конструкция становится похожей на быстродействующий микропроцессор с внешним MAC и PHY. Как показали испытания таких микропроцессоров, реально в 100Mbps сети по UDP удается предавать не быстрее 30Mbps. Много времени сжирает софт. Поэтому пришел к решению вести передачу данных RAW пакетами, без IP протоколов, стеков и OS. Hо в этом случае, FPGA и LAN9111 для 100Мbps не требуется. Вполне достаточно кристалла на базе ARM9 со встроенным MAC. Hапример, STR912FA за $14 может отсылать данные со скоростью 80Mbps с использованием RAW пакетов. Если же в нем использовать IP стек, OS, короче стандартный вариант, то получите по UDP не более 30Mbps. Т.е. вполне реальная альтернатива FPGA c NIOS. Зачем тогда, спрашивается, городить огород на FPGA?

To Aprox.
Спасибо за ответ и свои соображения. Мы тоже долго блуждали по поводу выбора архитектуры комплекса, в конце-концов остановились на упомянутом DK-NIOS, а он еще будет работать в связке с LM3S6965 Ethernet Evaluation Kits http://www.luminarymicro.com/products/kits.html Вместе они будут вести первичную обработку, а с противоположной стороны будет несколько компьютеров для вторичной обработки. Почему именно DK-NIOS, потому, что там, в FPGA нужно будет размещать еще много аппаратной ЦОС. А выбор в пользу покупки уже готовых плат связан со слабой конструкторской базой, да и время поджимает. Да, цены этих плат 1000 и 100 баксов, соответственно.
По поводу RAW пакетов, это как я понимаю чистые Ethernet пакеты и работа на MAC-уровне с собственными программами?
По поводу LAN91C111 дело сдвинулось, обнаружил, что внутри DK-NIOS этот контроллер включен по схеме ISA-Bus, и самое главное, что при обращении к нему, нужно к базовому адресу LAN91C111_BASE прибавлять смешение 0x0300 (основная особенность ISA). Жаль, потерял на это несколько дней.

У меня тоже схожая задача правда я пока не могу решить делать с НИОСом, Микроблейзом или еще как-нибудь. Желание использовать FPGA а не Микрик обусловлено тем, что надо кроме выдачи данных по езернет делать еще кучу всякой работы и при этом иметь макисмальную гибкость. А для конечного устройства микрик наверное лучше будет и дешевле

Да, в предельно простом случае это чистые Ethernet пакеты. Адресация ведется по физическим адресам. Для LAN9111 никаких особых софтов не потребуется, надо лишь правильно записывать его регистры подсовывать данные. Hа стороне компьютера для виндов потребуется, например, библиотека WinPCap. Для линукса ничего не потребуется.

Ну хорошо что у Вас разрешилось с lan91c111
os и стеки дают "приятную гибкость" , но мне не ясно почему ос и стек помешает отсылать raw пакеты, и тем более не ясно кто и что мешает использовать dma в ниосе?
Тоесть, если нет знакомства с осью и стеками и дровами для езера и т.д., я уже писал Вам что ваше решение - "решение для одного дня". И раз ещё проблема со сроками, то делайте безо всяких осей и стеков.
Как бы там ни было, Вам решать.
Удачи в реализации!

Да, режил делать без осей и стеков, сейчас этим и занимаюсь.

Не совсем ясна идея применения здесь dma.

Здесь пока колебания между raw и udp. Параллельно со мной работает программист на Delphi, пока он связывает напрямую два компа, один из которых потом заменит DK-NIOS. До этого он под виндой работал с raw, а сейчас перешел на udp. Обнаружил, что в последнем случае скорость стала выше раз в пять, т.е. сейчас для udp около 75Мбит для Eth-100, даже через LAN.

Что-то я уперся в проблему структурирования иерархического проекта на Си в среде Nios II 7.2 IDE. В других средах (IAR и Keil) для МК это проблемы не вызывало, а здесь головная боль. Т.е. есть Си - main и куча подчиненных *.c, которые записаны в main через #include. Далее их нужно подключить-определить в проекте еще и через IDE, и здесь все начинается. Хелры что-то не помогают. Особенно достают глобальные переменные, которые я хочу описать в отдельном файле. Кто-то сталкивался?

1)идея юзать ДМА в том чтобы передачей сырых пакетов из ОЗУ в ЛАН91Ц111 занимался не проц.
2) есть майн, хочется ещё 1 модуль в другом файле определить, создаём файл в ИДЕ, или если он есть переписываем в директорию и жмем рефреш, после это маке файл изменится. затем создает хедер файл с функциями те что определены в этом новом модуле....всё вроде просто и ясно и ОЧЕНЬ очевидно
я честно сказать даже не ожидал что это такая проблема - добавить новых модулей и обьявление новых глобальныз переменных

Ситуация с непрерывной передачей UDP-пакетов с использованием LAN91C111 под управлением Nios II(fast) наконец-то разрешилась. Выдаю из DK-NIOS-2S60N, а комп принимает.
Пока достигнута средняя скорость около 21 Мбит/с, это для полезных данных (payload).
Драйвера на Си писал сам. Смущает то, что в LAN91C111 нельзя загружать в буфер следующий блок, пока не будет выдан текущий. Много времени тратится на вычисление CheckSum для UDP, наверное, придется использовать для нее аппаратную акселерацию, а также переключаться на DMA между памятью и LAN91C111.

имхо плохой у вас драйвер :-)
тут читайте как сделать хороший(PDF!)
http://www.smsc.com/main/anpdf/an96.pdf
страница 63 Enqueue packet into TX fifo

Спасибо за ответ!
Я уже использовал в работе документ an96.pdf. Мне не ясно, зачем Вы указали на этот пример "Enqueue packet into TX fifo" на стр.63, ведь он описывается в главе 9.10, посвященной конкретно серии тестов для MMU.
Я отталкивался от главы 9.3 "Transmitting A Packet", что на стр.59.
Весь вопрос в том, что запись следующего пакета в TX FIFO нельзя делать пока из MMU не будет полностью выдан текущий пакет, для этого и в "Enqueue packet into TX fifo" и в "Transmitting A Packet" в конце есть команда "Poll for TX INT" для ожидания флага конца выдачи.
Почему-то мне нигде не попадалась описание-объяснение процесса одновременной выдачи и загрузки в FIFO для LAN91C111. Это не возможно?

такой вот вопрос к вам возник - а какого тогда спрашивается нужно 8 кб для буффера, и накой черт нужен этот мму? если по вашему получается
что запись следующего пакета в TX FIFO нельзя делать пока из MMU не будет полностью выдан текущий пакет, для этого и в "Enqueue packet into TX fifo" и в "Transmitting A Packet" в конце есть команда "Poll for TX INT" для ожидания флага конца выдачи.
и кстати пакет выдается не из мму
зачем все эти навороты? ведь можно было ограничиться 2 кб для передачитка и успокоится на этом

по ipv4 контрольная сумма для UDP необязательна, так что на ней можно сэкономить

Согласен, что можно, но по ТЗ требуется CheckSum считать...


Не имею ничего против LAN91C111, но если бы возможность одновременной выдачи по TX и записи в FIFO при его 8кб существовала, то это очень важное качество было бы где-то описано. Не считаю себя новичком, чтобы не заметить такого (за плечами CS8900 и KSZ8841).
А по поводу CheckSum хочу применить Custom Insrtuctions (плюс еще DMA), а с освоением C2H придется подождать до лучших времен.

ну что же отлично , тогда напрашивается вывод, что 8 кб, мму и алгоритм в ап96 на 63 стр 6.Enqueue packet into tx fifo это так для смеху