使用netduon做.NET MICRO FRAMEWORK做产品开发,发现每次调用到C#的时间都是需要超过5s以上。最近产品已经小PP了,所以有必要查看一下什么原因造成的?或者加载微软那个框架需要5s?
调试了好久,发现
“CLRStartup.cpp”文件下的 HRESULT Initialize(CLR_SETTINGS params) 函数会调用到 CLR_DBG_Debugger::Debugger_Discovery(); 该函数进去之后需要等待5s左右的时间才出来.
调试跟踪进入,原来调用的是“Debugger.cpp”的void CLR_DBG_Debugger::Debugger_Discovery() 函数。源代码如下:
void CLR_DBG_Debugger::Debugger_Discovery()
{
NATIVE_PROFILE_CLR_DEBUGGER();
CLR_INT32 wait_sec = 5;
CLR_INT64 expire = Time_GetMachineTime() + (wait_sec * TIME_CONVERSION__TO_SECONDS);
//
// Send "presence" ping.
//
CLR_DBG_Commands::Monitor_Ping cmd;
cmd.m_source = CLR_DBG_Commands::Monitor_Ping::c_Ping_Source_TinyCLR;
while(true)
{
CLR_EE_DBG_EVENT_BROADCAST(CLR_DBG_Commands::c_Monitor_Ping, sizeof(cmd), &cmd, WP_Flags::c_NoCaching | WP_Flags::c_NonCritical);
// if we support soft reboot and the debugger is not stopped then we don't need to connect the debugger
if(!CLR_EE_DBG_IS(Stopped) && ::CPU_IsSoftRebootSupported())
{
break;
}
g_CLR_RT_ExecutionEngine.DebuggerLoop();
if(CLR_EE_DBG_IS(Enabled))
{
//
// Debugger on the other side, let's exit the discovery loop.
//
CLR_Debug::Printf( "Found debugger!\r\n" );
break;
}
CLR_INT64 now = Time_GetMachineTime();
if(expire < now)
{
//
// No response in time...
//
CLR_Debug::Printf( "No debugger!\r\n" );
break;
}
}
g_CLR_RT_ExecutionEngine.WaitForDebugger();
}
可以看到开头有个 " CLR_INT32 wait_sec = 5; " 果然是5秒,看来自己的感觉还挺准的.
或者你说把这个时间改小或者修改为0,就可以解决开机慢的问题.其实,只要你修改了,如果小于2,你会发现你用VS调试你的C#应用的时候非常的困难.
这个不是治本的方法.
再看看代码,发现while循环中有一个条件分支
// if we support soft reboot and the debugger is not stopped then we don't need to connect the debugger
if(!CLR_EE_DBG_IS(Stopped) && ::CPU_IsSoftRebootSupported())
{
break;
}
从注释的信息可以看到,如果支持软件重启同时调试器没有停止的话,我们就不需要连接调试器. 从代码来看,如果支持软件重启那么就可以跳出循环.
那么我们看看CPU_IsSoftRebootSupported()这个函数写的是什么,找到STM32_Power_functions.cpp文件,看到如下截图
为什么不支持呢?按理说支持软件重启是分分钟的事情?不支持,真不太可能!!!!
不管三七二十一,直接修改成TRUE,编译下载。
用VS下载一个C#应用,一开机就从串口打印数据..
这次发现下载正常,并且大概1s左右就可以打印出数据了。
这个解决方法两者都兼顾到,完美.
来自:http://blog.csdn.net/lan120576664