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

[COURYHOUSE at aol.com]

we have some folk working on a museum display driver built around a  
raspberry PI it will also work teletypes aside from also running displays and  all 
sorts of other neat things


yea we are gonna bit bang the signal to the 60 mil converter from the gpio  
on it not the uart.

ed sharpe archivist for smecc
 
 

 
 
In a message dated 11/2/2012 10:10:22 P.M. Alaskan Daylight Time,  
nagle at animats.com writes:


>  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


______________________________________________________________
GreenKeys  mailing list
Home:  http://mailman.qth.net/mailman/listinfo/greenkeys
Help:  http://mailman.qth.net/mmfaq.htm
Post:  mailto:GreenKeys at mailman.qth.net

This list hosted by:  http://www.qsl.net
Please help support this email list:  http://www.qsl.net/donate.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qth.net/pipermail/greenkeys/attachments/20121103/c8863c6f/attachment.html