i tried running this program on a relatively new HP winXPpro machine with a single built in serial port as well as 2 netmos PCI serial port cards. This program looks very useful for my application, which is to be able to debug a embedded target platform remotely through its serial port similar to the desire for microsoft EMS remote support through telnet.
The sockets seem to work like a charm, and it reserves the com port and I can telnet to the TCP port it opened wonderfully. Only problem is what I type into that telnet port do not go anywhere and I do not receive any output at all. Im using the basic windows telnet client also. Maybe im doing something wrong?
Its too bad, this looked useful for my application. There is a linux version available also, but I do not have access to a linux computer right now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes, I tried that. I also have tried using realterm also without many problems. The potential for this application is greater. Do you have directions on how to build this project?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have the standard motherboard serial port which uses its own windows com driver, as well as 2 PCI serial cards which use the vendor driver. I've tried hooking it up to both.
Im connecting via the correct COM driver also I have verified that and I know its not target computer because I can try it using hyperterminal and realterm and it works fine.
I'm pretty sure the com ports are using standard IO and IRQ addresses though I did not assign them myself. Is there something I should be looking out for?
thanks for your help.
-Aaron
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
also it gives me a
com.c: Problem opening port "COM1"
when I try to connect when there is another program using the com port.
My other program connects fine at 9600 baud with 1 stop bit, no parity, 8 data bits, no hardware flow control. Are these settings that need to be changed in tcp2com?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With --test argument, the program runs at 115200 bauds, no parity, 8 data bits, and hardware flow control (you can check it in the code on CVS if u have C skills).
The error of opening COM1 certainly comes from the setup difference.
I'll try within a short while to add more verbose output on the COM init - and maybe rest of init parts of the application, especially errors returned by Win32 API.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well that sheds some light I guess. Can I set these settings in TCP.com? I can change the settings on the target device but that speed is not supported. I could check out the code and do my own build with the settings I need if you think thats possible. It would be convenient if there was a switch in the call that would be able to set these values. I can't access the CVS right now but at my home I probably can. I have developed using C but rarely for windows.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i tried running this program on a relatively new HP winXPpro machine with a single built in serial port as well as 2 netmos PCI serial port cards. This program looks very useful for my application, which is to be able to debug a embedded target platform remotely through its serial port similar to the desire for microsoft EMS remote support through telnet.
The sockets seem to work like a charm, and it reserves the com port and I can telnet to the TCP port it opened wonderfully. Only problem is what I type into that telnet port do not go anywhere and I do not receive any output at all. Im using the basic windows telnet client also. Maybe im doing something wrong?
Its too bad, this looked useful for my application. There is a linux version available also, but I do not have access to a linux computer right now.
did you try to check connection directly on local com port, using a tool like HyperTerminal ?
yes, I tried that. I also have tried using realterm also without many problems. The potential for this application is greater. Do you have directions on how to build this project?
Are your COM ports using the standard IO and IRQ addresses?
Are you selecting the correct COM port when starting tcp2com?
I know... these questions are a little simplistic but sometimes its a little things that burn you,
Grald
I have the standard motherboard serial port which uses its own windows com driver, as well as 2 PCI serial cards which use the vendor driver. I've tried hooking it up to both.
Im connecting via the correct COM driver also I have verified that and I know its not target computer because I can try it using hyperterminal and realterm and it works fine.
I'm pretty sure the com ports are using standard IO and IRQ addresses though I did not assign them myself. Is there something I should be looking out for?
thanks for your help.
-Aaron
more details. This is what I can do:
C:\>tcp2com --test tcp/23 com1
Test mode - Press Ctrl+C to stop program
bridge.c: StartTcpSocket() succeeded
bridge.c: GetOverlappedResult() succeeded
bridge.c: Accepted connection from 127.0.0.1
bridge.c: Closed connection from 127.0.0.1 (Ctrl-C)
I connected using telnet localhost and that connected just fine until I did a ctrl-C like they said.
I tried using automatically generated PNP io/irq settings.
this is automatic.
IRQ= 04
IO range = 03F8-03FF
I have tried other settings as well without much luck. Thanks for the help.
also it gives me a
com.c: Problem opening port "COM1"
when I try to connect when there is another program using the com port.
My other program connects fine at 9600 baud with 1 stop bit, no parity, 8 data bits, no hardware flow control. Are these settings that need to be changed in tcp2com?
With --test argument, the program runs at 115200 bauds, no parity, 8 data bits, and hardware flow control (you can check it in the code on CVS if u have C skills).
The error of opening COM1 certainly comes from the setup difference.
I'll try within a short while to add more verbose output on the COM init - and maybe rest of init parts of the application, especially errors returned by Win32 API.
well that sheds some light I guess. Can I set these settings in TCP.com? I can change the settings on the target device but that speed is not supported. I could check out the code and do my own build with the settings I need if you think thats possible. It would be convenient if there was a switch in the call that would be able to set these values. I can't access the CVS right now but at my home I probably can. I have developed using C but rarely for windows.