Последовательный порт. Да, поможет нам Python!

Давным-давно, когда я сидел под Виндовсом у меня была прога для работы с COM-портом. Это были мои «уши и руки» для доступа к моим микроконтроллерным устройствам. Я очень боялся потерять её, боялся, чтобы её не загрызли вирусы…

Потом я пересел на Линукс, и как все Линукс-новички искал аналоги этой проги. Можно не уточнять, что я их не нашел. Конечно, я тогда расстроился — «Ну как же так! Потребность есть, а проги нет? Что-то не так в мире Линукса. Ведь в мире Виндовса каких-только программ нет! А тут такая фигня — и нет! Да, похоже, правильно говорят: Линукс — это какая-то недоделанная ОСь. Ничего в нем (Линуксе) толкового нет!»

Да-да, именно такие мысли бродили у меня в голове. Иногда они подогревались Виндузятниками, которые «эксперты-по-Линуксу», и мне было очень даже тяжко. Но я, «закусив удила», пер как трактор — только вперед!

Через какое-то время я допер, что в мире Линукса существует программа MiniCom. Прога как прога, как принято говорить — «малость не дотягивает до уровня аналогичных программ для Виндос». Я ее юзал какое-то время, пока опять-таки не допер, что даже и она не очень-то нужна в мире Линукса.

Линукс — более чем самодостаточен. В Линуксе не надо никаких особых программ для работы с последовательным портом, как это принято в мире Виндовс. По этой причине, собственно, нет и не должно быть программ для работы с портом. Они просто не нужны!

В мире Линукса последовательный порт — это файл. (Вообще, Линукс на всё «смотрит» как на файлы. Всё унифицировано.) Ну а с файлами-то мы работать умеем! А раз так, то всякие вычурные программы с бантиками и бубенчиками — это ненужный антураж, который создает видимость «продуманности» программы. Отвлекать юзера от основной цели (назначения программы), уводить его на второстепенные (менее значительные) показатели и ненужную побочную функциональность — это по-Виндовому!

Однако, вернемся к Линуксу. Что я делал, когда мне нужно было принять информацию с устройства и сохранить ее в файле? Я просто в консоли выполнял команду:

$ cat /dev/ttyS0 > my-data

Но это прога выполнялась молча, на экран ничего не выводила. Но иногда требуется «мониторить» поток. Тогда команда должна стать составной — дополниться командой tee, которая одну копию потока отправляет в указанный файл, а другую выводит на консоль:

$ cat /dev/ttyS0 | tee my-data

Все предельно просто. Но что же делать, когда требуется какая-то обработка данных в реальном времени? И вот тут у меня не было ничего «красивого», что бы я мог предложить.

В этих случаях я поступал по-Виндовому. Я писал Си-шные программы, которые открывали последовательный порт, считывали из него информационный поток, как-то его обрабатывали, результат работы записывали в файл и при необходимости что-то выдавали на экран. Все это работало. Работало не плохо. Работало надежно. Но какое-то шестое чувство мне подсказывало, что это не совсем тот самый путь, который есть правильный. В Линуксе всё должно быть как-то по другому. Но, как? Я не знал. И продолжал компилировать свои многочисленные программы.

В процессе работы возникали смешные проблемы. Надо сказать, что все эти проги не были предназначены ни для продажи, ни для широкого тиражирования. Эти проги работали в единичных экземплярах и/или только с моим оборудованием. Но каждый раз, даже при незначительных (казалось бы!) изменениях, мне приходилось их заново компилировать и присваивать им версии. Путаница начинала свой разбег по взлетной полосе…

Конечно, можно было пойти по другому пути. Все переменные параметры можно было бы сохранять в конфигурационных файлах. Но, ребята, окститесь! Это ж не коммерческие проги! Я их сам поддерживаю, я сам знаю, что и где в них нужно подкрутить или изменить, чтобы они работали чуть-чуть по другому.

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

Я понимал, что нужно было что-то делать. Как минимум, нужно было что-нибудь почитать по Линуксу и обработке данных. И я погрузился в изучение парадигмы Линукса.

