Добавлено after 1 hour 12 minutes 5 seconds: Предлагаю ознакомиться с How does USB stack enumerate a device от программиста USB-стека Windows 7. Предполагаю, что в Windows 10, судя по логам, ничего не изменилось. То есть, более 80% всех компьютеров действуют по этому алгоритму. Вот это можно назвать обычно.
Последний раз редактировалось VladislavS Вт апр 06, 2021 16:58:36, всего редактировалось 1 раз.
На компе-то? Да хоть мегабайт! Я при обработке изображений иной раз вообще буферы в гигабайт выделяю для вспомогательных целей… P.S. А как игровые приставки энумерацию производят, мне глубоко наплевать! Я еще не скатился до такого маразма, чтобы игровые приставки для работы использовать.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Категоричное ОБЩЕИЗВЕСТНЫЙ ФАКТ ничего общего не имеющее с действительностью.
То есть для вас одно из старейших соглашений является откровением. Уж извините, но настолько агрессивного оппонента я учить что-то не хочу. Когда успокоитесь, почитайте про историю Си, про раздельную компиляцию и подобные вещи. В частности зачем разделяют *.c и *.h файлы, почему библиотеки обычно используются в скомпилированном виде.
Цитата:
Все ошибаются, про 8 байт в ep0 вы же поправились.
В смысле? Я два раза написал одно и то же, только во второй раз чуть более развернуто.
Цитата:
Откуда вы это взяли? Вы готовы доказать, что 50% + 1 хостов так делают?
Из личных наблюдений. Какую еще гарантию вы хотите на неопределенное "обычно"?!
Eddy_Em писал(а):
Я бы в своей реализации хоста в случае неизвестного размера дескриптора просил бы выслать 256 байт
Ну, доберетесь до реализации хоста (а я очень надеюсь что доберетесь - надо же мне будет у кого-то списывать!), выставите более разумную длину. Вообще-то я тоже не знаю почему компьютер использует такой скромный размер. Может, ограничения аппаратного модуля? Но ведь ему потом все равно принимать пакеты до 65535 байт. А может опять для защиты от кривых устройств, чтобы не ждать полторы вечности когда выйдет таймаут. Хотя ума не приложу как именно устройство должно быть сломано оно так проявилось.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Перестаньте с упорством барана догматы из Си переносить на С++.
То есть вы утверждаете что с матчастью ознакомились. Хорошо. Так для чего введено разделение *.c/*.h и *.cpp/*.hpp? Что такое раздельная компиляция? Почему библиотеки хранятся в скомпилированном виде?
Цитата:
Ну я, например, нашёл описание как делает самая массовая ОС.
Ради чего? Чтобы проиллюстрировать никому не нужный факт. Нет, оно конечно интересно, спасибо вам за ссылку. Подобные рассказы помогают запомнить или уложить в голове какую-то информацию. Но, как бы вам сказать... не самую ценную информацию вы решили иллюстрировать.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Ну, доберетесь до реализации хоста (а я очень надеюсь что доберетесь - надо же мне будет у кого-то списывать!), выставите более разумную длину.
У меня пока вообще никаких идей нет, зачем может понадобиться на микроконтроллере организовать хост. Мышу или клавиатуру туда воткнуть? И поддерживать эти 100500 вариантов HID? Какой же "толщины" прошивка в этом случае получится?
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Чтобы показать, что первый запрос Device Descriptor размером в 8 байт не имеет ничего общего со словом "обычно". Да и просто полезная информация для разработчиков устройств, чтобы понимать что же хост ждёт от устройства. Официальная спецификация не столь понятно написана, к сожалению.
У меня пока вообще никаких идей нет, зачем может понадобиться на микроконтроллере организовать хост.
Например. Еще в общих чертах могу представить зачем подключать флешку. Хотя конкретных применений тоже с ходу не придумаю. Или где-то натыкался на такой оригинальный способ вывода звука - через usb-host и внешнюю usb-звуковуху. Хотя у звуковух еще более мозговыносящие дескрипторы, чем у HID.
Мышу или клавиатуру туда воткнуть? И поддерживать эти 100500 вариантов HID? Какой же "толщины" прошивка в этом случае получится?
У HID все же есть структура, можно выловить какие байты отвечают за кнопки и координаты. Да банально найти usage_page(generic_desktop) + usage(keyboard) а потом считать Input'ы... Да... все просто... всего-то пара лет работы...
VladislavS писал(а):
Предлагаю вам ознакомиться с этим самостоятельно.
То есть вместо ответа и дальнейшей конструктивной дискуссии всего лишь попытка перевести стрелки. И почему я не удивлен...
VladislavS писал(а):
Чтобы показать, что первый запрос Device Descriptor размером в 8 байт не имеет ничего общего со словом "обычно"
Во-первых, ваша ссылка это не доказывает. Собственно, доказать или опровергнуть размытое "обычно" довольно сложно. А главное - даром никому не надо. Если, конечно, цель не попытаться цепляться к словам, как у вас. А во-вторых, наблюдаемое поведение нескольких операционных систем (что мной, что вами, что автором той статьи) в любом случае не может быть руководством к написанию софта. Руководством является документация. И ничего не помешает, скажем, Eddy_Em, написать свою реализацию хоста, которая в зависимости от фазы луны будет запрашивать от 1 до 9000 байт. Ну, кроме здравого смысла. Потому что объективной причины запрашивать именно 8 байт, а не 18, я не вижу. Кроме поддержки каких-нибудь кривулек, не умеющих следовать стандарту.
VladislavS писал(а):
Официальная спецификация не столь понятно написана, к сожалению.
Вы имеете в виду что в ней нет требования к хосту запрашивать именно 8 байт? А зачем оно там? А даже если бы было - зачем это устройству? Я уже два раза писал, что устройство обязано поддерживать разбиение пакета на кусочки по размеру ep0. И обязано отправлять не больше данных, чем хост хочет принять (хотя нормальные ОС все же допускают некоторые косяки).
То есть вместо ответа и дальнейшей конструктивной дискуссии всего лишь попытка перевести стрелки.
Опыт предыдущего хода дискуссии показал, что вы не воспринимаете то что вам говорят и соответсвенно дальнейшая дискуссия не имеет перспектив. Это называют "как об стенку горохом". Обучать вас насильно мне не доставляет удовольствия. Так что, самостоятельно.
Именно начинается обмен проходят первые приветствия идет запрос конечных точек и все облом.
Что значит "запрос конечных точек"? Если ConfigurationDescriptor передался, то хоть как-то в системе опознаться должно. Хотя в winXP не уверен...
Я точно не помню - надо уточнить - но доходит до запроса от хоста описания уже рабочих конечных точек (вид и пид принимается, но не отображается в системе устройство (точнее отображается по резистору на линию данных)) после отдачи выполняется перезапрос а потом пакет по которому , согласно спецификации, устройство должно отключится.
Если руки не из задницы, то ничего не мешает переписать все на современный лад!
Там мегабайты ассемблерного текста. Вы предсталяете объем работы, а переферия в виде ISA и PCI нестандартных плат, есть даже железо подключаемое вместо дисководов, чей контролер используется как высокоскоростной асинхронный приемопередатчик. Во времена ХТ было актуально. Вот одно из изделий переводим с ISA на USB. Еще одно с ISA на Ethernet - но не идет - уже второй программист уволился не сдюжив.
Опыт предыдущего хода дискуссии показал, что вы не воспринимаете то что вам говорят и соответсвенно дальнейшая дискуссия не имеет перспектив. Это называют "как об стенку горохом". Обучать вас насильно мне не доставляет удовольствия. Так что, самостоятельно.
Вторая попытка перевода темы замечена и проигнорирована. Я не просто так задал вопросы. И не потому что не знаю ответы на них. Мне хочется услышать вашу версию. Хотя бы потому что в отличие от вас мне интересно не цепляться к словам и формулировкам, а обсуждать внутреннее устройство, логику и иногда философию.
Нет, я не это имел в виду, а ровно то что написал. Не надо за меня домысливать.
Раз видите что я вас понял неправильно, сформулируйте свою мысль по-другому. Или это очередная попытка демагогии - высказаться максимально мутно чтобы на любые возражения отвечать "вы меня неправильно поняли, я такого не говорил"? Ну так методы борьбы с демагогами давно известны: задавать конкретные вопросы и нудно добиваться ответов.
Wladimir_TS писал(а):
Аппаратный контролер на параллельной шине. Тип завтра могу сообщить.
Мне достаточно информации что это внешний модуль, спасибо. Пользоваться подобным я вряд ли буду, раньше тоже не интересовался, поэтому и подсказать именно по нему не смогу. Максимум - по устройству самого USB, к железу не привязанному.
Wladimir_TS писал(а):
Я точно не помню - надо уточнить - но доходит до запроса от хоста описания уже рабочих конечных точек
Все равно не понимаю. Описания всех конечных точек (кроме ep0) находятся в ConfigurationDescriptor'е. Пока хост его не прочитает, он к точкам обращаться не будет. Кстати, вы не пробовали сначала более простое устройство сделать, без дополнительных точек и с максимально короткими дескрипторами? Я там раньше кидал ссылку на свою статью по USB на stm32, если не ошибаюсь, у первого устройства, которое CustomHID, все дескрипторы меньше 32 байт, то есть не требуют разбиения по размеру буфера. Вдруг у вас проблема все-таки в нем.
Wladimir_TS писал(а):
Не не идут .
Сочувствую, что тут еще сказать. Но на счет перехода на современные системы все-таки подумайте и начальство попинайте. Рано или поздно компьютер с winXP сломается, а на новый может не найтись дров. То же с внешним железом: если оно времен DOS'а, то тоже рано или поздно сломается, придется покупать новое, а оно уже на XP не факт что заведется.
Скорее всего выводился контроллером на UART, а оттуда переходником на компьютер. По крайней мере это стандартная практика. Иногда можно еще отладчиком смотреть напрямую в памяти, но это сложнее.
Кстати есть ограничение на время ответа после запроса по конечной точке 0 ?
Какие-то таймауты, конечно, есть, но разумные, порядка единиц - сотен секунд. Вряд ли ваш контроллер так долго готовит ответ. Нет, VladislavS, это не из документации данные, а из опыта, можете не тратить силы на требование доказательств: искать подобную мелочь мне лень.
Я точно не помню - надо уточнить - но доходит до запроса от хоста описания уже рабочих конечных точек
Все равно не понимаю. Описания всех конечных точек (кроме ep0) находятся в ConfigurationDescriptor'е. Пока хост его не прочитает, он к точкам обращаться не будет.
Запросов там много разных, таблица большая была - просто сейчас уже мало что помню, надо вспоминать - 2 года назад ковырялся. Пакеты небольшие - порядка 20-30 байт, добиваются, как требует стандарт до 64 нулями. CRC контролер считает сам. В общем первые запросы отрабатываются, в том числе передача VID и PID? потом идет запрос конечных точек - говорю 2 штука. Запрос описания конечных точек, отправляю описание и тут что-то не то, идет повторный запрос, после чего отлуп.
Кстати, вы не пробовали сначала более простое устройство сделать, без дополнительных точек и с максимально короткими дескрипторами? Я там раньше кидал ссылку на свою статью по USB на stm32, если не ошибаюсь, у первого устройства, которое CustomHID, все дескрипторы меньше 32 байт, то есть не требуют разбиения по размеру буфера. Вдруг у вас проблема все-таки в нем.
Сочувствую, что тут еще сказать. Но на счет перехода на современные системы все-таки подумайте и начальство попинайте. Рано или поздно компьютер с winXP сломается, а на новый может не найтись дров. То же с внешним железом: если оно времен DOS'а, то тоже рано или поздно сломается, придется покупать новое, а оно уже на XP не факт что заведется.
Там ПО очень непростое сильно завязанное на тайминги к тому-же работающее с уникальными ISA и PCI платами сделанными под заказ еще в 90х Документации по устройству тех плат нет. конторы, что их делала - тоже давно нет. Исходники ПО есть - ассемблер с минимумом комментариев.
Судя по вашим вопросам, вам для завершения разработки жизненно необходимо нормальную отладку заиметь. Не знаю возможно ли это на данном этапе вашей разработки, но раз уж вы в теме STM32 пишете, то рискну посоветовать их и применить. Примеров реализации USB на них в сети вагон и тележка. Вероятность получить помощь сейчас сильно выше, чем по AVR. На худой конец в том же кубе натыкать можно.
На компе любой терминал, подключаемый по IP откуда угодно. Это лог из контроллера. Лог обмена со стороны компа WireShark можно снять. Но куда полезней видеть что внутри контроллера происходит, вы же его отлаживаете, а не комп.
Сталкивался - что за время сброса содержимого буфера через UART на 115200 компьютер давал отлуп. А сбрасывалось-то 64 байта.
А вы что, без буферизации сбрасываете? Ну в смысле обычно для UART создают очередь передачи, откуда в прерываниях байты передаются по одному. Соответственно и задержек особых не добавляется.
Всех приветствую, попробую оживить тему, уже убил уйму времени, но проблему решить не удаётся. Пытаюсь освоить USB на контроллерах с OTG и не могу победить отправку. Делаю следующим образом: 1. Заполняю регистр DIEPTSIZ (PKTCNT = размер посылки / макс.размер пакета с округлением вверх, XFRSIZ = общий размер посылки). 2. Разрешаю прерывание по пустому буферу (устанавливаю бит в DIEPEMPMSK) 3. Устанавливаю биты CNAK и EPENA в регистре DIEPCTL. 4. Отправляю первую порцию данных (записью в TXFIFO).
В обработчике прерываний ловлю событие TXFE, в котором дописываю в TXFIFO следующую порцию данных (размер определяю по значению DTXFSTS), вроде все нормально, НО не случается события XFRC (то есть окончания передачи). Для отладки в событии TXFE логировал значение DIEPTSIZ, почему-то поле XFRSIZ декрементируется (причем правильно, каждый раз уменьшается на макс. размер пакета), а вот PKTCNT почему-то не уменьшается. Судя по RM этот регистр, вообще говоря, читать нельзя, пока бит EPENA в регистре DIEPCTL не сброшен, возможно, PKTCNT неявно и уменьшается, но тогда вопрос, почему не приходит событие окончания передачи.
Вдруг кто-то сталкивался, прошу помощи.
UPD: с конечными точками с большим макс.размером пакета, когда всё укладывается в одну посылку, всё работает нормально (и HID, и CDC удалось завести), а когда надо слать порциями - сломалось.
Отвечу сам себе. Дело в том, что отличия в модуле USB между f0/f1 и f4 (а точнее между обычным USB и USB_OTG) более чем существенные, и если для первых после приема пакета необходимо сбросить флаг USB_EP_CTR_RX и конечная точка сразу же готова к приему, то в OTG после приема пакета ничего сбрасывать не надо, однако для точки OUT аппаратно устанавливается состояние NAK. В моем случае проблема была в том, что если в процессе нумераций прилетел неизвестный (неподдерживаемый) пакет, то я ничего не отправлял, то есть в IN не записывал, а на успешную отправку стоит callback с разрешение точки OUT. Собственно, проблема решилась принудительным сбросом NAK (разрешением конечной точки) для OUT 0.
Всем привет, продолжаю побеждать OTG, все работает, но сейчас отправка реализована так, что посылаю по одному пакету макс.размера (то есть ловлю XFRC, заново настраиваю DIEPTSIZ и DIEPTCTL и так пока данные не закончатся).
Решил переделать на более правильный вариант, который подразумевает, что в регистре DIEPTSIZXFRSIZ нужно положить общий размер в байтах, а в PKTCNT количество пакетов (которое равно размеру, поделенному на макс. размер пакета с округлением вверх).
Собственно, какую странность обнаружил: все работает отлично, если макс. размер пакета больше 8 байтов, НО если макс. размер конечной точки данных равен 8 байтам, то посылки в 64 байта и выше не отправляются. То есть отправить 64 / 8 не получается (а 56 / 8 работает), но стоит изменить макс. размер пакета хотя бы на 16, все снова работает нормально (например, 512 байтов отправить получается). Такое ощущение, что конечная точка с макс. размером пакета в 8 байтов ломает весь USB. Может, кто-нибудь сталкивался с таким поведением?
Согласен, приемлемо, я так и сделаю скорее всего, однако эксперименты меня всё больше удивляют, опишу их результаты, вдруг кому-то пригодится:
1. В обработчике пустого буфера FIFO решил проверить значение DTXFSTS и XFRSIZ, для чего пишу их в Uart. 2. Первая особенность: первым всегда прилетает пара <размер_буфера>/<0>. Я не понял, почему. 3. Вторая особенность: с записью этих значений в Uart проблема решилась, то есть точка с размером пакета в 8 байтов заработала, что я связываю с какой-то гонкой.
И еще один эксперимент: поменял макс.размер пакета для точки на 16 байтов, а также глубину FIFO буфера увеличил вдвое, и получил ровно такую же проблему. Появилась гипотеза, что слишком большой буфер (пока порог одинаковый - в 4 раза больше макс.размера пакета) таким образом ломает передачу.
Думаю, что просто оставлю пока как есть или откажусь от 8-байтовых точек (что, правда, не гарантирует положительный результат), но эффект интересный и непонятный.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 39
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения