Ethernet. Вопросы по интерфейсу и реализации

[YS]

Учитывая, что я с Ethernet не очень... Да и с Си на Вы, как отловить баг ума не приложу Подскажите, с чего начать то?

Боюсь предположить... Наверное, с изучения документации по используемым протоколам и физическому уровню Ethernet? Хотя можно для начала изучить основы алгоритмизации и особенности синтаксиса Си, а сеть оставить на потом.



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

Кто из них первый разговаривать то с соседом начнёт?

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

[mas123]

ну а как этим "arp" я прочесть не успел

В консоли отменили "/?"?!
Ух, не пугай так - всё работает, только что проверил....

завладеть его UART модулем...

интернет- и физические магазины тоже отменили?

Кто из них первый разговаривать то с соседом начнёт? Или они будут одновременно кричать пока кто то не сдастся?

Что значит "разговаривать" и с какого перепугу компам захочется между собой общаться?
Пожалуй единственное, когда "комп" сам желает общаться - это запрос к DHCP-серверу за IP-адресом, ну и ARP-запросы перед отправкой пакета неизвестному получателю.

вот почитываю тут разное про Ethernet но нигде найти не могу

Помниться, вчера ты тоже нигде не мог найти про ARP и ICMP, пока я не начал цитировать вслух статью по твоей же ссылке....
Если уж решил заняться изучением матчасти - читай про 7-ми уровневую модель OSI, про BSD-сокеты...
Хотя всё это не самое необходимое для разработки и начального запуска Ethernet-устройства. Вот для его программирования и работы с ним - там это нужно, да.

[Грендайзер]

интернет- и физические магазины тоже отменили?

Ну это не так интересно Впрочем можно и так да...

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

Полностью согласен... но как всегда охота всего и сразу...

Хотя всё это не самое необходимое для разработки и начального запуска Ethernet-устройства. Вот для его программирования и работы с ним - там это нужно, да.

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

Всё понял, спасибо!

[Грендайзер]

Урааа, товарищи! Заработало Теперь самое интересное - в чём же была причина?! Не известно. В общем полез я в режиме отладки регистры шерстить и переменные... Студия мне пишет мол это оптимизировано, то прочесть не могу... ну мучился, мучился... В конце концов придушил оптимизатор нафиг. Зашиваю - РАБОТАЕТ! Ну думою оптимизатор - сволочь ! Включил его - ОПЯТЬ РАБОТАЕТ! Включил самую сильную оптимизацию - СНОВА РАБОТАЕТ!!! В общем слов нет... одни нецензурные Кстати, после отключения питания, то же не работало... Это впрочем легко решилось добавлением секундной задержки перед ф-цией lan_init(). От так ота

[YS]

Ну что я могу сказать, вам повезло.

[mas123]

Это впрочем легко решилось добавлением секундной задержки перед ф-цией lan_init().

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

В плане бреда - ENC может долго линк поднимать, а ты ею командуешь без учета её состояния.
ТУт она за секунду успела все сделать, а если завтра не успеет?

[Грендайзер]

Ну что я могу сказать, вам повезло.

Везение-результат целенаправленной деятельности

Я в таких случаях не радуюсь, а наоборот - усиленно "копаю".

А куда копать то... Достаточно сталкивался с багами в программных оболочках... Да что говорить, Вы на ENC эррату почитайте, а ENC это не ПО. Повторить предыдущую ситуацию не удаётся... так что Впрочем эксперименты с эзернетом теперь только начинаются, там глядишь и статистика какая нибудь наберётся. Если что то интересное замечу, обязательно напишу!

В плане бреда - ENC может долго линк поднимать, а ты ею командуешь без учета её состояния.

Это к вопросу об экспериментах

[mas123]

Везение-результат целенаправленной деятельности

Увы, как мне сейчас видится - не в твоём случае...

Да что говорить, Вы на ENC эррату почитайте, а ENC это не ПО.