Следует заметить, что Линукс очень силен в обработке статических текстов и текстовых потоков. Обработка текстовой информации — это один из столпов Линукса. Это могучий булыжник в фундаменте Линукса. И тот, кто упускает этот момент, можно утверждать, что он не понимает Линукса.

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

Понимая эту и некоторые другие Линуксовые идеи начинаешь задумываться над вопросом — «Ребята, а зачем нам вообще нужна Винда?» Она и без того мне мозги прочистила так, что я до сих пор иногда мыслю по-Виндовому. А когда я мыслю по-Виндовому, я не понимаю Линукса. Отсюда все мои неудачи и разочарования. К счастью, это происходит всё реже и реже!

Прошло ещё какое-то время, я открыл для себя удобство пользования языка Python. Казалось бы, язык интерпретируемый, а значит по определению — медленный. Однако, ирония в том, что он не абсолютно медленный, а — относительно. Относительно Си-шных программ программы на языке Python исполняются медленнее. Это не открытие. Открытие в том, что для работы с последовательным портом и обработки данных быстродействия Python-ских программ вполне хватает.

А раз так, то зачем нам какие-то специализированные (а к пущему греху еще и графические — прости-хоспади!) проги для работы с последовательным портом? Написать на Python-е для работы с последовательным портом прогу, специализированную под наши требования, — проще пареной репы!

Для работы с последовательным портом существует модуль serial, который инкапсулирует доступ к порту. (В интернете иногда можно встретить название PySerial. Это одно и тоже! Возможно, так назывался этот модуль раньше, но точно я не знаю. Это только мои предположения.) Модуль serial не входит в состав Python – его нужно устанавливать самостоятельно. В Ubuntu это делается с помощью команды:

$ sudo apt-get install python-serial

Заметьте, что название модуля и название пакета не совпадают. Почему? Какая причина?

Всё просто. Дело в том, что название пакета python-serial — это, так сказать, «область имен» в сфере пакетов программ, то есть в это область операционной системы, область репозиториев пакетов, область инсталляции программ — улавливаете?

А название модуля serial — это область работы Питона. Питон понятия не имеет об операционной системе и тем более о каких-то пакетах программ. У Питона свои тараканы — модули. Модули — это в некоторой степени библиотеки.

Вас ведь не смущает, что какая-нибудь программа-инсталлятор имеет одно имя, а устанавливаемая из неё программ — другое. Так и тут: имя пакета — это название коробочки, в которой лежит куча разных файлов. Среди этих файлов вполне может находиться Питоновский модуль, возможно какие-то справочные файлы или файлы конфигурации.

В программную среду Python модуль подключается обычным способом – через команду import:

import serial

И опять, название модуля отличается.

