Skip to content
This repository has been archived by the owner on Mar 22, 2021. It is now read-only.

What exactly is "serial?" #53

Closed
erikbgithub opened this issue May 27, 2013 · 4 comments
Closed

What exactly is "serial?" #53

erikbgithub opened this issue May 27, 2013 · 4 comments
Assignees
Labels

Comments

@erikbgithub
Copy link
Contributor

Problem

In monk we use the pyserial framework for serial connections. Yet serial itself is not a standard like USB.

Solution

Investigate what a serial connection is, how the standard works, which options exist and which errors might be possible.

@ghost ghost assigned erikbgithub May 27, 2013
@erikbgithub
Copy link
Contributor Author

General Investigation

Serial Port on Wikipedia (link ff)

  • Standards are RS-232, and maybe UART
  • USB is a new replacement for RS-232
  • unidirectional communication
  • Macs sometimes used the RS-422 standard with Mini-DIN connectors
  • other connectors:
  • there exist Virtual Serialports
  • without flow control typical errors:
    • wrong characters are received
    • characters are lost, because not read fast enough

Settings

  • notation: Data/Parity/Stop (typical 8/N/1, also default in DFE products)
  • Speed:
    • bits / seconds and bauds the same for serial?
    • port speed and device speed must match
    • not all ports support all bitrates
    • framing data reduces actual data transfered, so real bitrates are lower
    • commonly supported: 75, 110, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600 and 115200 bit/s
  • Data bits:
    • 5 (for Baudot code), 6 (rarely used), 7 (for true ASCII), 8 (for any kind of data, as this matches the size of a byte), or 9 (rarely used)
    • also little endian vs big endian (oftren not configurable)
  • Parity:
    • sends additional bit for each byte, so that the sum is either always even or always odd
    • can detect an uneven number of byte errors
    • settings: none (N), odd (O), even (E), mark (M), or space (S)
    • odd is most useful
    • none is most used, with a communication protocol on top ensuring data safety
  • Stop Bits:
    • additional bits that signal the end of a byte
    • usually 1, but for slower machines also 1.5 or 2 possible
  • Flow Control:

PySerial Docs (link)

  • allows all researched configuration, while object creation and afterwards
  • to debug the python code it's possible to connect to loop://logging=debug
  • command for fast debugging is in a terminal:
    $ python -m serial.tools.miniterm loop://logging=debug

UART to Serial Terminal (link)

  • MIDI protocol might implement some data safety features on UART
  • Problems with the first characters might occur when speed is >9600 baud
  • explains how to use screen as serial terminal (e.g. closing with CTRL+A k y)

Serial Programming Guide for POSIX Compliant Operating Systems (link)

  • empty line is always a never stopping 1
  • start bit is always a 0
  • stop bits always value 1 (like the "no communication" part it's basically a waiting time until the next frame is sent)
  • a break is a long 1 (about .5 or .25 sec) and is used to reset communication or change modes

Bit für Bit (link)

  • original TTY (=teletype) interface was working with 20 mA vs 0 mA signals instead of the common 0V vs 5V or -12V to -3V vs +3V to +12V interpretation of today's serial connection types
  • RS-232 was developed for computer to modem communication
  • sender should have the same amount or more stop bits then the receiver (note by @binschek: but maybe not good in bidirectional communication)
  • decreasing baud rates increases reliability

@erikbgithub
Copy link
Contributor Author

Typical Problems

  • sync time in the beginning (probably needs active I/O)
  • one side might lose characters on the way
  • one side might misinterprete characters
  • one side might have different baudrates
  • one side might have differently working clocks (which leads to misinterpretation of baudrates)
  • one side might stop sending because it waits for a control signal (hardware or software flowcontrol activated on one side only, or control characters lost)
  • one side might drop received data because it waits for a control signal (hardware or software flowcontrol activated on one side only, or control characters lost)
  • if the connection is lost for some time mid-sending it's quite hard to find the beginning of the next character (might be solvable by small periods of at-least-one-frame-long waits)

@erikbgithub
Copy link
Contributor Author

@erikbgithub erikbgithub modified the milestone: v0.2 - Serial Connection Dec 22, 2014
@erikbgithub
Copy link
Contributor Author

answered

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant