|
matrix2681 wrote: I'm not familiar with how USB even works, much less how it receives and interprets the information it gets.
Neither am I, but after some quick googling it seems that your scenario might not work due to the "power" control aspect of USB. You might want to do some research on this subject.
|
|
|
|
|
I did find something that makes it work, but it seems like more of a hack job than anything.
I found a program that I wrote before for messing with RS232, and made a connector that allowed the computer to talk to itself. So I looked at the device manager on here and saw that it considered the USB port to be "COM5". Basically it looks at it as a regular port.
So I modified the program to send data out COM1, like it used to (the RS232 port) and expect data to come in COM5, and it seems to work.
I'm not sure if this is what I want though... but it *can* take info in the port and display it... but there needs to be an RS232 connection present.
hmm...
What did you see about power control that set a red flag off for you? I know that power might be an issue since whatever project is made will be something standalone, so maybe it'll demand too much? USB can power devices from the power supply on the computer right?
Thanks,
Michael Fritzius
|
|
|
|
|
matrix2681 wrote: What did you see about power control that set a red flag off for you?
this discussion[^]
in the case of a connecting two PC’s USB ports directly things would fail (aside from the major electrical issues) because both PC’s would try to exert control and expect the other to submit... to get around this problem PC to PC USB cables have a controller within that allows each PC to think that they are in charge
|
|
|
|
|
Hi,
I am in the middle of similar things, i.e. I have a setup with some old Macs and my own
little microcontroller-based network, and I want to port that to one or two PCs that
dont have serial ports natively.
Some remarks:
1. in order to connect two PC's serially (also when looping back to the same PC) you
need a "null modem" (that's either a null modem cable or a very small null modem adapter,
both having two female DB9 connectors). I guess you figured that one out already.
2. I havent observed/measured it yet, but the addition of a USB-to-serial converter is likely
to add some latency, i.e. the characters will be transmitted/received a bit later than
would be the case in a direct RS232C interface; there are two reasons for this:
- encapsulating I/O commands in USB packets has some overhead;
- the USB-to-serial will try to utilize USB bandwidth the best way it can, i.e. not strain it,
so it will knowingly wait a while to see whether it can pack a couple of characters in
one packet.
3. Also I believe the timing of control lines (DTR/RTS/etc) may be somewhat less accurate,
so if you want to interface to special hardware that strongly relies on these timings,
it might go wrong.
4. The USB-to-serial cable comes with some software (a driver) that turns it into an
almost normal COM port: you can choose its number, after that it should show up in regular
lists of serial ports. As a result you can use any terminal emulator (HyperTerminal),
select and use the port.
5. The USB-based serial port probably shows up under Device Manager in a different category,
possibly named after its manufacturer (as opposed to the Ports category).
Cheers !
|
|
|
|
|
Luc Pattyn wrote: 4. The USB-to-serial cable comes with some software (a driver) that turns it into an
almost normal COM port: you can choose its number, after that it should show up in regular
lists of serial ports. As a result you can use any terminal emulator (HyperTerminal),
select and use the port.
This is what I've done. The driver software that came with this did exactly that. Any kind of project that is made will have something like this RS232-to-USB converter on board, since the solid, cheap chips I use have RS232 built in. Do you think this is a safer way to accomplish what I'm doing?
See, the thing is, I want to stay away from having to designate this device as a particular thing so that a particular driver can act on it. Nothing I make will be able to be labelled like that anyway--they will just be sending out information. If I can bypass that standard by just treating the whole USB port like a fake COM port, then that's awesome. Basically, I'm looking for a way to make a program that needs info from somewhere, and here (COM5--the USB port) is where to get it.
In fact, I just used HyperTerminal with an old project that talks to a GSM modem and it is able to receive info just as if it were looking at COM1, like it used to.
So I don't know. I mean, bearing all that in mind, would it still be necessary to do all the registering and driver matching for whatever device I make, or no?
|
|
|
|
|
Hi,
there seems to be a misunderstanding: it is the USB=to-serial converter that requires (and
comes with) a driver, independent of what you intend to do with the serial port.
So for any given model of USB-to-serial you install the driver once, that's it.
If later on, you decide to buy another make of USB-to-serial, that would come with its
driver, which you would have to install once. After that, you should be able to use both
of them, any way you see fit.
So none of this is directly related to the RS232 side: whether you connect a real terminal,
another PC, a GSM, or something you build yourself, it is all the same.
Basically one USB-to-serial convertor together with its driver replaces one RS232C port
And there is no way you can "speak to the USB port", you can only speak to a device connected
to the USB; same is true for Ethernet.
|
|
|
|
|
I see. That clears things up.
Thanks again everybody,
Michael Fritzius
|
|
|
|
|
I guess now the question is: How do I send data out the USB port, to the converter?
|
|
|
|
|
 seems you did not get it after all.
