Hyperterminal without protocols?

The UART can. I've written device drivers for it.

If its programmed to respect RTS/CTS that absolutely halts transmission at that point. Then teh ring buffer fills up, and then that should halt upstream sofware elements.

Under windows all bets are off, of course. Unix you can make em work with proper handshaking cos we used to drive

9600 baud ,modems at 115k no problem.

stty -crtscts would switch that on.,

It will if it set to respect it.

What you need to do is to find the command that sets the chipset/driver to CTS/RTS control.

The windows equivalent of an IOCTL call. I used to know what it was...

Oh. It looks relatively s**te

formatting link

Short answer. Ditch windows.

Reply to
The Natural Philosopher
Loading thread data ...

Then it isnt working at the chip level.

See my earlier post. Windows doesn't implement in chip handshake. Instead the windows driver MAY decide to have a look at the line and stop sending. But if its a 16550 it has as you surmise a 16byte ring buffer to empty.

The way round that is to tell the windows driver to do 'no overlap' that is it wont ever put more than one byte in the ring buffer.

That's an API call that may have a registry setting to control it.

Try \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial\Parameters

I don't have a windows machine anymore to try that on. Thank Clapton..

Ah. Been remembering with the aid of a data sheet how that 16650 works.

Yerrs. it codeosnmt cotrol teh bugffer on the chip via RTS/CTS. You should set the handhake to cause an interrupt, and then cxease sending it data at that poimt. BECAUSE of the way it works, the correct sequence for proper handahke is

if (TX buffer is empty AND CTS is low) THEN put byte in ring buffer ELSE wait until it is.

IIRC and its donkleys years, the way to do it under interrupts was to disable TX buffer empty and lines status interrupts UNTIL YOU HAD DATA TO SEND. Then when the driver buffer (not the chip FIFO ) had one or more bytes you would enable CTS and TX FIFO EMPTY interrupts and the interrupt would happen immediately, then the ISR itself would take one (or more) bytes from the driver buffer and stuff it in the chip. Once the driver buffer was empty, then the interrupt service routine would disable interrupts until the application thread enabled them again. If you got FIFO EMPTY and CTS was still blocked, you did nothing until the CTS interrupt came along. If there were no more bytes to send, the ISR would shut off interrupts from the TX side until the application part of et driver re-enabled them on the arrival of new data.

You never wrote more than one byte to the chip, if you wanted instant handshaking.

It looks lie the windows driver however can send more. But can be configured to send only one at a time...Thats what you need to do.

Reply to
The Natural Philosopher

its all software the end. Its just which chip its running on...

Reply to
The Natural Philosopher

I would normally use the term software flow control to describe schemes like XON / XOFF. Anything that uses discrete control lines (CTS/RTS or DTR/DSR etc) is "hardware" (even if it requires processing in the ISR).

Reply to
John Rumm

What happens if you set the Tx FIFO value to 8? (or even turn off the fifo altogether)

Reply to
John Rumm

HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.