?* @fn? ? ? UART1_IRQHandler

?*

?* @brief? ?UART1中斷函數(shù)

?*

?* @return? none

?*/

__INTERRUPT

__HIGH_CODE

void UART1_IRQHandler(void)

{

? ? volatile uint8_t i;

? ? switch(UART1_GetITFlag())

? ? {

? ? ? ? case UART_II_LINE_STAT: // 線路狀態(tài)錯(cuò)誤

? ? ? ? {

? ? ? ? ? ? UART1_GetLinSTA();

? ? ? ? ? ? break;

? ? ? ? }

? ? ? ? case UART_II_RECV_RDY: // 數(shù)據(jù)達(dá)到設(shè)置觸發(fā)點(diǎn)

? ? ? ? ? ? for(i = 0; i != trigB; i++)

? ? ? ? ? ? {

? ? ? ? ? ? ? ? RxBuff[i] = UART1_RecvByte();

? ? ? ? ? ? ? ? UART1_SendByte(RxBuff[i]);

? ? ? ? ? ??? ?UART3_SendByte(RxBuff[i]);//串口1接收的數(shù)據(jù)同時(shí)發(fā)送串口3

? ? ? ? ? ? }

? ? ? ? ? ? break;

? ? ? ? case UART_II_RECV_TOUT: // 接收超時(shí)，暫時(shí)一幀數(shù)據(jù)接收完成

? ? ? ? ? ? i = UART1_RecvString(RxBuff);

? ? ? ? ? ? UART1_SendString(RxBuff, i);

? ? ? ? ? ? break;

? ? ? ? case UART_II_THR_EMPTY: // 發(fā)送緩存區(qū)空，可繼續(xù)發(fā)送

? ? ? ? ? ? break;

? ? ? ? case UART_II_MODEM_CHG: // 只支持串口0

? ? ? ? ? ? break;

? ? ? ? default:

? ? ? ? ? ? break;

? ? }

}

您好，默認(rèn)代碼就可以接收7個(gè)字節(jié)以上的數(shù)據(jù)，需要用戶代碼做好接收緩存。

使用您的代碼，出現(xiàn)了什么現(xiàn)象呢，串口打印信息可以截個(gè)圖嗎。

以下博客中的代碼可以實(shí)現(xiàn)串口間透傳，供您參考。

https://www.cnblogs.com/JayWellsBlog/p/15950692.html

您好，我在源代碼的基礎(chǔ)上在中斷函數(shù)里進(jìn)行了數(shù)據(jù)轉(zhuǎn)存，在主函數(shù)里判斷后發(fā)送；

while(1)

?{

if(uart1RxBuff[0]==0x31)

{

? ? UART3_SendString(uart1RxBuff,32);//發(fā)送32位定長

? ? uart1RxBuff[0]=0x00;

}

}

串口截圖如下：

串口1發(fā)送16個(gè)數(shù)據(jù)，返回14位；串口3顯示接收32，有效數(shù)據(jù)只有7位。也就是最多只能接收7位數(shù)據(jù)。

您好，中斷中的接收越快越好，接收占用時(shí)間過長，會影響到串口1下一包數(shù)據(jù)的接收，串口打印、數(shù)據(jù)轉(zhuǎn)發(fā)等等都需要時(shí)間。

串口3那邊只收到7個(gè)字節(jié)有效數(shù)據(jù)，推測是由于串口1第一包接收的數(shù)據(jù)開頭為0x31，滿足if(uart1RxBuff[0]==0x31)，后續(xù)的數(shù)據(jù)開頭沒有‘1’，不發(fā)送。

您好，感覺不是您推測的那樣，一個(gè)字符串，“數(shù)組0”里的內(nèi)容符合條件就執(zhí)行，這個(gè)沒毛病的，之前其它芯片也這么寫都可以正確執(zhí)行的。那您看下Uart1的窗口發(fā)出16個(gè)數(shù)據(jù)返回14個(gè)數(shù)據(jù)是什么原因？這個(gè)是在接收的同時(shí)直接輸出的

串口1FIFO中緩存到7個(gè)字節(jié)就全部取出，第一次取出的數(shù)據(jù)確實(shí)是‘1’開頭的，中斷完后在主函數(shù)中發(fā)出沒問題。檢查一下第二次取出的以及最后一次在TOUT case中取出的數(shù)據(jù)，還是不是‘1’開頭的呢。

默認(rèn)例程中，串口1接收中斷中直接回傳數(shù)據(jù)，在波特率115200下是可行的，不清楚您的代碼還有哪些修改，您可以發(fā)送工程至郵箱zhaiyw@wch.cn幫您看下。

? ? ? ?只是在源代碼的基礎(chǔ)上添加了Uart3，刪除了原來的查詢方式。代碼已發(fā)送，麻煩幫實(shí)現(xiàn)下收發(fā)數(shù)據(jù)長度大于7的功能。謝謝！

您好，已將修改后的代碼發(fā)送至您郵箱。修改思路按貼子中的博客修改的，您仔細(xì)看看博客。也可以將相關(guān)變量寫在結(jié)構(gòu)體中，更有條理些。如果您的需求更苛刻些，比如說串口數(shù)據(jù)發(fā)送間隔更短，建議使用環(huán)形緩沖區(qū)緩存數(shù)據(jù)。

TECH_JW您好！

? ? ? 感謝您的幫助；剛剛測試了您修改后的代碼，效果不理想哦，芯片會死機(jī)，有單純中斷模式來實(shí)現(xiàn)的么？比如：一幀數(shù)據(jù)32位，或64位，接收完成就在緩存區(qū)緩存，而不是在while循環(huán)里查詢幾時(shí)接收完成這樣。截圖如下：

另外您提到的環(huán)形緩沖區(qū)緩存數(shù)據(jù)這個(gè)是純粹中斷模式實(shí)現(xiàn)接收么？

? 這是用源代碼中的純粹中斷法，代碼結(jié)構(gòu)和位置和上面那個(gè)測試是一樣的，測試的截圖：

數(shù)據(jù)沒報(bào)錯(cuò)，芯片沒死機(jī)。

您好，郵件提供的只是串口1與串口3的透傳，沒有涉及TMOS系統(tǒng)，您在本帖中也沒有提該需求。

之前提過，在TMOS系統(tǒng)中使用串口的話可以參考BLE_UART例程，您可以自行移植。

如果實(shí)在沒有開發(fā)能力，可以致電官網(wǎng)的技術(shù)支持，評估一下是否需要代開發(fā)。

你好，請教一下是如何實(shí)現(xiàn)單獨(dú)保存7字節(jié)以上數(shù)據(jù)，我使用strcat(TestBuf1,RxBuff)來進(jìn)行6字節(jié)拼接，發(fā)現(xiàn)不穩(wěn)定，有概率亂碼。

可以發(fā)送郵件至郵箱hy@wch.cn ，給你發(fā)送一個(gè)串口接收的例程供參考。

看上去問題在于串口讀取函數(shù)一次讀取只能得到有限的數(shù)據(jù)，可以考慮約定結(jié)束符，循環(huán)讀取串口數(shù)據(jù)填入數(shù)組，直到超時(shí)或者碰到結(jié)束符或者數(shù)組填滿為止。