RealTime Serial Communication in Windows

NTDEV
1

Hi All,
I am developing a software which is essentially a mechanical system tester, I have to use 3 serial ports (Asynch, Just Rx/Tx) to send/receive bytes at 115200 baud-rate and 1 KHz on each of them simultaneously in parallel,
Since the exact timing is critical to my needs, I tried a lot to reach the 1 ms event in user mode, finally I used NtQueryTimerResolution and NtSetTimerResolution and Waitable timers in a separate thread to create a 1 ms timer to send my bytes, but after some tests I found that sometimes the resolution of the timer changes to about 15~20 ms and then come back to 1 ms again, and this is not possible for me,
I am firmware/software and digital electronic designer/developer and completely familiar and experienced in micro-controllers and…, but this situation is defined for this project and I have to use windows which is not real time of course,
Question is that what would be the best solution for this problem, first get a exact 1ms interrupt timer on windows which does not change and be consistent, second how to use to send the serial bytes, use createfile and standard serial port driver or directly use uart controller, somehow write a simple and very customized driver?
All of these should be done in user mode or driver mode? Does writing a driver really helps? because I know that working threads and dpc timers also have latency,
I searched a lot about this, even thinking about hooking the rtc timer, writing driver, searched on your website, somewhere noted about writing a driver at clock level?

However I have never wrote a driver code, but I am not afraid, I did a lot on system programming, microcontrollers, rtos, and …,

I am essentially here looking for a solution and suggestion and really appreciate your kind helps…

Looking forward for your kind answers…

Ramin

2

> Since the exact timing is critical to my needs

Are you sure that RS-232 supports this at all? it is only obliged to support timings between the bits in the same byte (which is the “baud rate”), but not between bytes.

There is some doubt the OS-provided serial.sys supports realtime communications.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

3

Let me explain and clarify that, simply, every 1 ms, I need to send a (5 bytes packet) to each of the three ports at 115200 baud-rate, so I do not need timing between the bytes, but between the packets.

Each Packet which contains 5 bytes, should be sent continuously, which would be sent because of the mechanism of hardware fifo of the uart controllers.

4

> first get a exact 1ms interrupt timer on windows which does not change and

be consistent

The dynamic clock tick feature was introduced in Windows 8.1. Although there
is a boot flag “disabledynamictick”, I have never actually seen that work.
To get your solution to work, perhaps you should be running Windows 7, then
set the lowest timer resolution of 0.5 ms. And you would have to make sure
that your system is suitable for real-time, which means tweaked with
hardware and drivers that do not cause any significant latencies.

Having a precise timer on Windows requires an extra device that interrupts
periodically, which would also need a driver. There is plenty of hardware on
every system that could be used for this purpose but unfortunately this is
all owned by Windows and not to be programmed by us.

As an alternative for a precise timer, you could reserve a dedicated
processor in your system for this task which does nothing but spin in a loop
to check if a deadline is due. That would require configuring the system to
make sure no other threads, interrupts and DPCs are occuring on this
processor which is possible to achieve with boot parameters. Of course this
unorthodox method wastes a lot of heat but if that’s what it takes to get
your task done, perhaps it can be acceptable for a dedicated system.

//Daniel

5

xxxxx@gmail.com wrote:

I am developing a software which is essentially a mechanical system tester, I have to use 3 serial ports (Asynch, Just Rx/Tx) to send/receive bytes at 115200 baud-rate and 1 KHz on each of them simultaneously in parallel,
Since the exact timing is critical to my needs, I tried a lot to reach the 1 ms event in user mode,

If mechanical damage or injury could result from missed timing, then it
is criminally negligent to use Windows for this task. It’s never going
to work with complete reliability.

There are a billion better ways to do this. There are inexpensive USB
experimenter boards with very capable small processors that have
real-time guarantees. You could offload the real-time tasks to the
peripheral processor, while keeping the interesting parts in Windows.
That would be a much better solution.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

The best solution here is to write a custom HAL that,apart from other things, acts as a RTOS that runs Windows as one of its tasks. As long as your requirements are really hard-realtime ones this is the only way to go. Any other solution is going to be unreliable, because in order to meet your objectives you need a total control of how interrupts get delivered to the CPU. Certainly, it involves quite a bit of work, but it has been done more than once. IIRC, HAL Developer Kit was available from MSFT some time ago, but I am not sure if this option is still available…

