[ale] Connecting to r-pi

[Scott Plante]

Actually, lack of good flow control was what inspired me to really learn vi really well. I used to program all the time on a dumb terminal connected to a Unix box, and if you just held down an arrow key to get midway across the screen, the whole session would become jumbled and you'd have to refresh. So I learned all the obscure vi keys to move around the screen and file instead of arrow/page keys. Once internalized, it made me much more efficient even after I had a reliable terminal connection or full desktop. 


Scott 

----- Original Message -----

From: "Jim Kinney" <jim.kinney at gmail.com> 
To: "Chris Fowler" <cfowler at outpostsentinel.com>, "Atlanta Linux Enthusiasts" <ale at ale.org>, "Chris Fowler via Ale" <ale at ale.org>, "Scott Plante" <splante at insightsys.com> 
Sent: Thursday, October 25, 2018 8:12:39 PM 
Subject: Re: [ale] Connecting to r-pi 

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: 






----- Original Message -----


<blockquote>
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 




<blockquote>

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. 
</blockquote>
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. 



<blockquote>




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 
</blockquote>
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. :) 





</blockquote>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20181026/086d8c7c/attachment.html>