筆者最近在調試28377系列DSP芯片的can通訊時，遇到一個小問題，百思不得姐~
起因是這樣的，在設計一個多單元並聯的系統，所有單元使用can總線進行通訊，當通訊端口，can外設，以及相關通訊協議都設計好后，開始使用上位機進行通訊調試時，發現上位機可以正常接收到dsp通過can發送的數據，但檢測dsp中的接收緩存，始終看不到上位機下發的數據。
於是，筆者反復排查can模塊的配置，can郵箱的配置，以及相關變量的設計等，但並沒有找到問題所在。
經過了半天時間，突然想到是否是上位機下發數據格式問題，再次檢查上位機下發數據，發現在下發數據設置中勾選了Extended Frame（擴展幀格式）選項。
按照我在dsp中對can的調用，本意是使用擴展幀的，但實際在配置Can信息ID時，因為單元數量並不多，ID雖然是按照29位格式配置，但數值實際只是1到10這樣子，比如其中一個是“0x00000006”。
這里簡單介紹一下Can總線中，標准幀和擴展幀的區別，標准幀是使用11bit位作為ID識別，擴展幀使用29bit位作為ID識別，具體就不再贅述了，相關對can總線稍有了解的同學就知道這個ID識別的作用。
那么回到我們的問題中來，實際上28377系列芯片對於Can總線使用標准幀還是擴展幀是怎么配置的呢？注意，和28335或者2812等以前的Can結構是不一樣的，所以28377系列配置方法有區別哦，對於can的信息幀是擴展幀還是標准幀，28377系列使用其對應庫里相關的CANMessageSet(uint32_t ui32Base, uint32_t ui32ObjID, tCANMsgObject *pMsgObject, tMsgObjType eMsgType)函數進行配置，具體相關的配置語句是這樣的：
// See if we need to use an extended identifier or not.
if((pMsgObject->ui32MsgID > CAN_MAX_11BIT_MSG_ID) ||
(pMsgObject->ui32Flags & MSG_OBJ_EXTENDED_ID))
{
bUseExtendedID = 1;
}
else
{
bUseExtendedID = 0;
}
其中，CAN_MAX_11BIT_MSG_ID = 0x7ff，MSG_OBJ_EXTENDED_ID = 0x00000004
簡要解釋一下上面的意義，就是說，在配置can的MsgObject變量時，判斷其ui32MsgID(Can信息ID)值的大小，如果大於0x7ff則自動配置為擴展幀，0x7ff正是11bit位ID的最大值；或者，判斷ui32Flags標志，如果其bit2位是1，則也配置為擴展幀。
檢查了筆者對於can相關MsgObject配置，發現其ui32MsgID小於0x7ff，而ui32Flags又默認配成了0，所以，實際上dsp是以標准幀格式在接收數據的。
原因找到了，解決起來也很簡單，上位機取消勾選擴展幀格式，按照標准幀發送，則dsp正常接收。或者，上位機發送設置不變，dsp通過將can的接收MsgObject的ui32MsgID配置為大於0x7ff的值，或者將ui32Flags配置為0x00000004，則dsp可以擴展幀格式正常接收上位機信息。