Следующая программа позволяет найти в системе все последовательные порты. (Программа взята из книги «Beginning Python Visialization.: Crafting Visual Transformation Scripts» Shai Vaingast, 2009. Стр. 3., и немного переделана для работы Linux-е.

#! /usr/bin/env python
# coding: utf-8

import serial

found = False

for i in range(64) :
  try :
    port = "/dev/ttyS%d" % i
    ser = serial.Serial(port)
    ser.close()
    print "Найден последовательный порт: ", port
    found = True
  except serial.serialutil.SerialException :
    pass

if not found :
  print "Последовательных портов не обнаружено"

Следующая программа забирает поток данных из последовательного порта и выводит его на экран

#! /usr/bin/env python
# coding: utf-8

import serial

ser = serial.Serial("/dev/ttyS0")
ser.baudrate = 115200

while True :
  line = ser.readline()
  print line

Программа имеет бесконечный цикл, поэтому для ее окончания нужно нажать Ctrl-C.

Еще одна программа из книги «Beginning Python Visialization.: Crafting Visual Transformation Scripts» Shai Vaingast, 2009. (cтраница 5). Эта программа забирает поток данных из последовательного порта и сохраняет его в файле. В целях контроля, поток данных выводится на экран.

Имя файла формируется автоматически на основе времени запуска программы. Например, имя файла, созданного 8-го Февраля 2014-го года в 9 часов (утра) 3 минуты и 31-у секунду, будет следующим:

GPS-2014-02-08-09-03-31.csv

здесь GPS – это префикс файла. По нему можно ориентироваться, какие данные в нем находятся. Программа использовалась для работы с GPS-приёмником, это отразилось на имени создаваемых ею файлов.

Далее следует дата-время, записанные через дефис. Стандарт ISO 8601 предписывает числа в дате писать через черточки, а числа во времени писать через двоеточие. Использование символа двоеточия в именах файлов – это не очень хорошая идея, поэтому числа во времени удобнее написать так же через дефис. Следует обратить внимание, что месяцы, дни, часы, минуты и секунды должны всегда иметь две цифры – незначащий ноль должен присутствовать. Это облегчит поиск и анализ файлов в директории, где подобных файлов может оказаться очень много. Поскольку файловые менеджеры зачастую упорядочивают файлы, то избранная правильная система наименования файлов только облегчат работу с ними.

Суффикс файла csv – говорит о том, что этот файл текстовый, то есть состоит из строк текста. Каждая строка состоит из информационных полей, разделителем которых является символ запятая. В английском это более прозрачно: csv – это Comma Separaterd Values – значения, разделенные запятой.

Однако, давайте перейдем к рассмотрению самой программы:

#! /usr/bin/python
# coding: utf-8

import time, serial

ser = serial.Serial("/dev/ttyUSB0")
ser.baudrate = 9600

filename = 'GPS-%4d-%02d-%02d-%02d-%02d-%02d.csv" % time.localtime()[0:6]

f = open(filename, 'w')
while True :
  line = ser.readline()
  f.write(line)
  print line, # Запятая нужна!

Здесь имя последовательного порта несколько отличается. У меня GPS-приемник подключен к USB-порту через самодельный переходник USB-UART. Переходник самый обычный, выполнен на микросхеме FTDI232RL.

Со стороны компа я обращаюсь к UART-у, как к виртуальному последовательному порту, который «проброшен» через USB-порт. Поэтому имя файла порта в моем случае будет /dev/ttyUSB0.

В самой последней команде программы запятая нужна для того, чтобы исключить переход на следующую строку. Дело в том, что в сообщениях GPS-приемника, которые состоят из строк, символ перевода на новую строку уже есть. И если в команде опустить запятую, то на экран будут выводится два символа перевода на новую строку – один присутствует в самой строке , а другой – от команды print.

Вот пример текста, который появляется у меня на экране и записывается в файл:

...
$GNRMC,110354.000,A,5654.2781,N,06049.3861,E,0.07,105.23,110214,,,A*7E
$GPVTG,105.23,T,,M,0.07,N,0.13,K,A*3D
$GPGGA,110354.000,5654.2781,N,06049.3861,E,1,10,1.14,292.5,M,-7.0,M,,*74
$GNGSA,A,3,13,23,04,20,10,31,,,,,,,1.44,1.14,0.89*1E
$GNGSA,A,3,83,77,67,68,,,,,,,,,1.44,1.14,0.89*1C
$GPGSV,4,1,13,23,62,270,45,20,57,202,38,31,41,062,15,32,33,157,*71
$GPGSV,4,2,13,13,28,272,40,04,24,305,42,16,18,149,,25,08,023,*78
$GPGSV,4,3,13,29,06,045,16,10,05,316,30,02,04,348,18,01,02,209,*7C
$GPGSV,4,4,13,45,,,*7A
$GLGSV,3,1,09,67,74,300,34,76,66,063,,77,49,196,31,66,46,141,*6B
$GLGSV,3,2,09,68,19,314,42,84,18,002,,83,14,311,38,75,13,036,*6F
$GLGSV,3,3,09,85,04,045,*54
$GNGLL,5654.2781,N,06049.3861,E,110354.000,A,A*4C
...

Это текст в формате NMEA (америкосы произносят это как «эн-ем-Иа», ударение на «И»). Я бы не хотел сейчас заострять внимание на его расшифровке. Важно только то, что это, во первых, текстовая информация (а не двоичная), а во вторых, эта информация достаточно хорошо структурирована и может быть легко обработана.

Точно такой же тип текстовой информации я получаю с геологических приборов:

...
E 3 825 48 499 508 508 508 508 508 506 542 573 602 628 652 674 695 713 731 748 762 776 789 801 812 822 832 841 849 857 864 871 877 883 888 893 897 902 905 909 912 915 918 920 922 924 926 928 930 931 933 934 935 937 938 939 940 941 942 942 943 944 944 945 946 946 947 947 947 948 948 949 949 949 950 950 950 950 951 951 951 951 951 952 952 952 952 952 952 952 952 953 953 953 953 953 953 953 953 953 953 953 953 953 953 954 954 954 954 968 923 885 851 820 792 767 745 724 705 688 673 659 646 635 624 614 605 597 590 583 577 571 566 561 557 553 550 546 543 540 538 536 533 531 529 528 526 525 524 523 521 520 519 519 518 517 516 516 515 515 514 514 513 513 513 512 512 512 511 511 511 511 511 510 510 510 510 510 510 510 509 509 509 509 509 509 509 509 509 509 509 508 508 508 508 508 508 508 508 508 508 508 508 508 508 508 508 508 508 501 463 431 400 373 348 325 304 285 267 251 236 222 209 197 186 176 166 157 149 142 135 128 122 116 111 107 102 98 94 90 87 84 81 78 76 73 71 69 67 66 64 63 61 60 59 57 56 55 55 54 53 52 51 51 50 49 49 48 48 47 47 46 46 45 45 44 44 44 44 43 43 43 43 42 42 42 42 41 41 41 41 41 41 40 40 40 40 40 40 40 40 39 39 39 39 39 39 39 39 47 92 131 165 195 223 248 271 291 310 327 342 356 369 381 392 401 411 419 426 433 439 445 450 455 459 463 466 470 473 476 478 480 483 484 486 488 489 491 492 493 494 495 496 497 498 498 499 499 500 501 501 502 502 502 503 503 503 504 504 504 504 504 504 505 505 505 505 505 505 505 505 505 506 506 506 506 506 506 506 506 506 506 506 506 506 506 506 506 507 507 506 507 507 507 507 507 507 507 507
M 3 0 10524 12498 14417 16335 18239 20157 22078 23989 25915 27834
E 4 825 33 499 508 508 508 508 508 506 542 573 602 628 652 674 695 713 731 748 762 776 789 801 812 822 832 841 849 857 864 871 877 883 888 893 897 902 905 909 912 915 918 920 922 924 926 928 930 931 933 934 935 937 938 939 940 941 942 942 943 944 944 945 945 946 947 947 947 948 948 949 949 949 950 950 950 950 951 951 951 951 951 952 952 952 952 952 952 952 952 952 953 953 953 953 953 953 953 953 953 953 953 954 954 954 954 954 954 967 923 885 851 820 792 767 745 724 705 688 673 659 646 634 624 614 605 597 590 583 577 571 566 561 557 553 550 546 543 540 538 536 533 531 529 528 526 525 524 523 521 520 519 519 518 517 516 516 515 515 514 514 513 513 513 512 512 512 511 511 511 511 511 510 510 510 510 510 510 510 509 509 509 509 509 509 509 509 509 509 509 508 508 508 508 508 508 508 508 508 508 508 508 508 508 508 508 508 508 501 463 431 401 373 348 326 304 285 267 251 236 222 209 197 186 176 166 158 149 142 135 128 122 117 111 107 102 98 94 91 87 84 81 79 76 74 71 69 67 66 64 63 61 60 59 58 57 56 55 54 53 52 51 51 50 49 49 48 48 47 47 46 46 45 45 44 44 44 44 43 43 43 43 42 42 42 42 41 41 41 41 41 41 41 40 40 40 40 40 40 40 40 39 39 39 39 39 39 39 47 92 131 165 195 223 248 271 291 310 327 342 356 369 381 392 402 411 419 426 433 439 445 450 455 459 463 466 470 473 476 478 480 483 484 486 488 489 491 492 493 494 495 496 497 498 498 499 499 500 501 501 502 502 502 503 503 503 504 504 504 504 504 504 505 505 505 505 505 505 505 505 505 506 506 506 506 506 506 506 506 506 506 506 506 506 506 506 506 507 507 507 507 507 507 507 507 507 507 507
M 4 0 10528 12500 14420 16339 18243 20162 22084 23996 25924 27843
...

Здесь у меня чередуются два типа пакетов (два типа строк). Пакет типа «M» содержит данные Модуля Магнитного Каротажа (ММК), а пакет типа «E» – данные Модуля Электро-Каротажа (МЭК). Пакет ММК значительно меньше по размеру пакета МЭК. Если пакет ММК состоит из 13 полей, то пакет МЭК содержит более 400.

Каждая запись (каждый пакет) располагается в одной информационной строке, которая заканчивается символом «новая строка». Здесь поля отделяются друг от друга символом пробела. Это не совсем правильно. Это я только сейчас понял, что csv-формат может автоматически «затягиваться» в программы электронных таблиц из офисных пакетов (типа Calc из Libre-Office) без дополнительных телодвижений по указанию символов-разграничителей полей. Да, надо будет как-нибудь переписать программу и заменить символ-разграничитель.

Как видите, ничего сверхсложного и непонятного в работе с последовательным портом — нет. Я предполагаю, что вы немного знакомы с языком Python, поэтому я не слишком подробно прокомментировал действия в программах. Но если что, задавайте вопросы.

А пока на этом всё!

 

UPDATE 29.10.2015

Небольшая заметка, касающаяся особенности использования модуля serial под Python-3:

http://wp.me/p1H7g0-1ed

 

UPDATE 01.12.2015

Вопрос: где взять модуль serial для Python-3?

Ответ: Модуль serial для Python-3 я тупо взял из репозитория Debian-8. То есть даже не заморачивался его поисками в интернете.

Команда для инсталляции:

# apt-get install python3-serial

Установка модуля serial для Python-2.x на Ubuntu-10.04 LTS производится очень просто:

$ sudo apt-get install python-serial

Но для Python-3.x модуля serial в репозитории Ubuntu-10.04 LTS нет. Поэтому установка будет производиться несколько сложнее

1) Идем на страницу http://pupi.python.org/pypi/serial/2.7

