The Simplest Network - Making Things Talk - page 62

Figure 2-14
The completed Monski Pong Pro-
cessing sketch.

Flow Control
You may notice that the paddles don't always move as smoothly onscreen as Monski's
arms move. Sometimes the paddles don't seem to move for a fraction of a second,
and sometimes they seem to lag behind the actions you're taking. This is because
the communication between the two devices is asynchronous .

Although the devices agree on the rate at which data is
exchanged, it doesn't mean that the receiving computer's
program has to use the bits as they're sent. Monitoring the
incoming bits is actually handled by a dedicated hardware
circuit, and the incoming bits are stored in a memory
buffer, called the serial buffer , until the current program
is ready to use them. Most personal computers allocate a
buffer for each serial port that can hold a couple thousand
bytes. The program using the bits (Processing, in the
previous example) is juggling a number of other tasks, like
redrawing the screen, handling the math that goes with it,

and sharing processor time with other programs through
the operating system. It may get bytes from the buffer less
than a hundred times a second—even though the bytes
are coming in much faster.

There's another way to handle the communication
between the two devices that can alleviate this problem.
If Processing asks for data only when it needs it, and if
the microcontroller only sends one packet of data when
it gets a request for data, the two will be in tighter sync.

To make this happen, first add the
following lines to the startup() of
the Arduino sketch. This makes the
Arduino send out a serial message until
it gets a response from Processin.:

8

while (Serial.available() <= 0) {
Serial.println("hello"); // send a starting message
}