Как бы тебе сказать... У меня устройство на ENC работает уже пару лет в постоянном режиме.
Что касательно сетевых служб - там и SNTP поднят с DNS и ICMP. И клиент каждые 5 минут стучится наружу передать данные, и сервер постоянно ожидает подключение.
А за это время и свет в квартире выключался, и роутер требовалось перезапустить - а у ENC ничего не зависает и всё работает.
Так как думаешь - читал я еррата или "экспериментировал"?

[Грендайзер]

Думою да Впрочем из сказанного понял я не много....

[просто КОТ]

Ну чего, коты, моя очередь мучаться? Тоже мне понадобилось Ethernet поднять. И, боюсь, без Вас не разберусь.

Есть отладка STM32F746. Сам камень как будто бы внутри у себя имеет довольно мощные ресурсы по работе с этим делом. STM32Cube собрал мне проект, где я подключил Ethernet и LwIP. В проекте пока только подключена кучка библиотек, а из собственно кода в main.c HAL_GPIO_Init(); и HAL_LWIP_Init();

Вооот. Самый глупый вопрос -- как быть и что делать? Читаю про работу с TCP/IP четвёртые сутки, но так и не понял каков механизм создания связи. Чего писать, кому начать слать пакеты. Как их принять вообще?

Звучит очень глупо, но, боюсь, без вашей поддержки я так и не пойму ничего. До этого работал только с низкоуровневыми протоколами. По тому же UART сейчас отладка у меня отлично передаёт все данные в компьютер. Но... пришла пора пробовать что-то новенькое. Выручайте коты. Что читать? Что делать?

[Грендайзер]

Не хочу сейчас выпендриваться, но тем не менее... Не совсем понятно, а вопрос то в чём? Если Вы не знаете как программировать STM'ку то наверное лучше написать в соответствующий раздел форума т.е. про ARM. Там ответ быстрее найдёте. Если не можете разобраться со структурой езернет как было и впрочем осталось (хоть и в меньшей степени) у меня... то пишите конкретные вопросы. Будим думать вместе, а там глядишь и другие подтянутся...

[просто КОТ]

С STMкой-то я вроде справляюсь. А вот с езернетом... Я вообще не представляю что делать после инициализации стека LwIP. Как запросить себе IP? Как формировать и отправлять пакеты?

В идеале надо получить IP микрофон. На стороне чисто МК всё понятно. И опрос микрофонов (их 4 штуки) и фильтрация. Надо только каким-то макаром передать это на некоторое условнобольшое расстояние и на компьютере паковать в WAV-контейнер. Но как?

[YS]

Самый глупый вопрос -- как быть и что делать?

Прежде всего - выкинуть STM32Cube и прочие StdPeriphLib, прочесть в даташите, как работает Ethernet-периферия и написать всю инициализацию руками через регистры. Иначе так и будете ходить вокруг без глубокого понимания, в результате чего получать глюки в разных неожиданных местах.

Дальше, как бы попсово это ни звучало, почитайте Википедию. Там вы получите базовое представление о том, как работает TCP/IP и Ethernet. Вкратце - все устроено по принципу матрешки. Данные пакуются в TCP или UDP пакет, этот пакет пакуется в IP-пакет, IP-пакет пересылается в Ethernet-кадре.



Железка в вашем МК занимается тем, что передает и принимает Ethernet-кадры. После того, как вы приняли такой кадр, вы можете сами выковыривать из него данные, а можете отдать IP-пакет, вынутый из него, библиотеке TCP/IP стека. Я бы рекомендовал вам использовать uIP, потому что она не использует динамическое выделение памяти.

Как запросить себе IP? Как формировать и отправлять пакеты?

Я бы пока не заморачивался с DHCP. Используйте статический IP-адрес. Пакеты формируются либо руками, либо через ту же библиотеку TCP/IP стека, и передаются железкой в Ethernet-кадре. Почитайте как устроена uIP. Там все очень просто и удобно. С одной стороны вы подсовываете свой драйвер железа, передающего и принимающего Ethernet-кадры, а с другой стороны у вас есть набор обратных вызовов ваших функций.

[просто КОТ]

