8 ms·

I've given this some thought. The way to improve the TTY is to give it channels, like SSH or RDP. This way you can transit unrelated data over the same connecti

by R0b0t1 6y ago

I've given this some thought. The way to improve the TTY is to give it channels, like SSH or RDP. This way you can transit unrelated data over the same connection. And, if you think about it, most of the complexity of a serial interface is handling mode settings and state; streams abstract that away for you. Streams get rid of the need for control characters and in band signalling. Streams could be given priority and interrupt levels.

ksherlock 6y ago
If you add a header with the channel number and data length and a CRC, it starts looking like UDP.
tyingq 6y ago
RS-485 is essentially RS-232 with channels. Never used it, but Linux supports it at some level.
- nrclark 6y ago
  This might not be accurate. RS-485 is an electrical signaling standard for carrying arbitrary binary signals. It's usually used for carrying UART data, as a longer-range / higher-speed replacement for RS-232. It has no opinion about what is transmitted, and has no concept of channels or even any particular encoding format.
  - tyingq 6y ago
    It could be the basis for a tty with multiple channels, fairly easily.
    - catblast01 6y ago
      How does that make it an RS-232 with channels? You’re confused. RS-485 just like RS-232 is an electrical specification for serial signaling (with multiple access), nothing more nor less. There are USB to 485 converters that basically operate exactly the same as their serial port counterparts and will show up as a tty device in Linux/Unix flavor or a COM port in Windows.
      - tyingq 6y ago
        It's a bus, rather than point-to-point. Schemes to address devices on the bus separately exist. You could call them "channels" even. RS-232 can't do that, as it isn't an electrical bus. Respectfully, you're confused. Since tty's are fairly well married to a serial port, adding an ioctl() (or similar) that would switch channels would seem likely. RS-485 would provide a way for that to work not just with ptys, but with real physical devices as well. With reasonable backward compatibility.
        catblast01 6y ago
        This is really reaching. Channelization as being referred to upthread in reference to SSH or RDP is a protocol level abstraction, rs485 bussing is at the electrical level for multiple physical devices and also doesn’t specify any addressing scheme, that would be specified as a higher level protocol (that could be done just as well over rs-232). Device addressing and channelization are not even logically the same thing. Ethernet as it is typically deployed is not a bus either but it is used in channelized communication (packet switched no less) just fine. Edit: responding to your edit. The point still stands this is orthogonal to the physical or electrical layer. The vast vast majority of the internet including Ethernet and fiber links are point to point and clearly they carry a tremendous number of separate streams, and a small amount of broadcast. You can run layer 2 over an RS-232C serial port, whether its Ethernet, PPP, SLIP or ATM. In Linux PPP is in fact implemented as a tty line discipline. As for RS-485, there are widely used standards such as DMX512. It is not a strongly supported idea to put this stuff in the kernel, when performance in user space is sufficient. Finally, RS-232 can do the same thing (multidrop) with electrical repeaters. See MAX3322 eg.
        exmadscientist 6y ago
        The way 485 addresses devices is... just to prepend an address byte. Or bytes. Whatever you want, really. The link layer, which RS-485 is, doesn't care. As others have said, RS-485 isn't really the way to do this. It looks like RS-232, but it's just close enough to mislead you while being far enough away to be a total nightmare. For example, any bus collisions have to be handled in software. A driver that has to recognize and deal with bus collisions looks very different from one for a dedicated line. This rabbit hole is probably not worth going down.
- kyberias 6y ago
  RS-485 in itself really isn't. It has no concept of "channels" although it can be operated as multipoint. You may be mixing this with Modbus which is typically run on RS-485.
gonzus 6y ago
A big fat YES from me. I have been looking into TUIs lately, and the state of terminal handling is ridiculously bogged down by years of cruft that, honestly, I don't give a shit about anymore. To put it succinctly: I want Alt-Home and Ctrl-Click to work on a TUI. Period. If I had superpowers, I would layer the system as a very low-level library that recognizes keyboard / mouse / tablet / microphone input hardware events and encodes them somehow (so Alt is a separate key, pressing multiple keys is handled, clicking + moving the mouse is handled, etc); then a protocol that can give you this event stream, either from a local or remote source; then a layer that maps this into higher-level events (so Alt and Home pressed together is interpreted as Alt-Home). The idea would be to have the ability to detect, even over a serial connection, any of these input events, without resorting to escape codes. I don't even know if this all makes sense; I just hate the loops you have to go through today to even try to make sense of key combinations. /rant

