Детали низкого уровня для последовательной связи между UART микроконтроллера и ПК [закрыто]

Многое из этого касается программного обеспечения, а не аппаратного обеспечения. Я предоставлю простой обзор, который не зайдет слишком далеко. (Я прочитал почти 1000 страниц спецификации USB 2.0 и использовал много таких устройств, подключенных к USB. У меня также есть некоторый опыт работы с драйверами Windows.)

Я буду очень признателен, если кто-нибудь сможет просветить меня, как внутренние данные передаются от микро к ПК и наоборот, используя одиночные контакты Rx и Tx. Я действительно хочу понять, как это на самом деле работает на аппаратном уровне. (хотя я не ищу пример кода)

Существует процесс для USB-устройства, чтобы перечислить себя через USB. Для операционной системы Windows процесс можно найти здесь: Как стек USB перечисляет устройство? . Эта веб-страница даст вам хороший обзор процесса перечисления, которому следует Windows, и некоторые причины, по которым следует этот процесс. Поэтому я не буду пытаться дублировать то, что уже было сделано, намного лучше, чем я мог бы написать здесь. Прочтите эту страницу и получите обзор этого процесса.

Не вдаваясь в подробности, USB-устройство может иметь несколько конечных точек, и они могут быть нескольких типов. Операционная система хоста на самом деле не заботится. Он просто проходит через процесс их перечисления, чтобы они могли действовать в соответствии со своими описаниями. Таким образом, у вас может быть составное USB-устройство, которое, например, обозначается как HID, так и MSD.

Для многих демонстрационных плат существует отдельная микросхема (или несколько), связанная с обеспечением интерфейса в операционной системе USB-хоста. Например, если вы покупаете демонстрационную плату TI MSP430 с разъемом для различных DIP-устройств MSP430, на плате также будет отдельный раздел USB. Этот раздел включает в себя специальный MCU (вы можете его увидеть, так что просто посмотрите), который обрабатывает все детали перечисления USB, о которых вам НЕ сообщают, когда вы подключаете его к хост-компьютеру USB.

Одна конечная точка, которую перечисляет этот предварительно загруженный MCU, будет использоваться для отладки DIP-чипа MSP430, который вы можете добавить на плату. Вы не получите много информации об этой конечной точке USB или командах и запросах, которые она обрабатывает. Это связано с тем, что TI не документирует интерфейс отладки (публично). Таким образом, эта связь с конечной точкой USB будет обрабатываться драйвером, установленным на стороне хоста USB, а также программным обеспечением, предварительно загруженным на этот специальный MCU на стороне демонстрационной платы. Эта конечная точка отладки позволяет специальному программному обеспечению и протоколам отладки, почти всегда недокументированным, использовать отладочные части интерфейса JTAG (или аналогичного), который находится на вашем микроконтроллере DIP на демонстрационной плате. Таким образом, программное обеспечение для отладки выполняет свою работу, используя эту конкретную конечную точку USB «обратного канала». Вы НИКОГДА не получите много информации об этой конкретной конечной точке, если сначала не докажете, что вам это нужно, а затем не подпишете свою жизнь. (Иногда вы можете получить информацию о том, как загрузить код в устройство. Таким образом, вы получите информацию очастью этого интерфейса, время от времени. Кроме того, отладка JTAG ЦП ARM, напротив, задокументирована. Однако нестандартные периферийные устройства, добавляемые производителями к ЦП ARM, могут быть плохо задокументированы.)

Однако этот специальный MCU также обрабатывает для вас другую конечную точку. Это будет конечная точка виртуального COM-порта (HID). Таким образом, хост-ОС устанавливает драйвер виртуального COM-порта, предназначенный для представления «стандартного» интерфейса COM-порта, который может использоваться программным обеспечением, работающим на хост-компьютере USB (ПК). Любое программное обеспечение, которое вы пишете на этом ПК, будет «разговаривать» с этим драйвером, как если быэто был "настоящий" COM-порт. Это не. Это просто программное обеспечение. НЕТ оборудования, связанного с этим виртуализированным COM-портом на главном ПК. В конце концов, это «виртуальный» COM-порт. Все, что происходит, это то, что то, что вы делаете с этим виртуальным COM-портом, превращается в связь с конечной точкой USB (вход и выход). эта виртуальная ссылка на конечную точку COM-порта в небольших пакетах сообщает ему, что запрашивает программное обеспечение ПК. Часть этого просто поглощается специальным MCU и сохраняется внутри, чтобы он знал, что ожидается позже. Для обмена данными через контакты TX и RX специальный MCU действует так, как если быэто было внешнее последовательное устройство, подключенное к контактам TX и RX вашего DIP MCU. (Специальный MCU работает со своими собственными контактами для управления и получения от контактов вашего DIP MCU.) Однако эта информация превращается в пакеты USB для обмена между хост-компьютером и этим специальным MCU, обрабатывающим USB-интерфейс для ПК.

Итак, насколько может сказать ваш недавно запрограммированный микроконтроллер DIP, на самом деле он общается с последовательным устройством через TX и RX. Он делает это без всех обычных требований к напряжению RS-232, используя вместо этого локальный$V_\text{CC}$блоки питания на плате. Но вашему программному обеспечению все равно. До тех пор, пока контакты TX и RX «кажутся» взаимодействующими с чем-то, что правильно обрабатывает вещи, все в порядке, и ваше программное обеспечение «просто работает», как и должно работать.

ПРИМЕЧАНИЕ

Использование скорости передачи данных (часто неправильно называемой здесь «бод»), настроенной в программном обеспечении на стороне ПК с использованием обычных вызовов программного обеспечения для настройки, ВООБЩЕ НЕ ВЛИЯЕТ на связь с конечной точкой USB. USB работает с совершенно другим набором коммуникационных механизмов. Таким образом, хост-компьютер и специальный MCU вашей демонстрационной платы обмениваются данными через USB, и конфигурации скорости передачи данных передаются независимо друг от друга. Затем задача специального MCU на демонстрационной плате состоит в том, чтобы «настроить» себя так, чтобы он использовал правильные детали синхронизации, чтобы действовать так, как если бы была выбрана эта скорость передачи данных. Но последующие данные, передаваемые от программного обеспечения хост-компьютера к демонстрационной плате, ВСЕГДА поступают в отличном состоянии и неповрежденными, независимо от установленной скорости передачи данных для последовательной связи. Под этим я подразумеваю, что он всегда прекрасно доходит до специального MCU. Однако, специальный MCU теперь должен передавать контакты с определенной скоростью на ваш DIP MCU, что он и делает. Если ставки не совпадают правильно, возникают те же проблемы, которые вы обычно ожидаете. Но эти проблемы возникают только между специальным MCU и вашим MCU, но не между хост-компьютером и специальным MCU демонстрационной платы.