青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

CnComm勘誤及Faq(將會(huì)持續(xù)更新)

勘誤

1、2009-5-14 據(jù)shunruo網(wǎng)友發(fā)現(xiàn)了一個(gè)重要的BUG,在此感謝shunruo網(wǎng)友,還有張冬冬網(wǎng)友

CnComm1.5第1180行 函數(shù):DWORD Write(LPCVOID lpBuf, DWORD dwSize)

原有代碼:

 

DWORD Write(LPCVOID lpBuf, DWORD dwSize)
{
    DWORD dwTemp 
= dwSize, dwFree = FreeSize();
    
    
if (dwFree)//! 首先查找末尾空閑,并寫入數(shù)據(jù)
    {
        DWORD dwCopy 
= dwFree > dwSize ? dwSize : dwFree;
        memcpy(L_
->P_ + L_->E_, lpBuf, dwCopy);
        dwTemp 
-= dwCopy, L_->E_ += dwCopy;
    }

    
if (dwTemp)//! 剩余的數(shù)據(jù)分配新的空間并寫入
    {
        memcpy(NewBlock(dwSize)
->P_, lpBuf, dwTemp);//重要的BUG
        L_
->E_ += dwTemp;
    }

    S_ 
+= dwSize;
    
return dwSize;
}

 

請將該函數(shù)內(nèi)容修正如下:

 

DWORD Write(LPCVOID lpBuf, DWORD dwSize)
{
    DWORD dwTemp = dwSize, dwFree = FreeSize(), dwCopy = 0;

    if (dwFree)//! 首先查找末尾空閑,并寫入數(shù)據(jù)
    {
        dwCopy = dwFree > dwSize ? dwSize : dwFree;
        memcpy(L_->P_ + L_->E_, lpBuf, dwCopy);
        dwTemp -= dwCopy, L_->E_ += dwCopy;
    }

    if (dwTemp)//! 剩余的數(shù)據(jù)分配新的空間并寫入
    {
        memcpy(NewBlock(dwSize)->P_, ((LPBYTE)lpBuf )+ dwCopy, dwTemp);//該處原代碼未作偏移值修正,由于緩沖區(qū)一般較大,這一塊在測試中忽略了
        L_->E_ += dwTemp;
    }

    S_ += dwSize;
    return dwSize;
}


2、2009-4-29 根據(jù)網(wǎng)友檸檬的提醒,發(fā)現(xiàn)一個(gè)CnComm在WinCE下使用一個(gè)潛在的缺陷
CnComm1.5第1700行 函數(shù): virtual bool SetupPort()
原有代碼:

    virtual bool SetupPort()
    {
        
if(!CN_ASSERT(IsOpen()))
            
return false;

        
if(!CN_ASSERT(::SetupComm(hComm_, 4096, 4096)))//! 配置端口發(fā)送接收隊(duì)列大小, 讀4096字節(jié), 寫4096字節(jié), 阻塞I/O模式發(fā)送隊(duì)列無意義
            return false
; //此處有些硬件不支持
        
        
if(!CN_ASSERT(::GetCommTimeouts(hComm_, &CO_)))
            
return false;

        CO_.ReadIntervalTimeout            
= 100;//! 配置超時(shí)結(jié)構(gòu) 字符最小間隔100ms
        CO_.ReadTotalTimeoutMultiplier    = 0;
        CO_.ReadTotalTimeoutConstant    
= IsOverlappedMode() ? 500 : 250;//! 讀超時(shí) 重疊I/O模式下500毫秒 阻塞I/O模式下250毫秒
        CO_.WriteTotalTimeoutMultiplier = IsOverlappedMode() ? 1 : 0;
        CO_.WriteTotalTimeoutConstant    
= IsOverlappedMode() ? 10000 : 250;//! 寫超時(shí) 重疊I/O模式下(10000+1×字節(jié)數(shù))毫秒 阻塞I/O模式下250毫秒

        
if(!CN_ASSERT(::SetCommTimeouts(hComm_, &CO_)))
            
return false
        
        
if(!CN_ASSERT(::PurgeComm(hComm_, PURGE_TXABORT | PURGE_RXABORT | PURGE_TXCLEAR | PURGE_RXCLEAR )))//! 清除端口
            return false
        
        
return true;
    } 

將該函數(shù)修正如下:
    virtual bool SetupPort()
    {
        
if(!CN_ASSERT(IsOpen()))
            
return false;

    
#if defined(CN_COMM_FOR_CE)
        ::SetupComm(hComm_, 4096, 4096);
    #else
        if(!CN_ASSERT(::SetupComm(hComm_, 4096, 4096)))//! 配置端口發(fā)送接收隊(duì)列大小, 讀4096字節(jié), 寫4096字節(jié), 阻塞I/O模式發(fā)送隊(duì)列無意義
        return false; 
    #endif

        
        
if(!CN_ASSERT(::GetCommTimeouts(hComm_, &CO_)))
            
return false;

        CO_.ReadIntervalTimeout            
= 100;//! 配置超時(shí)結(jié)構(gòu) 字符最小間隔100ms
        CO_.ReadTotalTimeoutMultiplier    = 0;
        CO_.ReadTotalTimeoutConstant    
= IsOverlappedMode() ? 500 : 250;//! 讀超時(shí) 重疊I/O模式下500毫秒 阻塞I/O模式下250毫秒
        CO_.WriteTotalTimeoutMultiplier = IsOverlappedMode() ? 1 : 0;
        CO_.WriteTotalTimeoutConstant    
= IsOverlappedMode() ? 10000 : 250;//! 寫超時(shí) 重疊I/O模式下(10000+1×字節(jié)數(shù))毫秒 阻塞I/O模式下250毫秒

        
if(!CN_ASSERT(::SetCommTimeouts(hComm_, &CO_)))
            
return false
        
        
if(!CN_ASSERT(::PurgeComm(hComm_, PURGE_TXABORT | PURGE_RXABORT | PURGE_TXCLEAR | PURGE_RXCLEAR )))//! 清除端口
            return false
        
        
return true;
    } 

 3 、2009-5-18 根據(jù)網(wǎng)友騰空的提示,發(fā)現(xiàn)一個(gè)關(guān)于內(nèi)置緩沖區(qū)的BUG
CnComm1.5第1726行 函數(shù): DWORD PortToBuffer(DWORD dwPortByteNum)
原有代碼:

//! 將端口數(shù)據(jù)讀入緩沖區(qū)的
    DWORD PortToBuffer(DWORD dwPortByteNum)
    {
        
return dwPortByteNum ? I_.Release(ReadPort(I_.GetFreePtr(dwPortByteNum), dwPortByteNum)) : 0;
    }

將該函數(shù)修正如下:

    //! 將端口數(shù)據(jù)讀入緩沖區(qū)的
    DWORD PortToBuffer(DWORD dwPortByteNum)
    {
        BlockBuffer::InnerLock locker(&I_);
        return dwPortByteNum ? I_.Release(ReadPort(I_.GetFreePtr(dwPortByteNum), dwPortByteNum)) : 0;
    }

 4、2009-6-11 根據(jù)網(wǎng)友deke_chen的提示,修改兩個(gè)BUG
CnComm1.5 第487行 wchar_t * ReadString(wchar_t *szBuffer, DWORD dwLength, DWORD dwWaitTime = INFINITE)
原有代碼:

    //! 讀取串口 dwLength - 1 個(gè)UNICODE字符到 szBuffer 返回 C 模式字符串指針 適合一般字符通訊
    wchar_t * ReadString(wchar_t *szBuffer, DWORD dwLength, DWORD dwWaitTime = INFINITE)
    {
        CN_ASSERT(szBuffer);
        szBuffer[Read(szBuffer, dwLength - 1, dwWaitTime)] = L'\0';
        return szBuffer;
    }

將該函數(shù)修正如下:

    //! 讀取串口 dwLength - 1 個(gè)UNICODE字符到 szBuffer 返回 C 模式字符串指針 適合一般字符通訊
    wchar_t * ReadString(wchar_t *szBuffer, DWORD dwLength, DWORD dwWaitTime = INFINITE)
    {
        CN_ASSERT(szBuffer);
        szBuffer[(Read(szBuffer, (dwLength - 1)*sizeof(wchar_t), dwWaitTime) +1)/ sizeof(wchar_t)] = L'\0';
        return szBuffer;
    }

注:不推薦使用UNICODE字符串通訊,因?yàn)榇谑亲址ㄓ崳?span style="COLOR: #ff0000">不能保障2個(gè)字節(jié)的UNICODE字符一次性被接收到

CnComm1.5 第1307行 wchar_t* ReadString(wchar_t* lpBuf, DWORD dMaxSize)
原有代碼:

        //! 讀入U(xiǎn)NICODE字符串緩沖區(qū)
        wchar_t* ReadString(wchar_t* lpBuf, DWORD dMaxSize)
        {
            lpBuf[Read(lpBuf, dMaxSize)] = L'\0';
            return lpBuf;
        }

 將該函數(shù)修正如下:

        //! 讀入U(xiǎn)NICODE字符串緩沖區(qū)
        wchar_t* ReadString(wchar_t* lpBuf, DWORD dMaxSize)
        {
            lpBuf[(Read(lpBuf, dMaxSize*sizeof(wchar_t))+1) / sizeof(wchar_t)] = L'\0';
            return lpBuf;
        }

CnComm1.5 第1331行 void Clear(bool bDeleteAll = false)
原有代碼:

        //! 清除 \param bDeleteAll 為true時(shí)釋放所有內(nèi)存, 否則保留一個(gè)內(nèi)存塊以提高效率
        void Clear(bool bDeleteAll = false)
        {
            if (F_ && (F_==L_) && F_->S_>(M_<<2))
                memset(F_, 0, sizeof(Block));
            else
            {
                for (Block* t = F_;  t; delete  F_)
                    F_ = t, t = t->N_;

                F_ = L_ = NULL, S_ = 0;
            }
        }

 將該函數(shù)修正如下:

        //! 清除 \param bDeleteAll 為true時(shí)釋放所有內(nèi)存, 否則保留一個(gè)內(nèi)存塊以提高效率
        void Clear(bool bDeleteAll = false)
        {
            if (F_ && (F_==L_) && F_->S_>(M_<<2))
            {
                DWORD S = F_->S_;
                memset(F_, 0, sizeof(Block)), F_->S_ = S;
            }
            else
            {
                for (Block* t = F_;  t; delete  F_)
                    F_ = t, t = t->N_;

                F_ = L_ = NULL, S_ = 0;
            }
        }


 

Faq

1、用CnComm寫的程序發(fā)送不正常,但用其他程序打開端口后,再用CnComm寫的程序就好了?
分析:
具體原因是配置參數(shù)失敗。并且該網(wǎng)友沒有檢查Open()或者SetState()的返回值, 所以沒有發(fā)現(xiàn)配置參數(shù)失敗造成的。

比如設(shè)置波特率"9600,O,7,1",不小心把配置字符串寫成了"9600,7,O,1"。
使用CnComm配置后失敗,并沒有檢查返回值,發(fā)送數(shù)據(jù)就會(huì)是亂碼,或者不能正確接收。
這時(shí)很自然的,你會(huì)用其他工具程序打開端口,由于有可視界面,打開參數(shù)正確,又能正常發(fā)送。
然后你又想用CnComm再打開試試,結(jié)果發(fā)現(xiàn)又行了。
實(shí)際上配置串口失敗,會(huì)采用上一次正確配置,所以看上去正常了,實(shí)際上單獨(dú)運(yùn)行就不行了。

這和我的筆誤,即有一回把"9600,N,8,1"誤寫成了"9600,8,N,1",客觀上造成去多網(wǎng)友照搬出錯(cuò),對于這一部分網(wǎng)友,真誠表示歉意。
不過我還有看到更夸張的寫法,但部分網(wǎng)友不檢查返回值,是一個(gè)很不好的現(xiàn)象。
if (!Com.Open(19600)) 
    assert(
0);

if (!Com.Open(1"9600,N,8,1")) 
    assert(
0);
最起碼也要像上面這樣寫,當(dāng)然這只是舉例,實(shí)際應(yīng)用應(yīng)該更嚴(yán)謹(jǐn)才對。
另外在CnComm1.5版本以后打開和配置出錯(cuò),調(diào)試版中都會(huì)產(chǎn)生錯(cuò)誤提示,即便是你不檢查返回值。

CnComm配置字符串的標(biāo)準(zhǔn)寫法:

"BBBB,P,D,S" BBBB 為波特率,P 為奇偶校驗(yàn),D 為數(shù)據(jù)位數(shù),S 為停止位數(shù)。
 
合法的奇偶校驗(yàn)值:
E  偶數(shù) (Even)
M  標(biāo)記 (Mark)
N  缺省 (Default)
None   
O 奇數(shù) (Odd)
S 空格 (Space) 
合法的數(shù)據(jù)位:
4
5
6
7
8 (缺省)
合法的停止位值:
1  (缺省)
1.5   
2  

2、發(fā)送10個(gè)字節(jié)數(shù)據(jù),每次都分成兩部分,比如"0123456789", 被分成"01234"和"56789", 能不能一次讀取10個(gè)字節(jié)?
分析:這是個(gè)通訊的基本問題。
由于是10個(gè)字節(jié),你才會(huì)問這個(gè)問題,如果是1百萬個(gè)字節(jié),你就不會(huì)這樣問我了。
你肯定不敢開口要求一次性接受1百萬個(gè)字節(jié)。
通訊歸根結(jié)底是看似連續(xù),實(shí)則斷續(xù)。
在CnComm1.5已經(jīng)針對這個(gè)問題作了修改,對于百千個(gè)字節(jié)可以做到連續(xù)一次性接受
CnComm1.3可以采用Read(buf, 1000, false);
最好升級到CnComm1.5。這里參見我在CSDN博客中接收處理兩種用法
最規(guī)范的做法,是利用緩沖區(qū)緩存數(shù)據(jù),然后再做處理。

3、調(diào)用發(fā)送語句后,馬上關(guān)閉串口,常常數(shù)據(jù)發(fā)不出。
分析:如果你采用重疊IO方式即CnComm默認(rèn)方式打開串口,發(fā)送數(shù)據(jù)并不是在Write語句調(diào)用后馬上發(fā)生,而是系統(tǒng)在后臺(tái)幫你發(fā)送。
而你立即調(diào)用關(guān)閉,關(guān)閉里有清空隊(duì)列的代碼,就沒有系統(tǒng)運(yùn)行的機(jī)會(huì)。
解決辦法:同步IO,不存在這個(gè)問題。

使用重疊IO,在CnComm1.5 ,可以按如下做法
   
    CnComm com;
    com.Open(
1);
    com.Write(
"test");
    com.Flush();
    com.Close();


 

 

posted on 2009-05-15 09:56 llbird 閱讀(10474) 評論(45)  編輯 收藏 引用

評論

# 錯(cuò)誤 2009-05-15 22:39 張冬冬

修正的第一個(gè)錯(cuò)誤:“
memcpy(NewBlock(dwSize)->P_, lpBuf + dwCopy, dwTemp);//該處原代碼未作偏移值修正,由于緩沖區(qū)一般較大,這一塊在測試中忽略了”

這塊在調(diào)試中出現(xiàn)錯(cuò)誤:
錯(cuò)誤 7 error C2036: 'LPCVOID' :

還有Comm_.Write(buffer); 怎么不返回寫入的數(shù)字呢?
我是新手 請指教。

還有寫的很好,以后要好好研究
  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2009-05-15 22:52 llbird

memcpy(NewBlock(dwSize)->P_, ((LPBYTE)lpBuf) + dwCopy, dwTemp);//

這里忘記把const屬性去掉  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2009-05-15 22:57 llbird

Comm_.Write(buffer);
不返回發(fā)送數(shù)量是因?yàn)橹丿BIO的作用。
系統(tǒng)將在后臺(tái)幫你把數(shù)據(jù)發(fā)送出去,由于串口是低速設(shè)備,如果你要等待返回發(fā)送數(shù)量將浪費(fèi)系統(tǒng)資源,所以函數(shù)直接返回,以便你繼續(xù)操作,這樣并行操作,提高系統(tǒng)利用率  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2009-05-16 08:05 張冬冬

奧 看來我對串口的工作機(jī)制及C++語言規(guī)范還不是太懂,
謝謝回復(fù),會(huì)努力的。  回復(fù)  更多評論   

# evc關(guān)于模擬器的環(huán)境搭建咨詢 2009-05-30 08:27 hanliang

目前我手上搭建了wince 5.0模擬器的環(huán)境,但是無法測試通過.想確定一下你手上是如何搭建的模擬器環(huán)境.謝謝.我的郵箱是:hanliang516@126.com  回復(fù)  更多評論   

# 接受速度稍微有點(diǎn)慢,不知道是我用法不對還是怎么? 2009-05-30 12:23 張?zhí)旌?/a>

您好,看到這個(gè)串口類感覺很強(qiáng)大,多些作者開源,但是有個(gè)問題是我在應(yīng)用中感覺速度稍微慢,不知道是不是我應(yīng)用方式不對?請指教.
我的應(yīng)用介紹:開發(fā)一個(gè)讀卡器的dll類庫。實(shí)現(xiàn)發(fā)送命令。
我的做法是這樣:
------1、定義兩個(gè)全局變量,一個(gè)是長度一個(gè)是接收到的Buff如下
//-----------全局變量
char buffReceived[255];
int intReceived;

------2、繼承類:
class ClientComm : public CnComm
{
public:
//! 配置CnComm 監(jiān)視線程 重疊IO 雙緩沖區(qū)
ClientComm() //: CnComm(EN_THREAD | EN_TX_BUFFER | EN_RX_BUFFER | EN_OVERLAPPED)
{
hEvent_ = CreateEvent(NULL, TRUE, FALSE, NULL);
}
//!
virtual ~ClientComm()
{
CloseHandle(hEvent_);
}
//! 接收命令響應(yīng)信息 \sa CnComm::OnReceive()
void OnReceive()
{
char buffer[1024];
int len;
len = Read(buffer, 1024);
for (int i = 0; i<len ; i++)
{
buffReceived[intReceived] = buffer[i];
intReceived++;
}

}
//! 等待命令響應(yīng)


protected:
HANDLE hEvent_; //!< 等待輸入事件

};

------3、 處理事件

bool SendCmdIn()
{
char pSendBuf[10];
Comm_.Write(pSendBuf,5);//發(fā)送數(shù)據(jù)
//處理監(jiān)控得到的數(shù)據(jù)

while(1)
{
Sleep(1); //暫停1毫秒
if(intReceived==1 && (BYTE)buffReceived[0]== 0x01)
{
return true;
}
}

}  
回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新)[未登錄] 2009-05-30 13:16 llbird

C++寫的類,當(dāng)然性能是正常的。俺這么多年從來就沒有聽說性能問題。
什么叫慢?你的代碼片段不足以讓人了解你要做什么,如何測試,DLL和主模塊如何搭配,業(yè)務(wù)的東西你要自己做的,我不對業(yè)務(wù)做咨詢。
你如果能夠準(zhǔn)確明了的描述問題和想法,我有時(shí)間還是會(huì)做解答,但不承諾。
只對CnComm本身問題做咨詢。

注意超時(shí)控制,如果你想要接收到數(shù)據(jù)再返回,
要用精確控制。
比如14個(gè)字節(jié)的應(yīng)答包

void OnReceive()
{
for (1..14)
Read(&c, 1);//一個(gè)字節(jié)一個(gè)字節(jié)讀

或者Read(&c, 14);//直接控制恰當(dāng)?shù)淖止?jié)數(shù),而不是一味的用1024
或則Read函數(shù)會(huì)一直等到1024個(gè)字節(jié),但實(shí)際上它等不到,因?yàn)楦静豢赡軕?yīng)答1024字節(jié),它就會(huì)等個(gè)幾百毫秒超時(shí)了在返回,可能這就是你說的慢,不知道我的理解真不正確?

另外你的模式有問題,
while(1)
{
Sleep(1); //暫停1毫秒
if(intReceived==1 && (BYTE)buffReceived[0]== 0x01)
{
return true;
}
}
不應(yīng)該這樣用你可以用通知方式會(huì)更理想,循環(huán)很浪費(fèi)CPU,直接WaitEvent更好一些
}


  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2009-05-30 17:36 張?zhí)旌?/a>

謝謝回復(fù),我測試了一下確實(shí)是Read(&c, 1024);的問題,,不過還是把全部代碼發(fā)出來供llbird 及大家查看,可能這個(gè)問題初學(xué)者都能遇到吧,希望大家有時(shí)間給指點(diǎn)一下。
//======實(shí)現(xiàn)功能:向串口發(fā)送pSendBuf1,期望返回長度為1,當(dāng)返回為0x01時(shí),繼續(xù)發(fā)送pSendBuf2,否則退出,發(fā)送pSendBuf2 ,期望返回長度為2,返回char[0] = 0x01 并且char[1] =0x02 時(shí)成功否則失敗。
//========實(shí)現(xiàn)代碼

//-----------全局變量定義接受字符串和長度
char buffReceived[255];
int intReceived;

//! 執(zhí)行結(jié)果: 協(xié)議 ASCII(0~N)+0x3
class ClientComm : public CnComm
{
public:
//! 配置CnComm 監(jiān)視線程 重疊IO 雙緩沖區(qū)
ClientComm() //: CnComm(EN_THREAD | EN_TX_BUFFER | EN_RX_BUFFER | EN_OVERLAPPED)
{
hEvent_ = CreateEvent(NULL, TRUE, FALSE, NULL);
}
//!
virtual ~ClientComm()
{
CloseHandle(hEvent_);
}
//! 接收命令響應(yīng)信息 \sa CnComm::OnReceive()
void OnReceive()
{
char buffer[1];
int len;
len = Read(buffer, 1);
for (int i = 0; i<len ; i++)
{
buffReceived[intReceived] = buffer[i];
intReceived++;
}

}

//! 等待命令響應(yīng)
bool WaitReturn(DWORD dwWaitTime = 100)
{
return WaitForSingleObject(hEvent_, dwWaitTime) == WAIT_OBJECT_0;
}



protected:
HANDLE hEvent_; //!< 等待輸入事件

};

ClientComm Comm_;
ClientComm::BlockBuffer Rx_;



bool SendCmdIn() //
{
char pSendBuf1[5];
pSendBuf1[0]=80;
pSendBuf1[1]=01;
pSendBuf1[2]=00;//
pSendBuf1[3]=00;
pSendBuf1[4]=00;
intReceived =0;//初始化計(jì)數(shù)器
dwBytesWritten=Comm_.Write(pSendBuf1,5);//發(fā)送 pSendBuf1 期望返回長度為1 數(shù)據(jù)位 0x01
while(1)
{
Sleep(1); //暫停1毫秒
//應(yīng)答成功
if(intReceived==1 && (BYTE)buffReceived[0]== 0x01 )
{
break;//成功 退出
}
////應(yīng)答失敗
else if (intReceived>1)//
{
return false;//返回
}
}

char pSendBuf2[5];
pSendBuf2[0]=80;
pSendBuf2[1]=01;
pSendBuf2[2]=02;//
pSendBuf2[3]=00;
pSendBuf2[4]=00;
intReceived =0;//初始化計(jì)數(shù)器
dwBytesWritten=Comm_.Write(pSendBuf2,5);//發(fā)送 pSendBuf2 期望返回長度為2 數(shù)據(jù)位 0x01 0x02

while(1)
{
Sleep(1); //暫停1毫秒
//應(yīng)答成功
if(intReceived==2 && buffReceived[0]== 0x01&&buffReceived[1]== 0x02 )
{
break;//成功 退出
}
////應(yīng)答失敗
else if (intReceived>1)//
{
return false;//返回
}
}
return true;

}

  
回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2009-07-20 20:01 scaler

剛下了v1.5的,用了下發(fā)現(xiàn)當(dāng)接收連續(xù)的字符時(shí),當(dāng)中間包含有0x00 的數(shù)據(jù)時(shí),會(huì)丟掉后面的數(shù)據(jù)  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新)[未登錄] 2009-07-20 20:46 llbird

當(dāng)中間包含有0x00 的數(shù)據(jù)時(shí)不可以使用ReadString
應(yīng)使用Read  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2009-10-19 17:10 tianyu2467

你好!我用你你給的vc6的例子用2008編譯后,當(dāng)接收數(shù)據(jù)時(shí)出現(xiàn)藍(lán)屏(2005的例子收不到數(shù)據(jù)).
然后我自己根據(jù)你網(wǎng)上的帖子寫,用ReadString()讀數(shù)據(jù)仍然藍(lán)屏.這是怎么回事?  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2009-10-19 17:11 tianyu2467

補(bǔ)充一點(diǎn)1.3的類沒有問題,可發(fā)可收.  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新)[未登錄] 2009-10-21 22:59 llbird

例子是有BUG的,必須用1.51的版本,或者按照本文的進(jìn)行修正。  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2010-02-23 11:55 liqs99

請問一下,什么是讀反沖啊。
我的程序過一段時(shí)間總是在423行這里出問題
while (!CN_ASSERT(::GetOverlappedResult(hComm_, &RO_, &dwReadResult, TRUE)))
;  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2010-03-24 14:36 xihuwuyu

我拿來主義了!非常感謝!  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2010-03-26 14:30 xihuwuyu

bird老大,我可以直接#include CnComm.h嗎?為什么引用后會(huì)編譯通不過?f:\design\gms09\cncomm.h(1053) : error C2629: unexpected 'struct CnComm::BlockBuffer::Iterator ('
f:\design\gms09\cncomm.h(1053) : error C2334: unexpected token(s) preceding ':'; skipping apparent function body
可以指教下嗎?俺太菜了!  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新)[未登錄] 2010-04-21 15:16 John

你好,之前用LsComm寫了幾天,都處理不好,后來找到您這個(gè)CnComm類,中文注釋相當(dāng)親切,代碼也友好。就準(zhǔn)備寫一個(gè)接收程序,可是一接收就藍(lán)屏啊。(我用的是SerialNull虛擬串口生成一對串口COM3和COM4在本機(jī)上調(diào)試),CNCOMM單獨(dú)發(fā)送沒有問題,我用WINDOWS自帶的終端開兩個(gè)串口相互收發(fā)也沒有問題,就是CNCOMM一接收馬上藍(lán)屏:報(bào) stop:0x000000d1。
我調(diào)了一下,藍(lán)屏的代碼大概在:
ReadPort這個(gè)函數(shù)的
if (!::ReadFile(hComm_,pBuffer,dwLength,&dwReadResult,&R0_))
這里。實(shí)在是沒招了啊,請大大指點(diǎn)。  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新)[未登錄] 2011-01-18 10:03 tom

采用16進(jìn)制傳輸?shù)臅r(shí)候,解包成ascii A0變成20???B0變成30?  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新)[未登錄] 2011-01-26 11:09 bird

llbird,OverlappedModel的邏輯不是很清晰,不像Remon Spekreijse的CSerialPort那么容易理解,你覺得呢?比如dwMask = 0以及dwMask = EV_RXCHAR的處理就不是很好。  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新)[未登錄] 2011-02-26 14:36 llbird

抱歉,那段代碼是支持WINCE,他的代碼是只支持WINDOWS的@bird
  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2011-03-11 21:46 sg

健哥,你還有關(guān)注這個(gè)類啊!真可惜你轉(zhuǎn)行了@llbird
  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2011-07-27 14:25 1111

@llbird 使用READ依然不能接收0x00。。接收后后面數(shù)據(jù)丟失
  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新)[未登錄] 2011-07-28 21:00 llbird

多檢查一下程序吧,這個(gè)類用了很久了,酒精考驗(yàn)了,類似Read、Write之類的就不用問了,肯定沒問題的。  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2011-08-31 16:43 zjs

