Native usb что это

Обновлено: 04.07.2024

Добрый день
Имеется простая на вид задача, но я не могу ничего с ней сделать
Имеется Arduino DUE c двумя usb выходами.
Нужно:
1. Что бы при подключении к компьютеру через Native USB Port плата определялась не как COM-port, а как USB-устройство
2. В делфи принять на максимально возможной скорости данные. (Из-за этого DUE и выбрали). Нужно несколько тысяч чтений в секунду.

Скетч в ардуинке очень простой - пишет в SerialUSB миллисекунды.

__________________
Помощь в написании контрольных, курсовых и дипломных работ здесь

Arduino Due и PCA9685
Подскажите, как заставить работать Arduino Due и контролером PCA9685. Использую вот эту.

Прошить мк SAM3X8E от Arduino DUE
Приветствую всех! Подскажите, пожалуйста, ведь правильно, что можно прошить (новый, купленный).

Принять на нулевой скорости?

Что говорит гугл:

Для СОМ-порта стандартными являются следующие скорости: 50, 75, 110, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 бит/с. Идти копать огороды и не лезть в программирование и МК.

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

Собственный USB порт (Native USB port) подключен к SAM3X. Это позволяет осуществлять последовательную связь (CDC) посредством USB. Таким образом обеспечивается подключение к монитору последовательной шины, или другим приложениям на вашем компьютере. Также это дает Due возможность эмулировать для присоединенного компьютера USB мышь или клавиатуру

Ну так Вы код пишите который предназначен для Serial (СOM порта).
Для работы с USB нужно наверное использовать другие либы, и вероятно писать свой драйвер для ПК.

Serial и SerialUSB разные вещи
с обычным Serial и портом для программирования никаких вопросов нет. Прекрасно все работает. Но медленно.

Ну так в чем конкретно вопрос если есть пример кода?

1. Что бы при подключении к компьютеру через Native USB Port плата определялась не как COM-port, а как USB-устройство
2. В делфи принять эти данные, отправленные через SerialUSB. Через Serial - приходят по ком-порту. Через SerialUSB - нет, с ним как-то по другому надо

В делфи принять эти данные, отправленные через SerialUSB.

Добавлено через 3 минуты
Хотя нет. По Вашей ссылке ниже код на Python и там используется обычное соединение по COM порту.

Для меня это странно так как если речь идет о USB обычно говорят о каком то классе HID устройства которое соответственно определяется и под который пишется драйвер. Но подчеркну что у меня нет должного уровня знаний.
Стоит брать руководство/протокол по USB и его изучать его.

1. Что бы при подключении к компьютеру через Native USB Port плата определялась не как COM-port, а как USB-устройство

Есть много классов USB устройств. Вам какой нужен?

Это позволяет осуществлять последовательную связь (CDC) посредством USB.

Класс CDC это виртуальный COM порт. Учитывая что многое делается программно, что увеличивает нагрузку на МК, через USART удастся добиться большой скорости обмена.

Если нужна большая скорость обмена, лучше взять МК с USB HS (например STM32F407) и писать код в нормальной IDE, потому что ArduinoIDE и высокая скорость не совместимы.

Я про ArduinoIDE с ее библиотеками и стилем написания кода.

Стиль и библиотеки то отличные.

Код STM выглядит во многом менее читаемым.

Наверное, Communication Device (CDC) или Human Interface Device (HID)
К сожалению, я точно не знаю. Я пытаюсь разобраться со стандартом, но там так много информации, что мозги закипают и становится только еще менее понятно
Какой нужен тип для того, что бы считать один-два аналоговых сигнала?

В комплекте есть USBHost Library - примеры прошивают DUE в мышь или клавиатуру, которые, при подключении к Native USB port определяются как HID-совместимая мышь, а не ком-порт.
Но мне нужно не это, хотя это уже хоть какое-то направление.



Maximus Decim Native USB ver.3.3
by maxud

Только для Windows 98SE .
Нативная (без установки дополнительных драйверов для каждого типа) поддержка USB-флешдисков, цифровых фото- и видеокамер и прочих подобных устройств. Поддержка USB 2.0 без дополнительных драйверов.

