r2axz

Я, кстати, дизассемблировал usbser.sys на Windows 10 и посмотрел в чем там дело. Благо у MS есть отладочные символы для этого драйвера, поэтому разобраться что там где - тривиально. Так вот, надежды нет: если посмотреть на функции SetBreak или SetClrDtr, то там в какой-то момент происходит "call ClassVendorCommand" и это та функция, которая шлет нужный нам SetControlLineState. А вот пара функций SetRts и ClrRts такого вызова внутри себя просто не содержит. То есть, выглядит все так, что просто забыли дописать вызов функции и все. Такая вот типичная и банальная бага, никакой магии.

Спасибо за информацию. Недавно "лазил к вам в код" и видел commit messages на эту тему. Собственно лазил по поводу идей для борьбы с общей бедой с RTS и виндой. Но похоже проблема решается только с помощью workaround на уровне пользовательского приложения: типа хочешь поставить RTS, поставь заодно и DTR. Хоть даже в то же самое состоянии, но поставь))) Ох уж эти милые "особенности" Микрософта)

Я для тестов использовал Termite 3.4 (by CompuPhase). У него в настройках есть секция "Plug-ins", а в ней "Status LEDs", вот им и смотрю.

Да, в обработчике завершения передачи DMA разрешаем USART TC, а в обработчике прерывания от USART сбрасываем пин GPIO. Все как в AN3070.

И теперь не более, чем за 0.6 мкс :)

Зарелизил поддержку RS-485. Сигнал TXA (TX Active) служит для управления микросхемами трансиверов RS-485 (DE, /RE). TXA активен во время передачи данных и переключается в неактивное состояние не более чем за 1 мкс после завершения передачи. Это соответствует спецификациям RS-485 на скоростях до 460 кБод не менее чем с двукратным запасом по времени переключения. Возможно применение и на более высоких скоростях. Статья на Habr: https://habr.com/ru/post/530060/ Проект на GitHub: https://github.com/r2axz/bluepill-serial-monster

Сделал эксперементальную версию поддержки RS-485 и обновил статью на Хабре: https://habr.com/ru/post/530060/ Там написано про ограничения и где взять прошивку (отдельный пулл-реквест пока: https://github.com/r2axz/bluepill-serial-monster/pull/14) Нужны тесты на реальных применениях.

Добавил поддержу сигнала RI.

Вот, кстати, RI у меня не реализован, если вдруг что. Надо будет добавить. Я использовал Termite, там есть plugin для отображения состояния управляющих линий. Плагин идет сразу с программой, его надо просто включить в настройках.

Да, понимаю, эстетика далеко не самая последняя вещь в нашем деле. Вот по этому адресу https://www.usb.org/document-library/class-definitions-communication-devices-12 есть архив, внутри архива есть файл PSTN120.pdf. В нем на странице 30 есть список Abstract Control Model Notifications и в них входит SerialState, который в свою очередь описан на странице 32. И вот его я как раз и использую для уведомлений о переполнении, ошибке четности, DSR и DCD. Их и правда разных как грязи, но как только мне понадобились управляющие сигналы + композитное устройство + настройка инверсии, типов выходов, полярности + цена меньше пачки сигарет, то оказалось что и нет таких... Поэтому я и взялся за проект. Считаю, что сделал полезную вещь. Я не хотел использовать чужие VID/PID. Опасность того, что Prolific может мне "предьявить" за использование их VID для меня недопустима. Тем более, что GitHub серьезно относится к нарушениям такого рода. Вот поэтому я и взял PID у pid.codes. Если внутри usb implementers forum не случится революция, то я в безопасности. А если случится, то у меня точно будет время подумать. Вам спасибо за пояснения! Это интересно.

Спасибо! Да, я понимаю, что можно было использовать любой VID. Но раз https://pid.codes дают, то чего бы не взять... Кроме того, у меня в дистрибутиве есть подписанный INF-файл для Win XP, 7, 8, мне хотелось подписывать "свой" VID/PID, просто по эстетическим соображениям. Но это чистой воды загон, да еще и денег стоило.

Спасибо. Подозреваю что в таком случае и нотификации бы заработали. Может быть не на всех платформах. Надо будет протестировать.

И тем не менее, через эту точку я в соответствии со стандартом USB передаю состояние линий DCD, DSR и событие переполнения буфера на прием, ошибку четности, что отображается на хостах. Я могу ошибаться, но PL2303 не работает с CDC Class drivers, а требует своих драйверов. Почему потребовалось эмулировать именно его? Ну и опять же, есть стандарт USB CDC, я со своей стороны стараюсь максимально ему соответствовать. Хотя и там есть пространство для интерпретаций. Если какие-то драйвера не реализуют часть функциональности, то это в целом проблема этих драйверов, а не повод мне отклоняться от стандарта. Разумеется если это не вопрос вида: устройство не работает с кривой реализацией драйвера в популярной операционной системе. Тогда уже придется изворачиваться. Но я согласен, раз не нужны уведомления, ваш способ вполне имеет право на жизнь. Собственно я об этом в самом начале и сказал. Я думаю, достаточно. Навскидку больше ничего посоветовать не могу. Если честно, то сомневаюсь в возможности получения PID для коммерческого устройства у STM в 2020 году. Причина в позиции организации занимающейся распределением VID. Продавать и передавать PID больше нельзя, к сожалению. У этого запрета сомнительный юридический статус, но тем не менее по моему мнению STM не будет связываться. Но это всего лишь мнение не подкрепленное практикой, поэтому я могу ошибаться.

Спасибо, на счет "очень хорошо" не уверен :) Немного разбираюсь, да. Посоветую читать стандарты, простите за банальность. Перед этим для разминки можно прочитать USB in a Nutshell. Еще неплохая идея смотреть исходники драйверов (в том же Linux). Я не знаю есть ли хорошие книги обучающие USB и тем более CDC. Скорее всего есть, но я ничего такого не читал и посоветовать не могу, простите. В общем случае эта задача не имеет решения. В стандарте CDC отсутствует такое событие как открытие порта. Однако до некоторой степени это можно эмулировать с использованием состояния управляющих сигналов. Например, DTR. Надо только убедиться, что терминал (или собственное ПО) при закрытии делает DTR неактивным. Именно для адаптеров как у меня, такой способ не годится, да и не нужен. А для всяких специализированных применений - вполне. Нужная информация передается в SET_CONTROL_LINE_STATE. В целом, да. У меня такого опыта не было. Когда организации в которой я работал потребовался VID, мы просто его купили. Для проектов с открытым исходным кодом рекомендую использовать https://pid.codes Эти ребята получили в подарок VID от компании которой он больше не нужен, и это было сделано до момента когда USB консорциум запретил передачу/перепродажу PID. Правда сейчас этот VID считается deprecated, но это не несет ровным счетом никаких последствий кроме того, что USB консорциум потешил свое самолюбие. Назначить этот VID другой компании они не могут согласно своим же правилам.

Это один из способов, но он плох тем, что нет возможности отправлять notifications (невозможно использовать несуществующий INTERRUPT IN endpotint). Но если надо просто слать информацию, то сгодится. Альтернативой может быть совместное использование одного INTERRUPT IN endpoint несколькими CDC устройствами. Из стандарта не следует что это не будет работать. Более того, в структуре данных notifications есть поле под номер интерфейса. То есть, теоретические можно сделать 6 полноценных CDC с notifications. Но я не тестировал это с реальными драйверами операционных систем. Очень может быть, что на практике это не взлетит.