A driver is no more special than a process in terms of the scheduler. Have you tried cranking down the system timer resolution to 1ms and reducing the extraneous workload on the machine?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, November 8, 2016 10:20 AM
To: Windows System Software Devs Interest List Subject: [ntdev] Virtual Com Port ? Protocol Driver?
Hi all, I have a puzzle I?ve been trying to solve and I?m thinking that a driver might be the way to go. I work in the industrial automation industry and I have many years of experience developing software on Real Time Operations systems (using C) and user applications on Windows (C, C++ & VB) but I have only ever read about windows driver development. I’m still reading.
The automation industry still uses serial communications a great deal. It?s cheap, scalable and has a large install base. The two serial protocols that are used the most in my work are Modbus RTU and BACNet MSTP (Master Slave Token Passing). There are open source libraries for both of these protocols, but none of them work perfectly in Windows due to the 10ms timer resolution. BACNet MSTP for instance, can require that a device declare the token lost if nothing is detected on the com port for 10ms. Similarly, Modbus RTU determines that a message is done when the com port goes silent for 10ms.
What I?m thinking of is that I could implement the protocols in a driver which sits on top of Virtual com port drivers. From what I have read, and please correct me if I?m wrong, is that scheduling allows for precise control over timed code execution in kernel mode drivers. The goal would be to have the driver handle the link layer for the serial protocols. My questions are as follows: 1) Is this a reasonable idea? 2) Any advice on how to proceed?
I think I need to write a class level filter driver that supports PnP for USB Virtual com ports?
Hi Doron. Thanks for the reply. Yes I have tried setting the timer resolution to 1ms but I read that this was not advised because of power consumption and CPU loading. I made some difference but did not solve my problem entirely.
Also, the task scheduler in windows can’t be counted on to execute a user program often as I need it to. I’ve written code to test this and it only works maybe 60% of the time. I’ve also tried increasing my user program thread priority to REAL_TIME but it still can’t be counted on to be executed as often as I need it to in order to accurately time the interval between characters being received (or not received) on the com port.
The reason I was thinking of writing a driver was so I could use the KeSetTimer group of API functions to accomplish what I can’t seem to in a user program.
Guess what? The kernel timer uses the same scheduler and resolution
Bent by my phone
From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com Sent: Tuesday, November 8, 2016 3:09:50 PM To: Windows System Software Devs Interest List Subject: RE:[ntdev] RE: Virtual Com Port ? Protocol Driver?
Hi Doron. Thanks for the reply. Yes I have tried setting the timer resolution to 1ms but I read that this was not advised because of power consumption and CPU loading. I made some difference but did not solve my problem entirely. Also, the task scheduler in windows can’t be counted on to execute a user program often as I need it to. I’ve written code to test this and it only works maybe 60% of the time. I’ve also tried increasing my user program thread priority to REAL_TIME but it still can’t be counted on to be executed as often as I need it to in order to accurately time the interval between characters being received (or not received) on the com port.
The reason I was thinking of writing a driver was so I could use the KeSetTimer group of API functions to accomplish what I can’t seem to in a user program.
Hi Doron. Thanks for the reply. Yes I have tried setting the timer resolution to 1ms but I read that this was not advised because of power consumption and CPU loading. I made some difference but did not solve my problem entirely.
It’s true. That’s the trade-off for getting increased timer resolution.
Also, the task scheduler in windows can’t be counted on to execute a user program often as I need it to. I’ve written code to test this and it only works maybe 60% of the time. I’ve also tried increasing my user program thread priority to REAL_TIME but it still can’t be counted on to be executed as often as I need it to in order to accurately time the interval between characters being received (or not received) on the com port.
The reason I was thinking of writing a driver was so I could use the KeSetTimer group of API functions to accomplish what I can’t seem to in a user program.
All true. Windows is not a real-time operating system, and it never
will be. It’s simply not possible to achieve that level of accuracy.
You need to find another design, possibly using hardware assistance.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Threads that run in KM are scheduled in the same way as those that run in UM on Windows. There are of course differences, but they don?t really pertain to your problem, so you should expect the same sort of timer resolution in KM as you see in UM. To achieve the kind of reliability that you are after, you will need a timer resolution at least two orders of magnitude smaller than the intervals that you wish to measure (a general rule of thumb) and you are not going to get that on Windows using any of the standard techniques
There are only two ways that you will be able to make these protocols work on Windows:
Develop some hardware to implement the wire protocol + a simple driver to pass data to UM; or
Develop an advanced KM driver that will be branded as malware for general purpose use, but might work for you in a controlled environment.
If you are even thinking about #2, plan to have a stable hardware platform (including firmware) as well as a stable OS version (no windows update etc.). Also plan for no antivirus or other security software and accept the fact that there will be many challenges and a lengthy development cycle.
If none of that scares you, then think about a design where you corral the CPUs and then take over one or more of them from the OS. This is easy in Linux because you can modify the kernel itself but very hard in Windows and any solution that you come up with will necessarily be tied to a specific configuration. Also remember that you (or someone who will curse you) will have to maintain this at some point in the future
Likely, the cost of developing a simple FPGA device would be far less in the long run ? which is exactly why that is the dominant solution in the market right now.
From: Tim Robertsmailto:xxxxx Sent: November 9, 2016 12:41 PM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: Re: [ntdev] RE: Virtual Com Port ? Protocol Driver?
xxxxx@gmail.com wrote: > Hi Doron. Thanks for the reply. Yes I have tried setting the timer resolution to 1ms but I read that this was not advised because of power consumption and CPU loading. I made some difference but did not solve my problem entirely.
It’s true. That’s the trade-off for getting increased timer resolution.
> Also, the task scheduler in windows can’t be counted on to execute a user program often as I need it to. I’ve written code to test this and it only works maybe 60% of the time. I’ve also tried increasing my user program thread priority to REAL_TIME but it still can’t be counted on to be executed as often as I need it to in order to accurately time the interval between characters being received (or not received) on the com port. > > The reason I was thinking of writing a driver was so I could use the KeSetTimer group of API functions to accomplish what I can’t seem to in a user program.
All true. Windows is not a real-time operating system, and it never will be. It’s simply not possible to achieve that level of accuracy. You need to find another design, possibly using hardware assistance.
– Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
> Likely, the cost of developing a simple FPGA device would be far less in the
long run ?
Dear M.M., there’s no need to scare the OP
Modbus is a well known protocol, COTS solutions likely are available.
If not… FTDI makes easy to use serial to USB adapters, complete with drivers, libraries and app.notes.
A small microcontroller with USB and serial I/O, like Arduino or Cypress Ez-something will suffice.
