Hyperterminal without protocols?

[Andrew Mawson]

I want to send and receive text files to and from a machine tool of early

1990's vintage controlling the data flow using RTS/CTS handshaking. (This is called DNC).

Now the software I've been using to date ('RealTerm') seems to have a built in transmit buffer that I cannot disable, with the result that the machine says 'stop sending' but the program continues for up to 16 characters resulting in 'overflow' errors. My work around has been to slow the data down to 300 baud, which is painfully slow but gets round the issue as the machine has time to easily gobble up all the data without needing to pause for breath .

Looking at other programs for ascii file transfer Hyperterminal is a free possibility, but although character by character it is fine, when sending files it wants to use a protocol such as Kermit or X-Modem, which of course the machine doesn't understand.

Is there any way of setting Hyperterminal up to just use hardware handshaking and no protocol ? (Hyperterminal will run happily under Win7 if you copy it's .exe and .dll from a windows release that carries it)

AWEM

[Geo]

Just checking that it is the software and not windows... Control panel - system - hardware - device manager - Ports - Comx - properies - advanced - transmit buffer (1-16)

[Brian Gaff]

So what exactly is the device its interfacing to? Brian

[Brian Gaff]

I guess one could use a batch file using piping but off hand I'm not sure if that obeys the hardware handshaking. Its been a long time since having to do this with a Spectrum computer. Brian

[Andrew Mawson]

Yes I've been in there and disabled the Win7 buffer

AWEM

[Andrew Mawson]

[Geo]

Could I suggest using Bray's Terminal - it can send a file, has macros and a small scripting language. Various handshaking modes and it is just a single .exe file. It has been my RS232 debugging terminal of choice for years.

has a download link to zip file.

[Chris Bartram]

Have you tried PuTTY? It tends to behave itself in most ways.

[jkn]

Isn't that likely to be the 16550UART HW buffer, rather than RealTerm?

FWIW the source to RealTerm is available, you could take a peek. IIRC it's written in Delpho though, so not the easiest of things to recompile. Someone round here might be able to help if you pointed them at the code. Or even the RealTerm Author?

Jon N

[Bernard Peek]

The Free Pascal Compiler will compile most Delphi.

[John Rumm]

The 16550 will respect RTS/CTS handshaking though without needing to empty its fifo.

I have done tons of serial comms in Delphi...

[alan]

In my experience Hyperterminal has some major problems that alternatives such as Tera Term (free) overcome.

Tera term can be set for hardware handshaking

I've sent ASCII strings a to bespoke interface by just constructing a text file in a text editor (Textpad) and asking Tera Term to send the text file. Turn on logging for the results that come back (which is put into a text file)

[John Rumm]

Just use the Send Text File option from the transfer menu. It just dumps a file to the screen and also sends out the serial port as if you were keying it.

[Andrew Gabriel]

I would beg to differ. Some of the newer chips with larger FIFOs have automatic flow control handling (both RTS/CTS and XON/XOFF), but a 16550A doesn't.

[John Rumm]

Yup, I was about to say I could have worded that better - in that I was not trying to suggest that the UART itself would do fully automatic CTS/RTS handling without software intervention, unlike on the 16650 and later devices.

However, thinking about it now, I am not even convinced that it will inhibit transmit of what is actually in the fifo when CTS goes inactive.

There is a windows registry setting where you can control the number of bytes used in the Tx FIFO:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial\TxFIFO

You can also turn the FIFO off altogether if you want by setting the ForceFifoEnable key to 0

[Andrew Mawson]

I cannot find a specification anywhere saying how soon transfer should stop after the CTS/RTS transition. I'm getting at least 16 characters after the flag drops

AWEM

[Andrew Gabriel]

I don't have the standard, but I doubt that it says in any way which would be meaningful today. The two signals were originally designed for one-way half-duplex flow control mainly on form sending terminals, and I suspect the the current use for two-way full duplex flow control postdates the standard.

There's no way to stop the transmit FIFO from draining in a 16550A (at least, not without resetting it and losing an unknown number of characters still buffered in it). If you can't cope with 16 characters, you will need to disable the TX FIFO in the driver.

(There was an earlier chip without a FIFO, a 16450, but you won't find anything using that today. The very first 16550's without the 'A' suffix have the FIFO but a design fault stops the FIFO being usable - again, you won't find any of those today.)

Are you sure you have the sender configured for hardware flow control, and are you sure your cables and connectors do actually connect the modem lines all the way through? If you have an RS232 breakout box with signal lamps, it can be useful to see if the RTS/CTS modem signals are being waggled at all. I still have my Interfaker, having done lots of serial port programming in the past;-)

[Andrew Mawson]

Quite well equipped in that direction - I have the equivalent of an Interfaker, but also Two (!!) Tektronics 834 RS232 analysers :)

AWEM

[Andrew Gabriel]

Another thought - you might consider using a newer PCI serial card which has a 16750 or 16950 embedded, and suitable drivers. These run at higher speed with much larger FIFOs, but as a consequence, the chips directly handle flow control if programmed to do so by the driver. I've never used supplied drivers so I'm not sure what their supplied drivers are capable of. Also check that they will run at slow enough baud rates for your application (they mostly go up to

921600bits/s, but that can mean they don't support the 8 slowest baud rates unless the card has some provision for changing the clock generator frequency, which some do).

[Vir Campestris]

I'm 99% sure that's software flow control, not hardware - some status bit being set that the PC is noticing. CTS ought to be sampled before sending each start bit. But it's a while ago since I did this.

I still miss my interfaker :(

Andy