LINUX.ORG.RU

Возможно ли работать с com портами из андроида из питона?

 , , ,


0

2

Я себе спаял контроллер монтировки телескопа, но чуть промазал с выбором микроконтроллера и в него не влез код для работы по LX200 протоколу. Поэтому я реализовал в нем гораздо более простой протокол и написал питоновское приложение, которое преобразует LX200 протокол в то, чтоу меня.

Что конкретно оно делает: оно открывает 2 com порта.

Первый это тот, к которому подключен контроллер, а второй это тот, по которому оно будет получать команды lx200. Если второго порта не указано, то создается PTY, и lx200 команды принимаются через него.

На десктопе я соответственно в стеллариуме указываю протокол lx200 и порт /dev/pts/* который создался. Все работает без проблем.

Теперь хочется все это перенести на андроид, чтобы не таскать ноут с собой.

Из проблем, которые я уже вижу, это то, что в андроиде когда подлючаешь usb com порт, не создается /dev/ttyUSB* файла.

★★★★★

Ответ на: комментарий от menangen

Это ж страшные костыли, не?

Не.

COM - медленное последовательное старое дерьмо из конца 80-ых

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

USB - это современный параллельный интерфейс

С каких пор Universal Serial Bus стал параллельным?

для подключения мониторов в 2020

Каких мониторов? Ты с hdmi не спутал?

aureliano15 ★★ ()
Ответ на: комментарий от LINUX-ORG-RU

Да я краем уха слышал, что создатели usb уходят в сторону параллельной и асинхронной передачи данных, думал, уже будущее наступило

menangen ★★★★★ ()
Последнее исправление: menangen (всего исправлений: 1)
Ответ на: комментарий от menangen

в последних усб кагбэ да, стандартом заложен 6 диф.пар, по которым сигналы теоэрэтически можно прогнать параллельно :) но все равно енто не совсем то.
но даже так ты чутка спутал параллельные каналы для каждого «виртуального» endpoint в железке-респонденте с последовательной передачей бит в одном физическом канале :)

pfg ★★★★★ ()
Ответ на: комментарий от Morin

Там USB OTG, так что может. и еще я установил некий «serial port terminal», оно распознало воткнутый usb com порт и оно даже работает. Но /dev/ttyUSB* по прежнему нет

cvs-255 ★★★★★ ()
Последнее исправление: cvs-255 (всего исправлений: 1)

Нельзя / не на всех андройд устройствах.

  1. Обычный подход с ttyUSB/ACM и прочими не прокатит.
  • тебе нужны дрова в ядре андройда

  • тебе нужны права на открытие устройства

  • тебе нужен скрипт который будет создавать сериал порт при втыкании, что то типа удева.

Это работает только с рутованными андройд устройствами или с специальными BSP в которых это есть.

  1. Есть вариант работать без дров и прочего, используя USB АПИ, не помню как оно называется, что то типа либюсб. В этом случае можно работать с USB/ Serial шнурками, но только с определенными чипами, типа FTDI, PL2303 и прочими. Типа надо знать даташит на чип с инфой о USB протоколе, типа что писать и в какие эндпойнты.

По крайней мере раньше так было, как сейчас хз.

kuzulis ★★ ()
Последнее исправление: kuzulis (всего исправлений: 2)
Ответ на: комментарий от kuzulis

ох PLки я б не брал, паленые :) иногда жутко глючные эти самые паленые.

ft232r когда-то заводил на планшете, но было это очень давно, деталей уже не помню.

Morin ★★★ ()
Ответ на: комментарий от kuzulis

Видимо тема тогда переформулируется в «Что бы такого компактного (но с экраном) купить, на чем будет работать нормальный линукс»

cvs-255 ★★★★★ ()
Последнее исправление: cvs-255 (всего исправлений: 1)

1. Никаких /dev, доступ туда есть только у всратых китайцев. Андроид даёт доступ к USB только через хитро закрученную жопу.

2. Используй библиотеки, если не хочешь ковыряться полтора месяца. Для жабки эту, например. Для питона - хз, гугли.

izzholtik ★★ ()
Ответ на: комментарий от anonymous

Даже если работа с обычным usb com портом такая геморная, мне же еще надо будет создать pty, для приема команд. Подозреваю, что тут проблем на андроиде будет не меньше

cvs-255 ★★★★★ ()
Ответ на: комментарий от cvs-255

на чем будет работать нормальный линукс»

Хз, какой нить дешманский планшет (который не жалко) и на который можно линукс поставить.. гугл в помощь :)

ЗЫ: А можно сразу с виндой и проблем не будет )))

kuzulis ★★ ()
Последнее исправление: kuzulis (всего исправлений: 1)
Ответ на: комментарий от izzholtik

1. Никаких /dev, доступ туда есть только у всратых китайцев. Андроид даёт доступ к USB только через хитро закрученную жопу.

Если андроид рутован и можно грузить свое самосборное ядро, все проблемы решаемы так или иначе, вопрос только во время/трудозатратах.

SZT ★★★★★ ()
Ответ на: комментарий от SZT

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

izzholtik ★★ ()
Ответ на: комментарий от izzholtik

Смысл такой, что штатное апи может не все USB UART адаптеры поддерживать, и доступно оно из языка Java а значит если код работающий с UART написан не на Java и/или не под это конкретное API, надо переделывать.

SZT ★★★★★ ()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от SZT

Не, ну если ТС желает компилять ядро с нужными модулями, лочась на конкретный девайс, ради натягивания питона на андроид, мешать ему я не намерен. Но такое себе это оно, честно говоря.

izzholtik ★★ ()
Ответ на: комментарий от menangen

Там в последних стандартах всякие display port и thunderbolt шины внутри usb

Этого не знал. Хотя, учитывая увеличение скорости в usb 3, оно вполне логично.

SuperSpeed устройства, как я понял, параллельно передают пакеты внутри usb

В usb изначально (начиная с 1-й версии) была предусмотрена возможность подключения нескольких usb-устройств к одному хабу. Но не надо это путать с параллельностью. Шина всё равно остаётся последовательной, но по этой последовательной шине могут передаваться разные пакеты, как по сети. Потом эти пакеты идентифицируются по product id, vendor id и другим полям заголовка, подобно тому, как в заголовках сетевого пакета указывается его тип, например udp, а сами udp-пакеты идентифицируются ip-адресом и портом.

Могут быть стандартные и нестандартные usb-протоколы. Например, протокол для мышки стандартизирован, поэтому подключая её, тебе не надо заботиться о специальном драйвере для этой конкретной мышки. Если же устройство обладает нетипичными функциями, то для задействования этих функций нужен драйвер.

Переходник usb-com - это тоже специальное устройство, выполняющее задачу преобразования usb-пакетов в поток битов на com-порт и обратно. И устройство это не такое тривиальное, как может показаться на первый взгляд, хотя бы потому, что все устройства, соединённые через usb-шину - не равноправны. Устройства же, соединённые через rs-232 - равноправны. И, разумеется, к usb-шине совместно с таким переходником можно подключить и другие устройства.

Зачем нужен такой переходник для новых девайсов, если в них сразу можно реализовать usb-протокол? Затем, что usb-протокол сложнее, т. к. предназначен для одновременного подключения нескольких устройств и разделения шины между ними, uart же реализован максимально просто. Поэтому если у тебя серийное производство, то можно заморочиться и создать простой для конечного потребителя usb-девайс, даже если достаточно возможностей com (как в мышке). Но если ты и производитель, и потребитель, то реализовать логику на uart, подсоединив к нему usb-com-переходник, разумеется, проще.

Да я краем уха слышал, что создатели usb уходят в сторону параллельной [skip] передачи данных

Это не так, а полностью наоборот. Уже много десятилетий идёт процесс перехода от параллельных интерфейсов к последовательным, т. к. последние более помехоустойчивы на больших расстояниях или высоких скоростях. Соответственно, увеличивая длину кабеля либо пропускную способность даже на коротком кабеле, это неизбежно. Отсюда замена lpt последовательными интерфейсами типа usb, внутри компа - замена parallel ata на serial ata и т. д.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

Уже много десятилетий идёт процесс перехода от параллельных интерфейсов к последовательным

это не так, а полностью наоборот. В последнее время растут скорости передачи и данные передают параллельными каналами. lpt отсох потому что медленный а кабель нужен толстый.

anonymous ()
Ответ на: комментарий от aureliano15

Отсюда замена lpt последовательными интерфейсами типа usb, внутри компа - замена parallel ata на serial ata и т. д.

ты путаешь теплое с мягким, перешли на другой метод передачи данных

https://en.wikipedia.org/wiki/Differential_signaling

anonymous ()
Ответ на: комментарий от anonymous

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

Morin ★★★ ()
Ответ на: комментарий от Morin

В классике параллельной шины

ты тоже путаешь причины и следствие, причем тут параллельность ? То что на интерфейсах сначала по одной паре использовали это следствие только удешевления - нахера 16 пар делать если устройств с такой скоростью нет ?

anonymous ()
Ответ на: комментарий от Morin

историю пк

вот тебе история - скоростные интерфейсы (например sdram) никогда не были последовательными. Еще раз - то что изначально где-то использовали только одну пару это чисто экономика.

anonymous ()
Ответ на: комментарий от anonymous
 Тут правда оговорочка, если мы берем периферию довольно медленную

и тут ты такой весь в белом привел раму в тред которая с измальства пс висела отдельно ибо надо очень быстро и можно потрахаться с разводкой :) я фигею с твоей логики, тред был про довольно медленные интерфейсы перефирии

да, надо сказать, что попытки затащить раму в последовательную секту продолжаются и я думаю будут успешны

Morin ★★★ ()
Последнее исправление: Morin (всего исправлений: 1)
Ответ на: комментарий от Morin

попытки затащить раму в последовательную секту продолжаются и я думаю будут успешны

serial в названиях интерфейсов часто не имеет смысла - смотри D,QSPI, CSI-2,3 и тд. Для увеличения пропускной способности всегда рано или поздно начинают параллелить. Я не знаю почему до вас так туго это доходит, место тут видимо такое. А у SDRAM и сейчас стробы дифференциальные.

anonymous ()
Ответ на: комментарий от anonymous

да наплевать какие, давай ты перестанешь тащить память туда куда не нужно. Пойдешь почитаешь, на какой длине проводника ты получишь из параллельной шины - тыкву. Почитаешь как разводить высокоскоростные параллельные шины (мне довелось разводить сотни мегагерц, удовольствие то еще) , потом вернешся и осознаешь что мы про совсем другие шины ведем разговор и разговор этот про последовательную передачу данных.

qspi к примеру это не про хорошее решение, а про вендорлок :) но такое себе, я микроконтрошек пожрал много и чудес про изобретем новый стандарт видел очень много

Morin ★★★ ()
Ответ на: комментарий от Morin

Почитаешь как разводить высокоскоростные параллельные шины (мне довелось разводить сотни мегагерц, удовольствие то еще)

ты то тут причем, как твоя криворукость отменяет тот факт что для увеличения пропускной способности всегда начинают параллеить ? Кстати, если ты про разводку DDR то почитай про её калибровку и не гони пургу, не так страшен черт.

anonymous ()
Ответ на: комментарий от anonymous

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

Morin ★★★ ()
Ответ на: комментарий от Morin

ну мои девайсы вполне работали по тз

возьми последовательно с полки пирожки

не видишь цикличность

хуичность. У всего в природе есть физический предел, дальше только паралелить.

anonymous ()