[ale] Connecting to r-pi

[Jim Kinney]

Alcohol cures all flow control memories. I have no idea what you just said :-)

Had to calculate and test timings in early grad school. Signal propogation time in wire plus time in detection circuits plus time to trigger action on detection plus actual signal length, etc. Now add in the blasted data collection system was getting data from multiple sources with different timings, yeah. Fun stuff. 

On October 25, 2018 6:26:55 PM EDT, Chris Fowler via Ale <ale at ale.org> wrote:
>> From: "Scott Plante via Ale" <ale at ale.org>
>> To: "Alex Carver" <agcarver+ale at acarver.net>, "Atlanta Linux
>Enthusiasts"
>> <ale at ale.org>
>> Sent: Wednesday, October 24, 2018 4:03:34 PM
>> Subject: Re: [ale] Connecting to r-pi
>
>> If you're inclined to believe Wikipedia, the early teletypes would
>actually
>> perform a carriage return to the left and line feed the paper up one
>row on a
>> LF, but the CR was necessary because of timing--it took longer than
>the gap
>> between characters to physically return the print head so they added
>the CR to
>> allow enough time. Apparently they sometimes had to add NULs as well.
>Even some
>> CRT terminals took too long to scroll all the text up. Apparently
>they didn't
>> have flow control back then.
>
>Very small buffers. Very small. I had a similar problem automating
>Nortel Merdian PBX over its console. I wrapped up the expect send into
>a function that put a pause between each character. I basically
>automated the PBX and had to also simulate a person typing in the
>commands. If not, the PBX missed characters I had sent. If a T1/PRI
>failed the program would try to bring up and check. If it was still in
>alarm it would report the alarm and create the ticket. 
>
>> I used to have a TRS-80 and a "Gorilla Banana" printer. I could never
>get the
>> flow control to work with it, and had to write a program to print
>stuff. It
>> would manually pause a fraction of a second after each line before
>sending the
>> next one to the port. Those were the days! ha ha
>
>I was hoping I would never hear about flow control and serial printers
>ever again. And here you are... 
>
>XON/XOFF flow control is software and does have a tendancy to not work
>well with small buffer serial printers. 
>
>Hardware could be either DTS/DSR or CTS/RTS flow on the printer. Using
>that would have made it work better. The problem is that you need to
>know what flow the printer supports or you need to set the DIP switches
>to the flow you want. 
>
>My Okidata days are 20 years behind me. :) 

-- 
Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20181025/bbc9f35a/attachment.html>