Hi Wim Sturkenboom,

I tried using Hyper Terminal on my windows but did not receive any data from scales when I kept weight on it.

Thanks
Regards,

BTW what is the make/model of your scale.

Hi,

It is not an standard scale we got it for our college research and nothing related to it is available online. It is just a weighting scale as far I know.

Can I ask you one thing how to compile a C program with serial port connected. I mean as for reading from usb I have to compile using the command gcc -o program program.c -lusb.

Now I am trying to write C code using the link suggested by you. Hopefully that will work.

Looking forward for reply.
Regards,

Are you using a USB serial port adapter? Assuming that your device is supported it will typically have a device ID of /dev/ttyUSB0. Nothing special is required so all you need to do is replace /dev/ttyS0 with /dev/ttyUSB0 in the examples from the links provided.

I am doing using serial port.

You don't need any special libraries to use a standard serial port. The device driver creates a standard character device which can be accessed with the usual open()/read()/write()/close() paradigm. The termios interface is implemented without the need for additional libraries. See the termios man page for details. All of this applies equally for a standard UART-based serial port, or a USB-Serial dongle. The driver makes them functionally the same, except for the naming convention used.
I was able to copy & paste the example for Non-Canonical Input Processing from the Serial Programming Howto into a C source file 'serialProgHowto.c' and build with
To clean up the build, I added #include directives for stdlib.h & string.h.

--- rod.

I just remembered a tool that I have used somewhat in the past, which you will probably find useful: SerLooK. It should make it easier to view your binary data on the serial port. I have used it a bit in the past. It has a smallish domain of problems to solve and yours seems to be one of them.
--- rod.

Hello theNbomr,

The first thing to verify is that the serial port for which the software is configured is actually the one to which things are connected. The easiest way to do this is to get a piece of wire, such as a paper clip, and connect pins 2 & 3 of the serial port connector to each other. Use the terminal emulator to send some bytes, and see if they show up on the screen. If they do, you've confirmed that the port works, and that you've correctly associated the software with the correct port connector. It also confirms that your serial port has access permissions appropriate to the UID.


As I told you earlier I have tested using leds but then again you suggested me to do with the clips. I connected 2-3 pins using paper clip and opened my minicom and typed charters but I am not getting any character on minicom for any of the port ttyS0 or ttyS1. I have changed the permission for serial port by the command "chmod 666 /dev/ttyS0" but still it did not show any characters. What do you think the problem might be?

Looking forward for reply.

Regards,

Following with the logic of starting at the beginning, I would look through a recent instance of /var/log/messages and/or run dmesg, and confirm that there are serial ports that are identified as /dev/ttyS0 & /dev/ttyS1. If they are not there, then you should be able to identify what names the kernel/driver has created for them.

The test you did with the LEDs confirms nothing about how the software sees anything. If your terminal does not pass the loopback test, then it is very probable that you are using the wrong port name, or your software is misconfigured somehow. It is also possible (although improbable) that your kernel does not have a driver for your serial port hardware, and that you have not loaded an external driver. dmesg will tel you much about this.

Do you have any confirmation that the serial port(s) are actually functional with any software, or under any other OS? Not to sound disparaging, but are you sure that the connector you are using actually is a serial port? You wouldn't be the first person to connect to some other kind of connector, thinking it was a serial port. Is this a standard desktop PC?

--- rod.

Make sure hardware flow control is turned off (none).

Hello,

michaelk, I tried with hardware flow NO option . But still not getting anything on loopback test. On my minicom I have set serial port settings as
A - Serial Device : /dev/ttyS1
B - Lockfile Location : /var/lock |
C - Callin Program : |
D - Callout Program : |
E - Bps/Par/Bits : 115200 8N1 |
F - Hardware Flow Control : No
G - Software Flow Control : No

Regards,

Hello theNbomr,

Following with the logic of starting at the beginning, I would look through a recent instance of /var/log/messages and/or run dmesg, and confirm that there are serial ports that are identified as /dev/ttyS0 & /dev/ttyS1. If they are not there, then you should be able to identify what names the kernel/driver has created for them.


I have run dmesg |grep tty and I can see ttyS0 and ttyS1 in the output .

I have tested loopback test on both ttyS0 and ttyS1 settings as I do not know which one is for my serial port. dmesg is telling name of ttyS0 and ttyS1 , so I suppose drivers for serial port are there on my Linux box.

I do not know whether serial port on that Linux machine is working? It is tradition PC machine which has only Debian Lenny on it.I never checked serial port with any other software on it.

The connectors are serial port connectors only and I am able to see characters output of loopback test on separate windows machine on hyper terminal with same connector.

Regards,

Yes, dmesg shows messages emitted by drivers, so it confirms that the kernel knows about your two serial ports. Are these the only two serial ports that are reported by dmesg? Does that agrees with what you expect, based on other knowledge of the hardware?
So, you've performed the loopback test using a different host, and were successful there. But, you aren't able to get the loopback test working on the host in question. What is the output of
Can you use setserial to change things like bitrate, and then correctly read them back? Do you have an external modem, with LEDs on it? That can be a useful diagnostic, to reveal what a port is doing.
The list of possibilities is starting to narrow down to faulty hardware.
When you performed the loopback test, were you jumpering the pins right at the back panel connector of the host (ie. no cable attached)? Are you certain that you did not also short either of the pins to ground (which is usually present on the shell of the standard D-sub connector)?
I can think of no further testing that cannot be performed without a DVM or other method to measure DC voltages. I would want to see valid RS-232 line levels on all output pins of the serial port(s). From there, I would want to see those levels change in response to sending (Tx pin), or exerting control of other output pins.

I don't use minicom, but I guess it is possible that it leaves the serial port in cooked mode, which could require the user to press the 'Enter' key to send a line of text. Perhaps you could repeat the loopback test, pressing Enter after each character.

--- rod.

Hello theNbomr,

Thank you very much for all your time and valuable suggestions. I do not know what exactly was the problem, But now finally I am able to perform the loop back test.Now will start coding for the dumb device(Scales) and will ask you more questions.

Thanks again.
Regards

If your sign controller is sending AT commands, it probably means it is expecting to be dialing out to make a connection (and that does seem peculiar). If so, then you probably have to emulate a Hayes compatible modem in some way, to make the sign controller think it has made a connection. Try responding with strings like 'OK'. You will probably have to figure out, one command at a time, what the sign controller is sending, and return some response that will satisfy the controller that it is talking to a functioning modem.

--- rod.