MSP430多處理器之間的通信方式及協(xié)議
加入技術(shù)交流群
掃碼加入
和技術(shù)大咖面對面交流
海量資料庫查詢(xún)
1 MSP430多處理器
MSP430是一款超低功耗的混合信號控制器，具有1 6位RISC結構，有著(zhù)豐富的片內外設，主要包括有看門(mén)狗、定時(shí)器、比較器、硬件乘法器、液晶驅動(dòng)器、ADC、I／0端口、串口(USART)等等，還集成有64 KB的Flas’E-ROM和2 KB的RAM。其功能強大，應用場(chǎng)合廣泛。但是在大型復雜的場(chǎng)合或者實(shí)時(shí)性要求較高的場(chǎng)合，使用一個(gè)處理器處理所有的業(yè)務(wù)，總是顯得有些不足。引入多個(gè)MsP430處理器協(xié)作工作的模式，可以提高系統的實(shí)時(shí)性、可靠性和適用性。
在多數場(chǎng)合，MSP430無(wú)須為每個(gè)處理器擴展FlashROM，也無(wú)須擴展RAM，采用共享內存的數據交換方式組成多處理器系統并非最佳選擇。此外，MSP430包括有兩個(gè)串口(USART)，在MSP430的應用中，可以把兩組串行端口中的一個(gè)供外部通信使用，另一個(gè)串行端口供內部通信使用。采用串行總線(xiàn)中的串行通信方式組成多處理器系統是比較理想的選擇。
2 技術(shù)要點(diǎn)
2.1 MSP430多處理器組成
MSP430具有兩個(gè)串行端口(USART)，可以使用其中的一個(gè)作為多處理器之間的通信端口。由于串行通信的架構限制，MSP430采用UART串行通信模式組成的多處理器系統，必須建立一個(gè)主處理器和若干從處理器。主處理器的TXD端與所有從處理器的RXD端相連，所有從處理器的TXD端與主處理器的RXD端相連。MSP43O多處理器拓撲結構如圖1所示。
在這個(gè)結構中，主處理器通過(guò)TXD端發(fā)送出指令報文，傳輸到從處理器的RXD接收端；從處理器對指令報文進(jìn)行解包并且對這個(gè)指令報文進(jìn)行響應。從處理器的響應報文通過(guò)TXD發(fā)送到主處理器的RXD接收端，主處理器獲取響應報文確認指令是否被正確執行。從這個(gè)結構上看，主處理器可以與任何從處理器進(jìn)行通信，任何從處理器也可以和主處理器進(jìn)行通信，但是從處理器與從處理器之間卻不可以進(jìn)行直接的通信。
2.2 多處理器系統串行通信協(xié)議
在多處理器系統的串行通信方式中，可以有若干種通信協(xié)議進(jìn)行選擇，如ModBus、Brooks、工業(yè)總線(xiàn)協(xié)議等等。在此，可以選擇業(yè)界通用的MocBus通信協(xié)議作為處理器與處理器之間的通信協(xié)議。
2.3 ModBus通信協(xié)議
Modbus協(xié)議支持傳統的RS232、RS422、RS485和以太網(wǎng)設備。ModBus協(xié)議包括ASCII、RTU、TCP等報文格式，并沒(méi)有規定物理層。此協(xié)議定義了控制器能夠認識和使用的消息結構，而不管它們是經(jīng)過(guò)何種網(wǎng)絡(luò )進(jìn)行通信的。ModBtls的ASCII、RTU協(xié)議規定了消息和數據的結構、命令和就答的方式，數據通信采用Master／Slave方式。Master端發(fā)出數據請求消息，Slave端接收到正確消息后就可以發(fā)送數據到Mastez端，以響應請求；Master端也可以直接發(fā)消息修改Slave端的數據，實(shí)現雙向讀寫(xiě)。
2.4 ModBus在多處理器系統中的報文格式
由于是一個(gè)主服務(wù)器對應多個(gè)從處理器的系統，處理器與處理器之間的報文傳輸必須明確標注目標地址和源地址，以免不相干的處理器之間進(jìn)行誤導操作。除此以外，為了提高主處理器的處理能力，同時(shí)避免不同處理器存在報文相應速度差，以及不同指令任務(wù)之間存在處理量差異的問(wèn)題，必須采用異步通信模式進(jìn)行通信。要滿(mǎn)足異步通信模式，必須在報文中對每次的通信操作加注請求報文的16位標示(可以稱(chēng)之為句柄)，同時(shí)對這些句柄進(jìn)行記錄。
2.4.1 數據讀取請求報文格式
源地址：主處理器地址。
目標地址：指令目的地地址(從處理器)。
句柄：指令請求標示號。
功能代碼：操作指令代碼。
起始地址：讀取從處理器數據寄存器的起始地址。
字節數：操作所涉及的寄存器字。
校驗碼：CRC校驗碼或者LRC校驗碼。
2.4.2 數據讀取應答報文格式
源地址：從處理器地址。
目標地址：主處理器地址。
句柄：指令請求標示號。
功能代碼：操作指令代碼。
數據字節數：操作所涉及的寄存器字節數。
數據1至數據n:數據。
校驗碼：CRC校驗碼或者LRC校驗碼。
其中，應答報文中的目標地址等價(jià)于請求報文中的源地址，應答報文中的源地址等價(jià)于請求報文中的目標地址。
2.5 校驗碼
在ModBus中，通用的校驗方式是ASCII協(xié)議方式采用LRC校驗方式，RTU協(xié)議方式采用CRC校驗方式。
2.5.1 LRC校驗
LRC校驗比較簡(jiǎn)單。它在A(yíng)SCII協(xié)議中使用，檢測了消息域中除開(kāi)始的冒號及結束的回車(chē)換行號外的內容。它僅僅是把每一個(gè)需要傳輸的數據按字節疊加后取反加1即可。下面是它的C代碼：
BYTE GetCheckCode(const char*pSendBuf，Int nEnd)
{ ／／獲得校驗碼
BYTE byLrc=O。
char pBuf[4]；
int nData=0
for(i=1;i<end；i+=2)／／i初始為1，避開(kāi)“開(kāi)始標記”冒號
{／／每?jì)蓚€(gè)需要發(fā)送的ASCII碼轉化為一個(gè)十六進(jìn)制數
pBuf[O]=pSendBuf[i]；
pBu=pSendBuf；
pBuf[2]=、O’；
sscanf(pBuf，”％x”，& nData)；
bvLrc+=nData；
byhc=～byLrc；
byLrc++；
return byLrc;
}
2.5.2 CRC校驗
CRC是先調入一值是全“1”的16位寄存器，然后調用一過(guò)程將消息中連續的8位字節和當前寄存器中的值進(jìn)行處理。僅每個(gè)字符中的8位數據對CRC有效，起始位和停止位以及奇偶校驗位均無(wú)效。
CRC產(chǎn)生過(guò)程中，每個(gè)8位字符都單獨和寄存器內容相或(OR)，結果向最低有效位方向移動(dòng)，最高有效位以0填充。LSB被提取出來(lái)檢測。如果LSB為1，寄存器單獨和預置的值“或”一下；如果LSB為O，則不進(jìn)行。整個(gè)過(guò)程要重復8次。在最后一位(第8位)完成后，下一個(gè)8位字節又單獨和寄存器的當前值相“或”。最終寄存器中的值，是消息中所有字節都執行之后的CRC值。
CRC添加到消息中時(shí)，低字節先加入，然后高字節加入。下面是它的C代碼：
WORD GetCheckCode(const char*pSendBuf，int nEnd)
{ ／／獲得校驗碼
WORD wCrc=WORD(0xFFFF)；
for(int i=O；i<nEnd；i++){
wCrc^=WoRD(BYTE(pSendBuf[i])；
for(Intj=O；j<8；J++){
if(wCrc＆1){
wCrc>>=l；
wCrc^一OxA00l：
}
else{
wCrc>>=1；
retIlrIl wCrc：
3 報文示范
ModBus包含ASCII和RTU兩種報文格式。RTU報文較短，但是沒(méi)有邊界定義;ASCII報文較長(cháng)，但是邊界明了。在多處理器通信之中，由于通信距離很短，干擾較小，因此可以選擇較高的通信速率。通信速率提高了，報文長(cháng)度較長(cháng)對通信的影響不大，因此可以選擇ASCII報文格式進(jìn)行通信。
ModBus的ASCII讀取請求報文格式如下：
ModBus 的 ASCII讀取請求報文格式如下：
假設主機地址01，要對從機地址02進(jìn)行讀取247和248地址的兩個(gè)寄存器值的通信，并且本次通信為第1次通信，設定流水號為000l。
結 語(yǔ)
多處理器協(xié)作工作模式和通信協(xié)議，已經(jīng)成功應于CNG加氣機，使系統信息交換更加迅速、可靠，整個(gè)系統的性能得到了提高。
評論