我想請教一個(gè)問題,我在OnReceive()中接收數(shù)據(jù)后在在哪個(gè)函數(shù)里處理這些數(shù)據(jù)?
void OnReceive()

接收函數(shù)...
處理數(shù)據(jù)...

我在OnReceive()里處理數(shù)據(jù)時(shí)為什么處理數(shù)據(jù)的函數(shù)執(zhí)行不了  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2011-09-23 16:51 CnComm學(xué)習(xí)

發(fā)送十六進(jìn)制 80 00
收到的是00 00
調(diào)試跟蹤,發(fā)現(xiàn)進(jìn)了
//! 響應(yīng)EV_BREAK事件
virtual void OnBreak()
{
ClearCommBreak(hComm_);
Notify(ON_COM_BREAK);
}
我如果注釋掉ClearCommBreak這句,則可以收到80 00了。
用作者的VC6的那個(gè)串口通訊工具測試,發(fā)送十六進(jìn)制的80 00 后,彈出一個(gè)窗口“COM4 be placed in a break state.”。

我想知道進(jìn)入OnBreak,這是一個(gè)什么情況?這個(gè)處理是做什么的?
像我要正常收到80 00,是不是需要進(jìn)行其它配置?
我是在C++Builder2010下使用的,現(xiàn)在就調(diào)用了:
g_Comm->Open(4);
BYTE data[]={0x80,0x00};
g_Comm->Write(data,sizeof(data)/sizeof(data[0]));
然后就是添加LRESULT __fastcall TForm1::OnReceive(TMessage &msg)。
  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2011-12-17 15:17 Daywei

請教一個(gè)問題 如果 我每次發(fā)固定的字節(jié)數(shù) 比如8字節(jié),有兩種情況 第一種 我每隔一段時(shí)間發(fā)一次,共發(fā)五次,第二種 我在瞬間 比如 0.1毫秒內(nèi)發(fā)了 五次,他們的接收過程是否相同,我個(gè)人測試發(fā)現(xiàn) read可能一下讀了 16個(gè)字節(jié),而剩下的就按照發(fā)一次多少字節(jié)就接收多少字節(jié),也就是說兩者接收到的數(shù)據(jù)相同但接收的過程卻不一致,尤其第二種不穩(wěn)定,請教這是什么原因  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2011-12-26 23:21 Doug

今天拿來測了下...因?yàn)橹恍枰邮障挛粰C(jī)傳上來的數(shù)據(jù)...所以只使用了類里的onRecieve函數(shù)...我的波特率是156250的...所以才會(huì)找上llbird你的這個(gè)類哈...
接收有些許問題...有丟字節(jié)的情況出現(xiàn)...自己調(diào)用的程序有這種情況...用回你原來1.5版本的測試程序也有同樣的情況...嘗試更改傳輸?shù)淖止?jié)數(shù)...同樣出現(xiàn)丟字節(jié)的情況...
盡量幫你再多測幾次看看是為什么吧...
有情況再上來跟你反映...嘿嘿...  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2012-01-13 14:33 Doug

總算把事情搞完了,寫總結(jié)時(shí)還提到這個(gè)問題,現(xiàn)在過來澄清一下,其實(shí)從Debug中的數(shù)據(jù)來看,在內(nèi)存?zhèn)魉椭?由於LZ的示例程序中Ascii2Hex這個(gè)函數(shù)裡,在接收到0x00這個(gè)字節(jié)時(shí)(由於我是把低層的地址傳上來,所以會(huì)存在這個(gè)字節(jié)),程序會(huì)把其認(rèn)為是該字符串的結(jié)束符'\0',於是便會(huì)丟失數(shù)據(jù).
再者,當(dāng)把m_Rx接收到的字符串用StaticEdit來顯示時(shí),會(huì)出現(xiàn)有多餘的兩個(gè)字節(jié)(是無意義的),後來在調(diào)試時(shí),發(fā)現(xiàn)內(nèi)部傳輸是沒問題的,只是在顯示出來時(shí)卻多了兩個(gè)字節(jié),但是在接下來更新的字符串上來時(shí)又會(huì)把這多餘的兩個(gè)字節(jié)都覆蓋掉,原以為是String在接收顯示完畢後沒有及時(shí)被清空,後來發(fā)現(xiàn)清空後還是出現(xiàn)同樣的情況,卻又一直沒法找到,礙於時(shí)間,便不再追求.若有其它人尋找到原因及解決方法,方便的話請順便郵件於我.huangxiaodon@sohu.com謝謝.  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2012-02-01 10:43 dwwzl

if (msg.WParam == Comm_.GetPort())
行總是出現(xiàn)警告:
W8012 Comparing signed and unsigned values
如何修正呢?  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2012-03-16 16:46 文俊

在調(diào)試的時(shí)候向設(shè)備發(fā)送命令沒有一點(diǎn)反應(yīng),不知道我這種調(diào)用是不是有問題,請指點(diǎn),謝謝!

CnComm Com;
CnComm::BlockBuffer bb;

if (!Com.Open(1, "9600,N,8,1"))
{
assert(0);
}
char buf[1024] = {0};
Com.WritePort("*CLS",25);
Com.WritePort("*RST",25);
Com.WritePort("SYST:LOC",25);
Com.WritePort("SYST:REM",25);
Com.WritePort("MEAS:RES? DEF,DEF",25);
Com.ReadString(buf,25,500);
//上面的這些命令沒有一點(diǎn)反應(yīng) ,但在MSCOMM測試的時(shí)候是正常的,只是不知道為什么使用MSCOMM的時(shí)候,不能在我需要的時(shí)候得到返回值。還請大師指點(diǎn)。謝謝!
bb.Write("MEAS:RES? DEF,DEF",20);//寫入20個(gè)字節(jié)
bb.Read(buf, 20);//讀出20個(gè)字節(jié) 并返回實(shí)際讀出數(shù)

