Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Parallel Port Interrupt

Subject: Parallel Port Interrupt

From: Boris

Date: 15 Aug, 2012 00:57:08

Message: 1 of 4

Is it possible to use the Parallel Port as the execution interrupt source (which I understand uses the ACK pin) on the xPC Target while simultaneously using the data pins of the parallel port (strobe, busy, d0-d7) to output data to another device?

Thank you!

Subject: Parallel Port Interrupt

From: Gordon Weast

Date: 15 Aug, 2012 12:48:40

Message: 2 of 4

Boris,

That should work perfectly. The data port is independent of the
interrupt function.

Gordon Weast
xPC Target Development
MathWorks

Boris wrote:
> Is it possible to use the Parallel Port as the execution interrupt
> source (which I understand uses the ACK pin) on the xPC Target while
> simultaneously using the data pins of the parallel port (strobe, busy,
> d0-d7) to output data to another device?
>
> Thank you!

Subject: Parallel Port Interrupt

From: Boris

Date: 17 Aug, 2012 18:45:15

Message: 3 of 4

Gordon,

I tried it, but I've gotten some very strange behavior.

I'm sending data to a device over the data & strobe pins. When I am not using the Parallel Port interrupt to drive the XPC, the device correctly reads the data pins on the falling edge of the Strobe pin, even though the pulse is 100 ms wide (the xPC is running at 0.001s sample time.)

The strange thing is, when I ONLY switch the xpc to run on the interrupt from the ACK pin, the device reading the parallel port starts reading on the HELD value of the strobe pin. So, it reads over and over again while the Strobe pin is logic low (for 100ms.) The reading device sets the BUSY pin, and its behavior reflects the above: one read when not using the interrupt, but over 100 when using it. How could simply changing the interrupt effect the behavior of the downstream device? The driving signal is coming from a board not directly connected with the device that's reading the parallel port, so there shouldn't be any association there.

Weirdly, the strobe pin coming out of the xPC is actually doing the same exact thing in both conditions. Furthermore, this odd behavior sticks unless I restart the xPC. Just turning off the parallel port interrupt function won't put it back. Perhaps that is a sign that this is some problem with the xPC driver for the parallel port?

Thanks for your help!


Gordon Weast <gweast@mathworks.com> wrote in message <k0g5r8$llm$1@newscl01ah.mathworks.com>...
> Boris,
>
> That should work perfectly. The data port is independent of the
> interrupt function.
>
> Gordon Weast
> xPC Target Development
> MathWorks
>
> Boris wrote:
> > Is it possible to use the Parallel Port as the execution interrupt
> > source (which I understand uses the ACK pin) on the xPC Target while
> > simultaneously using the data pins of the parallel port (strobe, busy,
> > d0-d7) to output data to another device?
> >
> > Thank you!

Subject: Parallel Port Interrupt

From: Boris

Date: 17 Aug, 2012 21:21:13

Message: 4 of 4

Also:

Is there no way to configure the xPC to allow hardware to automatically manipulate the control pins? It seems like even a sample time of 0.001 is not fast enough to make for effective use of the parallel port.

Thanks,
Boris

"Boris" wrote in message <k0m3fr$a52$1@newscl01ah.mathworks.com>...
> Gordon,
>
> I tried it, but I've gotten some very strange behavior.
>
> I'm sending data to a device over the data & strobe pins. When I am not using the Parallel Port interrupt to drive the XPC, the device correctly reads the data pins on the falling edge of the Strobe pin, even though the pulse is 100 ms wide (the xPC is running at 0.001s sample time.)
>
> The strange thing is, when I ONLY switch the xpc to run on the interrupt from the ACK pin, the device reading the parallel port starts reading on the HELD value of the strobe pin. So, it reads over and over again while the Strobe pin is logic low (for 100ms.) The reading device sets the BUSY pin, and its behavior reflects the above: one read when not using the interrupt, but over 100 when using it. How could simply changing the interrupt effect the behavior of the downstream device? The driving signal is coming from a board not directly connected with the device that's reading the parallel port, so there shouldn't be any association there.
>
> Weirdly, the strobe pin coming out of the xPC is actually doing the same exact thing in both conditions. Furthermore, this odd behavior sticks unless I restart the xPC. Just turning off the parallel port interrupt function won't put it back. Perhaps that is a sign that this is some problem with the xPC driver for the parallel port?
>
> Thanks for your help!
>
>
> Gordon Weast <gweast@mathworks.com> wrote in message <k0g5r8$llm$1@newscl01ah.mathworks.com>...
> > Boris,
> >
> > That should work perfectly. The data port is independent of the
> > interrupt function.
> >
> > Gordon Weast
> > xPC Target Development
> > MathWorks
> >
> > Boris wrote:
> > > Is it possible to use the Parallel Port as the execution interrupt
> > > source (which I understand uses the ACK pin) on the xPC Target while
> > > simultaneously using the data pins of the parallel port (strobe, busy,
> > > d0-d7) to output data to another device?
> > >
> > > Thank you!

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us