2

My understanding is that Windows is non-deterministic and can be trouble when using it for data acquisition. Using a 32bit bus, and dual core, is it possible to use inline asm to work with interrupts in Visual Studio 2005 or at least set some kind of flags to be consistent in time with little jitter?

Going the direction of an RTOS(real time operating system): Windows CE with programming in kernel mode may get too expensive for us.

jdl
  • 6,151
  • 19
  • 83
  • 132
  • 3
    You want to target Windows 7 with VS *2005*? – Kerrek SB Sep 25 '11 at 23:57
  • More deterministic than *what*? Listing specific constraints your real-time system must meet may help a lot with potential solutions. In any case, modern personal computers have has many hardware optimizations that make it difficult to guarantee some constraints. This is never a software-only issue. – André Caron Sep 26 '11 at 00:11
  • VS 2005 is the last one that allows you to do inline ASM... and for 32 bit. 64 bit doesn't allow it. – jdl Sep 26 '11 at 00:56
  • 2
    VS2010 lets you do inline ASM on 32-bit as well. http://msdn.microsoft.com/en-us/library/4ks26t93.aspx – Mahmoud Al-Qudsi Sep 26 '11 at 01:04
  • @Andre: Perhaps he meant just "deterministic" rather than "more deterministic" since Windows is not at all deterministic in any useful sense. – Clifford Sep 26 '11 at 13:14

3 Answers3

2

There are third-party realtime extensions to Windows. See, e. g. http://msdn.microsoft.com/en-us/library/ms838340(v=winembedded.5).aspx

Seva Alekseyev
  • 59,826
  • 25
  • 160
  • 281
2

Real time solutions for Windows such as LabVIEW Real-time or RTX are expensive; a stand-alone RTOS would often be less expensive (or even free), but if you need Windows functionality as well, you are perhaps no further forward.

If cost is critical, you might run a free or low-cost RTOS in a virtual machine. This can work, though there is no cooperation over hardware access between the RTOS and Windows, and no direct communication mechanism (you could use TCP/IP over a virtual (or real) network I suppose.

Another alternative is to perform the real-time data acquisition on stand-alone hardware (a microcontroller development board or SBC for example) and communicate with Windows via USB or TCP/IP for example. It is possible that way to get timing jitter down to the microsecond level or better.

Clifford
  • 88,407
  • 13
  • 85
  • 165
1

Windows is not an RTOS, so there is no magic answer. However, there are some things you can do to make the system more "real time friendly".

  1. Disable background processes that can steal system resources from you.
  2. Use a multi-core processor to reduce the impact of context switching
  3. If your program does any disk I/O, move that to its own spindle.
  4. Look into process priority. Make sure your process is running as High or Realtime.
  5. Pay attention to how your program manages memory. Avoid doing thigs that will lead to excessive disk paging.
  6. Consider a real-time extension to Windows (already mentioned).
  7. Consider moving to a real RTOS.
  8. Consider dividing your system into two pieces: (1) real time component running on a microcontroller/DSP/FPGA, and (2) The user interface portion that runs on the Windows PC.
myron-semack
  • 6,259
  • 1
  • 26
  • 38