Anton Bassov

7

I think you’re using the wrong tool for the job. You don’t want Windows scheduling your time critical messages. What you want Windows for is to provide the data to be sent within these messages. To accomplish this you should leverage your self-proclaimed familiarity/experience with micro-controllers or other hardware. The hardware can then take advantage of a high frequency clock with a reliable clock generator. You then write a driver for that piece of hardware that keeps it’s queue fed with the expected data.

This is ONE possibility. However, I want to reiterate that using Windows to generate deterministic events at a 1ms interval is not an “easy” implementation; as in… I wouldn’t give it much more thought.

8

Hi,
I tried a lot to find a method for reserving a dedicated core on windows 7
on bootup, but was not successful,
I can use API calls to set the all the possible processes affinities at
run-time, but not DPC’s or interrupts and …, So
Could you please help me more about this?

Best Regards

On Fri, Apr 1, 2016 at 4:58 PM, wrote:

> first get a exact 1ms interrupt timer on windows which does not change and
>> be consistent
>>
>
> The dynamic clock tick feature was introduced in Windows 8.1. Although
> there is a boot flag “disabledynamictick”, I have never actually seen that
> work. To get your solution to work, perhaps you should be running Windows
> 7, then set the lowest timer resolution of 0.5 ms. And you would have to
> make sure that your system is suitable for real-time, which means tweaked
> with hardware and drivers that do not cause any significant latencies.
>
> Having a precise timer on Windows requires an extra device that interrupts
> periodically, which would also need a driver. There is plenty of hardware
> on every system that could be used for this purpose but unfortunately this
> is all owned by Windows and not to be programmed by us.
>
> As an alternative for a precise timer, you could reserve a dedicated
> processor in your system for this task which does nothing but spin in a
> loop to check if a deadline is due. That would require configuring the
> system to make sure no other threads, interrupts and DPCs are occuring on
> this processor which is possible to achieve with boot parameters. Of course
> this unorthodox method wastes a lot of heat but if that’s what it takes to
> get your task done, perhaps it can be acceptable for a dedicated system.
>
> //Daniel
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

9

You can use the parameters to create a second processor group and switch group awareness on.

https://msdn.microsoft.com/en-us/library/windows/hardware/ff542298(v=vs.85).aspx

"When the groupaware boot option is set, the operating system ensures that processes are started in a group other than group 0. This increases the chances of cross-group interaction between drivers and components. The option also modifies the behavior of the legacy functions that are not group-aware, KeSetTargetProcessorDpc, KeSetSystemAffinityThreadEx, and KeRevertToUserAffinityThreadEx, so that they always operate on the highest numbered group that contains active logical processors. "

/bcdedit /SET GROUPAWARE ON
/bcdedit /SET GROUPSIZE … (Set value to half of your logical processor count, but must be power of two)
/bcdedit /SET MAXGROUP ON

This should help you to reserve a free CPU in processor group 0.

It also helps if you have a system on which interrupts always occur on CPU0 instead of having them spread out across all processors. There are boot parameters also to modify this behavior.

//Daniel

“Ramin Raeisi” wrote in message news:xxxxx@ntdev…
Hi,
I tried a lot to find a method for reserving a dedicated core on windows 7 on bootup, but was not successful,
I can use API calls to set the all the possible processes affinities at run-time, but not DPC’s or interrupts and …, So
Could you please help me more about this?

Best Regards

On Fri, Apr 1, 2016 at 4:58 PM, wrote:

first get a exact 1ms interrupt timer on windows which does not change and be consistent

The dynamic clock tick feature was introduced in Windows 8.1. Although there is a boot flag “disabledynamictick”, I have never actually seen that work. To get your solution to work, perhaps you should be running Windows 7, then set the lowest timer resolution of 0.5 ms. And you would have to make sure that your system is suitable for real-time, which means tweaked with hardware and drivers that do not cause any significant latencies.

Having a precise timer on Windows requires an extra device that interrupts periodically, which would also need a driver. There is plenty of hardware on every system that could be used for this purpose but unfortunately this is all owned by Windows and not to be programmed by us.

