none
where is the MMTIMER registry key? RRS feed

All replies

  • The source code of MMTMER is in public\COMMON\oak\drivers\mmtimer\MMTimer.c
    Just create a registry entry in your project or platform REG file should work.
    Tuesday, April 12, 2011 6:24 PM
  • The source code of MMTMER is in public\COMMON\oak\drivers\mmtimer\MMTimer.c
    Just create a registry entry in your project or platform REG file should work.


    Please correct me if I am wrong, but I shouldn't have to modify MMTimer.c, right?  I went and created the following key:

     

    Priority256
    

     

    in

     

    HKEY_LOCAL_MACHINE\System\MMTIMER
    
    

     

    The key is a REG_DWORD and has a value of 0.  I did this in

     

    C:\WINCE600\PLATFORM\CEPC\FILES\platform.reg
    

     

    I didn't notice much change in behavior.  My callback function still can't execute every millisecond.  So maybe it should be noted that callbacks are not accurate to within 1ms?

     



    • Edited by mr_jeff Tuesday, April 12, 2011 8:05 PM formatting
    Tuesday, April 12, 2011 8:04 PM
  • Maybe you can show us your usage of timeSetEvent.
    And is your callback function invokes any blocked functions?
    You can also CELOG and Kernel Tracker to verify the MMTIMER thread priority and scheduled as expected
    Tuesday, April 12, 2011 8:50 PM
  • Maybe you can show us your usage of timeSetEvent.
    And is your callback function invokes any blocked functions?
    You can also CELOG and Kernel Tracker to verify the MMTIMER thread priority and scheduled as expected

    uiTimerRet = timeSetEvent(1, 0, TimerCb, dwTestData, TIME_PERIODIC | TIME_CALLBACK_FUNCTION);
    
    void CALLBACK TimerCb(UINT uTimerID, UINT uMsg, DWORD dwUser, DWORD dw1, DWORD dw2)
    {
    	glob_write[0] = 0x07;
    	glob_write[1] = 0x07;
    	WriteFile(hDriver, glob_write, 2, &numTimerWritten, NULL);
    	
    	glob_write[0] = 0x00;
    	glob_write[1] = 0x00;
    	WriteFile(hDriver, glob_write, 2, &numTimerWritten, NULL);
    }
    

    And WriteFile calls the driver's XXX_Write method, which looks like this:

     

    DWORD XXX_Write(DWORD hOpenContext, LPCVOID pBuffer, DWORD Count)
    {
    	WCHAR dbgBuf[50];
    	DWORD x;
    	USHORT usData, temp;
    
    	if (Count % 2)
    		return 0;
    
    	// Implement the code to write to the stream device here. 
        // XXX_Init set up
    	// information on where memory is (gMemBase).
    	for (x=0; x < Count; x+=2) {
    		temp = ((unsigned char *)pBuffer)[x+1];
    		usData = ((unsigned char *)pBuffer)[x] | (temp << 8);
    		WRITE_REGISTER_USHORT(gMemPtr + x, usData);	//write 2 bytes
    	}
    
    	return Count;
    }
    

     

    I hope WRITE_REGISTER_USHORT doesn't block.  Maybe the declaration of the variables takes too much time?

    Tuesday, April 12, 2011 9:50 PM
  • The WRITE_REGISTER_USHORT shouldn't block.
    Local variable uses stack as storage but in many case compiler optimization would use register to avoid accessing memory.
    In the case of accessing stack may trigger page fault but the recovery penalty should be minimal (compare to 1ms)
    You could "set WINCECOD=1" to review the list file (.COD)
    I suggest you to enable CELOG + kernel Tracker to analysis the issue.
    Also use hardware based timer is usually more reliable.


    • Edited by K M O S Monday, April 18, 2011 5:19 PM Correct the typo to stop making Michael LOL
    Tuesday, April 12, 2011 10:15 PM
  • WRITE_REGISTER_USHART
     
    Made me lol, haha!
     

    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.
    Sunday, April 17, 2011 10:37 PM
    Moderator