Так-с... Повыкидывал кучу всего из проекта касательно LwIP. Стал он практически пуст теперь. Только вот что сконфигурировал Ethernet. Теперь "нижний слой" вроде как готов, он со мной общается посредством команд:

HAL_ETH_TransmitFrame();
HAL_ETH_GetReceivedFrame();

Постараемся на это накатить следующий слой. Начинаю читать про uIP...

[просто КОТ]

Друзья, и ещё вопрос (уж простите за дабл-пост) но... Посмотрел я на uIP, всё дно много кода. И вот какой вопрос возник. Если уж меня интересует всё равно одна только функция -- сформировать UDP фрейм с выборками АЦП и переслать его удалённому компьютеру.

Т.е. только UDP, и только симплекс. Ну и возможно какую-нибудь функцию "эхо", если UDP запрос прилетел ко мне.

Возможно их можно реализовать отдельно. С нуля. Не переваривая весь этот стек. Ибо кажется над стеком мне придётся ещё солидно покурить. А сдать IP-микрофон очень надо бы на днях. Есть какая инфа с разжёванным алгоритмом именно по сборке/разборке фрейма?

UPD: в чём план:

Собрать вручную один кадр. Со статичным IP, неким фиксированным шлюзом. Фиксированной длиной пакета. Всем фиксированным. Собрать его вручную залить в память МК. А потом только менять внутри него значение Message через битовые маски, или около того. И выбрасывать наружу. По идее, это ведь самая простая и железная из реализаций, да?

[YS]

Есть какая инфа с разжёванным алгоритмом именно по сборке/разборке фрейма?

Что там собирать? Заводите массив и записываете в него данные согласно структуре IP-пакета с UDP-пакетом внутри. Как устроены пакеты IP и UDP написано много где. Например, в Википедии. И я даже ссылку приводил на статью, с которой можно начать читать.

Ethernet-кадр скорее всего собирает непосредственно блок Ethernet MAC в вашем контроллере. И вот тут вам надо почитать reference manual, главу про блок ethernet MAC.

Повторяю еще раз - чтобы ваш проект работал стабильно и без бубна, надо, чтобы вы досконально понимали, что, где и как работает. Потому забудьте про STM32Cube и StdPeriphLib (всякие HAL_xxx_xx), прочтите документацию и сконфигурируйте все руками. Иначе ваш успех будет определяться исключительно везением.

[просто КОТ]

Ethernet-кадр скорее всего собирает непосредственно блок Ethernet MAC в вашем контроллере. И вот тут вам надо почитать reference manual, главу про блок ethernet MAC.

Там всей главы -- один абзац:

The devices provide an IEEE-802.3-2002-compliant media access controller (MAC) for ethernet LAN communications through an industry-standard medium-independent interface (MII) or a reduced medium-independent interface (RMII). The microcontroller requires an external physical interface device (PHY) to connect to the physical LAN bus (twisted-pair, fiber, etc.). The PHY is connected to the device MII port using 17 signals for MII or 9 signals for RMII, and can be clocked using the 25MHz (MII) from the microcontroller.

Так что решил попробовать собрать вручную. Пока вышло следующее для IPv4 и UDP:

4 бита - Версия // =4
4 бита - Длина заголовка // =5
8 бит - Тип обслуживания // можно заполнить нулями ?
16 бит - Длина пакета // =22
16 бит - Идентификатор // какой угодно ?
3 бита - Флаги //=0b000
13 бит - Смещение фрагмента // тоже нули?
8 бит - Время жизни // =3 (по идее, много же не надо)
8 бит - Протокол //=17 (UDP)
16 бит - Контрольная сумма заголовка // как считать?
32 бита - IP отправителя // какой придумать?
32 бита - IP получателя // какой? если через маршрутизатор
16 бит - Порт отправителя // какой придумать?
16 бит - Порт Получателя // какой придумать?
16 бит - Длина посылки // = 4
16 бит - Контрольная сумма // =0 (IPv4 не требует)
32 бит -- Данные // = мои данные

