Cdc acm ko android

Глонас я отключил в нем, под виндой по Юриной инструкции через юцентр

А можно подробнее? У вас Нексус? Андроид 7?
Порт ttyACM не меняет свой номер при передёргивание в хабе?
Какую либу использовали?

Есть MINIX NEO-U1 (на чипе S905). На нем стоит Андроид 6.0.1 (кастомная прошивка с форума Миникса). Рут поставлен.
ublox m8030 (куплен тут: https://ru.aliexpress.com/item/USB-G. 311.0.0.rOY6ow). Ядро 3.14.29

Сначала делал все по инструкции в шапке. Драйвера для pl2303 не подошли. Нашел в Интернете модуль, который подходит. нашел, но ни одна навигационная программа не видит данные.
Затем на сайте миникса нашел инструкцию (http://www.minixforum.com/threads/howto-enable-gps.556/) пробовал ее, но увы. Результата нет.

Пробовал через программу you are here gps, тоже нет результата.

К слову сказать ublox определяется как ttyACM0. Это меня навело на мысль, что нужен не драйвер pl2303 а cdc-acm.ko.
Поиск его под мое ядро и архитектуру успехов не дало. Если у кого есть (или кто может скомпилить) буду признателен.

Что делать? Купить другой ГПС ресивер или помучать этот?

Кстати вопрос (еще один). Я правильно понимаю, что железка данные (NMEA) отдает (см. скрин)?

Источник

Cdc acm ko android

Инструкция для подключения внешнего USB GPS к андройд девайсам.

Предисловие:
p.s. by tsynik

GPS состоит из драйвера и C-либы Андройд, которые независимы. Драйвер отвечает за физическое unix-устройство (/dev/ttyACMxxx /dev/ttyUSBxxx), если оно появляется — в терминале достаточно (и обычно даже не обязательно) установить скорость и читать поток NMEA (cat /dev/ttyUSBxxx). Далее, нужно передать эти данные системе через MOCK LOCATIONS (множество вариантов софта в маркете и в сети типа USBGPS4Droid), либо использовать C+ либу (завязана на версию андроид, может как иметь, так и не иметь настраиваемых параметров имени устройства и скорости порта).

-Для GlobalSat BU-353(SiRF Star III) и их семейства необходим модуль моста PL2303, => pl2303.ko 4800\9600
-Для Locosys LS23030 (MTK3339), LS23030-G(MTK3333), GlobalSat BU-353G(MTK3333) необходим модуль моста PL2303, => pl2303.ko
-Для Locosys LS23090, Locosys LS23030 и других (noname) GPS на чипах MediaTek (MTK3329), => cdc-acm.ko 115200
-Для Holux M-1000B, необходим адаптер FT232RL, => ftdi_sio.ko
-Так же может стоять модуль моста CP2102, => cp210x.ko

Нужные вам модули кидаем в папку «/system/lib/modules/»
Права на них выставить 644:

Для загрузки, выполняем команду:

Если модуль успешно загрузился, можно посмотреть его наличие в памяти командной lsmod

В дальнейшем добавляем загрузку модуля в скрипт автозагрузки. (init.d или install-recovery.sh способом)

Софтовая версия модуля pl2303.
Которая не зависит от версии ядра и устройства. Должна работать у всех.
http://pccar.ru/showpost.php?p=321632&postcount=35

NEW! Версия pl2303drv с исправленной ошибкой «only position independent executables (PIE) are supported». thx DelleTenebre! :derisive:
http://pccar.ru/showpost.php?p=392461&postcount=1072

(в архиве new_gps.sun4i.so.zip)
Это обновленная версия либы, теперь в ней исправлен глюк с рестартом. Т.к раньше после сна или переключения устройства, приходилось постоянно ее перезагружать. была проблемма с переинициализацией.

Установка.
1. Кинуть с заменой файлов по пути /system/lib/hw и выставить права 644:
Только возможно потребуется переименовать. Смотрите gps.XXXX.so, где XXXX — название вашей.
gps.glofish.so -не трогать.

Например:
устройства на А10, -это gps.sun4i.so (для стока), gps.exDroid.so (кастом СМ9)
устройства на RK3066, RK3188, Amlogic 8726-MX -это gps.default.so

2. Добавить в автозагрузку команду

где:
4800 — рабочая скорость устройства. (4800, 9600, 14400, 19200, 28800, 38400, 57600 или 115200)
ttyUSB0 — это имя вашего устройства GPS в /dev.
Название может быть другим, например ttyACM0, ttyACM1. 2,3 и т.д.

3. Не забываем выставлять права доступа на gps устройство в /dev .

Решение некоторых проблем.

1. Проверяем текущую скорость порта командой «busybox stty -F /dev/ttyUSB0»
Потом, выставляется ли скорость командой «busybox stty -F /dev/ttyUSB0 speed 4800»
Бывает такое(зачастую на rk3066), что модуль pl2303.ko уже вкомпилен в ядро, и система не дает изменить скорость. ошибка «cannot perform all requested operations»
Решение нашел и описал подробно macau. читаем инструкцию

2. Если после ввода «cat /dev/ttyUSB0», побежали NMEA данные, либа на месте, но нави-софт не видит спутники:
-Проверяем есть ли пункт: «Настройки -> Местоположения -> По спутникам»
Что бы его добавить нужно:
Создать отсутствующий элемент android.hardware.location.gps.xml в папке \system\etc\permissions со следующим содержимым:

Использовать в крайних случаях. т.к это костыль

А для тех, у кого либа не завелась. или по иным причинам.
Предлагаю попробовать новую версию софта UsbGPS, а именно
UsbGPS4DHoneycomb_MR1 alpha1

В настройках -> Для Разработчиков -> ставим галку «Фиктивные местоположения» (Mock Locations)

Требуется андройд версии 3.0 и выше (Android SDK version 12)

Из минусов данного способа является то, что навигационные программы не видят количество спутников.

Часовой пояс GMT +4, время: 04:50 .

Страница 1 из 137

101

Last »

Работает на vBulletin® версия 3.8.4.
Copyright ©2000 — 2021, Jelsoft Enterprises Ltd.
Перевод: zCarot

Источник

Тема: Простой USB HID контроллер под Windows или Android 4-й версии

Опции темы

Поиск по теме

Отображение

Простой USB HID контроллер под Windows или Android 4-й версии

Прошлая, 3-я версия тут.

Главным ее отличием является:
— переход на 32-х битный микропроцессор ARM;
— встроенный источник питания 5В 2А на основе KIS-3R33S;
— поддержка шины IEBUS (AVC-LAN);
— поддержка шины BMW IBUS;
— поддержка HID CDC для UART GPS приемников или других устройств;
— подключение и управление внешними навигационными блоками GARMIN, PHANTOM, KENWOOD и т.д.
— поддержка мультитач жестов на обычной резистивной тачпанели

Кратенько по железу:
— 32-х битный контроллер ARM с аппаратным USB;
— источник питания DC/DC всеми любимый KIS-3R33S с защитой от бросков напряжения бортовой сети и возможностью полного программного отключения при отсутствии АСС;
— вход BAT и АСС;
— выход для питания тв-боксов 5В 2А которые можно повторно включить внешней штатной кнопкой включения;
— управляемый выход для питания свистков 5В 2А которые можно повторно включить только предварительно выключив;
— 2 выхода типа открытый коллектор до 500mA для управления кнопкой включения планшета, тв-бокса, либо внешним реле или выдачи ИК кода. ;
— 6 цифровых входов/выходов с защитой. Из них 2 шины — UART и шина I2C, 2 выхода ШИМ.
— 4 канала для подключения резистивных кнопок руля или внешних кнопок, джойстиков. (до 15 кнопок на канал);
— линии для подключения 4-х проводной тачпанели с внешним мультиплексором. Мультиплексор выполнен на отдельной плате 25×20мм с кабелем 20 см;
— 2 канала опроса цифровых энкодеров с предделителем;
— 2 линии аналогового входа 0. 18В;
— 2 канала аналогового управления штатными магнитолами;
— шина IEBUS (AVC-LAN) для эмуляции внешнего навигатора, внешнего DVD и CD чейнджера, управления штатным усилителем Toyota/Lexus без штатного головного устройства, чтения кнопок по шине, управления с родного тача головных устройств. ;
— разъем микро-USB + возможность припайки внешнего кабеля USB (питается контроллер только от BAT);
— размер платы 50×65мм;

Если кратко, то обеспечивает такой функционал после установки:
System.jpg

По софту включает все, что есть в 3-й версии.
Кроме того предоставляет хосту HID CDC устройство для подключения внешних модулей GPS с UART интерфейсом. Например такого или такого. Под windows он видится как обычный COM порт, для Android — ttyACMx (необходимо подключить драйвер cdc-acm.ko соответствующий версии ядра).
Увеличено количество типов поддерживаемых событий. В частности теперь с помощью события «Таймаут» можно организовать последовательную цепочку реакций на любое событие. Добавлены события для отслеживания напряжений на аналоговых входах и активации/деактивации шины USB хоста.
С помощью событий «Напряжение» и «Таймаут» элементарно делается переключение на камеру заднего вида и обратно на мониторах с кнопкой переключения источников.
Добавлены и реакции. Теперь любой ИК код можно выдавать на любые свободные ножки разъемов.
Кроме того добавлена реакция «USB нажатие» — виртуальное нажатие на тачпанель для совершения определенных автоматических действий.

Комплект состоит из собранной платы контроллера, разъемов с контактами, платы мультиплексора с кабелем и разъемом, 4-х проводный FPC шлейф длиной 20 см для подключения к штатной схеме тачпанели.
На фото показаны обе стороны платы мультиплексора. На одной 4-х контактные FFC разъемы с шагом 1мм, на обратной — 8 контактные с шагом 1мм.
IMG_2481.jpg
Для тех, у кого нет места для платы мультиплексора рядом со штатным тачем могу доукомплектовать 2-мя разъемами FFC(как на плате мультиплексора) и еще одним 4-х проводным FPC шлейфом длиной 20 см.

При заказе уточняйте тип шлейфа тачпанели, варианты:
— 4-х контактный шлейф с шагом 1мм (если не уточняете, то идет по умолчанию);
— 8-контактный шлейф с шагом 1мм;
— 8-контактный шлейф с шагом 0.5мм и такой-же разъем на плате мультиплексора вместо 4-х контактного с шагом 1мм.

Графическая оболочка для программирования YAMDT_GUIV4_V0413.zip
Текущая прошивка для загрузки через оболочку droid_touch4V0413.zip
Текущая прошивка без поддержки обычных кнопок (чтобы в андроиде не пропадала экранная клавиатура) droid_touch4V0413_wo_keys.zip
inf файл виртуального COM порта для windows DROID-TOUCH-V4-INF.zip
Чтобы не было курсора при нажатиях вообще, этот файл (после распаковки) положить в /system/usr/idc Vendor_ffff_Product_0011.zip, и выставить права 644.
Описание YAM-DROID-TOUCH-V4_V0413.zip
Подключение YAM_DROID_TOUCHV4_CONN.zip

Приехали UART GPS Glonass приемники по второй ссылке. Шли 12 дней, неплохо по моему.
IMG_2581a.jpg
Подключение к контроллеру:
VDD к X4/1
TXD к X4/2
RXD к X4/3 можно не подключать вовсе.
GND к X4/4
или
VDD к X6/1
TXD к X6/2
RXD к X6/3 можно не подключать вовсе.
GND к X6/4

Переключение между GPS и Glonass описано тут.

Видео работы под windows
Может работать и как сенсор местоположения под win7/8 (кому надо — в личку)

Работа в Андроид Навителе
Как оказалось в моем свистке уже встроен cdc-acm.ko драйвер, осталось добавить в автозагрузку только
setprop ro.kernel.android.gps ttyACM0
sleep 50
chmod 666 /dev/ttyACM0
Ну и переписать либу куда указано.
Вообще все подключение описано в теме уважаемого Rage2.

Есть ограниченное количество этих GPS модулей, кому надо — заказываете.

Управление мультитач жестами на примере зума и регулировки громкости с мьютом.
Файл конфигурации данного примера Gestures.zip

Так-же оказываю всяческую помощь в настройке контроллера под Ваши нужды и консультирую по скайпу или иным способом. Прошу обращаться в личку.

Цена осталась в районе стоимости 3-й версии.

Все вопросы по цене ( в личку. ).

Источник

Как мы преодолевали передачу данных по USB

С чего все началось

Итак, в нашем замечательном приборе Беркут-ММТ (на базе PXA320 и GNU/Linux) есть не менее замечательный модуль OTDR (на базе STM32 и NutOS), представляющий собой импульсный оптический рефлектометр. Эта связка работает следующим образом: пользователь нажимает на экране на различные элементы UI, в приборе происходит немножечко магии, и желания пользователя трансформируются в команды вида «duration 300», которые уходят в измерительный модуль. Конкретно эта команда выставляет длительность измерений в 300 секунд. Модуль к прибору подключен по USB, для передачи команд поверх USB поднят CDC-ACM.

Кратенько — CDC-ACM позволяет эмулировать последовательный порт через USB. Так что для верхнего уровня наш измерительный модуль в системе доступен как /dev/ttyACM0. CDC-ACM служит для передачи команд в модуль или чтения текущих настроек/состояния модуля. Для передачи самой рефлектограммы служил USB Bulk интерфейс, который все свое время посвящал только одному — передаче данных рефлектограммы из модуля в прибор, как бинарного потока данных. В какой-то момент мы заметили, что рефлектограмма приходит к нам не полностью. Так мы открыли для себя, что USB может терять данные.

Схематично это выглядело так:

b5-cardifaced — это демон, который принимает команды по D-Bus и отправляет их в карту через CDC-ACM интерфейс. Результат выполнения посылает обратно по D-BUS.

usbgather — небольшая программка, которая работает на базе libusb и занимается тем, что выгребает из модуля рефлектограмму через USB Bulk и выдает ее на stdout.

Костыли и велосипеды

Сели мы и подумали — нам нужно понимать вся ли рефлектограмма к нам пришла для возможности пропуска неполных рефлектограмм. Стали мы придумывать различные хитрые заголовки, контрольные суммы и тд. Потом поняли что изобретаем ТСР. И тогда было принято волевое решение вместо USB Bulk завести TCP/IP поверх CDC-EEM. Почему CDC-EEM? Потому что CDC-EEM позволяет наиболее просто использовать USB как транспорт для передачи сетевого трафика. На самом приборе поддержка CDC-ECM в ядре есть, а модулях мы используем NutOS в качестве операционной системы и поддержка CDC-EEM и TCP/IP стек в NutOS был.

Фикс длинною в жизнь 3 месяца

Казалось бы — ни что не предвещало беды. Подняли CDC-EEM, настроили IP адреса. Ping? Есть ping! Ура. Изменили механизм передачи данных с USB Bulk на передачу данных через TCP-сокет. Вот-вот должно было наступить счастье, но тут внезапно при тестировании сеть упала с криками в dmesg о своей непростой жизни, наших кривых руках и вставшей колом очереди на отправку для нашего сетевого интерфейса. Примерно так:

Если кратенько, буквально в двух словах — каждый сетевой интерфейс имеет таймер, который засекает время с каждой последней отправки данных и если оно превысило некий интервал — мы видим это сообщение. Дальше все зависит от драйвера — некоторые после этого нормально работают, некоторые — нет.

Корень зла

Все вышеперечисленное усугублялось сообщениями в dmesg о неизвестных link cmd. Добавили побольше дебага и узнали, что нам на USB host приходит ответ на echo request, который мы не посылали.

Когда ничего не работает — настает время читать документацию. Вот и мы раздобыли доку по CDC-EEM, да не откуда-нибудь, а прямо с usb.org. Оказывается первый EEM-пакет это не только кучка данных, но еще и EEM-заголовок, в котором содержится тип пакета (управление или данные) и длина данных. И да, у CDC-EEM есть свой echo request/echo response.

Но наше счастье было бы не полным, если бы не еще одна деталь — при приеме служебных пакетов модуль зависал. Наглухо. Вместе с CDC-ACM.

У нас в модуле USB было настроено так, что передача шла пакетами по 64 байта. Соответственно один Ethernet пакет бился на N пакетов по 64 и передавался через USB. Вот так:

После весьма продолжительного изучения ситуации мы пришли к выводу, что происходит вот что: мы теряем часть EEM-пакета (да, USB не гарантирует доставку). Но мы прочитали из заголовка длину и опираемся на нее. Соответственно мы из следующего пакета вычитываем N потерянных байт, а следующие данные воспринимаем как начало нового EEM-пакета и интерпретируем первые 2 байта как заголовок. А там может оказаться все что угодно. Вплоть до взведенного в 1 бита, который указывает что это служебный пакет. В совсем плохих случаях мы ловим такие данные, которые при интерпретации как EEM-заголовок дают нам Echo Response огромной длины. Гораздо большей, чем наша оперативная память. Так мы поняли что наша реализация usbnet в NutOS требует серьезных доработок.

Больше проверок хороших и разных

В процессе ковыряния usbnet в NutOS было выяснено, что текущий вариант вообще не готов к приему служебных пакетов. От слова совсем. Мы сделали новый вариант, который стал способен корректно обрабатывать служебные пакеты, а именно: мы смотрели тип пакета, ибо на echo по стандарту мы ответить обязаны; проверяли длину — если она больше MTU — то мы явно словили мусор. Еще нашли странность в функции, запускающей передачу данных по endpoint’у: мы проверяли — не занят ли сейчас нулевой endpoint, и если занят — просто выходили и все. Вызывающий эту функцию всегда считал что передача данных запущена, а часто получалось что нет. В итоге мы теряли данные, причем в обе стороны.

Были войны с ТСР-сокетом — иногда данные не передавались и мы не видели почему. Не знаю что руководило разработчиками NutOS, но множество функций, имеющих возвращаемый тип int в любой непонятной ситуации возвращали «-1». Некоторые из них записывали реальный код ошибки в информацию о сокете, некоторые нет. Так что пришлось позаниматься протаскиванием кодов возврата с самых низов, вроде функции отправки данных с сетевухи, до самых верхов — функций типа NutTcpDeviceWrite?(). После этого мы смогли видеть где случился затык.

Потом были всякие допиливания и донастройки таймаутов в сокете, добавки статических записей в ARP-таблицы на модуле и на самом приборе: в нашей сети всего 2 устройства: прибор и модуль, нет смысла в устаревании записей в ARP-таблице.

Итоги

В нашей карте теперь есть маленький ТСР сервер, который служит для передачи данных из карты в прибор. Перед началом измерений в карте запускается TCP сервер и карта начинает ждать входящих подключений. После того, как клиент подключится к ТСР серверу, карта начинает измерения и через TCP сервер отправляет результаты в прибор.

Теперь схематично работа прибора с модулем выглядит примерно так:

Действующие лица:
b5-cardifaced — тот же что и раньше — транслирует команды из D-Bus в карту и отсылает результат обратно в D-Bus;
nc — собственно netcat, читает данные рефлектограммы из сокета и отдает их на stdout для дальнейшей обработки.

После всех этих приключений у нас теперь сетевой рефлектометр. Сетевой, правда, не на все 100% — управление происходит через CDC-ACM, а сбор данных из модуля — по TCP/IP через CDC-EEM. У нас все равно есть небольшая потеря данных, но за счет использования TCP/IP на выходе мы всегда получаем полную рефлектограмму. Мы узнали много нового о USB в целом и CDC-EEM в частности и USB я стал любить чуть меньше, чем раньше.

Нагрузочный тест показал, наш модуль на базе STM32F103 может прокачать 220 килобайт данных в секунду по TCP/IP over CDC-EEM, при том что модуль в это время занимается полезной работой и USB у нас работает без использования DMA.

Источник

Читайте также: To the moon 4pda android