Итак, я реализовал API USB-аксессуаров для Android таким образом, чтобы я мог подключить свой телефон к своему ноутбуку под управлением Linux, и он переведет телефон в режим USB-аксессуаров. Затем я могу получить доступ к аксессуару, открыть его и начать читать письмо к нему. Мой код выглядит практически идентично примеру в документации . Основное отличие состоит в том, что я использую отдельные методы чтения и записи и обращаюсь к ним через JNI из нативного кода.
Вот где это становится интересным. После успешного чтения / записи в течение секунды или двух массовая передача записей с моего ноутбука начинает выдавать ошибки тайм-аута, а затем вызов чтения для USB-аксессуара в Android вызывает IOException с кодом ошибки ENODEV. Это с подключенным кабелем, и UsbManager все еще перечисляет Аксессуар в списке, и у меня все еще есть разрешение на это.
Чтобы добавить к этому странности, я обнаружил, что, если я помещаю 100 мс в цикл чтения, проблема в основном исчезает (хотя это все еще случается иногда). Выспаться - это не просто ужасный клочок, а непомерная задержка в моем приложении. Чем меньше время сна, тем менее эффективным является взлом, где он неэффективен при 10 мс времени сна.
Я передаю около 20-30 кбит / с данных в режиме реального времени, используя массовые передачи (но не настолько, чтобы в режиме реального времени объемной передачи не хватало), и размер передачи колеблется от 50 до 800 байтов при 20- 30Гц. Может ли быть ограничение USB? У меня нет опыта работы с ним, поэтому я отношусь к нему примерно так же, как к сетевому сокету. Стоит ли ставить в очередь сообщения меньшего размера и отправлять их вместе в виде менее частых, но более масштабных передач? Есть ли проблема с небольшими объемными передачами с высокой частотой передачи? Я посмотрю на это, но я в основном хватаюсь за соломинку здесь.
Оборудование: