minicom for serial communication in C under Linux
 

Hi all,


I am new to minicom. I have followed links and help online. I am able to see my serial port ttyS1. I as configured it and all for my protocol. But after connecting my serial port device and running minicom -c on. I do nto know how to proceed from there. Can any one tell me or suggest me the link where I can find details on it.

I want to read data from weighting scales to my linux machine in C program using serial port communication. Do you think I can use minicom for the same . if yes how?

please do suggest me , i need it to be done.

Thanks

Cadd

Similar to a question you asked in your other thread. You say "your protocol", and then describe wanting to run a C program to read data. You can't do both, and don't need to.

Minicom is a terminal emulator. It hooks up to a serial device. You press a key, it goes out, and anything received is displayed on the scren. That's it. Got basic file transfer capabilities via protocols like xmodem, etc., but there's not much to it. If you've written a C program to read/write data from a serial port, use it to read the data from the scale. Minicom doesn't enter into it. You CAN run a script through Minicom, but it's a manual process to kick it off and keep it running.

Thanks for reply.

So you mean if I put a weight on the scales minicom should show it. But it is not doing any thing . What I am seeing on my screen is it

Welcome to minicom 2.3

OPTIONS: I18n
Compiled on Feb 24 2008, 16:35:15.
Port /dev/ttyS1

Press CTRL-A Z for help on special keys


when I put a weight on my scale it does not read anything.
I even do not know why it is saying compiled on Feb 24 2008.

can u please help me with it. at least i will be sure that my scales are working.

then i will do the c programming stuff as u suggested.
thanks

First, spell out your words, and do not use that texting shorthand garbage here. It's against LQ rules, and rude.

Second, if you don't see anything on minicom when you put something on the scale, you either don't have the right serial port, have a mismatch in speed/parity/bits, or your scale isn't sending data. There's no other option...serial is as simple as it gets. Even if speed is wrong, you'd see garbage on the screen. You say nothing about what KIND of scale, so it's hard to give any details. Read the manual that came with it, and it should mention whatever you need to do to make it work via serial, along with speeds, etc.

Be aware that the FIRST serial port in Linux isn't ttyS1, but ttyS0. And if you're using a USB to Serial device, it's ttyUSB0.

Hello,

Thanks for your quick reply.

I am sorry, I do not want to be rude or do anything which is against LQ rules. I will keep it in mind and will never ever repeat it.

I have tried what you have suggested. But still not getting anything on minicom.

I am connecting scales through a modem cable to a box and from box , I have a RS-232 cable going to my Linux machine. I have set speed, data bits, parity and stop bit properly.

Apart from that my scales document says all commands start with an HEAD character followed by a length byte, the command itself, a checksum byte, and an END character at the end.

HEAD | L | x | C | END

Values in the form 0x00 are base 16 (hex).

Looking forward for reply.

With Regards,

Great. But, you are still lacking detail. Saying you connect "through a modem cable to a box and from box", doesn't give us alot to go on. What "box"? WHERE are you plugging into on your Linux machine? Have you tested and verified that the cable is good? Confirmed that you're using the right serial port???

Brought this up before...but you haven't answered. What serial port are you connecting to on the Linux system??? Are you ABSOLUTELY sure the cables are working? Are you using a null-modem cable, or straight through, and have you tried with/without those?? (sometimes transmit/receive is swapped, and you'll get no data) Explain what the "box" is...

When using serial interfaces, there are a number of places where things can go off the rails.

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.

Next, you need to confirm that the communications parameters, such as bitrate, parity, word size, etc are correct for the device with which you need to communicate. This should be documented with the device under test. There may also be requirements for handshaking/flow-control, and these too, should be understood. This may be related to the next point...

Finally, you need to confirm that the cable configuration is appropriate to the task. Not all serial cables are created equal. Some are 'cross-over' cables, which connect one end's transmit pin to the other end's receive pin and vice versa. Some are equipped with differing numbers and combinations of other RS-232 signals. In most cases, for modern devices that are not modems, a simple 3-wire cable containing Rx-Tx-Ground pins/conductors will work. It is vital that the end-to-end connection results in one device's Tx pin connecting to the other device's Rx pin. The pinout of the device at each end should be documented (one end is the computer), as should the nature of the cable.

In almost all cases, the Rx & Tx pins are on pins 2 & 3, but there is about equal probability which will be Rx and which will be Tx. If you have a DVM or oscilloscope at your disposal, you can easily see which is the transmit pin, as it will always have a non-zero voltage present on it. A ground connection can usually be gotten from the metallic connector shell.

Once the serial communications are working, there is still the matter of 'what' will be sent and received. As it appears, your device does not transmit strings of human-readable text, as do many other test & measurement devices. You may not be able to use a simple terminal emulator to accomplish much of a proof-of-principle test.

As an alternative to minicom, I prefer to use C-Kermit, which I find more flexible, scriptable, and generally of greater utility.

--- rod.

Hello TBOne,

Box is basically converter for RS-485 to RS-232. A cate 5 cable is coming from scales to box and then RS 232 is connected to serial port of Linux machine.I have mistakenly wrote modem cable in my last post which is cate 5 cable.

I have checked that cate 5 cable is working fine on my windows machine. I am able to see the weights using RS-232 connector to serial port of windows machine using the software provided by the scales manufacturer .

I have run the minicom for both ports ttyS0 and ttyS1. But did not get anything on the minicom.

Thanks
Regards,

Hello theNbomr,

As per your suggestion.

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.

I took an led and connected to pin 2,3 of Rs-232 connector and it was glowing. So the connector is working fine.And did the same to serial port pins also and Led was glowing.

I used xterm as terminal emulator. Did you mean typing in xterm and seeing the characters in minicom while keeping pin 2,3 of RS-232/serial port connected? I did that and could not see any thing on minicom for ttyS0 or ttyS1 settings.I have set speed , data rate, parity and stop bit correctly.

You suggested C-Kermit in your post, How can I get it.It did not appear in synaptic package manager?

Looking forward for reply.

Regards,

Without seeing the exact commands it is difficult to tell but it looks like the protocol is a binary format. This makes using minicom a bit difficult. I would also guess that you must poll your device for data which is why you do not see characters being continuously displayed in minicom.

Hopefully, the documentation explains in more detail how to communicate with your device then you have posted.

You are going to have to write a program to display data. Here is something to get you going.
http://tldp.org/HOWTO/Serial-Programming-HOWTO/

By 'terminal emulator' I meant a comm's program such as C-Kermit or minicom. To get C-Kermit, just click on the link in my earlier post. You'll have to build it from sources.

Your LED test is of some value, but doesn't confirm that the port you tested is actually the one your program is trying to use. Create a loopback by connecting the Tx pin back to the Rx pin. Typing characters into the comm's program with the loopback installed should display them (maybe two of each, if local-echo is enabled). That will confirm that your port sends and receives, and that the software is using the correct one. Use the LED test to find which of the pins at each device is the Tx pin: connect the LED between 2 and ground, and between 3 and ground. The one that lights the LED will be the Tx pin. It must connect to the Rx pin of the other device.

As michaelk also points out, you will probably not be able to see human-readable text emitted from the device. You will need to write some code to poll the device according to the documentation. See also:

Serial Programming Guide for POSIX Operating Systems
Serial Howto
as well as a plethora of other good info and code samples you can find with a Google search for 'linux serial programming'.

--- rod.

Thank you michaelk and theNbomr. I really appreciate your time and efforts.

I think I will have to write a code for getting it work as you both suggested. I have never worked with hex , binary data and serial port in C.I have tried goggling also but I kind of gets confused with different kinds of available I/O API's for linux like termio,termios and ioctl.

Can you please suggest me which I/O API should I concentrate and where can I find nice example for serial communication on that.

Thanks
Regards,

The different APIs all serve different and relevant parts to the serial communications system. I strongly suggest that you start with one of the good examples in the links that I and others have suggested. The termios interface provides a method to control the interface (as opposed to the device it connects to). Linux carries quite a lot of baggage around with the serial port as, historically, it was the principle interface used by users to login to a host, and perform work. To cater to the special needs of users attaching their serial terminals to serial ports, the driver was given properties that are mostly irrelevant to most of today's applications for serial ports. However, those properties still exist within the driver, and we must be able to control them, which is what the termios interface provides.
Don't get too worked up about hex vs. binary; they're all just bytes. Whatever radix you chose to represent them doesn't matter; you're just sending a stream of bytes to the device, and presumably, receiving the same in return. You are going to enable the serial port into raw mode, since there are not going to be lines of text delimited by newlines, but rather arbitrary bytes, delimited according the the device's published protocol. (BTW, does your device have a web site describing the protocol?)
If you have another computer with a serial port at your disposal, it may be of value to use it as a replacement for your device in the early stages of your software development. By running a serial terminal emulator on the other computer, it can act as a convenient way of sending and displaying received serial data. It will allow you to see what your code is sending, and to exercise the receiving side of your code (although you will ultimately have to go to non human-readable data to communicate with your device). You will need to make sure that this dummy device is properly cabled to your computer, as described earlier.
Good luck with your project,
--- rod.

Instead of using the dedicated software, use (a properly configured) hyperterm and see what is happening when you put a weight on the scale. You should see something although it might be garbage (in case of binary data). At least you can get a feel for the data.

Not necessarily, although it depends on the device and how it is configured. Some require a command to continuously output data to the serial port. If the setting can be saved then it could possibly output data when powered up.