Hyperterminal not printing the data until after 80 characters in loop back mode

NTDEV
1

Hi,

I am developing a serial driver and i am trying to test it’s read and write functionality using Hyperterminal. I have connected the serial port in loop back mode. hence i am expecting the characters that i type to be received by Hyperterminal and be printed on the screen.

After launching Hyperterminal and connecting to the port successfully, when i type characters i am not seeing them until i finish typing the entire line i.e. 80 characters. But i am expecting to see each character that i type to be seen on the Hyperterminal screen.

From my driver logs, i am seeing that Hyperterminal is sending a read request for 80 bytes. I think this is the root cause of the above behavior. But using Microsoft serial driver sample i am seeing that i am able to receive each character back on the Hyperterminal screen.

What could be the reason that Hyperterminal is sending the read request for 80 bytes but not for a single character ? How can i control this ?

ANy help is greatly appreciated…

2

seetha [whatever] wrote:

What could be the reason that Hyperterminal is sending the
read request for 80 bytes but not for a single character ?

Because sending reads for 1 byte is extremely inefficient?

How can i control this ?

You can’t. How could HyperTerminal possibly know in advance that you’re going to be typing a character at a time, and further, why would it care?

3

Right.

But you CAN support the standard IOCTL that provides a timeout, or simply choose an appropriate timeout value yourself in your driver. The timeout indicates the maximum amount of time an in-progress read should wait to complete, if the buffer isn’t filled.

Simple.

Peter
OSR
@OSRDriver

4

Peter Viscarola (OSR) wrote:

But you CAN support the standard IOCTL that provides a
timeout, or simply choose an appropriate timeout value
yourself in your driver.

OP is trying to use HyperTerminal with his driver. Necessarily, that means that he must fully implement the actual serial spec. So, respectfully, I’d submit that your statement should be subtly altered to the following:

  • he MUST support the timeout IOCTLs (in addition to other IOCTLs originated by WaitCommEvent() and so on; memory fails, but I wouldn’t be surprised if HyperTerminal is waiting for RXCHAR to fire…)

  • he MUST NOT choose a timeout value “himself”; whatever the app requests, needs to be honored, or things may not work correctly.

5

You think so? I’m not so sure.

If his driver implements GUID_DEVINTERFACE_COMPORT, I’d definitely agree. In that case, he is obliged to implement the serial port spec. So you and I, Mr. Aseltine, would definitely be on the same page.

OTOH, if his device merely does some serial port stuff, and he’s looking for a cheap/easy way to test his stuff by using Hyperterminal… then he needn’t implement the (fairly significant) serial port API.

I read his question as “how can I get Hyperterminal to work with my widget, which sort of works like a serial thingy”…

Peter
OSR
@OSRDrivers

6

Peter Viscarola (OSR) wrote:

> Necessarily, that means that he must fully implement
> the actual serial spec

You think so? I’m not so sure.

If his driver implements GUID_DEVINTERFACE_COMPORT, I’d
definitely agree. In that case, he is obliged to implement the
serial port spec. So you and I, Mr. Aseltine, would definitely be
on the same page.

Well, while I agree that device interface == contract, I don’t necessarily agree that the reverse is true, (i.e. no device interface == no contract.) What if someone enumerates the available ports by walking the SERIALCOMM registry entries instead? (which, by the way, is what I think Hyperterminal does?) They’re going to see “COM3”, “COM4”, and so on … and think serial ports.

OTOH, if his device merely does some serial port stuff, and he’s
looking for a cheap/easy way to test his stuff by using Hyperterminal…
then he needn’t implement the (fairly significant) serial port API.

My understanding from the other thread (the one about delegating interrupts and etc.) is that this guy is making a multi-port PCI serial port card. If that’s the case, then any user of his card is going to expect to open an arbitrary serial application, and have it work correctly.

Also, he specifically said he’s writing a “serial driver”; if he’s just trying to debug his card, implementing a serial driver to do that is probably the absolutely worst way to go.

Maybe OP can chime in here and give us more details…

7

HI all,

