FPGA - Ethernet - PC, Как лучше организовать? Опции

[kst]

Ситуация
Нужно сделать железку (плату), которая могла бы общаться с ПК по Ethernet в целях передачи:
- управляющей информации из ПК в железку (менее 1 Мб/с);
- информации о состоянии железки в ПК (менее 1 Мб/с);
- полезной информации из железки в ПК (~10 Мб/с);
- больших объемов информации (в планах несколько ГБ), накопленных на плате, не в режиме реального времени из железки в ПК, по его запросу.
Для указанных целей вполне подходит 100 Мб Ethernet.
Ethernet выбран как достаточно скоростной интерфейс, позволяющий подключить к компьютеру несколько таких плат.
На плате единственный управляющий элемент - это ПЛИС. Ориентировочно XC5VSX50T. Никаких микроконтроллеров и процессоров не планируется.

Мнение
Один из подходов в такой ситуации: использовать внешний (для ПЛИС) трансивер Ethernet физического уровня и встроенный в ПЛИС MAC-контроллер.
Я так понимаю, имея в руках только кадр MAC-уровня, многого не сделаешь - необходима реализация протоколов. К сожалению, пока не знаком с протоколами сетевого и транспортного уровней, поэтому не знаю всей сложности.
Хотелось бы услышать мнение тех, кто сталкивался с подобными вещами.

Вопрос
Реально ли вообще обойтись без каких бы то ни было микроконтроллеров/процессоров, имея только MAC-контроллер и программируемую логику, для организации обмена данными по сети?
Может быть существуют другие, более оптимальные варианты взаимодействия ПЛИС с ПК по сети Ethernet?

[ASN]

kst
Вопрос по ситуации: кроме FPGA вообще ничего нет? Всяких там FLASH, SDRAM и т.п.
Вопрос по мнению: а почему Вы не желаете использовать какой-нибудь MCU?
Дополнительный вопрос: все приборы будут работать в одной сегменте сети без выхода в другие сегменты?

[RobFPGA]

Приветствую!

Если требуется поддержка стека TCP/IP то совсем без подобия MCU обойтись будет сложно.
Но при этом сам MCU может быть частью FPGA. Для основных функций в принципе даже на ядре типа PicoBlaze (правда програмить только на асме) можно соорудить что-то поддерживающие медленный командный канал (ARP, ICMP , UDP управления и статуса). Большой поток данных при этом можно формировать аппаратно автоматом формируя например UDP пакеты. В свое врем я делал похожее на Spartan3-400 обработка данных с радиолокатора. Правда потом от внутреннего контроллера отказался - так как снаружи поставил ADuC841 в основном из за встроенных ADC,DAC. Выходной поток данных был до 6 Мбайт/сек.

Хотя если не хочется связыватся с MCU -
посмотри сдесь синтезируемый . TCP/IP stack VHDL

Успехов! Rob.

[sazh]

Если на киты посмотреть. Можно lan91c111 задействовать.
На входе например имитируете isa шину.

[:-)]

Тоже интересуюсь данной темой. Есть корыстный вопрос: Нет ли у кого рабочего примера примера посылки UDP пакетов (формирования кадра, расчёта CRC и т.д.) с помощью ПЛИС и микросхемы phy-уровня? И если есть, то могли бы вы им поделиться. Для тестов планирую использовать отладочную плату на spartan3e500.

[oval]

Вопрос
Реально ли вообще обойтись без каких бы то ни было микроконтроллеров/процессоров, имея только MAC-контроллер и программируемую логику, для организации обмена данными по сети?
Может быть существуют другие, более оптимальные варианты взаимодействия ПЛИС с ПК по сети Ethernet?

В данном случае, насколько я понимаю, потребуется достаточно развитое управление MAC уровнем в части приема/передачи/формирования пакетов, поэтому смотрите в сторону связки Microblaze (встраиваемое в ПЛИС процессорное ядро) + MAC + внешний PHY. При этом не потребуется никаких внешних управляющих микроконтроллеров и т.п.

[0xFF]

Доброго здравия!

Из моего личного опыта применения для связи ПЛИС и ПЦ наиболее оптимальным оказалось использование внешнего Ethernet PHY к плис и EthernetLite для микроблейза. (готовых примеров в сети предостаточно хотя бы на том же xilinx.com ) Организовывать различные виды tcp/ip стэков тоже конечно можно хоть софтов хоть аппаратно было бы желание, из личного опыта для опознования устройства компьютером можно приделать софтовую обработку ICMP и ARP пакетов , и UDP для связи а остальное просто игнорировать. Обмен по UDP вполне позволит просто работать с пакетами на Winsocketе.

