none
[SOLVED]How COM pdd and mdd come to know which UART port has to open?? RRS feed

  • Question

  • Dear Developers,

    Greetings!!!

    When application uses CreateFile and pass first argument as an port name for COM port, it maps to COM_Open in mdd.c file. I am selecting UART0,2,3 and during the loading time, only COM_Init should call for three instances but COM_Open is also called for three instances and COM_Close also called three times.

    This scenario is quiet strange to me why COM_OPen is called by device manager.

    Another thing I want to read the value of UARTINdex for instance 3 in DoTxData.. But how could we know in COM_Open that the application is asking to open UART3 or any other port??????????


    Thursday, June 11, 2015 10:41 AM

Answers

  • This should be stored in the In the context created in COM_INIT:

    In the XXX_INIT the (registry) active key is passed as a parameter (called ULONG Identifier) This way you can retrieve the registry parameter(s) for that specific driver and store that info in the context created in the XXX_init function (and thus there you determine which port is  opened).

    https://msdn.microsoft.com/en-us/library/ms894042.aspx

    So all communication go through the device manager. The device manager loads the driver by calling the _init function. The context returned by the driver will simply be passed by the device manager to the driver when the application calls CreateFile() => COM_Open(hContext). Perhaps a good reference is this book

    So COM_Open 'knows' it by getting that information from the context given as the parameter and this context is created in the _init method.


    Good Luck,

    Erwin Zwart, eMVP
    Check out my blog: http://guruce.com/blog
    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    Tuesday, June 16, 2015 10:17 AM
    1. Huh?  What is an "ellipse based function"?
    2. You should read the documentation for Stream Interface Drivers.  As you already must know:
          a. Device manager uses the registry and its own algorithm to assign the driver namespace.  Example: COM1
          b. Device manager loads the associated DLL for COM1
          c. Device manager calls COM1's XXX_Init function
          d. The XXX_Init function initialized the driver, and if needed stores context information in a variable which could be a structure.
          e. XXX_Init returns a variable which is typically a pointer to the structure, but it could be anything (non-zero) that the driver wants to use.
          f. The application calls CreateFile passing in "COM1"
          g. Device manager calls XXX_Open passing in the context variable returned from XXX_Init
          h. XXX_Open returns, after possibly modifying the context.
          j. Device manager returns a HANDLE to the COM1 driver - what that handle is doesn't matter becuase the device manager manages it.
          k. Future calls to COM1 functions pass in the HANDLE, which Device Manager uses to pass the context variable to the driver's functions.

    Bruce Eitman (eMVP) Senior Engineer Bruce.Eitman AT Eurotech DOT com My BLOG http://geekswithblogs.net/bruceeitman Eurotech Inc. www.Eurotech.com

    Thursday, July 2, 2015 2:03 PM
    Moderator

