none
Executing a pointer to a function from a WIndowsCe 6.0 driver API RRS feed

  • Question

  • Greetings:
    I have a Windows CE 6.0 driver that monitors a digital input and upon detect of a transition change, it suppose to go off and run a function.

    But when I try to actually compile a program that will pass a function to the API routine I get the following error message:

    error C2664: 'PointerFunctionTest' : cannot convert parameter 1 from 'long' to 'long (__cdecl )(long)'
    Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast.

    The driver code:(complies with no errors)

    LP8_API void __stdcall PointerFunctionTest ( long (*f)(long) );
    LP8_API void PointerFunctionTest(long (__stdcall *f) (long))
    {

         TCHAR szzmessage[255];
         swprintf(szzmessage, _T("PointerFunctionTest\r\n"));
         RETAILMSG(1, (szzmessage));

    }

    The program code:(compiles with error stated above)

    long TriggerTest(long x)
    {
     TCHAR szzmessage[255];
     swprintf(szzmessage, _T("TriggerTest...x=%d\r\n"), x);
     MessageBox(NULL, szzmessage, _T("TEST"), MB_OK);
     return 0;
    }

    Case IDC_RESET_TRIGGER:
          PointerFunctionTest(TriggerTest(1));
    break;

    Another variation results in the same error message:

    long (*goo)(long);

    goo = &TriggerTest;
    PointerFunctionTest(goo(1));

    I presume I must be declaring something wrong, but I'm not able to figure out how to declare it correctly. Can anyone give me some clues on how to find the solution?

    Thanks;

    Tuesday, May 29, 2012 6:56 PM

All replies

  • So far this is what I have done to get the routines to work:
    In the driver I changed:
     LP8_API int __stdcall PointerFunctionTest(int bit, long (__stdcall *f) (long) );
    To:
     LP8_API int __stdcall PointerFunctionTest (int bit, long f(void));

    The PointerFunctionTest() in the driver was changeda  to:

     LP8_API int PointerFunctionTest(int bit, long f(void))
     {
      TCHAR szzmessage[255];
      swprintf(szzmessage, _T("PointerFunctionTest...bit=%d\r\n"), bit);
      RETAILMSG(1, (szzmessage));
      f();
      return 0;
     }

    In the application program the function I want to exectute change a little to:(Not much different);

     long TriggerTest()
     {
      TCHAR szzmessage[255];
      swprintf(szzmessage, _T("NEW NEW TriggerTest...\r\n"));
      MessageBox(NULL, szzmessage, _T("TEST"), MB_OK);
      return(0);
     }

    And the button I used to test was changed to:

       case IDC_RESET_TRIGGER:
        PointerFunctionTest(4, TriggerTest);
        PointerFunctionTest(5, TriggerTest);
        PointerFunctionTest(6, TriggerTest);
       break;

    Don't really know why or what the "long (__stdcall *f) (long)" means or does, but it was already there when I started and the person who wrote this code originally knows much more than me, so I presumed it was valid and for all I know it may still be.

    Other inputs will still be gladly accepted.

     

    Tuesday, May 29, 2012 11:36 PM
  • On 5/29/2012 8:56 PM, Chulk Ches wrote:
    > Greetings:
    > I have a Windows CE 6.0 driver that monitors a digital input and upon
    > detect of a transition change, it suppose to go off and run a function.
    [...]
     
    Hi Chulk,
    consider that it's not safe and not allowed to have a driver executing
    user-mode code directly. You can't grant that the called function will
    not generate a fault, never return or do other operations that can
    impact the system reliability.
    For what you are willing to implement the simplest approach would be to
    have a thread inside your driver monitoring the input and then setting a
    named event that will "wake-up" a thread waiting in user mode.
    You can create named event using CreateEvent and OpenEvent (app-side)
    and using SetEvent to signal the event and
    WaitForSingle/MultipleObject(s) to block a thread waiting on the event.
     

    Valter Minute
    Windows Embedded MVP
    http://geekswithblogs.net/WindowsEmbeddedCookbook
    • Proposed as answer by Misbah Khan Wednesday, May 30, 2012 8:50 AM
    • Unproposed as answer by Misbah Khan Wednesday, May 30, 2012 8:51 AM
    Wednesday, May 30, 2012 7:58 AM
  • Named event is one approach, but this might not be fast enough if time constraint is there.

    1. The other approach could be block and run, get the event handle and block on that, the driver will signal it.

    2. Create a message queue and wait on that.

    --- Misbah


    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India) www.tes-dst.com email-misbah.khan@tes-dst.com

    Wednesday, May 30, 2012 8:57 AM
  • Misbah:

    How is your #1 different from Valter's suggestion?  Are you suggesting that named events are slower than unnamed events?


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

    Eurotech Inc.
    www.Eurotech.com

    Wednesday, May 30, 2012 11:12 AM
    Moderator
  • On 5/30/2012 10:57 AM, Misbah Khan wrote:
    > Named event is one approach, but this might not be fast enough if time
    > constraint is there.
    >
    > 1. The other approach could be block and run, get the event handle and
    > block on that, the driver will signal it.
    >
    > 2. Create a message queue and wait on that.
    >
    > --- Misbah
    >
    > ------------------------------------------------------------------------
    >
    > Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India)
    > www.tes-dst.com email-misbah.khan@tes-dst.com
    >
     
    If you create a named event you are actually sharing the same object
    between the driver and the app and, AFAIK, there is no difference in
    performances. It's not granted that passing an handle will work.
    You are correct about the fact P2P message queues could also be useful
    if you need to pass information and not just to report an event.
     

    Valter Minute
    Windows Embedded MVP
    http://geekswithblogs.net/WindowsEmbeddedCookbook
    Thursday, May 31, 2012 10:25 AM
  • Hi Guys,

    In my experience i have observed more bottleneck with named event.

    hence the above two methods worked well for me in the past. Hence i suggested it.

    If you have anything to share in this regard, it would a please for all the readers including me. 

    Chulk,

    following is the example how i did the 1st method:

    /*-------------------------------------------------------------------------------------------------*/

    static HANDLE hdaq_timeout_event=INVALID_HANDLE_VALUE;

    case IOCTL_GPT_EVENT_HANDLE_DUPLICATE:
                memcpy(&stHandle,pInBuffer,inSize);
                rc=GetHandle(stHandle.processid,stHandle.hEvent);

    BOOL GetHandle(UINT processId,HANDLE hEvent)
    {
        BOOL rc = FALSE;

        if(hdaq_timeout_event != INVALID_HANDLE_VALUE)
        {
            CloseHandle(hdaq_timeout_event);
            hdaq_timeout_event=INVALID_HANDLE_VALUE;
        }

        hdaq_timeout_event= CeDriverDuplicateCallerHandle(
             hEvent,DUPLICATE_SAME_ACCESS,FALSE,0);

        if(!hdaq_timeout_event)
        {
            RETAILMSG(ZONE_ERROR, (TEXT("GPTimer:GetHandle failed\r\n")));
            goto cleanup;
        }
        rc=TRUE;
    cleanup:
        return rc;
    }

    /********** signaling the event ***************************/

    SetEvent(hdaq_timeout_event);

    --- Misbah


    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India) www.tes-dst.com email-misbah.khan@tes-dst.com

    Friday, June 1, 2012 5:41 AM
  • Misbah,

    Could you elaborate on the performance issue you have seen with named events? AFAIK from a system perspective using names events uses the same handle under water, so there really should not be any performance difference with the duplicate handle method you are using.


    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.

    Friday, June 1, 2012 6:05 AM
    Moderator