Converting my v6.0 application to ver 7.0 has hugely slowed things down with respect to direct writing/reading hardware.

[Murray]

I have an application that has happily run on win95 box (Pentium MMX 233Mhz) developed on CVI 6.0 for many years. There is a request to move to winNT4.0 for better stability.  Now using CVI 7.0 the application works but when calling the PC104 data acquistion card the speed in hugely slower (ie. 10-20 times slower) IN fact I can only sample at around 5 hertz whereas 100Hz was happening. Under win95 this application (CVI v7.0) is still slow.  Is there an issue with the Low Level Driver cvintcrv.sys that slows things down?

Under win95 I needed to use the "SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);"  for the short actual acquistion time - and then back again to NORMAL mode. This helped ensure that win95 did not dissappear during the acquisition time.  This does not seem to make much of a difference here.

Is there some other compiler MACRO that should be looked at here that might speed this up? I would sincerely like your help here.
     

[Murray]

What I have since found out is that the slowing down speed  is not really the issue here. It is the difference between win95 and WinNT 4.0.  The WinNT with the same code (CVI v6.0) appears slow but it is actually 'bad' reads from the PC 104 hardware. This hardware is called directly with a memory addressing (0x220).  So I need to read the external card many times before I get a valid reading.  Any ideas with the difference between win95 doing these memory/hardware read/writes and winNT 4.0?  I would appreciate your input.

regards,

Murray

[RobertoBozzolo]

Windows/NT is a completely OS from Win9x, the improved security options for this operating system include particular rules for direct acces to memory and hardware, which in general is discouraged and filtered out by the OS. You may be running into problems like these when you are directly accessing memory and hardware ports.

As stated in online help (as an example look at inp and outp functions), you need to load the low-level support driver in order to use these function in Windows NT: it may be helpful to load it for your application too. Keep in mind, also, that some of the function that perform direct access to hardware do not retunr an error code if the low-level support is not loaded: you may need to execute CVILowLevelSupportDriverLoaded function at the beginning of the program to ensure it is already in memory before starting your application. Again, the online help clearly explains this fact.

To install the low-level support driver, you must check a correspinding option while creating the distribution kit for your application. If present, it is automatically loaded together with the cvi Run-time engine.

[Murray]

Thanks for that. I did find those references to the LowLevel drivers and have included that option in the build during my investigations. I also confirmed it was running (on winNT) and you can see "cvintdrv.sys" listed as one of the tasks. 

However, that has not given me any joy!

[msaxon]

In Windows 95/98/Me, applications have direct access to I/O space and the inp() and outp() function calls each reduce to a single machine code instruction within the application program.

In NT4/2000/XP, applications do not have direct access to I/O space. In this case, the inp() and outp() function calls result in operating system (kernel level) calls to the Low Level Support Driver to perform the necessary tasks. The overhead of doing this is quite considerable, what with the context changes and task switching required.

Are you using the exactly the same hardware in the Windows 95 and NT environments? Bad I/O reads on ISA bus (i.e. PC104) hardware can often be cured by reducing the I/O bus clock speed in the BIOS - if such an option exists.

[Murray]

Thank soooo much for your help out there. It is so crippling at my end having no-one to talk to about it. So thanks again.

Yes the hardward is EXACTLY the same. I have been swapping two Hard disks, one with WinNT and the other with Win95.  I havent been doing the development on that hardware however, that has been on my laptop running XP.  I create the distribution kit and pass that across the LAN.  I do have two different hardware pairs, (ie. CPU board and PC104 card) but that too has the same manifestation.

As far as slowing the clock, wouldnt that be fine if the win95 system is reading it okay? 

With the risk of sounding naiver, there is a _NT_ compiler define option. Is that anything related to this?

[msaxon]

> As far as slowing the clock, wouldnt that be fine if the win95 system is reading it okay? 

If there are other things attached to the PC104 bus (maybe on the processor card), it is likely that they are being used in different ways by NT and 95, which could lead to the results you are seeing.

[Murray]

Yes that is a thought. How would you find that out?  A change of the card address wouldnt help that would it?

[msaxon]

It might do, but not in a reliable or satisfactory way. Are you sure you can't slow the I/O bus clock (or add wait states)?