i´ve a little trouble sending binary bytes through com0com.
When a 0x1A Char is sent, the communication stops.
I made this in terminal 1: copy /B COM5: received.dat
then in terminal 2: copy /B send.dat COM4:
send.dat is a small binary file including a 0x1a char.
I´ve got trouble sending files containing XON/XOFF Chars but was able to solve it chaning the mode of COM4/COM5 thanx to a post in this forum.
Is there a easy way to solve this new problem too?
or is it a bug?
are there any other dangerous chars i should test?
thank a lot
wurfholz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The "copy" can't get info about end-of-file of
serial port so CTRL+Z (0x1A) character is
interpreted as an end-of-file on input.
Using "copy" to transfer binary files via serial
port is not a good idea. To transfer binary files
via serial port you need to use a special program
(HyperTerminal for exemple).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I´ve already (this morning) discovered, that sending even huge binary files via hyperterminal works fine!
Currently I´m working on a application, similar to com2tcp, that can do synchronized connecting and disconnecting to a remote tcp-device (e.g. an embedded device with a own COM port). During Connecting, the pc sends the common com-port data (baudrate, databytes,....) to the device, which opens it´s real COM port with this parameters.
The Problem is, that I don´t know, what kind of data are tunneled through tcp. It depends on the third device that is connected via RS232 to the embedded device. But it might be Binary data including 0x1a I guess. or is it completely uncommon to send 0x1a via serial cable?
Do ordinary serial devices (like measurement devices or something like that) and their software counterparts usually do some escaping or protocolling like Hyperterminal to transmit 0x1A chars?
If not, would´t it be nice to have a com0com option for "streaming" (without stopping at eof) or something like that?
If you think this is possible, could you please tell me where to search within com0com?
this is the last issue, before i´m able to release the first beta. I hope it will open some new ways (especially for developers).
Greetings and thank you again
wurfholz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After carefully reading your post again (after lunch break :) ) and googling a little around for "copy" and "0x1A" I discovered, that this is more a copy problem than a com0com issue. Is it right, that com0com transfers even the 0x1A data (into the virtual COM port buffer!?) but then "copy" stops writing into the receive-file?
If yes, there is no problem, because every remote device has got it´s own serial software running locally, which can deal with 0x1A chars on it´s own way.
If this is all true, I like to apologize for my stupid answer before.
(has been a hard week...)
hello,
i´ve a little trouble sending binary bytes through com0com.
When a 0x1A Char is sent, the communication stops.
I made this in terminal 1: copy /B COM5: received.dat
then in terminal 2: copy /B send.dat COM4:
send.dat is a small binary file including a 0x1a char.
I´ve got trouble sending files containing XON/XOFF Chars but was able to solve it chaning the mode of COM4/COM5 thanx to a post in this forum.
Is there a easy way to solve this new problem too?
or is it a bug?
are there any other dangerous chars i should test?
thank a lot
wurfholz
The "copy" can't get info about end-of-file of
serial port so CTRL+Z (0x1A) character is
interpreted as an end-of-file on input.
Using "copy" to transfer binary files via serial
port is not a good idea. To transfer binary files
via serial port you need to use a special program
(HyperTerminal for exemple).
thanx for the quick answer Vyacheslav,
I´ve already (this morning) discovered, that sending even huge binary files via hyperterminal works fine!
Currently I´m working on a application, similar to com2tcp, that can do synchronized connecting and disconnecting to a remote tcp-device (e.g. an embedded device with a own COM port). During Connecting, the pc sends the common com-port data (baudrate, databytes,....) to the device, which opens it´s real COM port with this parameters.
The Problem is, that I don´t know, what kind of data are tunneled through tcp. It depends on the third device that is connected via RS232 to the embedded device. But it might be Binary data including 0x1a I guess. or is it completely uncommon to send 0x1a via serial cable?
Do ordinary serial devices (like measurement devices or something like that) and their software counterparts usually do some escaping or protocolling like Hyperterminal to transmit 0x1A chars?
If not, would´t it be nice to have a com0com option for "streaming" (without stopping at eof) or something like that?
If you think this is possible, could you please tell me where to search within com0com?
this is the last issue, before i´m able to release the first beta. I hope it will open some new ways (especially for developers).
Greetings and thank you again
wurfholz
After carefully reading your post again (after lunch break :) ) and googling a little around for "copy" and "0x1A" I discovered, that this is more a copy problem than a com0com issue. Is it right, that com0com transfers even the 0x1A data (into the virtual COM port buffer!?) but then "copy" stops writing into the receive-file?
If yes, there is no problem, because every remote device has got it´s own serial software running locally, which can deal with 0x1A chars on it´s own way.
If this is all true, I like to apologize for my stupid answer before.
(has been a hard week...)
Greetings
wurfholz
PS: Here is the interesting link, which gave me "illumination":
http://chrio.org/serial/
> Is it right, that com0com transfers even the 0x1A
> data (into the virtual COM port buffer!?) but then "copy"
> stops writing into the receive-file?
Yes, it's right.