All replies

  • Another thing I want to read the value of UARTINdex for instance 3 in DoTxData.. But how could we know in COM_Open that the application is asking to open UART3 or any other port??????????

    Ask your board/BSP vendor. The answer is specific to the BSP.

    Usually, there is some registry setting that tells the driver which hardware to control.  Then, the "order" setting defines which COMx


    Bruce Eitman (eMVP) Senior Engineer Bruce.Eitman AT Eurotech DOT com My BLOG http://geekswithblogs.net/bruceeitman Eurotech Inc. www.Eurotech.com

    Friday, June 12, 2015 1:11 PM
    Moderator
  • Dear Bruce,

    Thanks for reply.

    We have full BSP source code. As, i was traversing through the code, I come to know that COM_Init should be called by device manager but after this I have observed that COM_Open is also called by someone as I was not running any application. More over in the driver registry, there are 6 COM instanced entries are there and out of that I am using only 3 COM ports. When I run the application, it should call COM_Open and its happening but there is no information in the source code of COM_Open that application is requesting for which port..

    As, the first parameter of COM_Open is the return type for COM_Init, then how Application CreateFile is mapped with COM_Open()

    Tuesday, June 16, 2015 4:35 AM
  • Hi Partap,

    The device manager calls XXX_INIT for EVERY instance of the driver only once. This means only once for COM1: only once for COM2: etc.. In the XXX_INIT the (registry) active key is passed as a parameter (called ULONG Identifier) This way you can retrieve the registry parameter(s) for that specific driver and store that info in the context created in the XXX_init function (and thus there you determine which port is  opened).

    Each CreateFile(L"COMX:", ...) call will result in in a COM_Open for that instance and each CloseHandle in a COM_Close...

    Check <WINCEROOT>\public\common\oak\drivers\serial\com_mdd2 for the MDD part where this is (in case for the uart). 

    This is the 'standard' behavior but as Bruce mentioned this could be modified by the OEM/BSP Vendor... 


    Good Luck,

    Erwin Zwart, eMVP
    Check out my blog: http://guruce.com/blog
    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    Tuesday, June 16, 2015 7:59 AM
  • Hi Erwin Zwart,

    Yes, this is the standard behaviour. But My point is that How driver COM_Open come to know that it has to open for which instance because the application is passing the COM number as an first argument but driver COM_Open first argument is the return type of COM_Init().. So, this is the confusion for me.....

    Tuesday, June 16, 2015 9:13 AM
  • This should be stored in the In the context created in COM_INIT:

    In the XXX_INIT the (registry) active key is passed as a parameter (called ULONG Identifier) This way you can retrieve the registry parameter(s) for that specific driver and store that info in the context created in the XXX_init function (and thus there you determine which port is  opened).

    https://msdn.microsoft.com/en-us/library/ms894042.aspx

    So all communication go through the device manager. The device manager loads the driver by calling the _init function. The context returned by the driver will simply be passed by the device manager to the driver when the application calls CreateFile() => COM_Open(hContext). Perhaps a good reference is this book

    So COM_Open 'knows' it by getting that information from the context given as the parameter and this context is created in the _init method.


    Good Luck,

    Erwin Zwart, eMVP
    Check out my blog: http://guruce.com/blog
    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    Tuesday, June 16, 2015 10:17 AM
  • Hello Erwin Zwart,

    Thanks for sharing the info. But this thing is clear to me. I have some doubts as mentioned below:-

    1. The stream driver xxx_open, etc are ellipse based function or not.

    2. Device Manager creates the instances during the time of loading the driver. But, when application uses CreateFile and it maps with COM_Open, How this information is passed between application-device manager-driver.??????

    Thursday, July 2, 2015 9:05 AM
    1. Huh?  What is an "ellipse based function"?
    2. You should read the documentation for Stream Interface Drivers.  As you already must know:
          a. Device manager uses the registry and its own algorithm to assign the driver namespace.  Example: COM1
          b. Device manager loads the associated DLL for COM1
          c. Device manager calls COM1's XXX_Init function
          d. The XXX_Init function initialized the driver, and if needed stores context information in a variable which could be a structure.
          e. XXX_Init returns a variable which is typically a pointer to the structure, but it could be anything (non-zero) that the driver wants to use.
          f. The application calls CreateFile passing in "COM1"
          g. Device manager calls XXX_Open passing in the context variable returned from XXX_Init
          h. XXX_Open returns, after possibly modifying the context.
          j. Device manager returns a HANDLE to the COM1 driver - what that handle is doesn't matter becuase the device manager manages it.
          k. Future calls to COM1 functions pass in the HANDLE, which Device Manager uses to pass the context variable to the driver's functions.

    Bruce Eitman (eMVP) Senior Engineer Bruce.Eitman AT Eurotech DOT com My BLOG http://geekswithblogs.net/bruceeitman Eurotech Inc. www.Eurotech.com

    Thursday, July 2, 2015 2:03 PM
    Moderator
  • Thanks bruce for exploring the things in details. But I need that device manager algo for more understanding??
    Thursday, July 2, 2015 2:26 PM
  • I am not sure what else to tell you about this and why you should investigate the device managers algo (which just loads busenum enumerates the builtin key's and call activatedevice() on each entry found) oh wait here this link..

    what part of bruce's comment is not clear?



    Good Luck,

    Erwin Zwart, eMVP
    Check out my blog: http://guruce.com/blog
    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    Thursday, July 2, 2015 2:35 PM
  • Thanks bruce for exploring the things in details. But I need that device manager algo for more understanding??

    Ok, so read the code.  The last time that I looked it is in the Private folder.

    Bruce Eitman (eMVP) Senior Engineer Bruce.Eitman AT Eurotech DOT com My BLOG http://geekswithblogs.net/bruceeitman Eurotech Inc. www.Eurotech.com

    Thursday, July 2, 2015 3:56 PM
    Moderator