Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

RE: Virtual Com Port ? Protocol Driver?

Doron_HolanDoron_Holan Member - All Emails Posts: 10,435
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 <xxxxx@lists.osr.com>
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?

Thanks in advance for any help you can provide.



---
NTDEV is sponsored by OSR

Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev>;

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at <http://www.osr.com/seminars>;

To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>;
d

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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.
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,435
    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.

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

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

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,002
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • MBondMBond Member - All Emails Posts: 846
    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:

    1) Develop some hardware to implement the wire protocol + a simple driver to pass data to UM; or

    2) 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.





    Sent from Mail for Windows 10



    From: Tim Roberts
    Sent: November 9, 2016 12:41 PM
    To: Windows System Software Devs Interest List
    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.


    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

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

    To unsubscribe, visit the List Server section of OSR Online at
  • Pavel_APavel_A Member Posts: 2,674
    > 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.

    Regards,
    -- pa
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA