Comments by GPIB1 (Top 6 by date)

What about the InTime link, it says it is a full RTOS for windows and is "hard real-time"

The mechanism they are using to do that is what is interesting, but should be impossible from what I am reading otherwise.

As long as windows is in the loop to interactively generate and send the data to the external device there could still be issues though? In most applications that I am looking at there needs to be a certain amount of coordination between anything external and real time and the software running on Windows.

For example using AutoCAD and its API to handle 3D point clouds and then driving some actuators based on this data (for arguments sake lets say some arbitrary control of a hot wire foam cutter in some bizarre display of art) I don't think that it would be reasonable to engineer an entire real time system that has the capabilities of AutoCAD included in it.

I know you can process the data on the Windows computer and then export/load it into the external real time system to process all at once. There are still cases though like what if the data was coming in "live" over the IoT that everyone is raving about.

This would have to be done carefully though to ensure that enough resources are available to meet your desired timing (more or less since it is not real time by definition) but this is not much different than a micro that is using a super loop without any RTOS.

It sounds like using a device driver is a way to get closer to the desired operation since it can have much greater control over the lower level timing.

This has to be similar to how games are constructed? I don't ever remember playing a game and hitting a direction key and having a random varying half a second delay before hitting the key and seeing a response. That is unless I set the frame rate/resolution way to high for the capacity of the system (which is the same scenario that I looking at except instead of a loop running as fast as possible it would be one that can be triggered every .5ms like the GMFC stuff....)

Agree about the controversy, but not sure what better phrase describes "real time as in decode video, synthesize audio, or control as in GMFC stepper motors without any skipping, jitter, etc"

There may not be real-time in Windows by definition but there is a way to write software as observed, it ran for hours without missing a beat or being able to notice any adverse/jittery operation. IIRC it did load the CPU/Windows to the point where the UI was not responsive, but it did still allow you to escape out with a key press.

I think this is the closest way that I can achieve what I want. After reviewing the software/hardware that I used years ago (GMFC) it turns out that there is a 2kHz signal that is generated on external hardware and this is used to send interrupts through the parallel port. So I think based on what I know now that it was actually using a hardware driver mechanism.