Но вот лично моё мнение: если не нужно организовывать передачи данных в интернет, связывать устройство с удалёным сервером, а нужно только построить простой обмен данными, то
а) обмен данными просто на Ethernet Frame со своей удобной структурой что позволит софтово на микроблейзе быстро и со вкусом паковать и распаковывать пакеты и обойтись без упаковки в пакет с трудоёмкой CRC и т.д.
б)на стороне компьютера ставим всеми любимый winpcap и работаем через его сокет. C ними работают Wireshark бывш. Ethereal, кстати xilinx ставит его для организации Co-Simulation со связью с target по Ethernet
в) При всём этом, если всё аккуратно написать в плис, то 5-7Мбайт в сек получить вполне возможно

Успехов!

[CodeWarrior1241]

Тоже интересуюсь данной темой. Есть корыстный вопрос: Нет ли у кого рабочего примера примера посылки UDP пакетов (формирования кадра, расчёта CRC и т.д.) с помощью ПЛИС и микросхемы phy-уровня? И если есть, то могли бы вы им поделиться. Для тестов планирую использовать отладочную плату на spartan3e500.

Занимаюсь тем же самым. Единственное нО - ИС для phy-уровня содежит в себе и mac-уровень тоже. Пользуюсь WIZnet W5100 - http://www.ewiznet.com. Предыстория - меня попросили взять существущие тест-инструменты, и дать возможность управлять ими дистанционно, через TCP или UDP - им без разницы. Инструменты разработанны нами, и содержут ПЛИС который управляет разной фигней. Я беру схемы существующих плат с плис'ом, и добовляю W5100. Конкретно мне оказалось удобнее использовать TCP для этой задачи, и 10Mbs для меня достаточно. Пользоватся W5100 - совершенно примитивно, выставлять TCP/IP, UDP, keepalive, итд опции тоже легко. Рекоммендую, если у Вас нету жестких требованей насчет скорости.

[des00]

ИМХО от времени и условий все у вас зависит.

отлаживать логику протоколов класса TCP-IP на проце намного легче чем на фпга.

Если время ограничено и нет человека который вариться в кухне EDK/SOPC то поставте внешний арм(например LPC2478 + бесплатный ничи стек).

Если запас есть то освоите EDK, пригодиться (да и чип у вас толстый). На форуме кстати темы про TCP/IP на микроблейзе были.

Можно конечно использовать опенсорсный проц класса AVR, MSP430, но думаю что по затратам времени это эквивалентно освоению микроблейза ( правда совесть будет более чистой %) )

TCP/IP stack VHDL кстати синтезируемый но проверен авторами на 10 мегабит эзернете.

ЗЫ. Сам использую частично переписанную корку от Igor Mohor.

Удачи!!!

[druzhin]

Тоже интересуюсь данной темой. Есть корыстный вопрос: Нет ли у кого рабочего примера примера посылки UDP пакетов (формирования кадра, расчёта CRC и т.д.) с помощью ПЛИС и микросхемы phy-уровня? И если есть, то могли бы вы им поделиться. Для тестов планирую использовать отладочную плату на spartan3e500.

У меня есть отсылка пакетов со скоростью 30 Мб/с TCP, используется спартан3+wiznet3150. Кстати, тоже данные от радара. Весь интеллект уместился в фсм на 24 состояния, полученный переложением на верилог фирменных Си-исходников. Могу намылить верилог, схему и описалово.

[alexadmin]

- информации о состоянии железки в ПК (менее 1 Мб/с);
- полезной информации из железки в ПК (~10 Мб/с);
Для указанных целей вполне подходит 100 Мб Ethernet.

Не хочу показаться занудливым, но есть мнение, что 11 Мб/с через 100 Mbit ethernet может и не пролезть, особенно для протоколов верхнего уровня (могут начаться проблемы со стороны ПК). Я бы рассчитывал на 8-9 Мб/с как реальный максимум.

Сообщение отредактировал alexadmin - Apr 15 2008, 09:34

[kst]

Огромное спасибо всем ответившим!

Платка должна быть промышленного исполнения.
На плату планируется ставить оперативку и FLASH.
Никакого интернета и никаких серверов пока не планируется. Конечная система - 4 платы, свитч и 1 компьютер. Все.
Можно даже какой-то самодельный протокол обмена данными придумать, главное - платы уметь различать.
Хотелось бы узнать какой минимум нужно реализовать в ПЛИС, чтобы обмениваться данными между платой и компьютером?

