Мы пытаемся прочитать значение с внешнего датчика, подключенного к USB-мосту CP2102 USB-UART.
Мы использовали эту библиотеку , чтобы установить последовательную связь. может отправить байты, такие как 0x69 0x14 0x00 .. и любые другие положительные байты (от 0 до 127), чтобы открыть датчик, нам нужно отправить номер датчика, который в нашем случае был 0x82 (эквивалент 130 в байтах без знака и-126 в знаковых 2)
В Kotlin мы не могли назначить 0x82 байтовой переменной, поэтому нам пришлось использовать ее десятичную форму -126, но отправка этого байта приводит к тому, что устройство прекращает отправку или получение данных.
Мы пытались использовать все положительные байты, и ничто не вызывало этой проблемы, только отрицательные.
С моей точки зрения, устройство использует неподписанные байты для получения и отправки данных, отправка подписанного байта как-товне его диапазона
в экспериментальном Kotlin есть неподписанные байты, такие как UBytes, но, к сожалению, оба устройства Android USB Host Api aи в последовательной связи библиотека использует традиционную ByteArray в качестве буфера.
В любом случае мы можем отправить 0x82 на устройство, не вызывая его прекращения работы?
Используя это Serial Terminal App , мы обычно можем отправлять 82 в шестнадцатеричном виде. Данные с датчика вернулись успешно и, как и ожидалось, в документации устройства.
Как это возможно?
Примечание: мы также попробовали некоторые утилиты, которые конвертируют hexStringToBytes, например, с 69 по 105, но результат по-прежнему такой же, как при назначении байта 0x82 непосредственно -126.
РЕДАКТИРОВАТЬ:
В библиотеке writeAsyncметод, который принимает ByteArray в качестве параметра. На наш взгляд, у нас есть текст для редактирования, который просит пользователя написать Bytes, например 105, 20 ... поэтому мы передаем byteArrayOf(editText.text.toString.ToByte()), который выдает, если значение превышает 127.
Пользователь долженвведите байт от -128 до 127.
Чтобы получить файл конфигурации от датчика, пользователь должен отправить
0x69 - то есть 105 в байтах, то 0x82 - что в 130 в Ubytesили -126 в байтах. 0x00 - это 0 и последний CRC (один байт от остатка деления на 256), который здесь 0x14. что равно 20.
после этого пользователь должен получить следующие данные (в шестнадцатеричном виде это будет выглядеть так):
96 82 00 3C 54 79 70 65 3D 70 48 20 EC E5 F2 F0 0A 50 61 72
61 6D 3D 70 48 0A 55 6E 69 74 3D 0A 6B 3D 3D 5B 8B AC 0A 62 3D 3E
C1 FF 2E 0A 6D 69 6E 00 3D 00 00 00 0A 6D 61 78 3D 41 60 00 0A 00 51
пользователь пишет 105, отправить, успешно отправлено, затем -127, отправка, ошибка, устройство перестает отвечать.
Мы не можем получить эти данные, потому что требуется 0x82.
Отправка 105, затем 0, 21 или любого другого положительного байта не возвращаетсялюбая ошибкаОтправка любого отрицательного байта останавливает устройство от чтения / записи
В журнале приложения мы конвертируем ByteArray в шестнадцатеричную строку для удобства чтения.
Отправка 105 записей request: byte= 105 hex= 69 в журнал cat,устройство получает эти данные обратно и записывает answer: byte= 105 hex= 69.
Запись 130 (для 0x82) выдает исключение приведения, которое вынуждает вас использовать другое значение, равное -126, которое немедленно останавливает устройство от чтения илиПри отправке данных журнал показывает только request: byte= -126 hex= 82 без ответа и после этого не принимает запросов.
Жесткие значения кодирования также делают то же самое.