CnComm勘誤及Faq（將會持續(xù)更新）

勘誤

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

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

原有代碼：

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

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

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

    S_ += dwSize;
    return dwSize;
}

請將該函數(shù)內容修正如下：

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

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

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

    S_ += dwSize;
    return dwSize;
}

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

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

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

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

        CO_.ReadIntervalTimeout            = 100;//! 配置超時結構字符最小間隔100ms
        CO_.ReadTotalTimeoutMultiplier    = 0;
        CO_.ReadTotalTimeoutConstant    = IsOverlappedMode() ? 500 : 250;//! 讀超時重疊I/O模式下500毫秒阻塞I/O模式下250毫秒
        CO_.WriteTotalTimeoutMultiplier = IsOverlappedMode() ? 1 : 0;
        CO_.WriteTotalTimeoutConstant    = IsOverlappedMode() ? 10000 : 250;//! 寫超時重疊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ā)送接收隊列大小, 讀4096字節(jié), 寫4096字節(jié), 阻塞I/O模式發(fā)送隊列無意義
        return false;
    #endif

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

        CO_.ReadIntervalTimeout            = 100;//! 配置超時結構字符最小間隔100ms
        CO_.ReadTotalTimeoutMultiplier    = 0;
        CO_.ReadTotalTimeoutConstant    = IsOverlappedMode() ? 500 : 250;//! 讀超時重疊I/O模式下500毫秒阻塞I/O模式下250毫秒
        CO_.WriteTotalTimeoutMultiplier = IsOverlappedMode() ? 1 : 0;
        CO_.WriteTotalTimeoutConstant    = IsOverlappedMode() ? 10000 : 250;//! 寫超時重疊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 根據網友騰空的提示，發(fā)現(xiàn)一個關于內置緩沖區(qū)的BUG
CnComm1.5第1726行函數(shù)： DWORD PortToBuffer(DWORD dwPortByteNum)
原有代碼：

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

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

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

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

    //! 讀取串口 dwLength - 1 個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 個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字符串通訊，因為串口是字符通訊，不能保障2個字節(jié)的UNICODE字符一次性被接收到。

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

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

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

        //! 讀入UNICODE字符串緩沖區(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時釋放所有內存, 否則保留一個內存塊以提高效率
        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時釋放所有內存, 否則保留一個內存塊以提高效率
        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ù)失敗。并且該網友沒有檢查Open()或者SetState()的返回值, 所以沒有發(fā)現(xiàn)配置參數(shù)失敗造成的。

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

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

if (!Com.Open(1, 9600))
assert(0);

if (!Com.Open(1, "9600,N,8,1"))
assert(0);

最起碼也要像上面這樣寫，當然這只是舉例，實際應用應該更嚴謹才對。
另外在CnComm1.5版本以后打開和配置出錯，調試版中都會產生錯誤提示，即便是你不檢查返回值。

CnComm配置字符串的標準寫法:

"BBBB,P,D,S" BBBB 為波特率，P 為奇偶校驗，D 為數(shù)據位數(shù)，S 為停止位數(shù)。

合法的奇偶校驗值:

E  偶數(shù) (Even)
M  標記 (Mark)
N  缺省 (Default)
None
O 奇數(shù) (Odd)
S 空格 (Space)

合法的數(shù)據位:

4
5
6
7
8 （缺?。?/span>

合法的停止位值:

1 （缺?。?br>1.5
2

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

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

使用重疊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) 編輯收藏引用

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

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

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

還有寫的很好，以后要好好研究
回復更多評論

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

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

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

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

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

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

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

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

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

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

您好，看到這個串口類感覺很強大，多些作者開源，但是有個問題是我在應用中感覺速度稍微慢，不知道是不是我應用方式不對？請指教.
我的應用介紹：開發(fā)一個讀卡器的dll類庫。實現(xiàn)發(fā)送命令。
我的做法是這樣：
------1、定義兩個全局變量，一個是長度一個是接收到的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_);
}
//! 接收命令響應信息 \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++;
}

}
//! 等待命令響應

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

};

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

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

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

} 回復更多評論

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

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

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

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

或者Read(&c, 14);//直接控制恰當?shù)淖止?jié)數(shù)，而不是一味的用1024
或則Read函數(shù)會一直等到1024個字節(jié)，但實際上它等不到，因為根本不可能應答1024字節(jié)，它就會等個幾百毫秒超時了在返回，可能這就是你說的慢，不知道我的理解真不正確？

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

