Linux Serial Programming

[ibwhoib]

Hey all,

I caught a job where I have to write a linux daemon that communicates with a
device connected to a serial port. Here are some details.

I connect to the device in the standard fashion:

fd = open(device, O_RDWR | O_NOCTTY | O_NDELAY);

I set the port options:

options.c_cflag = B9600 | CS8 | CREAD | CLOCAL | HUPCL;
cfsetospeed(&options, B9600);
tcsetattr(fd, TCSANOW, &options);

I now want to write some data to the port. The documentation on the device
has the following information:
"The command structure consist of one start byte, one command byte, five
bytes of data, and one byte checksum"
So I need a string of bytes. I created this string by using a unsigned
character array and setting the values to a command. Like so:

char cmd[7];
cmd[0] = 42;
cmd[1] = 0;
cmd[2] = 0;
cmd[3] = 132;
cmd[4] = 177;
cmd[5] = 0;
cmd[6] = 119;
cmd[7] = 188;

I then try to write the command to the port.

int written;
written = write(fd, cmd, 7);

My first question is is this the correct way to send this command?
Unfortunately, the device doesn't seem to think it is and returns 3 bytes
that are undocumented. I would appreciate any help. If you need any further
information, please let me know.

Thanks,
ib

[Ben Pfaff]

"ibwhoib" <ib*****@ibwhoib.com> writes:

I caught a job where I have to write a linux daemon that communicates with a
device connected to a serial port. Here are some details.

Your question is outside the domain of comp.lang.c, which discusses
only the standard C programming language, including the standard C
library. This is a remarkably narrow topic compared to what many
people expect.

For your convenience, the list below contains topics that are not
on-topic for comp.lang.c, and suggests newsgroups for you to explore
if you have questions about these topics. Please do observe proper
netiquette before posting to any of these newsgroups. In particular,
you should read the group's charter and FAQ, if any (FAQs are
available from www.faqs.org and other sources). If those fail to
answer your question then you should browse through at least two weeks
of recent articles to make sure that your question has not already
been answered.

* OS-specific questions, such as how to clear the screen,
access the network, list the files in a directory, or read
"piped" output from a subprocess. These questions should be
directed to OS-specific newsgroups, such as
comp.os.ms-windows.programmer.misc, comp.unix.programmer, or
comp.os.linux.development.apps.

* Compiler-specific questions, such as installation issues and
locations of header files. Ask about these in
compiler-specific newsgroups, such as gnu.gcc.help or
comp.os.ms-windows.programmer.misc. Questions about writing
compilers are appropriate in comp.compilers.

* Processor-specific questions, such as questions about
assembly and machine code. x86 questions are appropriate in
comp.lang.asm.x86, embedded system processor questions may
be appropriate in comp.arch.embedded.

* ABI-specific questions, such as how to interface assembly
code to C. These questions are both processor- and
OS-specific and should typically be asked in OS-specific
newsgroups.

* Algorithms, except questions about C implementations of
algorithms. "How do I implement algorithm X in C?" is not a
question about a C implementation of an algorithm, it is a
request for source code. Newsgroups comp.programming and
comp.theory may be appropriate.

* Making C interoperate with other languages. C has no
facilities for such interoperation. These questions should
be directed to system- or compiler-specific newsgroups. C++
has features for interoperating with C, so consider
comp.lang.c++ for such questions.

* The C standard, as opposed to standard C. Questions about
the C standard are best asked in comp.std.c.

* C++. Please do not post or cross-post questions about C++
to comp.lang.c. Ask C++ questions in C++ newsgroups, such
as comp.lang.c++ or comp.lang.c++.moderated.

* Test posts. Please test in a newsgroup meant for testing,
such as alt.test.

news.groups.questions is a good place to ask about the appropriate
newsgroup for a given topic.

--
"We put [the best] Assembler programmers in a little glass case in the hallway
near the Exit sign. The sign on the case says, `In case of optimization
problem, break glass.' Meanwhile, the problem solvers are busy doing their
work in languages most appropriate to the job at hand." --Richard Riehle

[Nick Austin]

On Sun, 18 Apr 2004 00:52:40 GMT, "ibwhoib" <ib*****@ibwhoib.com>
wrote:

I now want to write some data to the port. The documentation on the device
has the following information:
"The command structure consist of one start byte, one command byte, five
bytes of data, and one byte checksum"
That's 8 bytes.
So I need a string of bytes. I created this string by using a unsigned
character array and setting the values to a command. Like so:

char cmd[7];
unsigned char cmd[8];
cmd[0] = 42;
cmd[1] = 0;
cmd[2] = 0;
cmd[3] = 132;
cmd[4] = 177;
cmd[5] = 0;
cmd[6] = 119;
cmd[7] = 188;

I then try to write the command to the port.

int written;
written = write(fd, cmd, 7);

written = write(fd, cmd, 8);
or
written = write(fd, cmd, sizeof cmd);

Nick.

[Chris Torek]

In article <sj*********************@news4.srv.hcvlny.cv.net >
ibwhoib <ib*****@ibwhoib.com> writes:

fd = open(device, O_RDWR | O_NOCTTY | O_NDELAY);
Calls to open() and ioctl() (or tcsetattr(), which in turn is
usually just an ioctl()) and write() are off-topic in comp.lang.c,
in part because the details about which options you should use
(like O_NOCTTY and/or O_NDELAY) change from one system to another.
This, however, is on topic:
So I need a string of bytes. I created this string by using a unsigned
character array and setting the values to a command. Like so:

char cmd[7];
cmd[0] = 42;
cmd[1] = 0;
cmd[2] = 0;
cmd[3] = 132;
cmd[4] = 177;
cmd[5] = 0;
cmd[6] = 119;
cmd[7] = 188;

An array of size 7 has 7 total elements, in this case named cmd[0]
through cmd[6] inclusive. You are putting eight values (go ahead,
count them, there are 8) into a seven-value-size bucket. This
causes undefined behavior, i.e., the program may behave unpredictably
(or at least in a manner that, to predict, requires details that
one would not normally even want to think about).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.