by R0b0t1 6y ago

ksherlock 6y ago

If you add a header with the channel number and data length and a CRC, it starts looking like UDP.

tyingq 6y ago

RS-485 is essentially RS-232 with channels. Never used it, but Linux supports it at some level.

nrclark 6y ago
This might not be accurate. RS-485 is an electrical signaling standard for carrying arbitrary binary signals. It's usually used for carrying UART data, as a longer-range / higher-speed replacement for RS-232. It has no opinion about what is transmitted, and has no concept of channels or even any particular encoding format.
- tyingq 6y ago
  It could be the basis for a tty with multiple channels, fairly easily.
  - catblast01 6y ago
    How does that make it an RS-232 with channels? You’re confused. RS-485 just like RS-232 is an electrical specification for serial signaling (with multiple access), nothing more nor less. There are USB to 485 converters that basically operate exactly the same as their serial port counterparts and will show up as a tty device in Linux/Unix flavor or a COM port in Windows.
    - tyingq 6y ago
      It's a bus, rather than point-to-point. Schemes to address devices on the bus separately exist. You could call them "channels" even. RS-232 can't do that, as it isn't an electrical bus. Respectfully, you're confused. Since tty's are fairly well married to a serial port, adding an ioctl() (or similar) that would switch channels would seem likely. RS-485 would provide a way for that to work not just with ptys, but with real physical devices as well. With reasonable backward compatibility.
      - catblast01 6y ago
        This is really reaching. Channelization as being referred to upthread in reference to SSH or RDP is a protocol level abstraction, rs485 bussing is at the electrical level for multiple physical devices and also doesn’t specify any addressing scheme, that would be specified as a higher level protocol (that could be done just as well over rs-232). Device addressing and channelization are not even logically the same thing. Ethernet as it is typically deployed is not a bus either but it is used in channelized communication (packet switched no less) just fine. Edit: responding to your edit. The point still stands this is orthogonal to the physical or electrical layer. The vast vast majority of the internet including Ethernet and fiber links are point to point and clearly they carry a tremendous number of separate streams, and a small amount of broadcast. You can run layer 2 over an RS-232C serial port, whether its Ethernet, PPP, SLIP or ATM. In Linux PPP is in fact implemented as a tty line discipline. As for RS-485, there are widely used standards such as DMX512. It is not a strongly supported idea to put this stuff in the kernel, when performance in user space is sufficient. Finally, RS-232 can do the same thing (multidrop) with electrical repeaters. See MAX3322 eg.
      - exmadscientist 6y ago
        The way 485 addresses devices is... just to prepend an address byte. Or bytes. Whatever you want, really. The link layer, which RS-485 is, doesn't care. As others have said, RS-485 isn't really the way to do this. It looks like RS-232, but it's just close enough to mislead you while being far enough away to be a total nightmare. For example, any bus collisions have to be handled in software. A driver that has to recognize and deal with bus collisions looks very different from one for a dedicated line. This rabbit hole is probably not worth going down.
kyberias 6y ago
RS-485 in itself really isn't. It has no concept of "channels" although it can be operated as multipoint. You may be mixing this with Modbus which is typically run on RS-485.

gonzus 6y ago

A big fat YES from me. I have been looking into TUIs lately, and the state of terminal handling is ridiculously bogged down by years of cruft that, honestly, I don't give a shit about anymore. To put it succinctly: I want Alt-Home and Ctrl-Click to work on a TUI. Period. If I had superpowers, I would layer the system as a very low-level library that recognizes keyboard / mouse / tablet / microphone input hardware events and encodes them somehow (so Alt is a separate key, pressing multiple keys is handled, clicking + moving the mouse is handled, etc); then a protocol that can give you this event stream, either from a local or remote source; then a layer that maps this into higher-level events (so Alt and Home pressed together is interpreted as Alt-Home). The idea would be to have the ability to detect, even over a serial connection, any of these input events, without resorting to escape codes. I don't even know if this all makes sense; I just hate the loops you have to go through today to even try to make sense of key combinations. /rant