Помните! Вы устанавливаете ее на свой страх и риск!

Перед установкой:
1.Удалите ВСЕ драйвера USB-флешдисков. ( инструкция )
2.Удалите ВСЕ драйвера USB 2.0 контроллеров
3.Удалите ВСЕ неизвестные утсройства, имеющиеся в системе.
4.Установите NUSB 3.3 и обязательно перегрузитесь.
5.После обнаружения новых USB 2.0 контроллеров (если это произойдет) тоже следует перегрузиться.

Если система попросит указать конкретный путь к файлам драйвера, не указывайте ничего - пусть ищет у себя! Никаких особенностей при установке, можно ставить поверх любой предидущей версии NUSB

Флешка - 256Мб Нонэйм(Самсунг) - как определяется в НТ сказать не могу :-/

Видел в этом топике, что уже были грабли с этими флешками, но как решилось я так и не понял..

Имеется 2 компьютера.
Сначала была установлена версия Windows 98 (не SE). Устанавливал версию NUSBe 2.1 (английскую). Все нормально работало.

Вчера понадобилось на одном компьютере переставить систему и установили Windpws 98 Second Edotion. При установке драйвера NUSBе 2.2 (обновленная версия) система выдали "любимый" синий экран и которо можно вый только через Reset, но этот же экран система выдает снова. Пришлось переустановить Windows. Снова устанавливал драйвер NUSBе 2.2 - история повторилась.

На другой машине, где была установлена предыдущая версия драйвера (NUSBe 2.1) система выдала синий экран, но после Reset поднялась и заработала.
USB-драйв Sony 2.0 256 mb

На одной машине поставили драйвер от USB-драйва Axiot (не уверен в названии) - мызыкальный на 512 mb. Устройство читалось и работало нормально, а Sony 2.0 256 mb определился и вылетел в синий экран, но систему уже не убил.

На моей же машине с Windows XP это устройство Sony 2.0 256 mb работает нормально.

Может подскажешь что-нибудь?

Еще и как нужно

P.S. Поработал немного с Win98 с диска - глючит конкретно и без драйвера для флешек, про драйвер пришлось забыть .

У меня на рабочем месте старый комп 64 Мб памяти. Пишущего сидюка нет, но есть порты USB. WinPE не грузится - памяти не хватает. Если на компе винда упадет то мой лоховатый админ неделю будет инфу с винчестера вытягивать. Винду тоже долго ставить. Винчестер отцепить и домой унести не разрешат. А у меня есть флешка 1 Gb - все документы влезут и еще место останется в случае чего все скачаю и к соседу работать пойду. Вот и хочу как-то флешку под досом прикрутить чтоб инфу снимать.

Есть флэшка Kingston DT2. Есть машина с 98ми.
Скачал универсальный nusb22r, посмотрел, есть ли ошметки от старых драйверов (мало ли) в реестре и на диске, не нашел.

Поставил драйвера, поставил флэшку.

Находит "Kingston DataTraveler II", потом (2е устройство, сам лог. диск или как-то так. вообщем - то, что ставится во вторубю очередь) находит "Kingston DataTraveller II+" и вываливается в BSOD.

Чистим все, уносим в неизвестном направлении файлы драйверов - то же самое.

Уносим все, чистим все, качаем драйвера с сайта кингстона. та же фигня.

2й раз то же самое, 3й, - все бесполезно. Все хорошо до момента, как DTII определяется как DTII+. После этого - синий экран, финиш, все заново.

Подскажи, можно ли как-то насильно ему сказать, что DTII - это DTII, а не что-либо еще? Как можно вычистить до блеска и где могло что-тол остаться?

Что нового:
* добавлено очень много новых устройств.

Ra SPb
Попробуй этот апдейт, может поможет.

Ммм. странно как-то получилось.

Т.е. теперь он более четко определяет, что это не D-II, а DT-II+. Но при этом один раз за загрузку машины флешку можно воткнуть и она читается.

