Under WinNT I lose a lot time between successive reads to hardware

[Murray]

I am running NT4.0 CVI 7.0/6.0.

I have a PC104/ISA bus card that requires some handshaking when asking for data. (It gives me 24bit analogue data)

ie.

1. send a Read command to card

2. read Status Register and check if data ready to read ie. wait for DataReady flag

3. read first data byte

4. keep reading Status Register until DataReady flag set

5. read second data byte

6. keep reading Status Register until  DataReady flag set

7. read third data byte.

I use the inp() outp() functions and have loaded the cvintdrv.sys and confirmed that it is running.

In the sequence above if I wait too long before reading a data byte (ie. longer than ~5mSec) the PC104 card returns a timeout error and the sequence must start again. 

Basically I get many errors inbetween valid data.  I am not sure if the inp()/outp() are really working or that it is a timing error.  There are some single byte reads that I can do and they seem to be valid - therefore I am inclined to say the inp()/outp() are okay and it is a timing error.

I used the window set priority before and after my card calls as indicated, but that does not seem to help me.

//========================================================

  SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
   
    error = SD811_GetData (&data);
 
     SetPriorityClass(GetCurrentProcess(), NORMAL_PRIORITY_CLASS);

//========================================================
    
 

[Murray]

Whoops!  I have done the wrong thing and posted this prior to finishing - sorry.

I think the question that remains, can i get that read/write data sequence steps to the card be 'locked out' for a while from NT doing other things?  Is the cvintdrv.sys that does the inp()/outp() still being given enought priority?   How does the cvintdrv.sys actually work here?

[menchar]

Murray -

If you think that NT is "off doing other things" you can boost the priority of the thread doing the i/o.

WinNT has a "realtime" priority class, it's a bit drastic, pretty much nothing else will run if you set your thread to realtime priority.  No mouse movement, no key clicks, etc. etc.  You'd likely have to be clever about it, only boosting to realtime priority on a temporary basis.  A separate realtime thread to do the low level i/o might help simplify the design.

You can use the Win32 SDK to boost your thread's priority.

Menchar

[Murray]

THanks for the idea about set the priority to RealTime, I thought I was doing that  as indicated in the first message of this thread. As I am not really comfortable with this priority idea, I am happy to be guided in other ways. Do you think what I did there is what you were thinking?

[menchar]

Murray -

Sorry, didn't read your first message carefully.  Yes, you're getting your process into the realtime priority class, but you need to further set thread priority to

THREAD_PRIORITY_TIME_CRITICAL

or THREAD_PRIORITY_HIGHEST

to get the thread's base priority up to where you're certain you're going to be running at the highest priority.

NT may not support THREAD_PRIORITY_TIME_CRITICAL , that may have been added for Win2K or WinXP, not certain.

A priority class is a set of priorites as it turns out - you have to add the priority class to the thread priority to come up with the true thread priority (highest value is 31).

The Win32 SDK included with CVI FSD describes this - also see Beveridge & Weiner "Multithreading Applications in Win32".

Menchar

[mvr]

Other information including some of the source code is here in this thread http://forums.ni.com/ni/board/message?board.id=180&message.id=23842.  To answer a question from that thread,
>>So does win95 have less overheads and do the loops faster?
Yes.  The short version is that 95 is not a pre-emptive system, your program had virtually complete access and control over the hardware when it is executing.  NT on the other hand allows your application to run for a bit (a time slice) then pulls control back to take care of other tasks.

Do you know which timeout value you are getting?  There are two places that return SD811_IBF_TIMEOUT, which would require changing one of them to get more information if that is the returned error.

I do think your on the right track as far as looking at this as a timing problem.  Making the changes suggested by menchar is probably a good place to start. 

[Murray]

After researching further the priority classes and threads, I implemented this code, but with no observable difference. So now I am really at a loss.

   hprocess = GetCurrentProcess();
   oldPC = GetPriorityClass(hprocess);
   
   SetPriorityClass(hprocess, REALTIME_PRIORITY_CLASS);
  
   hThread = GetCurrentThread();
   oldTP = GetThreadPriority(hThread);
   SetThreadPriority(hThread, THREAD_PRIORITY_TIME_CRITICAL);
  
       error = SD811_GetData (&data);
   
   SetThreadPriority(GetCurrentThread(), oldTP);
   SetPriorityClass(GetCurrentProcess(), oldPC);
 

[msaxon]

Are the calls to SetPriorityClass() and SetThreadPriority() succeeding?

If they are, I suspect that Windows may be de-scheduling your process occasionally when the low level driver is called, which in your case is a bit of a pity. It's not easy to find out what goes on in Windows when device drivers are called from applications.