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
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.
“Adam Mallory” <firstname.lastname@example.org> wrote in message
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.
QNX Software Systems Ltd.
[ > email@example.com > ]
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> firstname.lastname@example.org
“john eddy” <> email@example.com> > wrote in
news:ac6siq$smp$> firstname.lastname@example.org> :
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.