По поводу Microblaze раздумываю, правда сей зверь мне знаком только понаслышке. Хотелось бы узнать, сколько ресурсов может уйти на его реализацию?
И вообще, можно ли как-то спрогнозировать, сколько от ПЛИС откусит все управление Ethernetом в лучшем случае???

Отдельный микроконтроллер ставить - это еще одна отдельная задачка. Плюс на плате придется потесниться. Но тоже, в принципе, вариант.

А вообще есть вариант покупки готовой промышленной процессорной платы с Ethernetом и USB на борту. Тогда нужно будет отлаживать взаимодействие 2х плат - платы с ПЛИС и процессорной платы - по шине, скажем, PCI. Эта задача мне вообще не знакома. Но может быть так проще будет?

[Дмитрий Мазунин]

Добрый день !
Мы пользуемся следующим набором:

HW - Virtex4FX, внутри PowerPC и железный MAC, собран MPMC3 и LL_TEMAC в режиме DMA, память DDR, системная тактовая и тактовая MPMC 100МГц, тактовая проца - 300МГц.

Стек - доработанная LWIP в режиме SOCKET API.

Передача - 80Мбит по 100Мбит линку.

Получали и 94Мбита при работе MPMC на 200МГц

[AndruB]

Может имеет смысл подумать над м\сх контроллера Ethernet совмещенного с процессором ? Например - Mcrel . Тогда Плис только поставщик информации и коммутатор шин, а управление и протоколы за процессором. Несколько смущает могучесть процессора (ARM9) для подобной задачи . но думаю можно найти и более подходящие варианты.

[CodeWarrior1241]

Может имеет смысл подумать над м\сх контроллера Ethernet совмещенного с процессором?

Так ведь это уже говорилось - можно micrel, realtek, я предложил wiznet... Варианты есть.

[ReedCat]

Тоже интересуюсь данной темой. Есть корыстный вопрос: Нет ли у кого рабочего примера примера посылки UDP пакетов (формирования кадра, расчёта CRC и т.д.) с помощью ПЛИС и микросхемы phy-уровня? И если есть, то могли бы вы им поделиться. Для тестов планирую использовать отладочную плату на spartan3e500.

Есть пример... Совсем тупой и без всякой PHY-микросхемы. То есть RxD и TxD заведены прямо на ПЛИС.
UDP-пакеты принмает/посылает. Больше не умеет ничего. Я с ним пока ещё плотно не возился (хотел к нему ARP-хотя бы прикрутить, чтобы не руками его регистрировать в ARP-таблице компа), время на другое сейчас уходит. Как вода в песок.

[:-)]

Есть пример... Совсем тупой и без всякой PHY-микросхемы. То есть RxD и TxD заведены прямо на ПЛИС.
UDP-пакеты принмает/посылает. Больше не умеет ничего. Я с ним пока ещё плотно не возился (хотел к нему ARP-хотя бы прикрутить, чтобы не руками его регистрировать в ARP-таблице компа), время на другое сейчас уходит. Как вода в песок.

Очень интересно было бы взглянуть...

[ReedCat]

Очень интересно было бы взглянуть...

Смотрите...

Прикрепленные файлы

 TENBASET.v ( 17.53 килобайт ) Кол-во скачиваний: 754

 

[chds]

Предложенные варианты с применением ARM7 или MSP явно не пройдут по скорости, которую хочет получить автор топика. От Микроблейза ждать чудес тоже не стоит. Хорошо если он будет фурычить на 100МГц, но к нему еще я так понимаю прикрутят прерывания и внешнюю периферию, окромя МАС и тоже выйдем на 600-800 кбайт в секунду.
Если ставить внешний MCU уровня ARM9/XScale то пропускную способность получить можно, с програмным обеспечением проблем ни каких, но по своему это решение очень жирное и финансово расточительное.
Но я по своему опыту работы на экстримальные приложения, а-ля милитари, закладывался б именно на такое решение - дорого но дубово. Военные денег не считают. Подняв Linux можно получить любой сетевой уровень.

Сообщение отредактировал chds - Apr 21 2008, 12:31

[kst]

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

Скорости требуются, на самом деле, не большие. Под Мб я понимал Мбит. Извините, если ввел в заблуждение.

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

