I wouldn't call them 'adjusted' to TTL levels. They're simply the levels that are used between UART and line buffers, which, yes, are TTL but not something arranged particularly for these devices. Of course, they aren't any more suitable for external connections than any other internal board-level signal. It's a hack, useful for making a short connection but it's the USB part that's intended to be exposed externally.
Note that they're also inverted relative to the RS232 levels because line buffers convert logic 1 to -15V. Some USB-serial chips have the ability to choose whether the signals are inverted. They also tolerate negative input voltages. This allows them to interoperate with buffered lines which interpret 0v as a negative voltage, but with extremely bad noise margins. On Sat, Feb 1, 2025 at 8:48 AM Steve Lewis via cctalk <cctalk@classiccmp.org> wrote: > > > > I'm not sure what you mean by 'a "TTL" logic level serial port', please > > elaborate. Do you mean signalling used between the UART and line drivers > > by any chance, such as with a serial connection made between UARTs > without > > > > That confused me at first as well. As you concluded: yes, not a "classic" > (or "real" serial port), but something adjusted to TTL-logic levels. > Reading the async-expansion for the IBM 5110, it talks about -25 to +25V > (the original spec of RS232?). On the 1980 Color Computer 1, I noticed it > uses -12V to +12V for its RS232. Later in the 1990s, laptops wanted to > sip less less power, and I think RS-232 revisions allowed for as low as -3V > to +3V swings? So those -5/+5V or 3.3 integrations get referred to as > more modern "TTL logic level serial port" (such as generally a USB/serial > adapter) to contrast from prior legacy devices. > > But I suppose it means these devices have less range (max cable distance) > than the original spec? I don't recall all the specifics of the original > SAGE, but I think it was an array of IBM704s across buildings. Or at least > across floors of a building. So the gobs of voltage maybe made sense back > then. If P=IV, the using less Voltage should conserve some power, while > also being faster to "swing" (transition +/-) and allow greater speeds (but > at more limited range). > > > > > > > > > On Fri, Jan 31, 2025 at 9:37 PM Maciej W. Rozycki via cctalk < > cctalk@classiccmp.org> wrote: > > > On Fri, 31 Jan 2025, Paul Koning wrote: > > > > > > FWIW I was able to get reliable serial communication under Linux of > up > > to > > > > 3.5Mbps with off-the-shelf proper PCIe UART hardware clocked at > > 62.5MHz > > > > despite that line drivers used with said hardware (soldered onboard) > > were > > > > spec'd for up to 1MHz only[1]. This was with plain PIO > > interrupt-driven > > > > operation, but then the UARTs used had decent FIFO sizes of 128 > > characters > > > > and the FIFO trigger level for the interrupt was reasonably set. > > > > > > > > Finally at 4.0Mbps data corruption reproducibly triggered, but it was > > > > garbled rather than lost characters, so I conclude the reason was > > either > > > > line drivers finally giving up or the transmission frequency hitting > > the > > > > bandwidth limit of the serial communication cable used. > > > > > > Was that with an actual RS232 port, i.e., a device using RS232 signal > > > levels, or a "TTL" logic level serial port? I'm guessing the latter. > > > > I'm not sure what you mean by 'a "TTL" logic level serial port', please > > elaborate. Do you mean signalling used between the UART and line drivers > > by any chance, such as with a serial connection made between UARTs > without > > actual line drivers in between? > > > > I've only seen such serial connections between onboard devices, such as > a > > SoC's onchip UART wired to an FTDI-like device soldered next to it on the > > PCB for a USB serial console, which seems an industry's recent workaround > > with development hardware for the usual lack of serial ports with modern > > general-purpose computers. I don't expect this to work very well over a > > cable unless very short. > > > > > In my high speed experiments, I found that the limit for RS232 data > > > rates comes from the relatively slow rise/fall times implemented in > > > RS232 drivers. If you have a port that uses logic levels the > > > transitions are likely to be much faster so loss of signal integrity > > > occurs only at much higher speeds. With the RS232 drivers I have used > > > (MAX3222), 250 kbps is roughly the upper limit. > > > > The serial port hardware I refer to uses a UART wired to a Zywyn ZT3243F > > line driver, which according to the manufacturer's datasheet signals at > > ±5V minimum transmitter voltage levels and accepts up to ±25V receiver > > voltage levels and: "Meets or Exceeds the EIA/TIA-232F and CCITT > V.28/V.24 > > Specifications for VCC at +3.3V ±10% and +5V ±10% Operations." While the > > transmitter voltage levels are not the highest recognised by the standard > > I do believe this line driver does comply with RS-232. > > > > As I say the datasheet explicitly says: "Guaranteed data rate 1000kbps," > > and according to my findings quoted above it is indeed the case (and well > > beyond). [Yes, I got it wrong by writing 1MHz rather than 1Mbps, a > mental > > slip I suppose.] > > > > NB I've also used the TI TRS3122E line driver, suitable for operation > > with 1.8V signalling per my requirement, and it is also documented to > > handle "data rates up to 1000kbps, while maintaining RS-232-compatible > > output levels." I haven't got a chance to go beyond 230400bps with this > > device though, but these two samples do suggest that supported operation > > at 1Mbps isn't that uncommon for currently available RS-232 line drivers. > > > > I've looked up the MAX3222 datasheet and it does say 250kbps max though; > > I guess it's older technology then? > > > > Does this answer your question? > > > > Maciej > > >
