locked
kernel mode vs user mode RRS feed

  • Question

  • Hi,

    I'm new to Win CE development, coming from the world of RTOS and flat memory models. I am familiar with the concepts of kernel mode vs user mode but we are struggling to determine if there is any benefit to writing software to run in user mode instead of kernel mode. The software is doing some data processing and eventually is controlling peripherals  such as PWM, A2D, I2C, ect... Obviously the code that controls the hardware will be kernel mode, but we're trying to determine if there is a benefit to separating the code into kernel mode code and user mode code. If it helps clarify, we're not concerned with any of the "safety" elements of user mode, we're mostly "firmware" guys who are use to programming on the bare metal.

    Thanks,

    Eric

    Wednesday, May 8, 2013 4:42 PM

Answers

  • You just have to keep in mind that any call from user space to kernel space involves a complete VM switch, so minimize the frequency of those switches for performance.

    Normally, you'd do any hard realtime stuff in kernel mode, inside a driver. Think data collection from a device when responding to an interrupt. Do as much as you can in the driver, put the data in a SW FIFO and allow the application to get the data in a lazy manner. Don't expect the application to respond within realtime boundaries.

    This will be your architecture:

    KERNEL MODE - Drivers, data collection, realtime control [NATIVE CODE]

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    KERNEL/USER MODE - SDK DLL - Handles all CreateFile(L"DRV0:", etc), DeviceIoControl(hDevice, etc) calls. All the plumbing required to allow easy interfacing from .NET to your driver [NATIVE CODE]. The SDK DLL has the Q flag specified in the bib records.

    vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

    USER MODE - .NET Application calling your SDK DLL (so better make sure your SDK functions are easy to P/Invoke)


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    • Marked as answer by EMG_Brady Monday, May 13, 2013 2:38 PM
    Friday, May 10, 2013 12:32 PM

All replies

  • So you're not doing user interface? You can't do that from kernel mode. If you're just using Windows CE as a framework for writing a no-UI, no-HMI (keyboard, mouse, joystick, touch) device, you can probably do everything in a kernel mode driver. I don't see why you'd use Windows CE for such an application but maybe you can tell us why and we can help from there.

    Paul T.

    Wednesday, May 8, 2013 11:03 PM
  • So there is a HMI but that is not my group's concern. There are user facing applications running in the .net framework and that is the main driver for using WinCE. The user interacts with the .net software and the result is that the "firmware" needs to actuate the hardware like motors and sensors. 

    I know that we can do everything in kernel mode, but I guess my question is should we do everything in kernel mode. We know that we have to write a lot of kernel space objects but we're attempting to determine if there is a benefit to designing the software to be in user space unless it needs to be in kernel space. Since my experience is all in RTOS and very embedded applications everything was on the bare metal and that is the model that most of the team is use to, but we're trying to adapt to WinCE and would like to follow the best practices for WinCE.

    Thanks 

    Thursday, May 9, 2013 5:03 PM
  • Thanks for the links.
    Thursday, May 9, 2013 5:15 PM
  • You just have to keep in mind that any call from user space to kernel space involves a complete VM switch, so minimize the frequency of those switches for performance.

    Normally, you'd do any hard realtime stuff in kernel mode, inside a driver. Think data collection from a device when responding to an interrupt. Do as much as you can in the driver, put the data in a SW FIFO and allow the application to get the data in a lazy manner. Don't expect the application to respond within realtime boundaries.

    This will be your architecture:

    KERNEL MODE - Drivers, data collection, realtime control [NATIVE CODE]

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    KERNEL/USER MODE - SDK DLL - Handles all CreateFile(L"DRV0:", etc), DeviceIoControl(hDevice, etc) calls. All the plumbing required to allow easy interfacing from .NET to your driver [NATIVE CODE]. The SDK DLL has the Q flag specified in the bib records.

    vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

    USER MODE - .NET Application calling your SDK DLL (so better make sure your SDK functions are easy to P/Invoke)


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    • Marked as answer by EMG_Brady Monday, May 13, 2013 2:38 PM
    Friday, May 10, 2013 12:32 PM