On 22/08/10 11:14 PM, venkata wrote:
> Can I generate a signal using MATLAB which is in the order of
> microseconds( Stays low for 1microsecond and becomes high the next
> microsecond) and output the same via serial or parallel port?
*Maybe*. I personally wouldn't count on it, though.
You _might_ be able to do an acceptable job of timing a signal if you
manage to find an appropriate available hardware-level timer on some
device, but it would be difficult to do in software unless perhaps you
are using the RTW.
Asynch serial ports are not designed to run at 1 megabit per second.
Apparently with 2009a and later, you can run at about 0.92 megabit/s,
but it would be impossible to control the timing of the bits precisely
within that framework.
Parallel ports... I'm having to do a bunch of careful reading here.
Look right near the bottom, where it talks about ISA cards supporting 2
megabytes per second maximum, and PCI cards supporting 5.5 to 6
megabytes per second maximum. That 5.6 to 6 megabytes per second
_sounds_ like plenty for your application, but it needs EPP mode to do
it as ECP mode is (the article says) not supported on PCI cards which
(the article says) do not support DMA. EPP works with hardware support
by monkeying with the bus wait states -- and that should raise red flags
about loss of precision in the timing and about clock jitter.
Perhaps I just haven't been paying attention (a good possibility in this
matter), but it seems to me that parallel ports these days tend to be
ECP rather than EPP. Perhaps support for both modes is common; I don't
do much PC hardware work.
This article gives more detail on how ISA cards are able to do 2
megabytes per second. The method is _comparatively_ simple and I would
_expect_ it to suffer less timing and jitter, but I'm not at all
certain. And there is the fact that not many systems these days are
built with ISA slots other than perhaps a compatibility mode.
Now, in general, the process of sending a signal through a parallel port
involves asserting a signal on to the lines, and when the lines have had
time to settle, asserting a strobe pulse on a separate line. The
destination then takes a snapshot of the state of the line, usually
triggered by the strobe line (leading vs trailing edge is defined in the
standards but not always adhered to), with there being a window during
which the source is expected to hold the lines steady (keeping in mind
signal propagation time). After that the parallel lines are supposed to
return to ground state -- parallel doesn't inherently mean "synchronous"
(other than for the 8 data lines): except in the advanced modes the
general assumption is that it will be a random amount of time before
there is more data to be transmitted, so except perhaps in some of the
advanced modes, two output bits in a row that happened to be the same
would cause two separate drive-up and release-down on the pin, rather
than just leaving the line in its last state until it is known to need
The implication of this for your purpose is that you are going to have
trouble getting your bit timing to be precise: you may get a million bit
samples per second, but those are transferred as short-term samples of
the state of the lines rather than through precise timing of the line
states themselves. From the beginning of the cycle until the strobe, the
data line is allowed to slew (and it probably will, as there is no
inherent active de-bouncing in the technology and the lines will be
moving from ground each time.) And then again after the strobe period
slew is allowed.
Really, if you wanted to do more precise bit-hold timing with parallel
ports, you should be working with the control bits rather than the data
bits -- some of the control bits are defined as being holdable for
extended times. The problem with that approach, though, is that you
would have to do it through low level software control, perhaps in SPP
mode (10 I/O cycles per byte), and you would never be able to get the
data rates that you want if you used those modes. The higher the data
rate you want, the more the work of the control pins is delegated to
special-purpose state-engine hardware...
So what is the summary here?
A) That if you need precise timing, you are better off using a digital
control of a device that generates the signal, whether that device be
custom or a signal generator; and
B) If data rates is the aim rather than signal timing, by the time you
want data rates of 1 megabits per second, you should probably give up on
asynch serial or parallel ports, and should instead move to synch
systems such as T1 or E0 lines, or to ethernet. A bit timing of 1
megahertz on a four-wire connection is no problem; the E0 maximum rate
is 1.544 megabits per second (T1 data rate is exactly 7/8 of that.)