User`s guide

Comparing Pipes and Streams
Input/Output Overview and Pipes 6-5
6.2 Comparing Pipes and Streams
DSP/BIOS supports two different models for data transfer. The pipe model is
used by the PIP and HST modules. The stream model is used by the SIO and
DEV modules.
Both models require that a pipe or stream have a single reader thread and a
single writer thread. Both models transfer buffers within the pipe or stream by
copying pointers rather than by copying data between buffers.
In general, the pipe model supports low-level communication, while the
stream model supports high-level, device-independent I/O. Table 6-1
compares the two models in more detail.
Table 6-1 Comparison of Pipes and Streams
Pipes
(PIP and HST)
Streams
(SIO and DEV)
Programmer must create own
driver structure.
Provides a more structured approach to
device-driver creation.
Reader and writer can be any
thread type or host PC.
One end must be handled by a task (TSK)
using SIO calls. The other end must be
handled by an HWI using Dxx calls.
PIP functions are non-blocking.
Program must check to make sure
a buffer is available before reading
from or writing to the pipe.
SIO_put, SIO_get, and SIO_reclaim are
blocking functions and causes a task to
wait until a buffer is available. (SIO_issue
is non-blocking.)
Uses less memory and is generally
faster.
More flexible; generally simpler to use.
Each pipe owns its own buffers. Buffers can be transferred from one stream
to another without copying. (In practice,
copying is usually necessary anyway
because the data is processed.)
Pipes must be created statically
with the Configuration Tool.
Streams can be created either at run time
or statically with the Configuration Tool.
Streams can be opened by name.
No built-in support for stacking
devices.
Support is provided for stacking devices.
Using the HST module with pipes is
an easy way to handle data transfer
between the host and target.
A number of device drivers are provided
with DSP/BIOS.