Какова граница ролей сетевых интерфейсов в MCU? - PullRequest
0 голосов
/ 22 апреля 2019

Я разработчик встраиваемого программного обеспечения, у которого есть опыт работы с TCPIP на подключенных устройствах.Кроме того, я не являюсь экспертом по программным протоколам, поэтому меня немного смущает стек протоколов TCPIP + ответственность его различных физических уровней.

Прежде всего, у меня есть опыт работы с такими протоколами, как UART, SPI, CAN, USB ... Как вы знаете, слой phy напрямую влияет на вас при выборе протокола, который вы использовали на программном уровне.Например, если вы используете usb и строите на нем программный протокол, вы иногда не сталкиваетесь с некоторыми деталями, такими как проверка поврежденного фрейма в вашем программном протоколе, потому что уровень phy гарантирует эту операцию.CAN также имеет некоторые средства CAN Controller, такие как crc и битовая начинка, поэтому он действительно надежен.Но ситуация не такая же для простых периферийных устройств, таких как UART / USART.Допустим, вы используете модуль Bluetooth для обновления своей прошивки, вам необходимо знать почти все, что может происходить при общении, например, задержки, поврежденные кадры, проверка полезной нагрузки и т. Д.

Вкратце, я пытаюсь понятьТочная роль интерфейсов newtork включена в микроконтроллеры, которые напрямую связаны с сокетами RJ45.Другими словами, представьте, что я написал серверное приложение на моем компьютере.Также я настроил и запустил приложение в моей плате разработки, у которого есть разъем RJ45, и он работает как клиент.Также представьте, что они установили соединение по TCP.Итак, какова будет ситуация на стороне клиента, когда я отправлю 32 байта данных в сокет со стороны сервера?Что я увижу на самом низком уровне MCU, который является RxCompleteInterrupt ()?Гарантируется ли отправка данных, которые я отправил, и некоторые другие материалы, добавленные к пакету TCP, контроллером eth в MCU и контроллером ethernet моего ПК?ИЛИ Я несу ответственность (или стек, который я использовал), чтобы проверить все вещи, необходимые для проверки, является ли фрейм действительным или нет?

Я пытался быть настолько ясным, насколько это было бы.Пожалуйста, если у вас есть опыт, то попробуйте написать чистые комментарии.Я не эксперт по TCPIP, возможно, я использовал неправильную терминологию, пожалуйста, сфокусируйтесь на основной концепции вопроса.

Спасибо, ребята.

1 Ответ

1 голос
/ 22 апреля 2019

Если у вас нет опыта работы с набором протоколов TCP / IP, я настоятельно рекомендую вам взглянуть на эту IBM Redbook , более конкретно на главы 2, 3 и 4.Это как говорится:

  1. Итак, что будет с клиентской стороной, когда я отправлю 32 байта данных в сокет со стороны сервера?Что я увижу на самом низком уровне MCU - RxCompleteInterrupt ()? Вы должны были получить кадр Ethernet в вашем буфере.Этот кадр Ethernet должен содержать IP-пакет.Этот IP-пакет должен содержать TCP-пакет, полезная нагрузка которого должна состоять из ваших 32 байтов данных.Но будет несколько обменов между клиентом и сервером до получения ваших данных, потому что TCP является протоколом, ориентированным на соединение, то есть будет отправлено / получено несколько фреймов Ethernet.
  2. Естьданные, которые я отправил, и некоторые другие материалы, добавленные в пакет TCP, гарантированно доставленные контроллером eth в MCU и контроллером ethernet моего ПК?ИЛИ Я несу ответственность (или стек, который я использовал), чтобы проверить все вещи, необходимые для проверки, является ли фрейм действительным или нет? Пакет TCP в конечном итоге будет доставлен, но нет никаких гарантий, что ваши кадры Ethernet и IP-пакеты будут доставлены и будут доставлены в правильном порядке.Это именно та работа TCP, как протокола, ориентированного на установление соединения, а не выполнение того, что необходимо для того, чтобы данные, отправляемые вами в качестве полезной нагрузки TCP, в конечном итоге доставлялись.Ваше оборудование MCU должно отвечать за проверку кадров Ethernet, но стек TCP / IP, работающий на MCU, отвечает за проверку пакетов IP и TCP и правильную доставку данных, отправляемых / получаемых по TCP.

Вы можете поэкспериментировать с TCP на ПК с Linux, используя netcat, и захватить обмен, используя Wireshark или tcpdump.

Создать файл «ответа», содержащий 32байт:

echo 0123456789ABCDEFGHIJKL > response.txt

Запустить Wireshark и выполнить фильтрацию на интерфейсе lo с использованием фильтра tcp port 1234Запустите TCP-сервер, прослушивающий TCP-порт 1234, который будет отправлять содержимое response.txt при получении соединения от клиента:

netcat -l 1234 < response.txt

В другой консоли / оболочке подключитесь к серверу, прослушивающему tcp / 1234, и отобразите, что было получено:

netcat localhost 1234
0123456789ABCDEFGHIJKL

На Wireshark вы должны увидеть следующее Wireshark Network Capture и иметь возможность развернуть все кадры / пакеты полного обмена, используя IBM Redbook в качестве ссылки.Ваши 32 байта данных будут находиться в разделе полезных данных пакета TCP, отправленного сервером.

...