Дак их даже приводить не надо. Ибо input-подсистема ядра умеет работать с эндодерма сама. И они прекрасно генерят уже mouse-like эвенты из коробки. Для этого никаких лишних телодвижений делать не надо. Более того — сборка Qt4 под х86 прекрасно умеет с этими эвентами работать. Почему-то эту возможность не впилили в сборку под Embedded. Да и нет никакого кастомного обработчика в нашем случае — клавиатура обрабатывается как клавиатура, тачскрин — как тачскрин.
Наверное я выложил недостаточно предистории. Сейчас попробую исправить это тут.
Изначально у нас связь прибора с модулем была реализована так:
И все работало нормально. Но потом купить такой USB хаб стало невозможно, и мы заменили его на CY7C65642. Тут и начались проблемы. При этом если карта работала напрямую с USB хостом — данные не терялись. Мы начали дебажить и заметили что в какой-то момент урбы от хоста на модуль не уходят. Читали разные доки по USB и в одной наткнулись на такую фразу:
4.3.1.3.6.1 Transmission Errors
For errors in this category, USB defines a policy that allows the transaction to be retried for up to three times before the transfer is failed and returned to the client.
Отсюда и возникло предположение что данные могут не дойти в USB bulk.
Ситуация усугублялась тем, что много приборов уже было поставлено и заменой хаба проблему было не решить. После долгих копаний и отладки был выбран EEM + TCP/IP.
по пунктам:
ACM работало как надо. Просто при приеме кривого пакета мы в силу кривизны алгоритма убегали за пределы памяти.
Насколько я помню — OTG корка генерит нам прерывание о возможности выгребать пакет из FIFO когда уже все ACK пришли.
работа с ЕЕМ заголовком происходит на том уровне, когда никакого ТСР еще нет.
И кто бы вы думали искал тут виноватых? Пост вообще-то не о том как какие-то нехорошие люди сделали плохой алгоритм, а мы его героически исправили. Даже наоборот — в силу сложившихся обстоятельств мы наступили на самолично написанные ранее грабли и узнали немного нового.
Поняли мы это по странному поведению цепочки утилит, которая обрабатывала данные на выходе с программы usbgather. Они-то рассчитывали на железобетонно целую рефлектограмму. Эхх, знали бы мы тогда как мы ошибались :)
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Изначально у нас связь прибора с модулем была реализована так:
И все работало нормально. Но потом купить такой USB хаб стало невозможно, и мы заменили его на CY7C65642. Тут и начались проблемы. При этом если карта работала напрямую с USB хостом — данные не терялись. Мы начали дебажить и заметили что в какой-то момент урбы от хоста на модуль не уходят. Читали разные доки по USB и в одной наткнулись на такую фразу:
4.3.1.3.6.1 Transmission Errors
For errors in this category, USB defines a policy that allows the transaction to be retried for up to three times before the transfer is failed and returned to the client.
Отсюда и возникло предположение что данные могут не дойти в USB bulk.
Ситуация усугублялась тем, что много приборов уже было поставлено и заменой хаба проблему было не решить. После долгих копаний и отладки был выбран EEM + TCP/IP.
ОТГ — в модуле. А со стороны прибора там ОТГ, потом хаб, потом уже ОТГ модуля.
USB — лично для меня — сложность отладки.
ACM работало как надо. Просто при приеме кривого пакета мы в силу кривизны алгоритма убегали за пределы памяти.
Насколько я помню — OTG корка генерит нам прерывание о возможности выгребать пакет из FIFO когда уже все ACK пришли.
работа с ЕЕМ заголовком происходит на том уровне, когда никакого ТСР еще нет.
И кто бы вы думали искал тут виноватых? Пост вообще-то не о том как какие-то нехорошие люди сделали плохой алгоритм, а мы его героически исправили. Даже наоборот — в силу сложившихся обстоятельств мы наступили на самолично написанные ранее грабли и узнали немного нового.