-
对了，NSS建立的时间单位怎么是tpclk?Data input 的单位是5ns?tpclk是36MHZ的话，那NSS的建立时间至少110ns以上啊？这是不是说明NSS反应要比data input要慢呢？难道问题出现在这里？SPI的标准到底是怎么样的呢？
-
1. 这条线（主设备端的MOSI）可以做输出，也可以做输入，方向由BIDIOE控制；即，收/发只能分时进行，所以是“单工”
2. 无论是双向之接收，还是RxOnly（单向），作为主设备，一旦配置好相应模式，使能SPI后，时钟自动送出，无须“通过写DR，发送数据才出时钟信号”
-
资料很全面
-
是上下抖动，VS不稳定。
屏是TTL接口的。
FCLK,HCLK,PCLK,VCLK试了多种方案，总是无法得到满意接口，这samsung的2440确实不大好用。
-
我把程序擦掉，还有那个样子！
-
这个我知道，那什么时候知道有数据进来？？我就是想知道这个？
-
你做的不是服务程序，而是启动自动加载的应用程序。
服务程序是由服务管理器来加载的，通常用OpenSCManager、CreateService函数来安装，服务程序入口需要调用StartServiceCtrlDispatcher给出服务名称及对应的主函数，由服务管理器调用主函数，在主函数中调用RegisterServiceCtrlHandlerEx注册handle函数，在handle函数中处理各种事件并设置服务状态。具体做法可以参考MSDN中相关内容，也可以在网上搜索。
-
买个开发板，的话按照开发板手册来做好了。我觉得飞凌的开发板就不错~
-
帮了我不少忙
-
传个文档给你
TDC-GP2应用手册.pdf (708.69 KB)
下载次数:206
2010-4-2 18:28
TDC-GP2在时差法(TOF)脉冲式激光测距中的应用.pdf (208.12 KB)
下载次数:187
2010-4-2 18:28
-
谢谢楼上的，用示波器我也测试到，空调的如果一直按，是不会重复发送的
-
这也是个比较大的题目啊，替楼主UP。
好像这个箱子所带的Linux资料很多，包括驱动，应用...
将这个箱子带的资料大体跑通，然后像上面所说的，将系统分模块，是能够搞定的。
-
OC 门时，当作IO口控制用，需要上拉，一般用4。7K电阻，如果要速度快，可以往下降，如1K。
另外，3。3V驱动5V时，会出现高电平达不到要求，需要上拉。
-
很明显，楼主的程序只能跑一次
-
首先谢谢楼上的各位。
接下来是我的情况：该产品不是消费类的电子产品，所以量应该不会那么大，10k/月不可能啦。我估计也就10k/年。
主要由于我们有一定的Mobile技术积累，目前产品周期又要求的比较紧张。所以才考虑到mobile的。我担心的是这样干完了，以后过认证、授权什么的成本太高，最终没法上市销售，只能做个摆设。 要是这样的话，还不如从现在就踏踏实实的搞wince。
Mobile的授权和开发的费用大家有没有具体的数字？好跟Wince对比。
-
哪家公司啊。呵呵。这样的招聘贴子也就让你放两天。
-
我将0xa0000000映射为0x00000000，那么看起来中断向量表就在0x00000000开始的地方，来了中断就到0x18处（实际上对应于物理地址的0xa0000018）找入口，不是这样吗？
-
哦，这样呀，我看看，谢谢先
-
读线程代码：
DWORD WINAPI ReadCommThread(LPARAM lparam)///读线程
{
extern charCount;
extern HANDLE m_hCom;
extern OpenCloseFlag;
extern unsigned char pszRecv[1024];
DWORD ReadBytes;
DWORD bResult;
DWORD dwErr;
OVERLAPPED ReadOver;
DWORD hMask;
DWORD CommEvent;
int i=0;
CRITICAL_SECTION section;
COMSTAT comstat;
DWORD Flag=0;
memset(&ReadOver,0x00,sizeof(ReadOver));
ReadOver.Offset=0;
ReadOver.OffsetHigh=0;
ReadOver.hEvent=CreateEvent(NULL,TRUE,FALSE,NULL);
PurgeComm(m_hCom,PURGE_TXABORT | PURGE_TXCLEAR | PURGE_RXABORT | PURGE_RXCLEAR);
InitializeCriticalSection(§ion);
for(;;)
{
bResult=WaitCommEvent(m_hCom,&hMask,&ReadOver);
if(OpenCloseFlag==1) //串口已被打开才做下一部
{
if(!bResult)
{
switch(dwErr=GetLastError())
{
case ERROR_IO_PENDING:
// MessageBox(NULL,"读取成功",0,MB_OK);
Flag^=1;
break;
/* case 87:
break;*/
default:
SetDlgItemText((HWND)lparam,IDC_COMMSTATE,"WaitCommEvent Error");
goto ErrorNext;
}
}else
{
bResult=ClearCommError(m_hCom,&dwErr,&comstat);
if(comstat.cbInQue==0)
continue;
}
WaitForSingleObject(ReadOver.hEvent,INFINITE);///等侍异步操作完成
Flag=0;
//ResetEvent(ReadOver.hEvent);////设置为不发信号状态
GetCommMask(m_hCom,&hMask);
if(hMask & EV_CTS)//CTS信号改变
{
}
if(hMask & EV_RXFLAG)//收到特殊字符
{
}
if(hMask & EV_BREAK)
{
}
if(hMask & EV_ERR)//端口错误信号
{
}
if(hMask & EV_RING) //ring信号变化
{
}
if(hMask & EV_RXCHAR)///收到一个或多个字符
{
EnterCriticalSection(§ion);
bResult=ClearCommError(m_hCom,&dwErr,&comstat);
if(!ReadFile(m_hCom,pszRecv,1024,&ReadBytes,&ReadOver))
{
switch(dwErr=GetLastError())
{
case ERROR_IO_PENDING:
Flag^=1;
break;
default:
goto ErrorNext;
}
}
if(Flag & 1)
{
SetDlgItemText((HWND)lparam,IDC_COMMSTATE,"正在读取数据");
WaitForSingleObject(ReadOver.hEvent,INFINITE);
if(GetOverlappedResult(m_hCom,&ReadOver,&ReadBytes,TRUE))
{
SetDlgItemText((HWND)lparam,IDC_COMMSTATE,"读取数据完成");
SetDlgItemText((HWND)lparam,IDC_SHOWINFO,pszRecv);
}
}
LeaveCriticalSection(§ion);
}
ErrorNext:
Flag=0;
PurgeComm(m_hCom,PURGE_TXABORT | PURGE_TXCLEAR | PURGE_RXABORT | PURGE_RXCLEAR);
}
}
return 1;
}
复制代码
-
問題解決了。今天更新了下BSP。
總結一下：
1.可能原因是視頻那塊的一個加速沒有被打開。具體是硬件加速還是軟件加速不詳。但是可以注意的一點是。如果芯片帶有對圖像處理的硬件加速器。一定要打開。
2.根據今天討論的結果。大概的意思是，由於沒有打開某加速，導致刷屏的時候出現卡的現象。這個現象出現的原因根本在於MPU屏的特性，MPU有一個DMA類似的內存空間，而RGB屏則不考慮直接送出，就是因為這個原因，再加上加速器並未打開。導致數據在存儲空間中有一個類似演示的效果處理，所以產生了播放不流暢的現象，而音頻的不流暢也是由於視頻緩衝所導致。
結束本帖。謝謝樓上各位了！
明天晚上結貼！再放一天
stm32/stm8