Serial communication problem

[tbrown]

Hello. I have the task of building an interface between an old serial device with limited and obscure flow control and the serial port on a PC. Programs on the PC fail, because the device is expecting real time synchronous communication, which Windows is having a hard time doing. My idea is to build/program an interface box that sends information through a serial port to a device and captures the data coming back into RAM. When the device is finished, I can then download the information in the RAM to a PC through another serial port on this device which. This part will then not need to be time dependant. My question is, where do I go to get started and what types of things are available where I could program a chip to do something like this? Thank you in advance!

 

[crust]

Is it really so bad that the device communication is not working. I recall having a similar device where the time between different messages was critical, but I had no trouble getting it working in Linux.

You could simply make a device with two serial ports that handles the real-time aspect of talking to your slave. Other than that, it would just pass the data back and forth. You could easily do this with a microcontroller that you could program yourself.

 

[tbrown]

Thanks for the reply. While I have experience in writing applications for computers, I have no idea where to begin with hardware devices such as this. The idea you presented was what I was thinking of. What needs to be done to build/program a device to the such a thing?
Thanks!

 

[Exo]

Hello. I have the task of building an interface between an old serial device with limited and obscure flow control and the serial port on a PC. Programs on the PC fail, because the device is expecting real time synchronous communication, which Windows is having a hard time doing. My idea is to build/program an interface box that sends information through a serial port to a device and captures the data coming back into RAM. When the device is finished, I can then download the information in the RAM to a PC through another serial port on this device which. This part will then not need to be time dependant. My question is, where do I go to get started and what types of things are available where I could program a chip to do something like this? Thank you in advance!

Serial communications on the pc side can be done real-time. If you have some knowledge of visual C++ it's pretty easy. Just create a second thread in the main program that handles nothing else besides the serial communications...

If you're stuck with VB that's a whole diffirent story :?

 

[tbrown]

Hmmm... I actually went ahead and wrote a multithreaded application with a sender and a receiver. I wrote it in C# on .NET though and not C++. It came real close, but sometimes, for some reason, usually an end-user receiving mail or another application using a tremendous amount of processor power slows the thread down too much and data gets lost. At any rate, it wasn't working. Was it the fact it was C# maybe?
Thanks again,
-tim

 

[Exo]

I don't know about C#, does it get compiled into a real executable, or is it a semi executable like VB...(wich means sloooooooow...)

anyways, you could try to set the priority of the thread to realtime.
I've never had any problems with it :?

 

[bmcculla]

The problem is the windows OS. Windows isn't a real time OS which means that the OS can interrupt your program at any point no matter what your program is like. This fact makes windows useless for any task that requires a specified latency. So there is no way to solve your problem with windows.

You could get a Real Time version of Linux or use an embedded solution. An embedded solution will probably be much easier. Just find a micro with two uarts to make your life easy.

Brent

 

[tbrown]

A micro with two uarts sounds like what I was looking for. Any one in particular you could recommend?
Thanks!

 

[bmcculla]

I think Atmel has some AVR's with two UARTS. I know Silicon labs has 8051's with 2 UARTS.

Brent

 

[tbrown]

Excellent. Just one last question about this then. In regard to the 8051, I have seen it operates in 4 modes. Modes 2 and 3 say there is a 9th data bit. The device I need to control uses 1200,8N2, I guess making each word 11bits long. Could I use one of the "data" bits for the extra stop bit?
Thanks, you've been a great help!

 

[Nigel Goodwin]

Excellent. Just one last question about this then. In regard to the 8051, I have seen it operates in 4 modes. Modes 2 and 3 say there is a 9th data bit. The device I need to control uses 1200,8N2, I guess making each word 11bits long. Could I use one of the "data" bits for the extra stop bit?
Thanks, you've been a great help!

As you're programming the device yourself it's not a problem, in any case receiving 8N2 is exactly the same as receiving 8N1. To transmit 8N2, simply send 8N1, then run a one bit time delay loop to waste an extra bit time. The only reason for having two stop bits is if the receiving device is slow (like a printer or something), the extra stop bit gives it more time to finish what it's doing before the next data byte arrives.

 

[aevans17]

C# is an interpreted language like Java so it is slower then true x86 machine code. however the problem is not the code it is the operating system. As others have said windows can interupt your code anytime it feels like and let something else happen. You could write your own Kernel mode driver to get better performance, but that might not work all of the time.

How did you write your C# code to communicate with .NET. did you use the netserialcomm code that was posted on MSDN??
OR
did you use interop and write the serial code yourself????

Most likely the code is causing the problem. If you wrote a seperate thread, even using .NET that sends the data you should be okay.

 

[Exo]

I've made some apps (in visual C++) wich required immediate response from pc, and like i said, it works perfectly...

Don't forget the fact that modern pc's run at speeds of 2 - 3Ghz. Even if windows interrupts your program to do something else, the USART would still be sending - receiving in the background. The time it takes to send 1 byte at 9600 baud is an eternity for a modern cpu...