0100 0101 00000000 00000000 00010110 iiiiiiii iiiiiiii 000 00000 00000000 00000011 00010001 ssssssss ssssssss aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb PPPPPPPP PPPPPPPP pppppppp pppppppp 00000000 00000100 00000000 00000000 dddddddd dddddddd dddddddd dddddddd

На тему сбора ручками. Дык я и пытаюсь. А через кубик просто проинициализировал ноги да выставил clocking. Дальше всё ручками попробую, если эта функция HALовская "не взлетит". А пока... что можете сказать по созданию посылки?

(Простите, если усердно "иду наперекор советам", но я совершенно "не вижу тропы" и мне кажется что совсем без HAL это дикость. )

А по поводу IP -- это надо наверное в маршрутизаторе включить привязку к МАС и получить уже один раз и навсегда IP для того и другого.

[YS]

Там всей главы -- один абзац:

По всей видимости вы читаете datasheet, а не reference manual.

мне кажется что совсем без HAL это дикость.

HAL должен быть, но я за самописный HAL. Когда сам инициализируешь оборудование через регистры, темных мест не остается, все на виду. Не надо брать чужие библиотеки, которые непонятно как работают. А запутанность и тяжеловесность STM32Cube превышают все мыслимые границы.

Найдите reference manual на ваш МК и прочитайте для начала, на что конкретно там способен модуль Ethernet MAC.

И вы прочли статьи в Википедии? Видимо, нет...

[просто КОТ]

В википедию вчитался как никогда. А только пользы мало. Видит око истина рядом... Да зуб неймёт. Так чо вынужден с вами согласиться -- на неизвестных библиотеках далеко не уедешь. Пытаюсь написать проект который буду знать полностью. Пока есть 4 файла, суммарно строк на 200.

system_stm32f7xx.c Там устанавливается тактирование и таблица векторов прерываний. Остальное вообще вынес.
gpio.c там включается тактирование GPIO и расставляются режимы выводов. Больше ничего.
eth.c тут устанавливается МАС адресс и объявляются спец.выводы. Остальное убрано.
main.c тут инициализация всего этого. И пока полностью пустой главный цикл.

Что делать теперь?

[YS]

"Чистый" проект для STM32FxxxXX должен включать в себя:

• system_stm32fxxx.c - занимается, как ни странно, не прерываниями, а стартовой настройкой тактирования. В нем надо как минимум посмотреть, от какого генератора и на какой частоте запускается контроллер. Там написано.

• startup_stm32fxxxxx.S - ассемблерный исходник. А вот тут как раз описаны прерывания, настраивается размер стека и кучи, инициализируется память, вызывается SystemInit(), после чего производится переход в main(). SystemInit() описана в system_stm32fxxx.c в куче вариантов. Вектора описаны в виде "слабых" символов, то есть, если компилятор встретит символ с таким же именем где-то еще, он выкинет существующее определение и будет использовать новое.

• system_stm32fxxx.h - заголовочный файл для system_stm32fxxx.c.

• stm32fxxx.h - файл с описаниями констант, флагов, регистров и прочего. Регистры заданы в виде структур. Например, вывод в порт выглядит как-то так:

Код: Выделить всё

GPIOA->ODR=...;

Остальные блоки периферии заданы аналогично.

• main.c - точка входа в программу, содержит функцию main(). Отсюда начинается код собственно приложения.

Среды разработки могут заодно неявно подключать CMSIS - это стандартная библиотека для контроллеров ARM-Cortex. Это произведение на ST, а непосредственно ARM. Полезная штука; нам пока не нужна, но и вреда от нее не будет.

И вот с этого момента вы можете начинать писать код инициализации всего и вся в main(). Можете попробовать инициализировать блок Ethernet MAC и отправить один статический пакет. Если отправится - можно начинать разбивать код на блоки и формировать какой-то уровень абстракции. Путь не такой быстрый, как ардуинообразные развлечения с STM32Cube, зато дающий стопроцентное понимание происходящего.

Reference Manual находится тут, в разделе "Design". Документ относится сразу к семейству контроллеров с одинаковыми блоками периферии. Вот, берите и читайте. Вас интересует глава 38, "Ethernet (ETH): media access control (MAC) with DMA controller".