回復更多評論

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

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

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

//! 執(zhí)行結果: 協(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_);
}
//! 接收命令響應信息 \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++;
}

}

//! 等待命令響應
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;//初始化計數(shù)器
dwBytesWritten=Comm_.Write(pSendBuf1,5);//發(fā)送 pSendBuf1 期望返回長度為1 數(shù)據位 0x01
while(1)
{
Sleep(1); //暫停1毫秒
//應答成功
if(intReceived==1 && (BYTE)buffReceived[0]== 0x01 )
{
break;//成功退出
}
////應答失敗
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;//初始化計數(shù)器
dwBytesWritten=Comm_.Write(pSendBuf2,5);//發(fā)送 pSendBuf2 期望返回長度為2 數(shù)據位 0x01 0x02

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

}

回復更多評論

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

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

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

當中間包含有0x00 的數(shù)據時不可以使用ReadString
應使用Read 回復更多評論

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

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

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

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

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

例子是有BUG的，必須用1.51的版本，或者按照本文的進行修正。回復更多評論

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

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

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

我拿來主義了！非常感謝！回復更多評論

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

bird老大，我可以直接#include CnComm.h嗎？為什么引用后會編譯通不過？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
可以指教下嗎？俺太菜了！回復更多評論

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

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

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

采用16進制傳輸?shù)臅r候，解包成ascii A0變成20???B0變成30？回復更多評論

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

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

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

抱歉，那段代碼是支持WINCE，他的代碼是只支持WINDOWS的@bird
回復更多評論

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

健哥，你還有關注這個類啊！真可惜你轉行了@llbird
回復更多評論

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

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

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

多檢查一下程序吧，這個類用了很久了，酒精考驗了，類似Read、Write之類的就不用問了，肯定沒問題的。回復更多評論

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

我想請教一個問題，我在OnReceive()中接收數(shù)據后在在哪個函數(shù)里處理這些數(shù)據？
void OnReceive()
｛
接收函數(shù)...
處理數(shù)據...
｝
我在OnReceive（）里處理數(shù)據時為什么處理數(shù)據的函數(shù)執(zhí)行不了回復更多評論

# re: CnComm勘誤及Faq（將會持續(xù)更新） 2011-09-23 16:51 CnComm學習

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

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

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

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

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

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

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

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

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

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

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

在調試的時候向設備發(fā)送命令沒有一點反應，不知道我這種調用是不是有問題，請指點，謝謝！

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);
//上面的這些命令沒有一點反應，但在MSCOMM測試的時候是正常的，只是不知道為什么使用MSCOMM的時候，不能在我需要的時候得到返回值。還請大師指點。謝謝！
bb.Write("MEAS:RES? DEF,DEF",20);//寫入20個字節(jié)
bb.Read(buf, 20);//讀出20個字節(jié) 并返回實際讀出數(shù)

bb.Clear();//清空
我的郵箱：jonesvale@live.cn，請指點，謝謝！回復更多評論

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

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

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

連續(xù)兩個Com.Write()
只接收到第一個的數(shù)據，
第二個沒收到，
Why？
請指點回復更多評論

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

謝謝 llbird，有這個更新 CnComm就好用了。回復更多評論

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

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

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

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

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

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

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

說接收速度慢的朋友，檢查一下有沒有預定義WIN32，沒有的話會用WINCE模式打開，默認阻塞IO，win32的可以在打開前調用 this->SetOption(EN_THREAD | EN_OVERLAPPED);
設置重疊IO（OVERLAPPED這個）回復更多評論

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

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

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

1234 回復更多評論

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

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

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

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

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

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

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

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

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

# re: CnComm勘誤及Faq（將會持續(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;
}
}

這個代碼有錯，bDeleteAll 根本就沒有被使用，并且就是在if分句中也沒有S_ = 0; 回復更多評論

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

在BlockBuffer析構時，buffer的內存沒有被釋放回復更多評論

刷新評論列表

只有注冊用戶登錄后才能發(fā)表評論。
【推薦】100%開源！大型工業(yè)跨平臺軟件C++源碼提供，建模，組態(tài)！



網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

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

CnComm勘誤及Faq（將會持續(xù)更新）

勘誤

Faq

評論

# 錯誤 2009-05-15 22:39 張冬冬

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# re: CnComm勘誤及Faq（將會持續(xù)更新） 2011-09-23 16:51 CnComm學習

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

導航

統(tǒng)計

常用鏈接

留言簿(8)

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜

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