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

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;
}

 

請(qǐng)將該函數(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ū)一般較大,這一塊在測(cè)試中忽略了
        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ò),對(duì)于這一部分網(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)才對(duì)。
另外在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)針對(duì)這個(gè)問題作了修改,對(duì)于百千個(gè)字節(jié)可以做到連續(xù)一次性接受
CnComm1.3可以采用Read(buf, 1000, false);
最好升級(jí)到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) 評(píng)論(45)  編輯 收藏 引用

評(píng)論

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

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

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

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

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

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

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

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

# 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ù)  更多評(píng)論   

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

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

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

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

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

您好,看到這個(gè)串口類感覺很強(qiáng)大,多些作者開源,但是有個(gè)問題是我在應(yīng)用中感覺速度稍微慢,不知道是不是我應(yīng)用方式不對(duì)?請(qǐ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ù)  更多評(píng)論   

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

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

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

謝謝回復(fù),我測(cè)試了一下確實(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ù)  更多評(píng)論   

# 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ù)  更多評(píng)論   

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

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

# 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ù)  更多評(píng)論   

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

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

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

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

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

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

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

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

# 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ù)  更多評(píng)論   

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

你好,之前用LsComm寫了幾天,都處理不好,后來找到您這個(gè)CnComm類,中文注釋相當(dāng)親切,代碼也友好。就準(zhǔn)備寫一個(gè)接收程序,可是一接收就藍(lán)屏啊。(我用的是SerialNull虛擬串口生成一對(duì)串口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í)在是沒招了啊,請(qǐng)大大指點(diǎn)。  回復(fù)  更多評(píng)論   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 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è)串口通訊工具測(cè)試,發(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ù)  更多評(píng)論   

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

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

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

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

# 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í)間,便不再追求.若有其它人尋找到原因及解決方法,方便的話請(qǐng)順便郵件於我.huangxiaodon@sohu.com謝謝.  回復(fù)  更多評(píng)論   

# 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ù)  更多評(píng)論   

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

