Precise signal generation using matlab

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?
8/23/2010 4:14:05 AM
comp.soft-sys.matlab 211266 articles. 19 followers. lunamoonmoon (257) is leader. Post Follow

2 Replies

Similar Articles

[PageSpeed] 44

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 
to change.

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.)
8/23/2010 5:33:12 AM
@walter robertson

Thank you for the reply.
9/8/2010 5:04:04 AM