bb.Clear();//清空
我的郵箱:jonesvale@live.cn,請指點(diǎn),謝謝!  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新)[未登錄] 2012-04-01 13:53 kkk

cn_assert(isopen()failed;cncomm(909)  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2012-05-02 10:18 syrchina

連續(xù)兩個(gè)Com.Write()
只接收到第一個(gè)的數(shù)據(jù),
第二個(gè)沒收到,
Why?
請指點(diǎn)  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2012-09-21 08:44 huaqping

謝謝 llbird,有這個(gè)更新 CnComm就好用了。  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2012-09-25 09:09 huaqping

llbird,這幾天用CnComm在VC下寫了個(gè)測試工具,發(fā)現(xiàn)一個(gè)問題用Comm_.Read(szComSendBuf, 1);時(shí)若緩沖區(qū)有兩個(gè)數(shù)據(jù),有時(shí)只能接受到的是第二個(gè)數(shù)據(jù),第一個(gè)就丟掉了。請問有沒有取接受緩沖區(qū)數(shù)據(jù)量的函數(shù)?  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2013-01-15 18:14 恨鐵不成鋼

曾經(jīng)瘋狂而執(zhí)著的健哥終于甩手了哦……
中國編程界一大損失  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2013-03-14 13:26 ajia

這個(gè)類最高支持多少的通訊速率 為什么超過115200就不行了  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2013-03-26 18:35 Karsion

說接收速度慢的朋友,檢查一下有沒有預(yù)定義WIN32,沒有的話會(huì)用WINCE模式打開,默認(rèn)阻塞IO,win32的可以在打開前調(diào)用 this->SetOption(EN_THREAD | EN_OVERLAPPED);
設(shè)置重疊IO(OVERLAPPED這個(gè))  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2013-06-06 23:21 mzcc

前輩好,您寫的CnComm實(shí)在是非常的好用。
我想問一下,CnComm的接收緩沖區(qū)會(huì)溢出么?
我在xp下運(yùn)用CnComm快速的接收數(shù)據(jù),估計(jì)10ms接收一次13byte,用的是625000波特率。在連續(xù)10分鐘左右,則會(huì)出現(xiàn)電腦死機(jī)的情況,您看這會(huì)是緩沖區(qū)溢出的原因么?  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2013-10-10 09:45 12345

1234  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2013-10-10 09:47 12345

@Doug
這個(gè)是庫函數(shù)strlen的問題,它會(huì)將0x00作為字串的終止符, 只能自己寫一個(gè)strlen,
這個(gè)也不會(huì)太困難, 至于多出的2個(gè)字符, 還是在asciitohex函數(shù)中, 最后一句,
有加入"\0"  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2013-10-11 12:02 12345

請教博主:
如何最大限度提升cncomm的發(fā)送速度?

我遇到的問題是: 假設(shè)用通用com工具做發(fā)送, cncomm做接收, 假定速率為10kbytes/s, 這時(shí)用cncomm發(fā)送, cncomm接收(對傳), 速率只有5kbytes/s  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2013-12-12 20:07 賣鋼材不如賣礦泉水

空前絕后,后無來者啊。
除了llbird還真沒有繼承人了了  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2014-02-26 14:05 聽楓2005

cnComm類中沒有提供清空發(fā)送緩存區(qū)和接收緩存區(qū)的接口.如果上一次返回的數(shù)據(jù)在接收緩存區(qū)內(nèi)由于某些原因沒有被處理,則下一次接收數(shù)據(jù)時(shí)會(huì)將上一次的數(shù)據(jù)也一起讀取出來,在某些特定環(huán)境下,這可能會(huì)導(dǎo)致致命錯(cuò)誤.所以應(yīng)該提供兩個(gè)接口讓用戶自主選擇.  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2014-03-24 16:39 夢游鯊魚

void Clear(bool bDeleteAll = false)
{
if (F_ && (F_==L_) && F_->S_>(M_<<2))
{
DWORD S = F_->S_;
memset(F_, 0, sizeof(Block)), F_->S_ = S;
}
else
{
for (Block* t = F_; t; delete F_)
F_ = t, t = t->N_;

F_ = L_ = NULL, S_ = 0;
}
}


這個(gè)代碼有錯(cuò),bDeleteAll 根本就沒有被使用,并且就是在if分句中也沒有S_ = 0;  回復(fù)  更多評論   

# re: CnComm勘誤及Faq(將會(huì)持續(xù)更新) 2014-03-24 16:51 夢游鯊魚

在BlockBuffer析構(gòu)時(shí),buffer的內(nèi)存沒有被釋放  回復(fù)  更多評論   

<2025年9月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

導(dǎo)航

統(tǒng)計(jì)

常用鏈接

留言簿(8)

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            欧美喷潮久久久xxxxx| 日韩一区二区精品葵司在线| 亚洲综合色激情五月| 国产精品九九久久久久久久| 亚洲一区久久| 午夜视频一区二区| 精品动漫一区二区| 亚洲国产精彩中文乱码av在线播放| 久久久久久久一区二区三区| 亚洲二区视频| 亚洲毛片在线观看.| 欧美高清hd18日本| 久热精品在线| 欧美成人午夜激情| 亚洲一品av免费观看| 亚洲综合视频1区| 136国产福利精品导航网址应用| 亚洲成人在线视频播放| 蜜桃av综合| 亚洲欧美大片| 久久最新视频| 亚洲香蕉成视频在线观看| 午夜视频一区二区| 99精品国产在热久久婷婷| 正在播放日韩| 亚洲精品一区中文| 午夜在线a亚洲v天堂网2018| 91久久久亚洲精品| 欧美在线视频一区| 在线亚洲一区| 久色成人在线| 午夜视频久久久久久| 久久综合成人精品亚洲另类欧美| 中文精品99久久国产香蕉| 久久国产精品久久久久久久久久| 一本大道av伊人久久综合| 欧美在线一级视频| 亚洲男人av电影| 欧美激情va永久在线播放| 免费观看成人| 国产视频一区免费看| 亚洲精品欧美一区二区三区| 悠悠资源网久久精品| 亚洲欧美一区二区激情| 一个色综合导航| 欧美a级大片| 免费观看日韩| 伊甸园精品99久久久久久| 亚洲欧美中日韩| 亚洲欧美日韩综合| 欧美日韩国产小视频在线观看| 麻豆精品91| 伊人春色精品| 久久亚洲欧美| 久久久久久9| 国产一区二区在线观看免费| 亚洲午夜极品| 亚洲在线观看视频网站| 欧美三级免费| 亚洲伦伦在线| 亚洲婷婷国产精品电影人久久 | 亚洲一区二区三区免费观看| 欧美jjzz| 91久久精品一区二区三区| 亚洲精华国产欧美| 欧美r片在线| 亚洲韩国精品一区| 日韩视频在线你懂得| 欧美黄在线观看| 一本色道久久综合亚洲精品不| 日韩午夜av在线| 欧美日韩一区不卡| 亚洲一区视频在线观看视频| 亚洲欧美中文另类| 国产亚洲激情| 久久亚洲精品欧美| 亚洲国产专区校园欧美| 欧美一区高清| 欧美午夜电影网| 一本色道久久综合一区| 亚洲综合欧美| 国产视频在线一区二区 | 久久亚洲精品一区二区| 在线观看不卡| 欧美三日本三级三级在线播放| 一本大道久久精品懂色aⅴ| 欧美一级电影久久| 亚洲丁香婷深爱综合| 欧美韩国一区| 亚洲综合视频1区| 农村妇女精品| 亚洲一区视频在线| 韩日午夜在线资源一区二区| 欧美高清视频一二三区| 亚洲午夜小视频| 老司机成人网| 亚洲夜间福利| 在线播放不卡| 国产精品久久久久91| 久久久久国产成人精品亚洲午夜| 亚洲国产精品一区| 欧美一区二区三区在线观看| 亚洲欧洲一区二区天堂久久 | 国内精品久久久久影院色| 久热综合在线亚洲精品| 亚洲午夜一二三区视频| 欧美韩日一区二区| 欧美一区二区成人| 99精品国产在热久久| 国产日韩精品在线观看| 欧美国产一区二区| 欧美中文日韩| 亚洲线精品一区二区三区八戒| 蜜臀av性久久久久蜜臀aⅴ| 亚洲永久在线| 日韩一级精品| 亚洲大片av| 国产在线观看一区| 国产精品久久久久久妇女6080 | 最新国产成人av网站网址麻豆| 国产精品欧美一区喷水| 欧美日韩999| 每日更新成人在线视频| 久久av一区二区| 亚洲一区美女视频在线观看免费| 亚洲第一在线综合网站| 久久字幕精品一区| 久久精品亚洲精品| 先锋影音网一区二区| 亚洲一区三区视频在线观看| 亚洲免费av网站| 亚洲精品人人| 亚洲日本va午夜在线影院| 伊人久久男人天堂| 韩国av一区| 国内精品视频在线播放| 国产婷婷色一区二区三区在线| 国产精品成人在线观看| 欧美日韩国产专区| 欧美日韩成人激情| 欧美日韩国产综合新一区| 欧美国产视频在线| 欧美日韩精品免费在线观看视频| 久久久久久久久一区二区| 亚洲欧洲另类国产综合| 国产精品久久久久久久午夜 | 玖玖玖免费嫩草在线影院一区| 久久成人18免费观看| 欧美一区在线看| 久久久www成人免费无遮挡大片| 午夜精品久久久久久久久久久久久 | 亚洲欧美激情视频| 午夜国产一区| 欧美怡红院视频一区二区三区| 性欧美大战久久久久久久久| 欧美在线观看视频在线| 久久精品中文字幕一区| 免费亚洲视频| 欧美日韩免费高清| 国产伦精品一区二区三区高清| 国产亚洲网站| 亚洲人www| 亚洲免费中文字幕| 久热精品在线视频| 亚洲美女诱惑| 欧美在线视频免费| 欧美激情一区在线| 国产精品自拍小视频| 影音先锋亚洲电影| 99国产精品99久久久久久粉嫩| 亚洲资源av| 久久伊人精品天天| 亚洲久久视频| 久久久久高清| 欧美日韩免费在线观看| 国产亚洲欧美日韩一区二区| 亚洲国产综合视频在线观看| 亚洲一品av免费观看| 免费美女久久99| 一区二区激情小说| 麻豆成人在线| 国产精品日日摸夜夜摸av| 亚洲娇小video精品| 午夜天堂精品久久久久| 欧美国产在线电影| 久久不射中文字幕| 欧美日韩在线看| 激情视频一区二区三区| 亚洲一二三区在线观看| 欧美成人激情在线| 亚洲欧美日韩精品久久久久| 欧美xxx成人| 国语对白精品一区二区| 亚洲欧美日韩一区在线| 91久久精品国产| 久久婷婷丁香| 国产欧美在线| 亚洲尤物在线视频观看| 亚洲韩国精品一区| 免费不卡在线视频|