 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Pocket PC Forum / Developers / VC++ for WinCE / July 2008Virtual driver and power managment
Hello, Our device (Pidion under WM5) has a built-in serial port. The problem is the following : we open this port and if we switch off the device it's still opened. It seems the driver doesn't handle power managment. To solve this problem, we're trying to write a virtual driver based on the "Serial driver for Pocket PC" article in codeproject site. This little driver map a new serial port to a hardware port. The driver is a DLL that exports the following functions: * COM_Init * COM_Deinit * COM_Open * COM_Close * COM_Read * COM_Write * COM_Seek * COM_IOControl * COM_PowerDown * COM_PowerUp This driver is working very well, but it seems COM_PowerDown and COM_PowerUp functions are not called when we switch ON/OFF the device. I just would to call COM_Close function in COM_PowerDown, and COM_Open in COM_PowerUp. I've read the "An In-Depth Look at the Power Manager in Windows CE .NET 4.1" article on MSDN, but i don't know what can i do to solve this problem ... Any help would be greatfully appreciated. Thanks in advance. Implement the IOCTL_POWER_ ioctls and see if that works, or write a simple application that uses RequestPowerNotifications with PBT_TRANSITION so you can see what power messages your system broadcasts when you press the ON/OFF button. If you can create a debug kernel; that will show you what the PM sends as well (if you turn on all debugzones for PM). Good luck, Michel Verhagen, eMVP Check out my blog: http://GuruCE.com/blog GuruCE Ltd. Microsoft Embedded Partner http://GuruCE.com Consultancy, training and development services. > Hello, > [quoted text clipped - 31 lines] > > Thanks in advance. Kirk a écrit : > This driver is working very well, but it seems COM_PowerDown and > COM_PowerUp functions are not called when we switch ON/OFF the device. In fact it seems COM_PowerDown is called, but only one instruction in this function seems to "crash" the driver : DEMODLL_API void COM_PowerDown(DWORD hDeviceContext) { int value=1; } If i have no time to do this simple instruction, i understand why i can't close COM port ... And i can't power up the device after, i need to reset the device ... What does crash mean to you? Is the declare of "value" and initialize it to 1 actually the one instruction? I suspect that that code gets optimized out, so I doubt it. What you cannot do is call system APIs, like CreateFile() and CloseHandle(). You can output a DEBUGMSG.  SignatureBruce Eitman (eMVP) Senior Engineer Bruce.Eitman AT EuroTech DOT com My BLOG http://geekswithblogs.net/bruceeitman EuroTech Inc. www.EuroTech.com > Kirk a écrit : >> [quoted text clipped - 13 lines] > > And i can't power up the device after, i need to reset the device ... Bruce Eitman [eMVP] a écrit : > What does crash mean to you? I suppose, because i can't power up the device after a power down, but it is more complicated i think than my knowledges ... > Is the declare of "value" and initialize it to 1 actually the one > instruction? I suspect that that code gets optimized out, so I doubt it. sorry, it seems to work with this simple instruction (i forgot to reset the device with this new driver) > What you cannot do is call system APIs, like CreateFile() and CloseHandle(). > You can output a DEBUGMSG. so i can't close the COM port in COM_PowerDown function (inside COM_Close function there's of course a CloseHandle API) ? And you can power cycle the device without problems without this COM driver right? > so i can't close the COM port in COM_PowerDown function (inside > COM_Close function there's of course a CloseHandle API) ? Why is there "of course" a CloseHandle API? CloseHandle is called from an application to close the handle to the driver, *not* from the driver itself (at least not on the driver "handle"). Usually the "handle" inside the driver is a block of memory containing instance data for the driver. Closing the "handle" in COM_PowerDown does not make sense from a driver point of view. What you should do in COM_PowerDown is put your serial HW in the lowest possible powerstate, and get it out of this powerstate at COM_PowerUp. But... I will repeat myself again: You should not be using the PowerUp/Down functions anymore. Instead implement the IOCTL_POWER ioctls. They are much more flexible and allow multiple powerlevels. You can also call system API's from the IOCTL handling code. Good luck, Michel Verhagen, eMVP Check out my blog: http://GuruCE.com/blog GuruCE Ltd. Microsoft Embedded Partner http://GuruCE.com Consultancy, training and development services. > Bruce Eitman [eMVP] a écrit : >> What does crash mean to you? [quoted text clipped - 12 lines] > so i can't close the COM port in COM_PowerDown function (inside > COM_Close function there's of course a CloseHandle API) ? Michel, notice this is a virtual com driver, so it is doing CreateFile and CloseHandle, that makes sense, but **of course** not in the power functions. Kirk: Since Michel has said it twice, and becuase it is new to you, I will repeat if you need to call those APIs you should use the power manager IOCTLs instead. But really if your physical com driver works well you shouldn't need to do anything in response to the power functions. SignatureBruce Eitman (eMVP) Senior Engineer Bruce.Eitman AT EuroTech DOT com My BLOG http://geekswithblogs.net/bruceeitman EuroTech Inc. www.EuroTech.com > And you can power cycle the device without problems without this COM > driver right? [quoted text clipped - 44 lines] >> so i can't close the COM port in COM_PowerDown function (inside COM_Close >> function there's of course a CloseHandle API) ? |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.