Если потребуется реализация стека протоколов, задумаюсь о Microblaze. Для обмена служебной информацией быстродействия должно хватить, ибо это будет не в реальном времени. А вот поток данных ~10 Мбит/с возможно надо будет слать в raw-пакетах.

[KostyanPro]

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

В моем случае , также пришел к похожей идеи. Не хочу никаких контроллеров и процессорв на кристалле. Только mac на логике и PHY на плате. Формируем пакет и отсылаем/ принимаем (собираюсь использовать только UDP ). Сначала хотел с нуля написать по статьям Iosifk mac контроллер , но время стала поджимать.
Из доступного , приведенный выше http://www.itee.uq.edu.au/~peters/xsvboard/stack/stack.htm и кое что на opencores на wishbone. Правда с последней шиной не работал , поэтому не хочется выбирать данный путь из-за недостатка времени.

Что есть еще ?? может что-то пропустил.

[Chudik]

У меня есть отсылка пакетов со скоростью 30 Мб/с TCP, используется спартан3+wiznet3150. Кстати, тоже данные от радара. Весь интеллект уместился в фсм на 24 состояния, полученный переложением на верилог фирменных Си-исходников. Могу намылить верилог, схему и описалово.

Было бы очень интересно. Если за два года оно не умерло

[a123-flex]

Было бы очень интересно. Если за два года оно не умерло

таки видимо, умерло) или уже стало бесценным)))

[gosu-art]

У меня вопрос по программной реализации.

Есть Actel SmartFusion (хардвареный CortexM3 на борту с Ethernet МАС) eval kit. Сделал UDP, ARP, ICMP протоколы.
Теперь нужно организовать прием/передачу с компУтером.

Я думаю со стороны ПК использовать UDP сокет сервер WinSock2. Хорошо... создаем его, открываем какой нить порт, посылаем байтики.

Теперь, какой должен быть алгоритм со стороны железяки?
Приняли пакет, посмотрели IP адрес и номер порта, если адрес и порт мой, то, соответственно, и байтики тоже)?

Или же у сокетов есть особый протокол? и без ОС или lwIP стека не обойтись?

[vadimuzzz]

Приняли пакет, посмотрели IP адрес и номер порта, если адрес и порт мой, то, соответственно, и байтики тоже)?

да, все так

без ОС или lwIP стека не обойтись?

вполне можно обойтись

[gosu-art]

Возникла проблема:

При соединении точка-точка все работает нормально- пинг идет, UDP пакетики принимаются.
Стоит воткнутся в свич - все, ничего не работает и пинг в том числе.
В сети, у нас, DHCP сервак раздает IP и маску подсети.
ставлю статический IP 192,168,1,110 на компе (192,168,1,111 на железяке) маска 255,255,255,0 - тоже ничего.

Может быть из-за маски проблема? как ее можно учитывать внутри железяки?

[XVR]

Стоит воткнутся в свич - все, ничего не работает и пинг в том числе.

ARP точно работает? IMHO без него через простой свич может не ходить

[gosu-art]

ARP точно работает? IMHO без него через простой свич может не ходить

При точке-точке смотрел - ARP ответ приходит! Если бы не приходил пинг бы не работал. верно?

[XVR]

При точке-точке смотрел - ARP ответ приходит!

Проверьте на всякий случай - в командной строке (на хосте) наберите arp -a и посмотрите, есть ли в списке ваша плата с правильными MAC и IP

Если бы не приходил пинг бы не работал. верно?

Нет, за ping отвечает ICMP

[bark]

МАС какой-то осознаный у железяки? ни с кем больше не совпадает?
ещё учтите что если свич какой-нить умный, то после включения железяки или изменения её параметров (как правило МАС) некоторое время (обновление ARP таблиц от 2 до 10 минут) свитч может не пропускать нормально пакеты.

и да, регулярно при тестах проверяйте что на хосте в ARP таблице записано. команда как уже писали выше arp -a.
если её надо очистить принудительно то используйте arp -d * (но на свитч это естессно не повлияет никак)

[gosu-art]

Нет, за ping отвечает ICMP

Я имел в виду что если ARP ответа не будет, то компутер (если уже нет этого адреса в ARP таблице) не пошлет ICMP пакет!
Смотрю... ARP запросы не доходят до меня, какие то левые идут не с моим IP. ставлю брейк пойнт в ф-ции send_arp_reply. ничего...

[XVR]

Я имел в виду что если ARP ответа не будет, то компутер (если уже нет этого адреса в ARP таблице) не пошлет ICMP пакет!

