Baud Rate In Serial Comm, Buffer overrun

[Guest]

hi,
currently we are using hp & asus pocket pcs. During serial communication,
will it support 38.4 kbps baudrate?

we are using null modem cable for transfering data (no hardware flow
control). We are having software flow control in our protocol. Will it
cause buffer overrun?

kindly reply,

thanks & regards,
hari

 

[Guest]

currently we are using hp & asus pocket pcs. During serial communication,

will it support 38.4 kbps baudrate?
Yes.

we are using null modem cable for transfering data (no hardware flow
control). We are having software flow control in our protocol. Will it
cause buffer overrun?

No. That's the whole point of flow control - to prevent overruns.

-Chris

 

[Guest]

hi,
my application is in such a way that the desktop pc(host) transfers data to
the pocket pc using a null modem rs 232 cable. while transfering data, no
other operations (no other threads) are running and only this data transfer
will take place. but the processor speed of the host pc is 1 GHz and that of
the pocket pc is only 400 MHz. Will this difference in speed cause Buffer
Overrun?

please reply,
thanks and regards,
hari

 

[Chris Tacke, eMVP]

Processor speed has nothing to do with anything here. You're sending data
at a fixed, slow rate of 38.4kbps. Flow control monitors the rx buffer and
tells the sender to stop sending when a high water mark is passed, and to
resume sending when it falls back below it. You should do some googling for
the fundamentals of serial communication. It's simple, but more complex
than I feel like typing into a newsgroup post.

 

[Paul G. Tobey [eMVP]]

It's entirely impossible to answer this question. How many processes are
running on the Pocket PC? Which *version* of Pocket PC is it? How much
interrupt activity is taking place on the Pocket PC (RF Ethernet, for
example, on an active network, generates an interrupt for every packet,
which is very frequently, taking processors cycles that might otherwise be
used for serial I/O). Is the port configured for XON/XOFF handshaking or
are you trying to handshake from the application software? If the latter, I
feel pretty confident that yes, you will have overruns (that's a poor
choice).

The speed that matters is the baud rate, not the processor speed. The PC
can't send data any faster than the baud rate, even if it's running at
5000GHz, right? The processor speed being higher simply means that there is
a lower probability of being caught doing something else when a serial
interrupt occurs and not being able to finish that other process, whatever
it is, before a character is lost. So, if there is going to be an overrun,
the probability of it happening on the PC side is relatively low and on the
PPC side relatively high, but there's no way to tell you that it will or
won't happen; that's why you test.

Paul T.

 

[Dick Grier]

Hi,

Both Chris and Paul have jumped in, so let me do so (too).

Even with no other threads running (actually, there are several that you
have no control over), there is a substantial chance for a date overflow at
38400 bps. You should implement hardware flow control to avoid this issue.
Then, as your program's complexity grows -- and it almost certainly will --
you won't have this come up as a problem.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.