и скачиваем архивный файл pyserial-2.7.tar.gz

$ wget -c http://pupi.python.org/pypi/serial/2.7/pyserial-2.7.tar.gz

2) Распаковываем полученный архивный файл:

$ tar -xvf pyserial-2.7.tar.gz

3) Заходим в поддиректорий:

$ cd pyserial-2.7/

4) Запускаем процесс  инсталляции:

$ sudo python3 setup.py install

После этого можно использовать модуль serial в программах под Python-3.x.

Есть мнение, что можно проинсталлировать модуль вот так:

pip install pyserial

или так

$ easy_install -U pyserial

, но я этого не делал. Поэтому я не могу сказать можно ли так делать или нельзя.

 

UPDATE 30.03.2016

Написал новую статью: «Python, последовательный порт и нуль-модемный кабель»

http://wp.me/p1H7g0-1nb

14 responses to “Последовательный порт. Да, поможет нам Python!

  1. А как обстоят дела у линуха, если нужно при передаче пакета, дёрнуть какой-то ногой , пином общего назначения, для того, чтобы к примеру включить передатчик, а по окончании передачи пакета дёрнуть в обратную сторону ? Нужно перекомпливать ядро линуха ?

    • Забегаете вперед, уважаемый!

      Расскажу и научу это делать, но чуть позже. Пожалейте же пианиста!

  2. Ок🙂 Я тут просто приобрел БиглБоард ( http://beagleboard.org/Products/BeagleBone%20Black ), и по причине полной отстранённости от Линухов, не смог сделать с ним ничего лучше чем, попросматривать директории, посоздавать файлы, покопаться в исходниках программ обслуживания периферии, ужаснуться от своего непонимания нифигушки в них и отложить плату до лучших времен. А линкс на железе стоимостью в 50 баксов, с таким богатым комплектом периферии, это весьма аппетитная перспектива… Видимо прийдётся таки разбираться. Потому и опрашиваю Вас, Вы уж не серчайте🙂

    • Добрая плата, могучий процессор, не запредельная цена, плюс желание двигаться вперед и правильно выбранное направление мысли — это можно только приветствовать!

  3. Исправьте опечатку, должно быть
    found = False

  4. А если два ПК соединены нуль-модемным кабелем, как через pySerial отправить с одного ПК на другой хотя бы один символ? Хочется увидеть рабочий пример.

    • Основная проблема в коммуникации через последовательный порт состоит в непонимании какую роль играет операционная система.

      Начну с противоположного — с Виндовса. В ДОС-е/Виндовсе терминалы не являются жизнеобеспечивающим механизмом, поэтому они там не развиты совсем. Соответственно, последовательный порт, на основе которого изначально строились почти все хост-терминальные системы, в ДОС-е был вообще без надобности.

      Конечно, через последовательный порт (там он носит название «коммуникационного» — сокращенно «СОМ») использовался для подключения различных периферийных устройств. В основном это были измерительные приборы или какое-то управляющее оборудование для хозяйственной деятельности. Но это точно не была система типа «компьютер + удалённый терминал». Поэтому и средств в операционной системе ДОС/Виндовс для работы с последовательным портом, как с ИНТЕРФЕЙСОМ ДЛЯ ДИСТАНЦИОННОГО ПОДКЛЮЧЕНИЯ К ОПЕРАЦИОННОЙ СИСТЕМЕ — нет. А это значит, в контексте ДОС/Виндовс последовательный порт — это всего лишь ещё одна дырка для передачи данных, управление которой полностью отдано пользователю. Иначе говоря операционная система (ДОС/Виндовс) не вмешивается в работу этой дыры. Максимум, что делает, Виндовс — это как-то пытается управлять доступом к этому ресурсу. ДОС — вообще этот вопрос никак не регулирует.

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

      Совсем иначе обстоят дела в Линуксе. Линух/Юникс — это изначально хост-терминал ориентированные системы. И как я уже говорил, в древние времена коммуникация с терминалами в основном осуществлялась через последовательные порты. Значительно позже Линукс появился на персональных компах (класс компьютеров IBM PC), но изначально UNIX строился на основе большого мощного компа и множества терминалов.

      Через какое-то время на персоналках «заработал» Линукс. Но персональные компы это не мощные вычислительные машины, с множеством терминалов, а автономные вычислительные системы со своими клавиатурами и дисплеями. Таким образом, идея терминала в отношении персонального компа — стала несколько надуманной. Ну, просто терминал не нужен там, где есть встроенные в (аппаратно) систему клавиатура и дисплей. Поскольку в основе Линукса лежит UNIX (система, основанная на терминалах), это не могло не отразиться на специфике Линукса, как операционной системы.

      Иначе говоря, последовательный порт в Линуксе это не дырка для передачи данных. Последовательный порт в Линуксе — это мощный механизм, встроенный в операционную систему. Этот механизм отвечает не только за передачу данных туда-сюда, на него возложены также функции безопасности системы — пользователь, не имеющий учётной записи, не должен получить управление системой.

      Во времена расцвета UNIX производители оборудования («железа») выпускали целый зоопарк различных устройств. Эти устройства имели сходные характеристики, но та же имели и свои уникальные. Так например, некоторые терминалы не имели клавиш управления курсором. Иные устройства работали только с символами CR (Возврат каретки), а другие только с символами LF (первод строки). Но операционная система должна была уметь работать и с теми, и с другими, и еще бог-знает с какими устройствами! Поэтому в операционной системе была встроена возможность настраивать последовательный порт для работы с тем или иным оборудованием.

      Ну, как бы я много сказал. Короче можно сказать, что последовательный порт в ДОС-е/Виндовсе — это всего лишь порт (микросхема), через которую можно передавать и принимать данные. Ну, разве что с минимальной программной обвязкой в виде драйверов у Виндовс, а ДОС-е — это вообще голая вещь. А в отношении Линукса, последовательный порт — это целая система, которая гибко настраивается под потребности пользователя.

      Проблема в том, что пользователи знают СОМ-порт от Виндовса, и думают, что в Линуксе последовательный порт — это тоже самое. Нет! В Линуксе последовательный порт — это совершенно другая ипостась! А это значит, методы работы с последовательным портом в Виндовсе и Линуксе существенно отличаются.

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

      Пару дней назад на elecrtonix.ru один товарищ задавал вопрос по работе порта под Линуксом и костерил Линукс последними словами за то, что Линукс никак не хотел передавать два символа LF-CR вместо одного символа LF.

      Прогу, которая связывает два компа через нуль-модем, я может быть чуть позже напишу. Там, собственно, сложно ничего нет. Если будете писать самостоятельно, обратите внимание на то, что Линуксовые терминалы «заточены» на передачу строк, а не отдельных символов. Передавать отдельные символы — это достаточно накладная процедура. Поэтому рациональнее объединять их в пакет (то есть в строку) и в таком виде отправлять. Тем более, что отдельные символы сами по себе мало что значат. Значат — законченные строки (команды).

      А если возникает необходимость передавать отдельные символы (ну, допустим, для игровых программ или наподобие), то терминал нужно перевести в так называемый «неканонический» режим.

      В каноническом режиме любой ввод должен заканчиваться нажатием на клавишу Enter. Пока эта клавиша не нажата, обработку строки (то есть редактирование, исправление ошибок) осуществляет терминал. Но как только будет нажата клавиша Enter, строка из терминала будет передана хосту.

      В неканоническом режиме каждое нажатие клавиши на клавиатуре вызывает отправление кода в хост. Таким образом хост вынужден постоянно «дёргаться». Как я уже говорил, иногда в жизни для некоторых программ это так и надо делать. Но в основном для работы в командной оболочке (shell) используется канонический режим. Вспомните, для чего (в Линуксе) нужен терминал и всё сразу станет на свои места.

  5. Спасибо за ответ.
    Я использую (на обоих ПК) Windows XP SP3, Python 3.4, pySerial 3.0.1.
    Использование FIFO буферов включено: по моему предположению этот буфер используется принимающим ПК, когда пишут в порт отправляющего ПК. И потом на принимающем ПК сообщение можно считать из порта.

    Что я делаю (на каждом ПК в оболочке IDLE):
    import serial
    ser = serial.Serial()
    ser.port = ‘COM15′ (отправляющий и’COM1′ — принимающий)
    ser.dsrdtr = 1 (пробовал и при 0 на обоих ПК)
    ser.timeout = 1 (только для принимающего ПК в цикле while True)
    ser.open()

    И далее:
    На отправляющем ПК пишу
    ser.write(b’hello’) (или b’hello\n’)
    На принимающем
    ser.read() или
    ser.readline()
    присваивал результаты этих команд переменным. Ничего! Только b».
    Цель — передать файл с одного ПК на другой при помощи pySerial.

    • Понятно. Ладно, ждите статью.
      Бог даст может быть сегодня чего-нибудь напишу на эту тему.

  6. Добрый вечер. Поставил com0com — симуляция нуль-модемного соединения через виртуальные COM-порты ‘NCNA0’ и ‘CNCB0′ — на них всё работает (переда-приём b’hello’ и т.п.), в двух терминалах IDLE на одном ПК. Очень не хочется об этом думать, но возможно у меня сгорели COM-порты на обоих ПК…

    • Фёдор, замкните контакт 2 и контакт 3 на разъеме порта. Эти есть контакты TxD и RxD. Такое соединение называется «локальное эхо». Комп (порт) будет получать всё, что передаёт. Таким образом можно легко проверить работоспособность порта.

      Вообще говоря, у Вас есть еще одна заморочка, которая не позволит Вам сделать это легко. Я говорю об отсутствии у Вас опыта. Но когда-то же надо его получать!

  7. Спасибо за подсказку про «локальное эхо». Сам бы не догадался, что так можно сделать. Такая простая вещь, а как облегчает жизнь. Оказалось, что действительно на одном ПК не работает COM-порт. И найденный переходник USB-COM, подававший большие надежды, тоже оказался не рабочим.

  8. Спешу напомнить, что в Windows последовательный порт это тоже файл и PySerial на винде работает точно также. Собственно, я эту связку и использую на работе (там Linux не дают ставить). Вы, сами того не зная, нашли кросс-платформенное решение. Это преимущество не Линукса, а скорее языка Python. Хотя да, Линукс шикарен.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s