Угу

Смотрю... ARP запросы не доходят до меня, какие то левые идут не с моим IP. ставлю брейк пойнт в ф-ции send_arp_reply. ничего...

Возможно MAC адрес вашей платы уже лежит в кэше ARP. Очистите его (arp -d *) и сделайте ping.

[gosu-art]

Один пинг прошел


UPD:


смотрю ARP -a и вот

[XVR]

Мдя, с ARP явный косяк. MAC адрес из всех нулей явно через свич не пройдет

[artix]

ещё учтите что если свич какой-нить умный, то после включения железяки или изменения её параметров (как правило МАС) некоторое время (обновление ARP таблиц от 2 до 10 минут) свитч может не пропускать нормально пакеты.

если свитч сильно умный, то у него может быть своя таблица маршрутизации и пакеты с устройства МАС которого не в его базе разрешенных адресов, вообще никуда лететь не будут.
У меня МАС от Igor Mochor + самописный стек с UDP уровнем+самый простой свитч D-Link пол года полет нормальный.

[gosu-art]

При пинге компьютер не получает ARP ответа...
А железяка не получает ARP запроса

Хотя получает, но от других адресов. И в функцию он благополучно заходит! Но ответ не посылает т.к. IPшники da и ta не те вообще...

Собственно ф-ция обработки ARP запроса

Код

unsigned char process_arp_packet(unsigned char *buf)
{
    arp_pkt_xp arp_pkt = (arp_pkt_xp )(buf + sizeof(ether_hdr_t));
    if (arp_pkt->opcode[1] != ARP_OPCODE_REQ_1) {
    if (arp_pkt->opcode[1] == ARP_OPCODE_REPLY_1)
    {        
         if (!memcmp(my_ip, arp_pkt->ip_sa, IP_ADDR_LEN))
         {         
             //printf("IP conflict with MAC");
             //printf("%02x:%02x:%02x:%02x:%02x:%02x",arp_pkt->mac_sa[0],arp_pkt->mac_sa[1],arp_pkt->mac_sa[2],arp_pkt->mac_sa[3],arp_pkt->mac_sa[4],arp_pkt->mac_sa[5]);
         }             
    }
    return ERR;
    }  

    if (memcmp(my_ip, arp_pkt->ip_ta, IP_ADDR_LEN)) {
    return ERR;
    }  
    return send_arp_reply(buf);
}

UPD: у меня этот стоит!

[artix]

А каким образом у вас кабели обжаты от ПК->Switch->Ваш девайс? Потому что не смотря на то что должны опознавать тип кабеля на практике не у всех свитчей это получаеться

Сообщение отредактировал artix - Aug 11 2011, 11:03

[gosu-art]

Кабель рабочий!остальные девайсы работают нормально + на компьютере проверял.

[bark]

gosu-art
MAC сделайте какой-то адекватный.. не нулевой.
лучше всего с железякой уйдите в какую-то свою подсеть. поставьте сниффер и смотрите что у вас там происходит на самом деле.

artix и? не понял суть поста.

[artix]

artix и? не понял суть поста.

вот с этим свичем http://www.dlink.ru/ru/products/2/26_b.html пару часов пропарился, когда мне врулили кабель обжатый Машина-Машина, а не Машина-Свитч : пинг как и все остальное не пролезало к остальным устройствам

При пинге компьютер не получает ARP ответа...
А железяка не получает ARP запроса

Хотя получает, но от других адресов. И в функцию он благополучно заходит! Но ответ не посылает т.к. IPшники da и ta не те вообще...

Собственно ф-ция обработки ARP запроса

Код

unsigned char process_arp_packet(unsigned char *buf)
{
    arp_pkt_xp arp_pkt = (arp_pkt_xp )(buf + sizeof(ether_hdr_t));
    if (arp_pkt->opcode[1] != ARP_OPCODE_REQ_1) {
    if (arp_pkt->opcode[1] == ARP_OPCODE_REPLY_1)
    {        
         if (!memcmp(my_ip, arp_pkt->ip_sa, IP_ADDR_LEN))
         {         
             //printf("IP conflict with MAC");
             //printf("%02x:%02x:%02x:%02x:%02x:%02x",arp_pkt->mac_sa[0],arp_pkt->mac_sa[1],arp_pkt->mac_sa[2],arp_pkt->mac_sa[3],arp_pkt->mac_sa[4],arp_pkt->mac_sa[5]);
         }             
    }
    return ERR;
    }  

    if (memcmp(my_ip, arp_pkt->ip_ta, IP_ADDR_LEN)) {
    return ERR;
    }  
    return send_arp_reply(buf);
}