Thanks for your response so far. I figured out the problem in the my code. While i am timing out a request in my Interval timer (Hyperterminal sets the interval time out to 10 ms) I was not giving the data that i have at that moment to application. After doing it i found i am able to see each and character every character that i type on the Hyperterminal screen.

I am implement GUID_DEVINTERFACE_COMPORT in my serial driver and i am implementing drivers for a multi port serial card.

However i am now seeing another issue. When i copy some text and try to paste it on to Hyperterminal window, Hyperterminal is hanging and the data is not getting transmitted. I can’t see anything in the driver logs.

What is expected is that the content should be transmitted through the target COM port and hence it should appear back on the screen (since i have connected the port in loopback mode)

Could this be related to an issue in implementation of write in my driver? I tested the write functionality multiple times with various applications (test cases like writing data in bulk to the COM port, etc) and they all passed.

I am curious about what is the difference in pasting the content on the Hyperterminal screen and typing characters manually. In both cases the app must be sending a write command to the target COM port (with a different payload in both cases although).

8

Have you tried copy pasting text in hyper terminal to a different com port
(one without your driver)? What is the behavior of hyper terminal then?
On Aug 25, 2014 11:35 PM, wrote:

> HI all,
>
> Thanks for your response so far. I figured out the problem in the my code.
> While i am timing out a request in my Interval timer (Hyperterminal sets
> the interval time out to 10 ms) I was not giving the data that i have at
> that moment to application. After doing it i found i am able to see each
> and character every character that i type on the Hyperterminal screen.
>
> I am implement GUID_DEVINTERFACE_COMPORT in my serial driver and i am
> implementing drivers for a multi port serial card.
>
> However i am now seeing another issue. When i copy some text and try to
> paste it on to Hyperterminal window, Hyperterminal is hanging and the data
> is not getting transmitted. I can’t see anything in the driver logs.
>
> What is expected is that the content should be transmitted through the
> target COM port and hence it should appear back on the screen (since i have
> connected the port in loopback mode)
>
> Could this be related to an issue in implementation of write in my driver?
> I tested the write functionality multiple times with various applications
> (test cases like writing data in bulk to the COM port, etc) and they all
> passed.
>
> I am curious about what is the difference in pasting the content on the
> Hyperterminal screen and typing characters manually. In both cases the app
> must be sending a write command to the target COM port (with a different
> payload in both cases although).
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

9

seetha wrote:

However i am now seeing another issue. When i copy some
text and try to paste it on to Hyperterminal window, Hyperterminal
is hanging and the data is not getting transmitted. I can’t see anything
in the driver logs.

Could this be related to an issue in implementation of write in my driver?

Gee, you think?

I tested the write functionality multiple times with various applications
(test cases like writing data in bulk to the COM port, etc) and they all
passed.

Serial IS NOT a dumb “bulk” pipe through which you can conduct arbitrary read and write I/O. Go through every single read, write, and IOCTL request that you got from Hyperterminal from the moment it opened the port. Make sure you’ve implemented everything on all of these pages:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363190(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363435(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363200(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363473(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363428(v=vs.85).aspx

10

xxxxx@gmail.com wrote:

I am curious about what is the difference in pasting the content on the Hyperterminal screen and typing characters manually. In both cases the app must be sending a write command to the target COM port (with a different payload in both cases although).

The only difference is the transmission speed. What do you do with
writes of more than one character?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

11

Well, that settles THAT. Contract compliance *clearly* required.

That puts Mr. Aseltine and I in complete agreement… in the case we MIGHT not have been before.

Peter
OSR
@OSRDrivers

12

Tim Roberts wrote:

The only difference is the transmission speed. What do you
do with writes of more than one character?

Excellent point, and yet another reason why serial is difficult; your hardware may only support writes of size “X”, but you may be submitted a write from userspace of some amount much larger than that.

OP will need to pend said userspace write requests while he sends the data in chunks (however this is accomplished in his “design”), and then complete when finished.

I believe the fakemodem sample refers to this concept as “staging I/O”.