Вынимаем - идет предупреждение о том, что это небезопасное извлечение. следующий раз втыкаем - BSOD.

И так - очень стабильно. Т.е. после загрузки системы можно 1 (один ) раз воткнуть флешку. После этого - опаньки

Добрый день
Имеется простая на вид задача, но я не могу ничего с ней сделать
Имеется Arduino DUE c двумя usb выходами.
Нужно:
1. Что бы при подключении к компьютеру через Native USB Port плата определялась не как COM-port, а как USB-устройство
2. В делфи принять на максимально возможной скорости данные. (Из-за этого DUE и выбрали). Нужно несколько тысяч чтений в секунду.

Скетч в ардуинке очень простой - пишет в SerialUSB миллисекунды.

__________________
Помощь в написании контрольных, курсовых и дипломных работ здесь

Arduino Due и PCA9685
Подскажите, как заставить работать Arduino Due и контролером PCA9685. Использую вот эту.

Прошить мк SAM3X8E от Arduino DUE
Приветствую всех! Подскажите, пожалуйста, ведь правильно, что можно прошить (новый, купленный).

Принять на нулевой скорости?

Что говорит гугл:

Для СОМ-порта стандартными являются следующие скорости: 50, 75, 110, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 бит/с. Идти копать огороды и не лезть в программирование и МК.

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

Собственный USB порт (Native USB port) подключен к SAM3X. Это позволяет осуществлять последовательную связь (CDC) посредством USB. Таким образом обеспечивается подключение к монитору последовательной шины, или другим приложениям на вашем компьютере. Также это дает Due возможность эмулировать для присоединенного компьютера USB мышь или клавиатуру

Ну так Вы код пишите который предназначен для Serial (СOM порта).
Для работы с USB нужно наверное использовать другие либы, и вероятно писать свой драйвер для ПК.

Serial и SerialUSB разные вещи
с обычным Serial и портом для программирования никаких вопросов нет. Прекрасно все работает. Но медленно.

Ну так в чем конкретно вопрос если есть пример кода?

1. Что бы при подключении к компьютеру через Native USB Port плата определялась не как COM-port, а как USB-устройство
2. В делфи принять эти данные, отправленные через SerialUSB. Через Serial - приходят по ком-порту. Через SerialUSB - нет, с ним как-то по другому надо

В делфи принять эти данные, отправленные через SerialUSB.

Добавлено через 3 минуты
Хотя нет. По Вашей ссылке ниже код на Python и там используется обычное соединение по COM порту.

Для меня это странно так как если речь идет о USB обычно говорят о каком то классе HID устройства которое соответственно определяется и под который пишется драйвер. Но подчеркну что у меня нет должного уровня знаний.
Стоит брать руководство/протокол по USB и его изучать его.

1. Что бы при подключении к компьютеру через Native USB Port плата определялась не как COM-port, а как USB-устройство

Есть много классов USB устройств. Вам какой нужен?

Это позволяет осуществлять последовательную связь (CDC) посредством USB.

Класс CDC это виртуальный COM порт. Учитывая что многое делается программно, что увеличивает нагрузку на МК, через USART удастся добиться большой скорости обмена.

Если нужна большая скорость обмена, лучше взять МК с USB HS (например STM32F407) и писать код в нормальной IDE, потому что ArduinoIDE и высокая скорость не совместимы.

Я про ArduinoIDE с ее библиотеками и стилем написания кода.

Стиль и библиотеки то отличные.

Код STM выглядит во многом менее читаемым.

Наверное, Communication Device (CDC) или Human Interface Device (HID)
К сожалению, я точно не знаю. Я пытаюсь разобраться со стандартом, но там так много информации, что мозги закипают и становится только еще менее понятно
Какой нужен тип для того, что бы считать один-два аналоговых сигнала?

В комплекте есть USBHost Library - примеры прошивают DUE в мышь или клавиатуру, которые, при подключении к Native USB port определяются как HID-совместимая мышь, а не ком-порт.
Но мне нужно не это, хотя это уже хоть какое-то направление.


