[prottoss 0]

Подскажите, установка конфигурации 0 - это закрытие виртуального порта, или отсоединение устройства?

SET CONFIGURATION = 0, это значит устройство не сконфигурировано - доступ к нему не разрешен операционной системой - читай - ошибка где то.

 

Какой смысл что-то слать...

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

 

[Сергей Борщ 60]

Параметр 3 - это при наличии DTR со стороны хоста.

И если большинство "обычных" софтин поднимают его, то нежно любимый мной Bray Terminal оставляет его на усмотрение пользователя. И по умолчанию он там выключен...

Другого способа я не нашел.

Подскажите, установка конфигурации 0 - это закрытие виртуального порта, или отсоединение устройства? Если первое, то флажок "connected" можно ставить по любому SET_CONTROL_LINE_STATE.

Мысль интересная. Писал давно. При закрытии порта точно вызывается SET_CONTROL_LINE_STATE с параметром 0. А вот set_configuration вроде бы вызывается только при подключении устройства.

[jcxz 81]

После прихода в CDC запроса setup request с типа SET_CONTROL_LINE_STATE с параметром 3 порт открыт, можно слать привествие. После прихота этого же запроса с другим значением параметра или после установки конфигурации 0 - порт закрыт.

Автору вроде нужно не открытие/закрытие COM-порта в винде, а отрывание USB-шнурка. Шнурок могут выдернуть и не закрывая COM.

А также по стандартным запросам от host-а никак не определить факт отрывания шнурка.

Только VBUS или SOF.

SOF кстати - более универсальный способ чем VBUS.

[0men 0]

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

 

мой вариант прекрасно работает :)

[jcxz 81]

Но узаете о том, что не подключены только через VBUS.

Не обязательно. Я уже писал. VBUS элементарно может быть не подключен, при этом USB вполне себе нормально будет работать. В этом случае нужно использовать SOF.

 

мой вариант прекрасно работает :)

Ваш - находится у вас, а у автора может быть другая схема.

[0men 0]

Ваш - находится у вас, а у автора может быть другая схема.

 

у меня тоже через куб, как и у автора. Это штатная переменная в кубе

Edited December 11, 2017 by 0men

[jcxz 81]

у меня тоже через куб, как и у автора. Это штатная переменная в кубе

Куб уже научился и провода подпаивать?

[prottoss 0]

Не обязательно. Я уже писал. VBUS элементарно может быть не подключен, при этом USB вполне себе нормально будет работать. В этом случае нужно использовать SOF.

да, конечно, через SOF - это отличная идея. Но требует определенных программных затрат. Нужны таймауты. Если у ТС устройство в разработке, я бы рекомендовал выделить линию порта МК под мониторинг VBUS. Я делаю именно так.

[jcxz 81]

да, конечно, через SOF - это отличная идея. Но требует определенных программных затрат. Нужны таймауты. Если у ТС устройство в разработке, я бы рекомендовал выделить линию порта МК под мониторинг VBUS. Я делаю именно так.

У меня в практике был случай, когда в устройстве (с USB-device) использовалась ADUM4160 и схемотехник VBUS нормально завёл на неё, а вот как МК, находящемуся за барьером, дать знать об отключении хоста - не подумал. И линия VBUS которую он завёл в МК, всегда сидела в "1".

Вот тогда только SOF и спасал.

[prottoss 0]

if (hUsbDevice_0 == 0) то шнурок отключен

Никогда не использовал КУБ - пользуюсь самописным софтом. Вот мне интересно, как Вы думаете, или может быть точно знаете - каким образом данная библиотека отслеживает выдергивание шнурка. Как говорил раньше - у STM32 c OTG есть средства - есть регистры и биты, по которым можно отследить состояние VBUS (если линия подключена). У МК с USB-device вообще таких средств мониторинга нет. Как там КУБ определит? Возможно, что как предложил jcxz по SOF, но я сомневаюсь, что в КУБ-е это реализовано.

 

 

Вот тогда только SOF и спасал.

Повторюсь - идея отличная. Обязательно напишу код для своей библиотеки.

 

[0men 0]

Куб уже научился и провода подпаивать?

 

у него все уже подпаяно, если внимательно почитать.

 

куб определяет при вхождении в прерывание OTG_FS_IRQHandler через флаг USB_OTG_GOTGINT_SEDET

Edited December 11, 2017 by 0men

[prottoss 0]

у него все уже подпаяно, если внимательно почитать.

 

куб определяет при вхождении в прерывание OTG_FS_IRQHandler через флаг USB_OTG_GOTGINT_SEDET

Да. Но VBUS должен быть подключен, иначе Вы постоянно будете висеть в этом прерывании.

И как решить вопрос с МК, у которых нет OTG? Например STM32F103? ...Хотя ТС озвучил F4xx серию, тем не менее, пускай вопрос будет риторический.

[0men 0]

Да. Но VBUS должен быть подключен, иначе Вы постоянно будете висеть в этом прерывании.

И как решить вопрос с МК, у которых нет OTG? Например STM32F103? ...Хотя ТС озвучил F4xx серию, тем не менее, пускай вопрос будет риторический.

 

там, видимо, как то иначе, не работал с первой серией

[prottoss 0]

там, видимо, как то иначе, не работал с первой серией

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

 

[0men 0]

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

 

USB_OTG_GOTGINT_SEDET как раз и работает с VBUS

 

Bit 2 SEDET: Session end detected

The core sets this bit to indicate that the level of the voltage on VBUS is no longer valid for a

B-Peripheral session when VBUS < 0.8 V