Какие особенности работы с физическими последовательными портами?
Имеется промышленный компьютер с несколькими физическими последовательными интерфейсами.
Обнаружил, что в отличии от виртуальных портов, недостаточно просто указать нужный бодрейт при открытии порта (с использованием допустим python (pySerial)), необходимо также установить соотвествующий baud_base при помощи команды sudo setserial /dev/ttyS0 baud_base 115200, иначе данные будут искажены. Я не понимаю что такое baud_base и в каком соответствии он находится с бодрейтом, который я указываю при открытии порта. А при скорости 460800 и установка base_baud в соотвествующее значение не помогает - получаю мусор. Неужели контроллер (fintek f81803) не поддерживает такую скорость, или есть какой-то нюанс?
115200 по-моему максимальная скорость. Вообще я думаю, стоит почитать, что из себя представляет физический последовательный порт, а уже потом пытаться творить дичь.
For max PCLK frequencies of 26MHz (maximum PCLK frequency in case of ADuCM302x) and 52MHz (maximum PCLK frequency in case of ADuCM4050) and parameters OSR = 0 and DIV = 1, the simplified equation above actually translates to maximum UART baud rates of 6.5Mbps and 13Mbps for ADuCM302x and ADuCM4050 respectively. Now, it is important to note that these are the theoretical maximum baud rates. The practical UART baud rate that can be achieved in a system will depend on several factors, some of which are listed below for your consideration.
большие скорости можно прогнать только по rs485. несимметричная линия 232 или uart не рассчитана на большие скорости.
а так, теоритически, имея доступ к "железным" регистрам можно выбрать практически любую скорость.
обычно верхний предел скорости ограничивается возможностями выходного каскада порта.
Тут самое главное:
1) да контролеер может не поддерживать
2) автоопределения скорости нет! Поэтому скорость нужно устанавливать до передачи данных на обеих концах одинаковую!
3) на больших скоростях может шуметь линия и тупо приходить грязь. И да, по стандарту всего 12 метров для rs-232. Иначе сигнал тухнет.
4) сигнал аналоговый и в нем не предусмотрено никаких шумодавов, crc, fec и прочего...
pfg21, А это здесь причем?
эзернет тоже физического, только там как минимум CRC.
Ну или CAN, во!, последовательная, дифференциальная, с CRC, автоопределением скорости...
неа :) Ethernet описывает и физический и канальный уровень согласно определениям OSI.
так же как и CAN. и к примеру i2c и некоторые другие.
кстати уарт тоже "чуть выше" физического уровня osi, он оперирует словом (а не битами как то постулирует физ.уровень osi)
и даже имеет минимальный CRC в виде бита четности. но вот этим практически никто не пользуется.
наверное потому что uart сформировался еще до представления стека OSI :)
Если уж по OSI, то это сова, натянутая на глобус - попытка описать и упорядочить существующий мир.
Мне вот всякие интерфейсы типа USB, FiberChannel, InfiniBand... Да любой современный, типа Thunderbolt.
Сова хрустит от удовольствия на этих глобусах.
Да что там говорить, даже просто TCP/IP хрен натянешь на OSI.
Не, оно в теории, красивое канешна.
И вот с чем я полностью согласен! OSI - место на сносках в учебниках для лучшего понимания предмета.
За всю свою карьеру в IT, а это более уже 30 лет, ни разу не видел ни одного интерфейса и протокола, полностью соответствующего OSI.
А в институтах школяров зубрить это все заставляют... А ну-ка дружок, ткни-ка пальчиком в эту пирамиду Маслоу...
Цитата из википедии, пока еще не закрытой.
Пока комитеты ISO спорили о своих стандартах, за их спиной менялась вся концепция организации сетей и по всему миру внедрялся протокол TCP/IP.
<…>
И вот, когда протоколы ISO были наконец реализованы, выявился целый ряд проблем:
эти протоколы основывались на концепциях, не имеющих в современных сетях никакого смысла;
их спецификации были в некоторых случаях неполными;
по своим функциональным возможностям они уступали другим протоколам;
наличие многочисленных уровней сделало эти протоколы медлительными и трудными для реализации.
<…>
Сейчас даже самые ярые сторонники этих протоколов признают, что OSI постепенно движется к тому, чтобы стать маленькой сноской на страницах истории компьютеров.
— Эви Нэмет
В данном случае речь идет о RS422, и длина кабеля там не более метра. Сам порт в настройках BIOS также переведен в режим работы RS422. Устройство работающее на скорости 460800 - волоконно-оптический гирокомпас, и выбрать другую скорость там к сожалению нельзя. К слову, через USB преобразователь работет прекрасно, но раз уж есть физические порты, хотелось обойтись без промежуточных устройств.
По поводу выбра скорости: да, я понимаю что скорость должна быть согласована, но меня сам способ согласования удивил. Обычно, при работе с виртуальными портами я указываю нужную скорость непосредственно в софте. Открываю допустим PUTTY, указываю необходимые настройки порта и все ок. Но с физическими портами это не работает. Приходится сначала установить baud_base для порта, при помощи setserial. Т.е. фактически я устанавливаю скорость дважды: при помощи setserial, и в ПО для работы с портом. Так и должно быть, или действительно что-то не так с драйвером, как предположили ниже?
предположу реализация програмного драйвера косячит и не может нормально принимать скорость установки порта, умеет только sudo setserial /dev/ttyS0 baud_base 115200 :)
"это не баг, это особенность" :)
