Slow I/O and giving up time??

QNX Newsgroups (Archives) qdn.public.ddk.network
1

Hello,

I have an application that needs to drive a high speed serial link using
devices that have very long access times.

One character’s transmit time is about 6.5uS, and one read or write access
to this chip takes over a microsecond. It takes several accesses to handle
the chip in a strictly polled mode, and even more accesses to handle it in
interrupt driven mode.

The only way I can meet the deadlines transmitting is to poll it, but that
takes 100% of the processor time, since running at lower prioritiy causes
delays that cause me to miss sending data in time (SCLC is very unforgiving
of underruns).

Is there any way to get back the time I spend in wait states while accessing
IO across a pci bus? No DMA is NOT an option with this device, I already
thought of that.

I am trying to locate a faster device for this app, but … this is
something that has to have been encountered before. Someone should find a
hardware/software solution to this.

I would envision … MMU detects SLOW accesses, and begins the access
requested, while sending an interrupt to wake up the operating system to let
other code run. When the IO completes, another interrupt is used to take
over control and pass it back to the I/O blocked task. Not sure if this type
of interface exists, or is implemented already, but it sounds good in
theory.

Comments??

2

“john eddy” <johnheddy@adelphia.net> wrote in message
news:ac6siq$smp$1@inn.qnx.com…

I would envision … MMU detects SLOW accesses, and begins the access
requested, while sending an interrupt to wake up the operating system to
let
other code run. When the IO completes, another interrupt is used to take
over control and pass it back to the I/O blocked task. Not sure if this
type
of interface exists, or is implemented already, but it sounds good in
theory.

SMP?

3

Bill,

Summetric Multi-Processing would be nice, but I only have one cpu on this
computer. I don’t think Qnx counts the PCI bus controller as a processor
capable of SMP. The point here is that on any standard PC or single cpu
embedded system in general, you can run into slow IO operations that have to
be updated (on occasion) at near 100% of processing time. Recovering that
wasted time you spend in wait states would make life easier for those of us
who can’t buy the expensive toys

But you are right, that would work…


John.
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:acbaer$4if$1@inn.qnx.com…

“john eddy” <> johnheddy@adelphia.net> > wrote in message
news:ac6siq$smp$> 1@inn.qnx.com> …

I would envision … MMU detects SLOW accesses, and begins the access
requested, while sending an interrupt to wake up the operating system to
let
other code run. When the IO completes, another interrupt is used to take
over control and pass it back to the I/O blocked task. Not sure if this
type
of interface exists, or is implemented already, but it sounds good in
theory.

SMP?

4

What about a combination of an interrupt handler for the timer interupt
which does the “poll/grab” for info. You could then set the ClockPeriod()
to adjust the amount of polling.

Just an idea.

–
Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>



“john eddy” <johnheddy@adelphia.net> wrote in
news:ac6siq$smp$1@inn.qnx.com:

Hello,

I have an application that needs to drive a high speed serial link
using devices that have very long access times.

One character’s transmit time is about 6.5uS, and one read or write
access to this chip takes over a microsecond. It takes several accesses
to handle the chip in a strictly polled mode, and even more accesses to
handle it in interrupt driven mode.

The only way I can meet the deadlines transmitting is to poll it, but
that takes 100% of the processor time, since running at lower prioritiy
causes delays that cause me to miss sending data in time (SCLC is very
unforgiving of underruns).

Is there any way to get back the time I spend in wait states while
accessing IO across a pci bus? No DMA is NOT an option with this
device, I already thought of that.

I am trying to locate a faster device for this app, but … this is
something that has to have been encountered before. Someone should find
a hardware/software solution to this.

I would envision … MMU detects SLOW accesses, and begins the access
requested, while sending an interrupt to wake up the operating system
to let other code run. When the IO completes, another interrupt is used
to take over control and pass it back to the I/O blocked task. Not sure
if this type of interface exists, or is implemented already, but it
sounds good in theory.

Comments??
\

5

Adam,

I have already thought of that.
The data I am trying to read in is coming at 1 byte every 6.5uS and the
minimum I can set the system clock to is 500uS according the the
documentation. If it were say 500 nS, then I could just give up time with
normal operating system calls in the polling loop, but I can’t wait 500uS or
I loose data.

I have been looking at polling until all the fifos are full/empty, and then
sleeping until I get a signal from an interrupt handler to wake me up. I
still can’t give up any time while polling (even though most of that time is
spent waiting for slow IO), but at least I can give up the gaps between
messages.

The other thing I was thinking of was setting up single address dma accesses
using the pci controller on the carrier card, and having it wake me up by
interrupt when the IO is done. I just am not sure how the manufacturer wired
the controller to the IO. They say DMA is not possible with this board, but
the controller AMCC 5933 clearly supports it.

Thanks,

John Eddy
“Adam Mallory” <amallory@qnx.com> wrote in message
news:Xns92177D8D3D860amalloryqnxcom@209.226.137.4…

What about a combination of an interrupt handler for the timer interupt
which does the “poll/grab” for info. You could then set the ClockPeriod()
to adjust the amount of polling.

Just an idea.

–
Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net



“john eddy” <> johnheddy@adelphia.net> > wrote in
news:ac6siq$smp$> 1@inn.qnx.com> :

Hello,

I have an application that needs to drive a high speed serial link
using devices that have very long access times.

One character’s transmit time is about 6.5uS, and one read or write
access to this chip takes over a microsecond. It takes several accesses
to handle the chip in a strictly polled mode, and even more accesses to
handle it in interrupt driven mode.

The only way I can meet the deadlines transmitting is to poll it, but
that takes 100% of the processor time, since running at lower prioritiy
causes delays that cause me to miss sending data in time (SCLC is very
unforgiving of underruns).

Is there any way to get back the time I spend in wait states while
accessing IO across a pci bus? No DMA is NOT an option with this
device, I already thought of that.

I am trying to locate a faster device for this app, but … this is
something that has to have been encountered before. Someone should find
a hardware/software solution to this.

I would envision … MMU detects SLOW accesses, and begins the access
requested, while sending an interrupt to wake up the operating system
to let other code run. When the IO completes, another interrupt is used
to take over control and pass it back to the I/O blocked task. Not sure
if this type of interface exists, or is implemented already, but it
sounds good in theory.

Comments??



\