Help! serial communications programming in c

[vicky]

Hello,I met a question when I wrote the program.I want the program can
transmit the data frame continuosly through the RS232 when the
communication has been interrupted.But I don't know how to write. I
don't know how to record.Who can give me hand?Thanks very much!

[Walter Roberson]

In article <11************ **********@e56g 2000cwe.googleg roups.com>,
vicky <lj******@163.c om> wrote:

Hello,I met a question when I wrote the program.I want the program can
transmit the data frame continuosly through the RS232 when the
communicatio n has been interrupted.But I don't know how to write. I
don't know how to record.Who can give me hand?Thanks very much!

The closest that the C language itself comes to knowing about
RS232 or serial communications, is that there are certain
provisions about default buffering if the implementation can
prove that a stream is a "terminal". C does not define what
a "terminal" is, though, so the connection between that and
"serial" is pretty weak.

This newsgroup, comp.lang.c, only deals with that which is
covered in the C standards. Hence, this is not an appropriate
newsgroup for asing about RS232 or serial communications.

I would redirect you to a more appropriate newsgroup, but you
did not mention anything about which OS you are using,
so I cannot tell you at the moment which would be the appropriate
place. Probably one of the Windows or Unix newsgroups.

When you go to post your question to a more appropriate newsgroup,
I would suggest that you explain your question in more detail.
I do not understand what you mean when you say that you want
the program to transmit the data frame "continuous ly" when the
communications has been interrupted. I am not sure if you are
talking about the bit level, or the character level, or some kind
of packet level. I cannot tink of any circumstances under which
continually retransmitting the same bit or byte would be useful,
and retransmitting the same packet would normally not be done
until you were sure the other end had not received it. I do not
know how you intend how to detect that "communicat ion has been
interrupted".

I have to wonder whether you are reinventing things, and whether
you would perhaps be better off using an already written
transmission program such as x-modem, z-modem, or kermit.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[vicky]

I mean that when my program is ended or my computer is closed
suddenly,the program can transmit data from the former when I reset.And
the OS is Windows.The data I want to transmit is byte.

[Keith Thompson]

"vicky" <lj******@163.c om> writes:

I mean that when my program is ended or my computer is closed
suddenly,the program can transmit data from the former when I reset.And
the OS is Windows.The data I want to transmit is byte.

Read and understand <http://cfaj.freeshell. org/google/> before you
post to Usenet again.

Your question is off-topic. Try a Windows-specific newsgroup (I don't
know which one). And when you do, try to be clearer about what you're
asking.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[joeschmoe40]

Where is Kenny McCormack - when we need him?

[Walter Roberson]

In article <11************ **********@j33g 2000cwa.googleg roups.com>,
vicky <lj******@163.c om> wrote:

I mean that when my program is ended or my computer is closed
suddenly,the program can transmit data from the former when I reset.And
the OS is Windows.The data I want to transmit is byte.

This is, as I indicated, not on-topic in comp.lang.c .

What you want to do cannot be done with RS232 serial communications.

RS232 provides no mechanism for the remote end to signal that
it has received any particular byte, so there is no way for the
serial port to detect whether a particular byte was transmitted
successfully or not.

Typically when you are transmitting serial data, your application
queues a number of bytes to be transmitted and lets the serial driver
handle the details -- so your application would not typically
know which byte had been reached before the application
unexpectedly quit. Your application could choose to submit
only one byte at a time and wait for the data write call to
return, but you would almost certainly lose a *lot* of performance
that way, as you would be expecting the computer to handle
3840 interrupts per second.

The only realistic way to handle what you appear to want to do,
is to use an application protocol that is able to negotiate with
the remote end to detect where to resume. If you go to that trouble,
you would usually also want the application protocol to detect
transmission errors and automatically re-send when bad data was
detected or when bytes accidently got lost. Two well-established
protocols that can do these things are kermit and z-modem. The
z-modem protocol is small enough to be practical for an experienced
programmer to re-implement, but you do not appear to be an experienced
programmer, so I would suggest that you simply download kermit
or a file transfer program that is able to handle the z-modem protocol.

kermit for unix is free, but the official kermit program for Windows
is not. You can download a time-limited version of it (kermit95) from
http://www.columbia.edu/kermit/k95.html .
--
Programming is what happens while you're busy making other plans.

[Default User]

jo*********@yah oo.com wrote:

Where is Kenny McCormack - when we need him?

In most people's killfiles. Eager to join him? You're on the right path.

Brian

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)

[Mark McIntyre]

On 10 Mar 2006 21:19:43 -0800, in comp.lang.c , "vicky"
<lj******@163.c om> wrote:

Hello,I met a question when I wrote the program.I want the program can
transmit the data frame continuosly through the RS232 when the
communicatio n has been interrupted.But I don't know how to write. I
don't know how to record.Who can give me hand?Thanks very much!

Unfortunately this is offtopic in CLC, since it is hardware-specific,
and operating system specific. You should ask in a group specialising
in your OS.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Dave Thompson]

On Sat, 11 Mar 2006 17:14:10 +0000 (UTC), ro******@ibd.nr c-cnrc.gc.ca
(Walter Roberson) wrote:

In article <11************ **********@j33g 2000cwa.googleg roups.com>,
vicky <lj******@163.c om> wrote:

I mean that when my program is ended or my computer is closed
suddenly,the program can transmit data from the former when I reset.And
the OS is Windows.The data I want to transmit is byte.
This is, as I indicated, not on-topic in comp.lang.c .

What you want to do cannot be done with RS232 serial communications.

RS232 provides no mechanism for the remote end to signal that
it has received any particular byte, so there is no way for the
serial port to detect whether a particular byte was transmitted
successfully or not.

RS232 as usually implemented today, just async (serial) data, no.

If you can still find (or make) a proper full RS232 implementation,
you could reasonably use CTS for this. RTS/CTS were most often used
for blocks (today, packets), but there is nothing in their definition
that would make them unsuitable for bytes. In fact I seem to recall
some terminals (one possibly rogue neuron is claiming VT100) did use
them for byte-granularity flow control.

For that matter, you could stretch a point and use (simulated) DCE
clocking for this. But good luck finding a serial interface today that
allows direct access to clocks even in hardware much less the OS,
unless of course you build your own from the ground up.

<snip> The only realistic way to handle what you appear to want to do,
is to use an application protocol that is able to negotiate with
the remote end to detect where to resume. If you go to that trouble,
you would usually also want the application protocol to detect
transmission errors and automatically re-send when bad data was
detected or when bytes accidently got lost. Two well-established
protocols that can do these things are kermit and z-modem. The
z-modem protocol is small enough to be practical for an experienced
programmer to re-implement, but you do not appear to be an experienced
programmer, so I would suggest that you simply download kermit
or a file transfer program that is able to handle the z-modem protocol.
This is certainly a better general solution.
kermit for unix is free, but the official kermit program for Windows
is not. You can download a time-limited version of it (kermit95) from
http://www.columbia.edu/kermit/k95.html .

Or PPP, for which there is an opensource implementation. And today
rather wider recognition and support. I love(d) Kermit, but it just
isn't needed nearly as much today, and thus not as much known.

- David.Thompson1 at worldnet.att.ne t