As an alternative for a precise timer, you could reserve a dedicated processor in your system for this task which does nothing but spin in a loop to check if a deadline is due. That would require configuring the system to make sure no other threads, interrupts and DPCs are occuring on this processor which is possible to achieve with boot parameters. Of course this unorthodox method wastes a lot of heat but if that’s what it takes to get your task done, perhaps it can be acceptable for a dedicated system.

//Daniel

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

10

What Mr. Roberts and Mr. Corbin said. Go back and read and follow their advice.

Square peg… Round hole… Problems ensue,

Peter
OSR
@OSRDrivers

11

Can you not use an Arduino or Cortex M0 of some variant, and just
control it from the PC?

If you are using USB-to-serial converters, you need additional hardware
anyway. If the 3 serial ports are USB serial, USB CDC serial uses bulk
endpoints so you aren’t guaranteed any timing.

James

On 4/1/2016 4:47 AM, xxxxx@gmail.com wrote:

Hi All,
I am developing a software which is essentially a mechanical system tester, I have to use 3 serial ports (Asynch, Just Rx/Tx) to send/receive bytes at 115200 baud-rate and 1 KHz on each of them simultaneously in parallel,
Since the exact timing is critical to my needs, I tried a lot to reach the 1 ms event in user mode, finally I used NtQueryTimerResolution and NtSetTimerResolution and Waitable timers in a separate thread to create a 1 ms timer to send my bytes, but after some tests I found that sometimes the resolution of the timer changes to about 15~20 ms and then come back to 1 ms again, and this is not possible for me,
I am firmware/software and digital electronic designer/developer and completely familiar and experienced in micro-controllers and…, but this situation is defined for this project and I have to use windows which is not real time of course,
Question is that what would be the best solution for this problem, first get a exact 1ms interrupt timer on windows which does not change and be consistent, second how to use to send the serial bytes, use createfile and standard serial port driver or directly use uart controller, somehow write a simple and very customized driver?
All of these should be done in user mode or driver mode? Does writing a driver really helps? because I know that working threads and dpc timers also have latency,
I searched a lot about this, even thinking about hooking the rtc timer, writing driver, searched on your website, somewhere noted about writing a driver at clock level?

However I have never wrote a driver code, but I am not afraid, I did a lot on system programming, microcontrollers, rtos, and …,

I am essentially here looking for a solution and suggestion and really appreciate your kind helps…

Looking forward for your kind answers…

Ramin

NTDEV is sponsored by OSR

Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

12

> What Mr. Roberts and Mr. Corbin said. Go back and read and follow their advice.

Well, their advice does not seem to eliminate Windows PC from the equation,right? You can certainly
offload RT processing job to the embedded system that may be, in itself, suitable for hard RT tasks, but as long as this embedded system has to communicate with Windows PC on hard RT basis the whole thing boils down to a proverbial saying about a chain being as strong as its weakest link…

Anton Bassov

13

Despite the OP being aware that Windows is not a RTOS, he said the
requirement was to do this on Windows. People may have valid reasons to do
things on Windows, even if that’s not ideally the most suitable platform for
a particular task. It’s the world in which we are living.

//Daniel

14

In addition to advises recommended by Mr. Viscarola + James Bellinger -
if you need a quick solution with no self-made hardware, have a look at FTDI USB connected serial controllers.
They have two software interfaces: one is highly compatible with the normal Windows serial API, and another is custom, but gives more low-level control and higher speed.
And you get a ready, well-tested and supported Windows driver.

Though USB is much more complex than plain serial comm and thus a “weak link” for a realtime system, USB also gives you few major advantages for free: cheap off-the-shelf USB cable extenders. You get much longer cables than RS-232 allows at high speed. The transmission is more reliable too, because USB (when done right, of course) has built-in error correction.

Regards,
– pa

15

>but as long as this embedded system has to communicate with Windows PC on hard RT basis

So all RT state machines must be in a controller.

Windows (or Linux) PC should only provide control/status UI (GUI, command line, WS-Management, JSON, webserver) features to the controller app.

BTW, using HID for this (the way similar it is used for UPSes) seems to be a very good idea.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

16

> So all RT state machines must be in a controller.

…and, at this point, the whole thing boils down to “your entire control system has to be re-desiged
from the scratch”…

From the technical perspective this is definitely the best approach. Strictly speaking, the very idea of using x86 architecture for hard RT purposes is flawed in itself due to its “peculiar” feature known as SMI. This is a complete terra incognita as far as the OS software is concerned - you don’t know what triggers it, you don’t know how often it happens, and its execution may take HUNDREDS of milliseconds. This feature alone certainly it does not contribute to overall predictaility, so that even taking the full control of interrupt delivery and ISR scheduling “a-la RTOS” does not completely eliminate the problem.

From the software point, using a true RTOS seems to be much more appropriate than trying to tweak GPOS in order to make it suitable to real-time requirements. There are plenty of both
commercial and open-sources RTOSes available, so that you can choose anything that suits your purposes best.

The "only"problem is that I am not sure the OP can afford it - after all,he made it clear that he has to use Windows despite being aware of its obvious unsuitabiliity for the purpose…

Anton Bassov

17

115200 kbps is the same speed that was easily handled on the original IBM PC 8088 4.77Mhz in 1980 with a decent ISR. Since for ages after that the serial port even has a FIFO buffer to relax latency requirements. How much is maximum interrupt latency these days in Windows? You could just about tolerate an entire millisecond without an overrun which is a whole lot. So is an interrupt driven solution really going to be a problem? I can remember when 250us maximum was the design guide in NT, but maybe someone who is up to date in this area might comment. And why aren’t the built in serial drivers and their associated API not adequate for the desired functionality?

18

>How much is maximum interrupt latency these days in Windows?

The maximum interrupt latency MIGHT be huge. The PCIe spec allows devices to respond to config space read requests with a retry status, repeating forever if the device so chooses. Somehow hardware busses have turned into WANs, with allowed latencies longer than I get pinging google.com.

Some devices will implement config space processing in firmware, so depending on how busy the firmware processor is, if the processor reads config space on that device it might find the read doesn’t complete for a long time. If the device doesn’t respond to the config read at all (like the firmware crashed), there is a timeout implemented in the root complex. If the device responds within the timeout with a retry status the root complex sends the config read to the device again, so this root complex timeout only applies if the device is not responding with a retry status. I just happened to measure this timeout a few weeks ago, and on my little Lenovo TS140 server it was 50 milliseconds. Typically config reads come back in a small number of microseconds, but there is no guarantee of this, and a timeout of 50 milliseconds implies locking the processor on config reads for up to 49 millisecond is considered normal operation. While a processor core is waiting for the config read response, it’s locked and not taking ANY interrupts.

I was actually pondering what to tell firmware developers what “too” long for a config space read to take should be from a Windows driver developers perspective.

There also is the issue of system management mode processing, which is often used for things like scrubbing ECC memory for correctable faults and a variety of power management operations. I don’t have any recent measurement of SMM induced latency.

Jan

19

With respect, that’s a bit like saying “how long is a piece of string” – There’s no “maximum”, this isn’t Windows CE (see other thread).

The guideline is that a driver should not spend more than 100us in its ISR or DPC during a single invocation… however, you’ll note that the actual Driver Verifier bugcheck timeout is “somewhat longer than that” (and measured in tens of seconds).

Exactly #yuuuuge

Mr. Terhell wrote about some of the issue encountered in real-time processing in Windows quite eloquently in The NT Insider a while back:

https:</https:>

Peter
OSR
@OSRDrivers

20

And what OS ran on this system? Remember that it is still used in anger in the real world of industry because fitness for a purpose is sometimes more important than modernity.

The OP has done a poor job of describing his actual requirements, and likely they could in fact be satisfied with a solution using Windows, but as stated, he is SOL

Sent from Mailhttps: for Windows 10

From: xxxxx@gmail.commailto:xxxxx
Sent: April 5, 2016 7:50 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] RealTime Serial Communication in Windows

115200 kbps is the same speed that was easily handled on the original IBM PC 8088 4.77Mhz in 1980 with a decent ISR. Since for ages after that the serial port even has a FIFO buffer to relax latency requirements. How much is maximum interrupt latency these days in Windows? You could just about tolerate an entire millisecond without an overrun which is a whole lot. So is an interrupt driven solution really going to be a problem? I can remember when 250us maximum was the design guide in NT, but maybe someone who is up to date in this area might comment. And why aren’t the built in serial drivers and their associated API not adequate for the desired functionality?

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>