[GreenKeys] USB to TTY-loop possibility...

[John Nagle]

> From: epvgk at limpoc.com
> Subject: [GreenKeys] USB to TTY-loop possibility...
> To: greenkeys at mailman.qth.net
> 
> It seems like lots of folks have been looking for an easy solution to 
> connecting a computer to a TTY loop... There are various options like 
> reprogramming the CP2102-based usb-serial adapters and using PC software
> to generate the baudot code for it. 
> 
> I just picked up a little breakout board for an Atmel cpu (Atmega32u4)
> which is tiny and has USB support builtin. The whole board is only like 
> 3/4" by 1" and costs $16.  I've been playing around a bit writing software
> to make it act as a complete USB to TTY adapter...
> 
> The idea is to make it look to the computer like a generic USB serial device,
> but internally handle all the character set conversion, shifts, and framing,
> and without a large internal buffer. So you talk to it from the computer
> in ASCII and it ignores whatever the computer thinks about baud rate, character
> size, etc, and produces correctly timed 7.42 code at 45.45 baud on the output
> end, and vice versa for receiving. It only picks up a new character from 
> the computer when it's done sending the current one to the loop, to avoid
> having to wait for a buffer full of data to transmit once you stop sending.

   That's a reasonable way to approach the problem.  I considered doing
that with an Arduno.

   Probably the absolute minimum device for this is

http://www.hotmcu.com/cp2102-module-usb-to-33v-ttl-p-35.html

which is a CP2102 on a PC board for $3 including shipping.
There's no modem control (which I use for motor turn-on)
and output signals are 3.3V, but for a very basic converter box,
it would work.

   ASCII to Baudot is non-trivial to do right.  If you're handling
keyboard input, you need need to handle half-duplex vs full duplex
issues, speed, echo, shifts, multiple character sets (USTTY, ITA2,
Fractions), carriage return delay, end of line protection, and output
buffer flushing.   The main problem with doing this in a USB
device is that you then have to have a way to express all those
options to the USB device.  Most of them can be expressed through
the I/O control functions, but there's no direct way to specify the
character set in use. I prefer to do the code conversion on the host
side, rather than in the peripheral controller.  Most of this
doesn't matter when you don't do much keyboard input, or have a
RO machine to drive.

   I've found it useful to represent the output shift state as FIGS,
LTRS, or UNKNOWN.  At startup, the state is UNKNOWN.  Thereafter,
the state changes when FIGS or LTRS is sent.  When SPACE is sent
and the state is FIGS, the state becomes UNKNOWN.  This handles
machines with or without unshift-on-space.

				John Nagle