Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Проблема Ehernet в LPC1766
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
b-volkov
Не могу добиться, что бы Ehernet- модуль принимал только "свои" кадры ( адрес которых совпадает с адресом контроллера). Выставляю бит APE в RXFILTERCTRL (как рекомендуется в UM) - "свои" кадры не принимаютя. Если разрешить бродкасты, то они принимаются нормально. Если разрешить мультикасты, то принимается куча всяких кадров, включая и "свои". Короче, перепробовал все комбинации битов фильтра - не получается.
Может быть для приема пакета недостаточно только совпадения адресов, а нужно еще и корректное заполнение каких-то других полей кадра (например, CRC) ? В отличии от брод/мультикастов, которые просто есть в сети (соединение комп-контроллер не изолировано от локалки), " свои" кадры формируются мной. А я, кроме адреса и данных ни каких других полей не заполняю.
Палыч
Цитата(b-volkov @ Jun 8 2017, 18:55) *
Не могу добиться, что бы Ehernet- модуль принимал только "свои" кадры ( адрес которых совпадает с адресом контроллера). Выставляю бит APE в RXFILTERCTRL (как рекомендуется в UM) - "свои" кадры не принимаютя.

К этому следует добавить установку регистров SA0, SA1, SA2 и режима Unicast (AcceptUnicastEn). Про фильтрацию пакетов смотри п.10.17.10 User Manual.
b-volkov
Цитата(Палыч @ Jun 9 2017, 09:44) *
К этому следует добавить установку регистров SA0, SA1, SA2 и режима Unicast (AcceptUnicastEn). Про фильтрацию пакетов смотри п.10.17.10 User Manual.

Само-собой, в SA0-3 я записал МАС-адрес. AUE то же ставил - не принимается.
Палыч
Нулевой (хорошо бы, и первый) бит первого октета МАС-адреса имеет нулевое значение?
b-volkov
Имеет место какая-то путаница с порядком октетов в МАК-адресах. В моей голове или в мануале - не знаю пока. Понял я это, когда догадался наконец-то не принимать, а передавать пакеты.
Адрес я выбрал простой: 11.22.33.44.55.66. Смотрим стр 167 UM: SA0 хранит октеты 1 и 2, SA2 - 3 и 4, SA3 - 4 и 5. Далее смотрим рисунок 19, на нем ясно видно, что нумерация октетов идет "слева направо", т.е. первый байт кадра, это первый октет DestAddr, а 7-й, это первый октет SrcAddr
Исходя из этого я заполняю регистры SA таким образом:
SA0=0x1122;
SA1=0x3344;
SA3=0x5566;
Начинаю посылать пакеты и в Wirehark вижу такую картину:



Т.е., октеты идут в обратном порядке! Соответственно, когда я их переставил, то заработал и прим пакетов. Объясните мне, это я чего-то недопонял, или имеет место ошибка в документации?

Палыч
Порядок передачи октетов МАС-адреса по сети обратен их традиционной шестнадцатиричной записи.

Ваш адрес: 11.22.33.44.55.66
В нём 11.22.33 - идентификатор производителя; 44.55.66 - уникальный номер, присвоенный производителем
В выбранном Вами идентификаторе производителя закралась ошибка: первый октет в идентификаторе производителя (11) - не может иметь такое значение: определяют только старшие шесть бит (заменим его на 10). В сеть вначале передаётся идентификатор производителя, затем - номер.

Итого:
SA0= 0x6655; SA1=0x4433; SA2=0x2210;

Кстати, я с Вами использую какие-то разные manual'ы: у меня ни страницы не совпадают, ни рисунки, и регистра SA3(о котором Вы всё время говорите) - нет.
b-volkov
Извиняюсь, с нумерацией регистров SA я и вправду накасячил .

Я пользоваллся User Manual UM10360 Rev. 4. 1 — 19 December 2016.

Кидаю скриншоты страницы 167, где описаны SA0-SА2 и рисунок 19.







Если сопоставить нумерацию октетов на этих картинках, и заполнить регистры так, как Вы сказали :SA0= 0x6655; SA1=0x4433; SA2=0x2210, то начало передаваемого пакета должно выглядеть следующим образом (ХХ адрес получателя):

ХХ ХХ ХХ ХХ ХХ ХХ 66 55 44 33 22 10 ....

Ну а на самом деле, порядок октетов получается обратным.
Палыч
Первоначально картинка выглядела так:
Нажмите для просмотра прикрепленного файла
Затем картинку зачем-то поменяли, причем замена была только в UM серии 17хх. В документации на другие серии МК картинка не изменилась.
b-volkov
Теперь понятно sm.gif. Спасибо за разъяснения.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.