在調(diào)試的時(shí)候向設(shè)備發(fā)送命令沒有一點(diǎn)反應(yīng),不知道我這種調(diào)用是不是有問題,請(qǐng)指點(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測(cè)試的時(shí)候是正常的,只是不知道為什么使用MSCOMM的時(shí)候,不能在我需要的時(shí)候得到返回值。還請(qǐng)大師指點(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,請(qǐng)指點(diǎn),謝謝!  回復(fù)  更多評(píng)論   

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

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

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

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

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

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

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

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

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

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

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

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

# 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ù)  更多評(píng)論   

# 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ù)  更多評(píng)論   

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

1234  回復(fù)  更多評(píng)論   

# 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ù)  更多評(píng)論   

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

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

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

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

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

# 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ù)  更多評(píng)論   

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

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ù)  更多評(píng)論   

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

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


只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


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

導(dǎo)航

統(tǒng)計(jì)

常用鏈接

留言簿(8)

隨筆檔案

搜索

最新評(píng)論

閱讀排行榜

評(píng)論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            亚洲成色999久久网站| 欧美区二区三区| 99精品视频免费观看视频| 一二三四社区欧美黄| 午夜精品久久久久久久蜜桃app| 欧美在线观看日本一区| 蜜桃久久av| 国产精品任我爽爆在线播放| 在线观看欧美日本| 亚洲一级二级在线| 久久天天躁夜夜躁狠狠躁2022| 亚洲精品欧美专区| 久久精品最新地址| 欧美视频中文字幕在线| 亚洲二区视频| 久久国产黑丝| 亚洲精品一区在线观看| 国产精品主播| 亚洲一区中文| 亚洲激情婷婷| 99精品国产福利在线观看免费 | 91久久国产综合久久蜜月精品 | 亚洲一区二区三区精品在线观看 | 亚洲欧美不卡| 欧美日韩一区二区在线观看 | 国产精品v亚洲精品v日韩精品 | 一区二区免费看| 亚洲国产精品成人综合| 久久免费黄色| 国内成+人亚洲| 欧美日韩综合视频| 伊人久久亚洲热| 亚洲美女视频在线观看| 蜜臀a∨国产成人精品| 亚洲一区视频在线| 欧美mv日韩mv亚洲| 亚洲国产女人aaa毛片在线| 久久亚洲欧洲| 欧美午夜视频网站| 蜜臀a∨国产成人精品| 亚洲人妖在线| 欧美精品九九| 99伊人成综合| 一级日韩一区在线观看| 尤物九九久久国产精品的特点| 亚洲社区在线观看| 国产精品综合不卡av| 亚洲精品视频在线看| 在线成人激情| 欧美在线你懂的| 久久精品国产亚洲一区二区| 欧美一区视频在线| 国产一区二区三区在线观看精品 | 亚洲国产成人在线| 久久福利资源站| 在线观看亚洲精品| 久久成人精品电影| 久久av一区| 国产欧美一区二区白浆黑人| 久久精品国产99国产精品| 国产精品高清网站| 久久久午夜电影| 欧美国产日韩a欧美在线观看| 亚洲午夜久久久久久尤物| 欧美激情一区二区三区在线视频| 亚洲第一精品影视| 久久精品视频免费观看| 久久黄色小说| 国内精品久久久久影院色| 性一交一乱一区二区洋洋av| 亚洲激情校园春色| 欧美成在线观看| 久久精选视频| 欧美精品久久一区| 亚洲乱码视频| 午夜欧美精品| 欧美大尺度在线观看| 亚洲国产影院| 亚洲视频1区| 麻豆91精品91久久久的内涵| 欧美大学生性色视频| 国产精品揄拍500视频| 欧美亚洲自偷自偷| 蜜乳av另类精品一区二区| 最新日韩在线| 国产精品乱码一区二三区小蝌蚪| 欧美成熟视频| 一本不卡影院| 国产亚洲精品高潮| 欧美不卡视频一区| 中文精品视频一区二区在线观看| 久久成人国产精品| 先锋资源久久| 久久精品国产亚洲aⅴ| 免费成人高清视频| 一区二区三区产品免费精品久久75| 国产精品你懂得| 国产亚洲欧美一区二区三区| 亚洲国产天堂网精品网站| 欧美成人四级电影| 亚洲天堂av综合网| 亚洲高清av在线| 欧美日韩综合在线| 久久久久久久久久久成人| 欧美有码在线视频| 欧美日韩专区| 久久青草福利网站| 亚洲一区二区三区在线观看视频| 一区二区三区国产精华| 国产一区二区三区黄视频| 欧美国产成人精品| 欧美与黑人午夜性猛交久久久| 亚洲欧洲美洲综合色网| 久久蜜桃精品| 亚洲欧美日韩成人高清在线一区| 欧美日韩一区在线观看| 久久久国产精品亚洲一区| 一区二区三区四区精品| 亚洲精品五月天| 午夜欧美大片免费观看| 亚洲国产高清视频| 久久久久女教师免费一区| 亚洲午夜精品视频| 亚洲九九爱视频| 欧美国产日韩精品免费观看| 欧美影院在线| 欧美亚洲一区二区在线| 在线亚洲欧美| 一区二区三区视频免费在线观看| 欧美激情视频一区二区三区在线播放| 在线不卡a资源高清| 国产欧美精品国产国产专区| 欧美日韩三级一区二区| 欧美激情偷拍| 免费亚洲电影在线| 老牛嫩草一区二区三区日本| 亚洲国产另类久久久精品极度| 久久精品中文字幕一区二区三区| 先锋影音国产精品| 亚洲欧美日韩综合一区| 亚洲影院在线| 亚洲欧美日韩久久精品| 亚洲一区二区在线免费观看| 亚洲一二三级电影| 亚洲免费视频一区二区| 亚洲一区在线观看免费观看电影高清| 一本不卡影院| 亚洲一品av免费观看| 亚洲欧美成人一区二区三区| 亚洲欧美综合| 久久精品首页| 欧美 日韩 国产在线| 一区二区三区精品国产| 一区二区三区www| 亚洲亚洲精品三区日韩精品在线视频 | 久热爱精品视频线路一| 欧美成人精品高清在线播放| 欧美高潮视频| 国产精品久久久对白| 国产日韩精品电影| 伊人久久久大香线蕉综合直播| 91久久精品www人人做人人爽| 宅男噜噜噜66国产日韩在线观看| 久久精品人人爽| 老司机一区二区三区| 一区二区不卡在线视频 午夜欧美不卡'| 亚洲精品视频在线看| 亚洲一级片在线观看| 久久久久久久97| 亚洲狠狠丁香婷婷综合久久久| 日韩网站在线观看| 性做久久久久久久免费看| 美日韩精品视频| 国产精品国产三级国产普通话蜜臀 | 欧美系列电影免费观看| 国产一区二区三区久久悠悠色av| 亚洲高清资源| 午夜日韩在线| 欧美二区在线播放| 亚洲一二三区精品| 美女黄色成人网| 国产精品日韩一区| 亚洲国产毛片完整版| 午夜欧美大尺度福利影院在线看| 欧美阿v一级看视频| 亚洲视频一二三| 欧美国产日韩视频| 国产资源精品在线观看| 亚洲性视频网址| 欧美国产综合| 久久精品国产清高在天天线| 国产精品大片wwwwww| 91久久视频| 免费欧美视频| 欧美亚洲在线| 国产欧美日韩视频一区二区| 一区二区欧美激情| 欧美黄色一区二区| 久久九九免费视频| 国产性做久久久久久|