Forget about USB, once you installed the cable and its driver, it has become a
regular serial port (COM3 or whatever) except for the few comments I gave much earlier.
so you use the SerialPort class and talk "to the DB9 connector" if you really want to
talk to something other than what is at the other end of the cable.
if, for some reason, you decide to buy a "terminal server" (that's a box that would
connect 1, 4, 8 or 16 serial ports to an Ethernet cable), things would remain the same:
install a driver, figure out the names of the ports (possibly call one more method to
get things set up), then speak "SerialPort" stuff.
|
|
|
|
|
I understand how the converter works--it treats the USB port like a regular serial port.
The problem I'm having is that, while it can send data from the RS232 to the USB and show up on the screen, it doesn't show up when I try to send it from the USB to the RS232.
If it's supposed to work both ways, then I have a mistake in my code. I'm just trying to figure out where to start looking for errors--is it in the code? Maybe the ports aren't handled right? Maybe I've got the wrong kind of cable connecting the RS232 and USB ports?
If you'd like to take a look at the code, I'd be happy to send it to you.
Take care,
Michael Fritzius
|
|
|
|
|
matrix2681 wrote: Maybe I've got the wrong kind of cable connecting the RS232 and USB ports?
???
you did buy a USB-to-serial cable, didnt you ? That would plug into a USB port
and end on a male DB9 connector, exactly the same as can be found on some modern
and all old PCs.
So you then need a "null modem cable" which you can buy too; such cable is
completely symmetrical, you can interchange both ends, it will do the same job.
If you did built the null modem yourself, test it by reversing it.
|
|
|
|
|
I should recap something for you here:
I just tried running two instances of HyperTerminal, one set up for COM1 and the other on COM5 (the USB port).
It works, so the connection and wiring are all right. So that means something is definitely wrong in the code.
Any ideas?
Take care,
Michael Fritzius
|
|
|
|
|
Sure, I bet you forgot to set RTS, that is mySerialPort.RtsEnable=true;
I trust HyperTerminal does it (as long as it owns the port).
|
|
|
|
|
Well it's set to "true" for both ports.
Also, I just commented out the part in the code that opens the RS232 port, and instead used HyperTerminal to watch that one. Data sent out the USB port is caught by HyperTerminal... but not by the program itself. I can also send characters from HT and it shows up, as they are typed, in the program (which is to be expected, since data is being sent one byte at a time instead of the whole string).
I don't know if this will help or not, but I've got the whole program set to ignore any cross-threaded calls. Would this be a problem?
Take care,
Michael Fritzius
|
|
|
|
|
Hi,
matrix2681 wrote: ignore any cross-threaded calls. Would this be a problem?
It is in general a bad idea.
I don't expect it wil affect the serial port I guess, it will, if anything,
show up as a GUI that works half or not at all (immediately or after some time).
Do not do this. Fix it, you will have to fix it anyway, why run such risks now.
If all you need is visual feedback from some thread, use Console.WriteLine(),
that works all the time (towards Visual's output pane when running under Visual).
So your app receives, but is unable to transmit ? That is a first, most
people get the opposite.
I trust you have code for synchronous transmission, i.e. port.WriteLine() ?
IIRC the default settings are OK for simple transmission.
This is code from my very first SerialPort experiment:
SerialPort port;
...
port=new SerialPort(portName, 9600, Parity.None, 8, StopBits.One);
port.Encoding=Encoding.ASCII;
port.NewLine="\r\n";
port.Open();
...
port.WriteLine(someString);
Hope this helps.
|
|
|
|
|
matrix2681 wrote: Well it's set to "true" for both ports
That cant be true, if one port belongs to your app, trying to transmit;
and the other port is handled by HyperTerminal.
Either your app or HT must be failing to open the port (who ever comes last).
You are putting things in try-catch and properly showing all exceptions, are you ?
|
|
|
|
|
Here's what I have for initializing the ports:
serialPort1.ReadTimeout = 1000;<br />
serialPort1.BaudRate = 115200;<br />
serialPort1.StopBits = StopBits.One;<br />
serialPort1.Parity = Parity.None;<br />
serialPort1.DataBits = 8;<br />
serialPort1.RtsEnable = true;<br />
serialPort1.PortName = "COM1";<br />
serialPort1.Encoding = Encoding.ASCII;<br />
<br />
serialPort2.ReadTimeout = 1000;<br />
serialPort2.BaudRate = 115200;<br />
serialPort2.StopBits = StopBits.One;<br />
serialPort2.Parity = Parity.None;<br />
serialPort2.DataBits = 8;<br />
serialPort2.RtsEnable = true;<br />
serialPort2.PortName = "COM5";<br />
serialPort2.Encoding = Encoding.ASCII;<br />
I added a couple of buttons that can turn on/off the ports on the fly, so I can test with HyperTerminal if needed. But both port have RTS line enabled. The ports aren't opened immediately after the program starts, but the settings are set. Just press a button and go for it. port 1 is the RS232 and port 5 is the USB.
Here's how I handle sending/receiving messages:
private void serialPort1_DataReceived(object sender, SerialDataReceivedEventArgs e)<br />
{<br />
txtfromusb.Text += (serialPort1.ReadExisting());<br />
}<br />
<br />
private void serialPort2_DataReceived(object sender, SerialDataReceivedEventArgs e)<br />
{<br />
txtfromrs232.Text += (serialPort2.ReadExisting());<br />
}<br />
<br />
private void sendfromrs232btn_Click(object sender, EventArgs e)<br />
{<br />
try<br />
{<br />
sendtextfromrs232.Text += "\r";<br />
serialPort1.WriteLine(sendtextfromrs232.Text);<br />
sendtextfromrs232.Text = "";<br />
baudRatelLabel.Text = "Ready";<br />
}<br />
catch (System.Exception ex)<br />
{<br />
baudRatelLabel.Text = ex.Message;<br />
}<br />
}<br />
<br />
private void sendtextfromrs232_Click(object sender, EventArgs e)<br />
{<br />
sendtextfromrs232.Clear();<br />
}<br />
<br />
private void sendtxtfromusb_Click(object sender, EventArgs e)<br />
{<br />
sendtxtfromusb.Clear();<br />
}<br />
<br />
private void sendfromusbbtn_Click(object sender, EventArgs e)<br />
{<br />
try<br />
{<br />
sendtxtfromusb.Text += "\r";<br />
serialPort2.WriteLine(sendtxtfromusb.Text);<br />
sendtxtfromusb.Text = "";<br />
baudRatelLabel.Text = "Ready";<br />
}<br />
catch (System.Exception ex)<br />
{<br />
baudRatelLabel.Text = ex.Message;<br />
}<br />
<br />
}<br />
Oh I am so stuck  Can I send you the entire project? I know you said you were working on something similar, so if you have the hardware ready, maybe you can get further than I have.
Take care,
Michael Fritzius
|
|
|
|
|
Hi,
I am not going to adopt your project right now.
I suggest you show more of the code: the instantiation of the port(s),
and the read and write code.
You have not yet told whether they are synchronous/asynchronous, and I am
getting the impression you are mixing characters and bytes, which are not
interchangeable (a char is 16-bit Unicode, a byte is 8-bit).
And you have not given clear symptoms:
HT (as a receiver) shows nothing at all ? some good chars + some strange chars ?
only strange chars ?
|
|
|
|
|
The code I put up before is almost the whole thing, short of a few housekeeping snippets like clearing the textbox when the user clicks on it. I think this message you sent was sent before you saw the code though.
When both ports are examined by HT (not using my program at all), the ports can talk to each other just fine, both ways. So the hardware is solid.
When my program is running and sending data out one port, with HT receiving on the other, HT can receive all data, regardless of if it's looking at the RS232 or the USB.
The problem shows up when I try to use only my program. Data can come in the USB port, but data sent out the USB port either gets garbled, or is misunderstood by the converter or something else.
(also I tried reversing the cable, and it still works in the same way listed above, so it is in fact a null modem cable, like what I need )
I know this seems really weird, and it seems like it SHOULD work... but for whatever reason, a transfer from USB to RS232 just ain't happening in my program.
I just thought of something... do you think that including the driver DLL that came with the converter as a reference would help? I mean it's obvious that HT has the ability to get and understand whatever is coming in the USB port. Could it be that HT is making use of something that I have to tell my program to make use of the same DLL or something?
|
|
|
|
|
Give this a try:
replace both lines containing port.WriteLine(...) by port.WriteLine("abcdefghijk");
and test again.
|
|
|
|
|
|
That's too bad.
Writing to a serial port is the simplest part of it all. It takes no more than 10
to 15 lines of code to come up with an entire Console app that does exactly that.
And that is the only thing I can recommend under the current circumstances.
Good luck.
|
|
|
|
|
Ok let's try a different approach then.
I'm noticing the common problem being when data comes out the USB--either from the program or HT--and goes to the RS232 that's associated with the program. The common thing is the RS232 when the program is running.
Is there any reason why the RS232 wouldn't understand input?
Thanks for your time so far, there are a lot of things I wouldn't have guessed at had it not been for your input.
Take care,
Michael Fritzius
|
|
|
|
|
correction
Seems I somehow missed reading part of your last message.
my current impression is you confused yourself having two ports in your app.
matrix2681 wrote: //write line to USB port
sendtextfromrs232.Text += "\r";
serialPort1.WriteLine(sendtextfromrs232.Text);
//clear the text box
sendtextfromrs232.Text = "";
The above seems inconsistent, are you refering the right TextBox (or whatever
sendtextfromrs232/USB may be) ?
|
|
|
|
|
This is just the box that holds the text to be sent out the RS232 port. All it does is send it using the WriteLine() command and clear the box. The other method for this, the one that uses serialPort2 is the one associated with the USB port. It works the same way.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