Когда мы в SberDevices делаем новое устройство, работаем над его аппаратной частью, перед нами встаёт вопрос выбора интерфейсов. Важным моментом при выборе является их доступность и совместимость с другими устройствами.

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

Краткий обзор особенностей USB TYPE-C

Стандарты USB существуют много лет, развиваются и совершенствуются по мере увеличения технологических потребностей и возможностей. Несмотря на свою универсальность, которая следует из аббревиатуры, привычный USB перестал удовлетворять по объему своей функциональности. В частности, не может решить задачу по обеспечению питания многих современных устройств, потребление которых серьёзно увеличилось. Первая версия USB TYPE-C появилась в 2013 году. Помимо возможностей USB 2.0 и USB 3.0, USB-C стал поддерживать существенно более энергоёмкие профили питания, а также альтернативные режимы работы. В альтернативных режимах контакты разъёма используются для передачи данных высокоскоростных стандартов, таких как Display Port, Thunderbolt, HDMI, Mobile High-Definition Link (MHL). Недавно была опубликована новая реализация стандарта — USB4, которая также ориентируется на спецификацию USB-C.

Описание и назначение контактов разъёма

Разъём включает в себя 24 контакта. Такое большое число контактов по сравнению с привычными разъёмами USB связано как с добавлением новых контактов, расширяющих функциональность, так и с дублированием контактов на противоположную часть разъёма. Так группы сигналов USB 2.0 и USB 3.0 задублированы, разъем стал симметричным, поэтому теперь его можно вставлять любой стороной.

Рассмотрим группы сигналов USB-C соединителя:

Группа Цепи
Питание VBUS (4 контакта), GND (4 контакта)
USB 2.0 DP (2 контакта), DN (2 контакта)
USB 3.0 TX1+, TX1-, TX2+, TX2-, RX1+, RX1-, RX2+, RX2-
Конфигурационные контакты CC1, CC2
Дополнительные (Альтернативный режим) SBU1, SBU2

Видно, что под питание заложено 4 пары контактов. Это намекает на то, что через разъём стала возможна доставка существенно большей энергии для питания устройства. Через контакты питания возможна передача до 100 Ватт в нагрузку.

Профили питания доступные через USB TYPE-C:

USB 2.0 5 В 500 mA
USB 3.0/USB 3.1 5 В 900 mA
USB BC 1.2 5 В, до 1.5 А
USB Type-C Current 1.5A 5 В 1.5 A
USB Type-C Current 3.0A 5 В 3.0 A
USB Power Delivery до 20 В, до 5A

Режим питания зависит от того, какая функциональность USB-C используется. Появившиеся контакты CC позволяют установить требуемый режим питания и открывают некоторые дополнительные возможности, но об этом позже.

Чтобы иметь возможность использовать профиль питания с большим током, при установке соединения нужно воспользоваться конфигурационными контактами CC.

Конфигурационные контакты СС

С помощью конфигурационных контактов CC (Configuration channel) происходит подключение двух устройств, установка параметров соединения, профилей питания, а также информационный обмен протокола USB Power Delivery. Функционально CC1- и CC2-пины решают следующие задачи:


Источник (он же DFP) подтягивает линии CC к плюсу через резисторы Rp или использует источники тока. Потребитель (UFP) в свою очередь через резисторы Rd подтягивает линии CC к минусу.

Выставляя определённый номинал Rp (или создавая определённый ток на линии СС), host сообщает, какой ток для питания устройства он может обеспечить. Измеряя падение напряжения на Rd, потребитель понимает, какой Rp используется на противоположном конце и, следовательно, определяет ток питания, который может обеспечить host. Без использования USB Power Delivery по такой схеме возможно установить соединение c током до 3А с единственно возможным напряжением 5В.

Экономичный вариант реализации без USB PD

Как видно выше, спецификация USB-C поддерживает широкий спектр стандартов передачи данных и профилей электропитания, но это не означает, что разработчик обязан использовать всю функциональность. Минимальный набор USB TYPE-C может включать в себя USB 2.0 с контактами CC и единственным напряжением питания 5V. В такой конфигурации можно обеспечить потребителю до 15 Вт (5 В, 3А), что значительно больше, чем может дать стандартный порт USB 3.0 – 4,5 Вт (5В, 900 мА).