UPD: у меня этот стоит!

не силен в С но я чего то не наблюдаю где вы тут указываете свой МАС в пакете который возвращаете в качестве ответа


там есть пример формирования ARP http://ru.wikipedia.org/wiki/ARP

Сообщение отредактировал artix - Aug 11 2011, 11:42

[gosu-art]

2 bark

сниффером я и смотрю! ARP от компа идут, к компу ответы - нет=>нет ping'а.
МАС не нулевой стоит! А он увидел нуль по пингуемому адресу=> по этому аресу никого нет (физически).

Вопрос: А как перевести железяку на другую подсеть?

2 artix

unsigned char send_arp_reply(unsigned char *buf)
{
/* Modify the packet in place */

arp_pkt_xp arp_pkt = (arp_pkt_xp )(buf + sizeof(ether_hdr_t));
eth_hdr_xp eth_hdr = (eth_hdr_xp ) buf;

memcpy(eth_hdr->da, eth_hdr->sa, ETH_ADDR_LEN);
memcpy(eth_hdr->sa, my_mac, ETH_ADDR_LEN);
arp_pkt->opcode[1] = ARP_OPCODE_REPLY_1;
memcpy(arp_pkt->mac_ta, arp_pkt->mac_sa, ETH_ADDR_LEN);
memcpy(arp_pkt->ip_ta, arp_pkt->ip_sa, IP_ADDR_LEN);
memcpy(arp_pkt->mac_sa, my_mac, ETH_ADDR_LEN);
memcpy(arp_pkt->ip_sa, my_ip, IP_ADDR_LEN);
num_pkt_tx++;
// MSS_MAC_tx_packet(buf,42, MSS_MAC_BLOCKING);
MSS_MAC_tx_packet(buf,42,1);

return OK;
}

Вот ф-ция ответа!

[bark]

gosu-art
вот как у нас обычно в таких случаях работают:
1. В машине 2 сетевые карты. (одна для общей сети, а вторая специально для работы с отлаживаемыми устройствами).
2. Допустим если общая сеть 192.168.1.x , то для работы с железякой использует каждый какую-нить свою подсеть типа 192.168.21.x
эти два пункта позволяют с минимум настроек и фильтров наглядно мониторить в сниффере всё происходящее в сети. (например битые пакеты, если что-то где-то нарушено)

3. Сначала естессно всё проверяется и отлаживается точка-точка, потом комп - отдельный хаб/свитч - железяка, а потому уже общий свитч если вообще предполагается такой режим работы.

допустим свитч может быть не пропустит UDP пакет с плохой чексуммой или превышеным лайфтайм, но ARP пропускать как бы должен. если только не хранит у себя в таблице какое-то старое значение IP для какого-то MAC. не поленитесь подождать 10 минут после подключения через свитч. это стандартное время очистки записи в ARP-таблице.

и ещё конечно вопрос- правильно ли формирует ARP ответ железяка? может что-то не соблюдено и поэтому свитч не пропускает ответ.
заодно достоверно ли вы видете что железяка получила запрос? лампочкой например подмигнуть можно.

[XVR]

У вас в my_ip IP в правильном порядке байтов лежит?

[akorud]

Обратите внимание что младший бит старшего байта МАС не может быть 1 (тогда мультикаст получается). Я как-то 3 дня бился с МАС 01:02:03:04:05:06 - не работало, поменяли на 00:... - все сразу заработало.

[gosu-art]

Утром пришел сегодня на работу, включил и вот....




Поменял только IP на 192,168,1,110 (маска 255,255,240,0) все работает!
Почему вчера не получалось!? может потому, что пока машин в сети мало?

UPD: поработало и хватит! опять все заткнулось Че то видать в сети нехорошее включается...

[artix]

Утром пришел сегодня на работу, включил и вот....




Поменял только IP на 192,168,1,110 (маска 255,255,240,0) все работает!
Почему вчера не получалось!? может потому, что пока машин в сети мало?

UPD: поработало и хватит! опять все заткнулось Че то видать в сети нехорошее включается...

Вы говорили что в сети у Вас ДХЦП есть может конфликт адресов возникает? Не может он выдать кому нить еще этот ИП? Нету ли у Вас возможности поцепить скажем еще одну сетевуху и через свитч соединить с Вашей платой?