views:

306

answers:

5

What's the problem in given code? Why it is not showing the output for rs232 when we connect it by the d-9 connector with the short of pin number 2 & 3 in that?

#include <bios.h>
#include <conio.h>
#define COM1       0
#define DATA_READY 0x100
#define SETTINGS ( 0x80 | 0x02 | 0x00 | 0x00)
int main(void)
{
   int in, out, status;
   bioscom(0, SETTINGS, COM1); /*initialize the port*/
   cprintf("Data sent to you:  ");
   while (1)
   {
      status = bioscom(3, 0, COM1); /*wait until get a data*/
      if (status & DATA_READY)
           if ((out = bioscom(2, 0, COM1) & 0x7F) != 0)  /*input a data*/
              putch(out);
           if (kbhit())
           {
              if ((in = getch()) == 27)   /* ASCII of Esc*/
                 break;
              bioscom(1, in, COM1);   /*output a data*/
           }
   }
   return 0;
}
A: 

Well, the code looks alright. Have you really connected the remaining pins correctly in the plug, see serial and pin connections.

Anders
A: 

Nothing obvious stands out from your code as the cause. Check all your bases as you are dealing with hardware/software. The following Microsoft article has a different implementation using _bios_serialcom (from bios.h) which might be a good reference point for you.

http://support.microsoft.com/kb/39501

Suggestions for where to go from here:

  1. I would also suggest replacing the literals (eg 0x08) using the constants predefined for Baud rate, Parity (eg _COM_NOPARITY) to make the code more readable in your question.

  2. Check that the Com port is actually open, as its a assumption which is unchecked in your code example above.

  3. Also check up on the pin connections for the DB9. To connect two computers/devices you will need to null modem it, eg pin 2 to pin 3 at the other end, plus the Signal Ground. Make sure you are disabling/not looking for DTR.

  4. If the other computer/device is setup then I would suggest first running HyperTerminal (Programs->Accessories->Communication) and connect to your COM 1 and check you can see characters from the other device. If not its most likely related to your cable.

Hope that helps.

miltonb
A: 

Before checking with your code always check your serial communication with a terminal program. I don't have much experience with Windows environment but in Linux you have programs like cutecom or gtkterm where you can send/receive data from serial port. We extensively used these programs for serial communication in Linux, they are great for debugging potential problems with serial port interface (both h/w & s/w as well). So, before suspecting your code check with a terminal emulator program.

rocknroll
A: 

Hey, I am not an expert on Win32, but it seems to be easier to use another article as a source (the one mentioned here before looks outdated):

http://msdn.microsoft.com/en-us/library/ms810467

This is old too, dated around 1995, but it looks still effective. The NT architecture is very restrictive when it comes to grant access to hardware, for example, to send bytes to a PC paralell port one needs to rely on workarounds dll written by open source developers.

zlogdan
A: 

I'm assuming from your comment about "pin 2 & 3" that you've connected a loopback cable, so you're expecting to see anything you type come up on the screen (and stop doing so when you disconnect the cable).

I think there's a bug in the code: the if (kbhit()) is inside the if (status & DATA_READY).

That means you only check the keyboard if there is some input ready to receive from the serial port - which there won't be, because you haven't sent it anything yet! Try moving the test and see if it improves matters.

(Here is some similar serial port code that puts the if (kbhit()) test outside the DATA_READY check. It doesn't claim to work, but provides some evidence that this might be the source of the problem...)

psmears