Чтобы реализовать логику подключения между DFP и UFP, можно использовать микросхему контроллера конфигурации CC, например, PTN5150. Этот вариант значительно проще и дешевле навороченных контроллеров, поддерживающих USB Power Delivery. Структурная схема выглядит так:


Как видно, основные узлы представляют собой: монитор напряжений на СС контактах, набор источников тока, резисторов для переключения состояния выводов, модуль управления ролями устройства.

Микросхема имеет интерфейс I2C, с его помощью можно определить или изменить роль устройства (DFP, UFP, DRP).

Когда выбирается роль DFP, устройство предполагается как Power Source, для которого есть возможность выбрать 3 профиля питания. После выставления соответствующих бит в регистре управления, происходит подключение соответствующего источника тока на линию CC.

Ток на СС-линии Режим питания
80 uA 5V / 0.9 A
180 uA 5V / 1.5 A
330 uA 5V / 3 A

В случае определения микросхемы в качестве UFP, контакты CC подключаются через резистор 5,1 кОм на землю. Монитор измеряет падение напряжения на этом резисторе и в статусный регистр заносится текущий режим питания.

Также возможно установить роль Dual Role Power (DRP), в этом режиме микросхема последовательно изменяет состояние СС-контактов от “pull-up Rp” до “pull-down Rd” и обратно до тех пор, пока не будет установлено соединение. Соединение возможно только между одним источником (Power Source) и одним потребителем (Power Sink). Таким образом, когда микросхема находится в режиме DRP и монитор напряжения CC-контактов замечает понижение напряжения на противоположном конце (подключён “pull-down Rd”), устройство понимает, что подключено к Sink, и начинает играть роль Source. Такой режим полезен в том случае, когда заранее неизвестно, в каком режиме должно работать устройство.

Рассмотрим пример использования контроллера

Кроме описанных выше СС-пинов и I2C-шины стоит отдельно отметить контакты ID, CON_DET, PORT. Контакт ID отображает режим, в котором в данный момент находится контроллер. Когда устройство определило себя в качестве DFP, ID примет значение LOW. Контакт CON_DET находится в HIGH, когда соединение установлено, LOW — в обратном случае. Эти два логических сигнала будем использовать далее для включения (когда мы DFP) и отключения (UFP) питания подключённого устройства.

Port — это вход, которым задаётся начальный режим устройства после включения питания. В случае, когда используется “pull-up”, контроллер становится DFP, если “pull-down” — UFP. Если нога осталась «висеть в воздухе», будет использоваться режим Dual Role, и устройство будет ждать подключения, чтобы определиться со своей ролью. Это состояние может быть изменено позднее, после конфигурирования по I2C или изменения уровня напряжения на PORT. Таким образом можно управлять режимами работы без использования I2C.

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


Наша задача подавать питание на разъём USB-C только в том случае, когда к нам подключён UFP. ID в таком случае примет значение LOW, CON_DET — значение HIGH. Для того, чтобы открыть ключ высоким уровнем HIGH, надо реализовать функцию Y = CON_DET& (NOT ID). Таким образом, если снаружи подключён UFP, он от нас питается, если DFP, то напряжение на разъём не подаётся и не происходит конфликта двух источников.

В случае, если нет задачи менять роль устройства в процессе работы, а также не требуется определения ориентации кабеля, можно выполнить вариант проще, без микросхемы вообще. Допустим, ваше устройство играет строго одну роль — UFP/Power Sink, например, это флешка. В таком случае достаточно выводы СС1 и СС2 на разъёме подключить через 5,1 кОм на землю.
В случае, если ваше устройство играет только роль DFP/Power source и оно должно подключаться к устройству USB-C Dual Role, также можно обойтись резисторами. В этом случае подбираем номиналы в зависимости от напряжения источника, к которому подключаем резисторы.

Читайте также: