This way?

[Florin Boariu]

hello everybody!

i'm having a lot of trouble getting a piece of hardware to work 
properly. the hardware is a prototype of a CCD camera with a very 
unforgiving behaviour. it has a work cycle like:

 |---send-pixel-data-to-pc----|--send/recv-stat/setup-data--|
 |---send-pixel-data-to-pc----|--send/recv-stat/setup-data--|
 |...

pixel data is actually sent to a PLX-based PCI card specially
designed for that cam. it can be up to 150M/min, which is quite a lot 
for the PCI-bus to swallow, i guess... but that's not really a problem, 
since data is written in a FIFO and can be read by the computer at a 
later time (there is a fifo-half-full interrupt).

stat/setup data is very small (1 packet of 7 bytes sent/received) and 
runs over several registers of the PLX card.

the main problem with the cam is that its time constraints must be met 
very sharply. that is, the cam won't wait for the PC to do the 
handshaking (communication protocol is designed that way). it will 
simply just assume that the PC is there to answer. and, to make things 
worse, all the bits look the same (from the protocol's point of view). 
if you're the PC, there's no way of telling whether the cam expects you 
to send the 2nd or the 50th bit... you simply send and hope it works 
out.

most of the time it does, since the cam is very strict about its working 
cycle. in order to meet the right sending time, i use the 
fifo-halffull-interrupt: as soon as a fifo-hf-irq arrives, i read just 
as much data as i need to in order to have the next pixel-send of the 
cam refill the fifo up to half-full (or slightly more than that to gain 
some time). this way i know that, as soon as the next fifo-hf-irq 
arrives i have (or soon will have) the cam ready to do the communication 
handshaking.

i hope it's understandable that this kind of an ISR must run with 
highest priority possible -- that's why i'm using RTAI.

my problem is that sometimes, under more or less "heavy system load" the 
PC is too slow.

"heavy load" means, for example, hard disk usage. it needn't even by 
heavy HDD usage, it simply suffices to be badly timed. "find / *" while 
the cam is running will definitely get things messed up (i know. "find" 
is heavy usage :-)

things lighten up a bit if i use a system with a NFS root filesystem, 
but still not reliable. if i start messing with processes (for example 
endless loops of start/stop processes, like ls or ps) will cause the cam 
to run out of sync sooner or later... now i'm a bit confused, because i 
expected the RTAI-ISR to preempt any other code running on the same 
machine.

i would greatly appreciate if someone could have a look over my code and
tell me whether i misunderstood RTAI-code -- i might have forgotten some
flag or something... anybody kind enough to help me out? :-)

i attached a short version with relevan RTAI-parts in it (mmc-short.c)
to this email. i can also send you the complete driver code (about 2000 
lines), you only need to ask. (i don't know about list policies -- would 
it have been unpolite if i had send the complete code right away with 
this email?)

regards,
florin.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mmc-short.c
Url: http://mail.rtai.org/pipermail/rtai/attachments/20041016/51af68d5/attachment.txt