嵌入式編程的復(fù)雜性
能從PC機(jī)器編程去看嵌入式問題，那是第一步；學(xué)會用嵌入式編程思想，那是第二步；用PC的思想和嵌入式的思想結(jié)合在一起，應(yīng)用于實(shí)際的項(xiàng)目，那是第三步。很多朋友都是從PC編程轉(zhuǎn)向嵌入式編程的。在中國，嵌入式編程的朋友很少是正兒八經(jīng)從計(jì)算機(jī)專業(yè)畢業(yè)的，都是從自動控制啊，電子相關(guān)的專業(yè)畢業(yè)的。這些童鞋們，實(shí)踐經(jīng)驗(yàn)雄厚，但是理論知識缺乏；計(jì)算機(jī)專業(yè)畢業(yè)的童鞋很大一部分去弄網(wǎng)游、網(wǎng)頁這些獨(dú)立于操作系統(tǒng)的更高層的應(yīng)用了。也不太愿意從事嵌入式行業(yè)，畢竟這條路不好走。他們理論知識雄厚，但缺乏電路等相關(guān)的知識，在嵌入式里學(xué)習(xí)需要再學(xué)習(xí)一些具體的知識，比較難走。
雖然沒有做過產(chǎn)業(yè)調(diào)查，但從我所見和所招聘人員，從事嵌入式行業(yè)的工程師，要么缺乏理論知識，要么缺乏實(shí)踐經(jīng)驗(yàn)。很少兩者兼?zhèn)涞摹＞科湓?，還是中國的大學(xué)教育的問題。這里不探討這個問題，避免口水戰(zhàn)。我想列出我實(shí)踐中的幾個例子。引起大家在嵌入式中做項(xiàng)目時對一些問題的關(guān)注。
第一個問題：
同事在uC/OS-II下開發(fā)一個串口的驅(qū)動程序，驅(qū)動和接口在測試中均為發(fā)現(xiàn)問題。應(yīng)用中開發(fā)了個通訊程序，串口驅(qū)動提供了一個查詢驅(qū)動緩沖區(qū)字符的函數(shù)：GetRxBuffCharNum()。 高層需要接受一定數(shù)量的字符以后才能對包做解析。一個同事撰寫的代碼，用偽代碼表示如下：
bExit = FALSE;
do {
if (GetRxBuffCharNum() >= 30)
bExit = ReadRxBuff(buff, GetRxBuffCharNum());
} while (!bExit);
這段代碼判斷當(dāng)前緩沖區(qū)中超過30個字符，就將緩沖區(qū)中全部字符讀到緩沖區(qū)中，直到讀取成功為止。邏輯清楚，思路也清楚。但這段代碼是不能正常工作。如果是在PC機(jī)上，定然是沒有任何問題，工作的異常正常。但在嵌入式里真的是不得而知了。同事很郁悶，不知道為什么。來請我解決問題，當(dāng)時我看到代碼，就問了他，GetRxBuffCharNum()是怎么實(shí)現(xiàn)的？打開一看：
unsigned GetRxBuffCharNum(void)
{
cpu_register reg;
unsigned num;
reg = interrupt_disable();
num = gRxBuffCharNum;
interrupt_enable(reg);
return (num);
}
很明顯，由于在循環(huán)中，interruput_disable()和interrupt_enable()之間是個全局臨界區(qū)域，保證gRxBufCharNum的完整性。但是，由于在外層的do { } while() 循環(huán)中，CPU頻繁的關(guān)閉中斷，打開中斷，這個時間非常的短。實(shí)際上CPU可能不能正常的響應(yīng)UART的中斷。當(dāng)然這和uart的波特率、硬件緩沖區(qū)的大小還有CPU的速度都有關(guān)系。我們使用的波特率非常高，大約有3Mbps。uart起始信號和停止信號占一個比特位。一個字節(jié)需要消耗10個周期。3Mbps的波特率大約需要3.3us傳輸一個字節(jié)。3.3us能執(zhí)行多少個CPU指令呢？100MHz的ARM，大約能執(zhí)行150條指令左右。結(jié)果關(guān)閉中斷的時間是多長呢？一般ARM關(guān)閉中斷都需要4條以上的指令，打開又有4條以上的指令。接收uart中斷的代碼實(shí)際上是不止20條指令的。所以，這樣下來，就有可能出現(xiàn)丟失通信數(shù)據(jù)的Bug，體現(xiàn)在系統(tǒng)層面上，就是通信不穩(wěn)定。
修改這段代碼其實(shí)很簡單，最簡單的辦法是從高層修改。即：
bExit = FALSE;
do {
DelayUs(20); //延時 20us，一般采用空循環(huán)指令實(shí)現(xiàn)
num = GetRxBuffCharNum();
if (num >= 30)
bExit = ReadRxBuff(buff, num);
} while (!bExit);
這樣，讓CPU有時間去執(zhí)行中斷的代碼，從而避免了頻繁關(guān)閉中斷造成的中斷代碼執(zhí)行不及時，產(chǎn)生的信息丟失。在嵌入式系統(tǒng)里，大部分的RTOS應(yīng)用都是不帶串口驅(qū)動。自己設(shè)計(jì)代碼時，沒有充分考慮代碼與內(nèi)核的結(jié)合。造成代碼深層次的問題。RTOS之所以稱為RTOS，就是因?yàn)閷κ录目焖夙憫?yīng)；事件快速的響應(yīng)依賴于CPU對中斷的響應(yīng)速度。驅(qū)動在Linux這種系統(tǒng)中都是與內(nèi)核高度整合，一起運(yùn)行在內(nèi)核態(tài)。RTOS雖然不能抄襲linux這種結(jié)構(gòu)，但有一定的借鑒意義。
從上面的例子可以看清楚，嵌入式需要開發(fā)人員對代碼的各個環(huán)節(jié)需要了解清楚。
第二個例子：
同事驅(qū)動一個14094串轉(zhuǎn)并的芯片。串行信號是采用IO模擬的，因?yàn)闆]有專用的硬件。同事就隨手寫了個驅(qū)動，結(jié)果調(diào)試了3、4天，仍舊是有問題。我實(shí)在看不下去了，就去看了看，控制的并行信號有時候正常有時候不正常。我看了看代碼，用偽代碼大概是：
for (i = 0; i < 8; i++)
{
SetData((data >> i) & 0x1);
SetClockHigh();
for (j = 0; j < 5; j++);
SetClockLow();
}
將數(shù)據(jù)的8個bit在每個高電平從bit0到bit7依次發(fā)送出去。應(yīng)該是正常的啊?？床怀鰡栴}在哪??？我仔細(xì)想了想，有看了14094的datasheet，明白了。原來，14094要求clock的高電平持續(xù)10個ns，低電平也要持續(xù)10個ns。這段代碼之做了高電平時間的延時，沒有做低電平的延時。如果中斷插在低電平之間工作，那么這段代碼是可以的。但是如果CPU沒有中斷插在低電平時執(zhí)行，則是不能正常工作的。所以就時好時壞。
修改也比較簡單：
for (i = 0; i < 8; i++)
{
SetData((data >> i) & 0x1);
SetClockHigh();
for (j = 0; j < 5; j++);
SetClockLow();
for (j = 0; j < 5; j++);
}
這樣就完全正常了。但是這個還是不能很好移植的一個代碼，因?yàn)榫幾g器一優(yōu)化，就有可能造成這兩個延時循環(huán)的丟失。丟失了，就不能保證高電平低電平持續(xù)10ns的要求，也就不能正常工作了。所以，真正的可以移植的代碼，應(yīng)該把這個循環(huán)做成一個納秒級的DelayNs(10);
像Linux一樣，上電時，先測量一下，nop指令執(zhí)行需要多長時間執(zhí)行，多少個nop指令執(zhí)行10ns。執(zhí)行一定的nop指令就可以了。利用編譯器防止優(yōu)化的編譯指令或者特殊的關(guān)鍵字，防止延時循環(huán)被編譯器優(yōu)化掉。如GCC中的
__volatile__ __asm__("nop;\n");
從這個例子中可以清楚的看到，寫好一段好代碼，是需要很多知識支撐的。你說呢？
嵌入式往往沒有操作系統(tǒng)支撐，或者因?yàn)橛胁僮飨到y(tǒng)支撐，但因?yàn)榉N種的限制，操作系統(tǒng)提供的功能少得可憐。所以，很多代碼不能像PC編程那樣天馬行空，任意馳騁。今天就聊聊內(nèi)存分配的問題，內(nèi)存碎片，可能大家都不陌生。然而在嵌入式系統(tǒng)里，最怕的就是內(nèi)存碎片，也是系統(tǒng)穩(wěn)定的頭號殺手。我曾經(jīng)做了一個項(xiàng)目，系統(tǒng)中有很多的malloc和free，尺寸不一，從60多個字節(jié)到64KB的不等。使用一款RTOS作為支撐。當(dāng)時我有兩個選擇，一個是使用C系統(tǒng)庫的malloc和free，另外一個是使用操作系統(tǒng)提供的固定內(nèi)存分配。我們系統(tǒng)的設(shè)計(jì)要求要能穩(wěn)定運(yùn)行3個月以上。實(shí)際上連續(xù)運(yùn)行6天左右就宕機(jī)了。各種問題都懷疑過，最后定為在內(nèi)存分配上，其實(shí)就是長時間，大量的內(nèi)存分配后，系統(tǒng)的內(nèi)存變得零散而無法連續(xù)。雖有大空間，但卻無法分配連續(xù)的空間。當(dāng)有大空間申請時，只能是宕機(jī)完蛋。為了使系統(tǒng)達(dá)到原先的設(shè)計(jì)需求，我們在PC機(jī)上模擬了整個硬件，將嵌入式代碼在 PC機(jī)上跑起來，并重載了malloc和free，做了個復(fù)雜的統(tǒng)計(jì)程序。統(tǒng)計(jì)系統(tǒng)的內(nèi)存行為。運(yùn)行了若干天以后，將數(shù)據(jù)提取出來分析，雖然申請的內(nèi)存5花八門，還是有些規(guī)律，我們把100個字節(jié)以下的歸為一類，512B的歸為一類，1KB的歸為一類，2KB歸為一類，64KB一下歸為一類。統(tǒng)計(jì)出每類的數(shù)量，在原先的基礎(chǔ)上加上30%的余量。做成固定內(nèi)存申請，使得系統(tǒng)穩(wěn)定連續(xù)運(yùn)行的時間大大加長。嵌入式就這樣，不怕方法原始，就怕性能不達(dá)要求。
內(nèi)存溢出問題，內(nèi)存溢出問題嵌入式系統(tǒng)比PC系統(tǒng)更可怕! 往往是沒有察覺的就溢出了。都很難想到，尤其是C/C++的初學(xué)者，對指針不熟悉，查都沒法查。由于PC系統(tǒng)有MMU，內(nèi)存發(fā)生嚴(yán)重的越界時，有MMU的保護(hù)，不會產(chǎn)生嚴(yán)重的災(zāi)難后果。而嵌入式往往沒有MMU，差別很大，系統(tǒng)代碼都被破壞了還能跑。只是只有上帝和那個CPU才知道跑得是什么。我們來看看這段代碼：
char *strcpy(char *dest, const char * src)
{
assert(dest != NULL && src != NULL);
while (*src != '\0')
{
*dest++ = *src++;
}
*dest = '\0';
return (dest);
}
這個代碼是一個字符串拷貝的代碼，PC機(jī)這樣寫，基本上就可以了。但嵌入式要提防一件事情，那就是 src真的以'\0'結(jié)束的。要不是得話，那就悲劇了。到什么時候能結(jié)束，呵呵，只有上帝老人家才知道。這段代碼僥幸能跑完成的話，估計(jì)也別想程序能正常的跑了。因?yàn)閐est指向的內(nèi)存區(qū)域都被破壞的差不多了。為了和標(biāo)準(zhǔn)C/C++的庫兼容，還真的沒什么好辦法，所以這個問題只能留給程序員自己檢查。
相同的，
memcpy( dest, src, n);
內(nèi)存拷貝同樣的問題，要提防n傳遞個負(fù)值進(jìn)去。這個是拷貝多少個字節(jié)，負(fù)值被強(qiáng)制類型轉(zhuǎn)換成正的。變成一個很大的正數(shù)，造成dest之后的內(nèi)存全部被破壞……
嵌入式里的內(nèi)存指針必須做嚴(yán)格的檢查才能使用，內(nèi)存的尺寸也必須進(jìn)行嚴(yán)格的調(diào)試。不然的話，悲劇是很難避免的。如一個函數(shù)指針，雖然在嵌入式里賦了個NULL,0。若是ARM的話，連個異常錯誤都沒有，直接復(fù)位了，因?yàn)檎{(diào)用這個函數(shù)指針即便是讓代碼從0開始運(yùn)行。而0是ARM上電后運(yùn)行的第一條代碼的位置。在ARM7上尤其如此。這種悲劇比PC上悲情多了，MMU 定然給一個無定義指令的錯誤。引起程序員的重視。在嵌入式里，全部都留給了程序員去尋找了。
內(nèi)存溢出發(fā)生在任何一個不經(jīng)意的時刻，你給整個前后臺的系統(tǒng)(或操作系統(tǒng))分配了多大的堆？多大的棧？在通常情況下系統(tǒng)的調(diào)用深度是多少(最大是多少)，占用多少棧？光看程序的功能正確還不夠，還需要統(tǒng)計(jì)這些參數(shù)。不然，只要有一個地方有溢出。對系統(tǒng)都是致命的。嵌入式系統(tǒng)要求系統(tǒng)連續(xù)工作時間長，穩(wěn)定性可靠性要求苛刻。是需要一些時間仔細(xì)的磨這些系統(tǒng)的。
嵌入式系統(tǒng)的調(diào)試往往很復(fù)雜，可用的手段并不像PC編程那么多，開發(fā)成本較PC系統(tǒng)也要大很多。嵌入式系統(tǒng)調(diào)試主要手段只有JTAG為代表的單步追蹤、printf夾殺大法等。
地球人都知道，嵌入式的最大挑戰(zhàn)在于硬件和軟件同時成熟；出了個問題，不知道是軟件問題還是硬件問題。當(dāng)然，可以通過虛擬的方式解決大部分問題，但虛擬終歸是虛擬。不是實(shí)際，上了實(shí)際的板子，還是有不少問題。嵌入式領(lǐng)域，特別是底層技術(shù)，由軟件(驅(qū)動)和硬件兩個部分組成。解決起來，需要兩個部分的知識，對人員的素質(zhì)要求更高。我曾經(jīng)遇到很多棘手的問題，都是復(fù)雜的系統(tǒng)問題。
網(wǎng)上有些朋友經(jīng)常問我一些問題。有關(guān)于底層的知識，其中不乏一些多處理器的問題。關(guān)于多處理器的問題，我也才疏學(xué)淺，說來與大家討論一下，關(guān)于嵌入式領(lǐng)域的 多CPU的應(yīng)用。嵌入式說來說去是計(jì)算機(jī)科學(xué)的應(yīng)用領(lǐng)域之一。既然是計(jì)算科學(xué)的應(yīng)用領(lǐng)域之一，那么要做好這個領(lǐng)域，必須有過硬的計(jì)算機(jī)理論知識。
首先多處理器分為好幾種，
處理器是同一型號，大家完全一樣，通過一種通訊方式連接，如多口的RAM，rapidIO，千兆級以太網(wǎng)，或者PCI-E等；
處理器不同型號，甚至架構(gòu)都完全不一樣。之間通過一種通訊方式連接，同上，如多口RAM、RapidIO等；
同一個芯片中集成了多個CPU。這幾個CPU什么都共享，屬于比多口RAM還要緊耦合的系統(tǒng)。
為什么要用多處理器？
大規(guī)模的并行運(yùn)算；
想利用多個CPU的特點(diǎn)，如DM642這樣的方案，應(yīng)用于復(fù)雜的視頻方案。想利用DSP的浮點(diǎn)計(jì)算能力，同時也使用ARM的事務(wù)計(jì)算能力；
單純的提高系統(tǒng)的性能。
對于普通的應(yīng)用，提高系統(tǒng)性能是基本出發(fā)點(diǎn)。但嵌入式系統(tǒng)應(yīng)用多處理器并不是一個簡單的事情。多處理器的軟件設(shè)計(jì)難度很大，調(diào)試也是很大的問題。
如果不采用操作系統(tǒng)處理，采用前后臺系統(tǒng)。那么自己還要設(shè)計(jì)一個通信算法，還要設(shè)計(jì)一個結(jié)果整合系統(tǒng)。這樣的系統(tǒng)自己設(shè)計(jì)很多東西，其中總線的可靠和容錯設(shè)計(jì)至關(guān)重要。 所以可能的話，利用成熟穩(wěn)定的操作系統(tǒng)來支持多處理器可以減少不少的開發(fā)難度。然而，尋找這樣的一個操作系統(tǒng)并非易事。
首先要明確自己的應(yīng)用，需要線程進(jìn)程遷移嗎？需要處理器平衡嗎? 對于多處理器，如果不支持線程進(jìn)程遷移，那也就談不上處理器任務(wù)的動態(tài)平衡，不然只能事前指定好線程進(jìn)程運(yùn)行于哪個處理器。對于異構(gòu)型多處理器，線程遷移和進(jìn)程遷移并沒有多大的實(shí)際意義。對于追求利益的公司來說，目前還談不上實(shí)用價值。所以，遷移只限于對稱處理器。然而，對稱處理器也不是什么進(jìn)程可遷移。對于對稱處理器，操作系統(tǒng)封裝好底層，讓用戶開發(fā)起來像是對一個CPU再做開發(fā)，當(dāng)然不可能與單個CPU完全一致，但起碼減輕了許多難度。
很多朋友問我RTEMS可以跑在x86這樣的CMP的多處理器上嗎？當(dāng)然。但是，設(shè)計(jì)起來又不同于普通的對稱多處理器。因?yàn)?，CMP處理器上的CPU共享了許多東西，中斷，內(nèi)存，總線，他們的編址空間基本上都是一致的。對于RTEMS這樣的RTOS來說，它采用的是異構(gòu)型的方式支持對稱處理器，即有幾個CPU就得跑幾個RTEMS。那么通訊顯得尤為重要，多個RTEMS需要多個系統(tǒng)的TICK，那么TICK從哪里來，CMP共享著很多資源，那么就要求，使用者必須為RTEMS手動的指定中斷源，劃分內(nèi)存空間，這就造成了，CMP上的多個CPU雖然都是跑RTEMS，但是想關(guān)于CPU的驅(qū)動很多都是不一樣的。這種緊耦合的系統(tǒng)是非常難辦的。
相對于CMP，同 種CPU組成的SMP就要簡單一些，因?yàn)槿框?qū)動都是一樣的，可能會因?yàn)橥ㄐ欧绞降膯栴}，通信驅(qū)動要特殊處理一下，但這會極大的減輕了開發(fā)的壓力和調(diào)試的難度。總好比每個CPU一個Core，那是要崩潰了。特別是調(diào)試問題，所以從經(jīng)濟(jì)角度的問題考慮，還是比較喜歡這種多個相同的單個CPU組成的多處理器系統(tǒng)。
很多時候，對于那個異構(gòu)型的處理器，當(dāng)然用RTEMS也可以輕松擺平，但是還是一個問題，多個核心需要自己的RTEMS支持，開發(fā)多有不便。況且，操作系統(tǒng)的調(diào)試還是比較復(fù)雜的。所以現(xiàn)實(shí)版的方案都是，異構(gòu)型處理器當(dāng)中負(fù)責(zé)事務(wù)運(yùn)算的處理器跑操作系統(tǒng)，而負(fù)責(zé)計(jì)算的處理器采用前后臺系統(tǒng)，簡單的通過共享內(nèi)存通訊，響應(yīng)操作系統(tǒng)的計(jì)算請求。這樣大大的減小了開發(fā)難度，反正操作系統(tǒng)把DSP當(dāng)作了個硬件的寄存器，寫幾個寄存器就能得到結(jié)果，或者是輸入一組天文一樣的數(shù)據(jù)，得到一個復(fù)雜的結(jié)果。Anyway，總之這樣的反應(yīng)式的處理方式是絕大部分工程中采用的方式。就是簡單、可靠、實(shí)用。
看來，嵌入式系統(tǒng)中的多處理器還是與應(yīng)用高度的相關(guān)
這兩種調(diào)試方法在嵌入式中也不盡然全部能解決問題。Jtag需要調(diào)試者有一個調(diào)試設(shè)備(有可能很昂貴)，和目標(biāo)系統(tǒng)相連。使用類似GDB Client等軟件登錄調(diào)試設(shè)備，跟蹤運(yùn)行程序。說實(shí)話，這個方法對嵌入式來講是終極的調(diào)試辦法，也是比較好的調(diào)試方法。但仍然有幾個不足,當(dāng)斷點(diǎn)過多時，超出硬件的限制，某些低檔的CPU不支持更多的斷點(diǎn)，就需要JTAG利用軟件模擬，或采用軟件陷阱(軟中斷或異常)等辦法實(shí)現(xiàn)斷點(diǎn)。機(jī)理比較復(fù)雜，簡單點(diǎn)說，1.不能進(jìn)行長時間調(diào)試，不太穩(wěn)定; 2.有可能影響程序的運(yùn)行時刻的行為，通過時序影響。掛接JTAG系統(tǒng)后，利用硬件實(shí)現(xiàn)的斷點(diǎn)不會影響系統(tǒng)運(yùn)行的速度，但是軟件實(shí)現(xiàn)的斷點(diǎn)是必定犧牲一些性能的?？煽啃砸惨蛘劭鄣摹．?dāng)斷點(diǎn)太多，而系統(tǒng)又進(jìn)入臨界區(qū)域，可能會造成斷點(diǎn)不起作用。因?yàn)榍度胧綄?shí)現(xiàn)全局臨界區(qū)域往往需要關(guān)閉中斷，有些CPU沒有非屏蔽中斷，當(dāng)斷點(diǎn)超過一定數(shù)量，使用軟件斷點(diǎn)，而軟件斷點(diǎn)又需要在中斷工作的情況下使用……
特別調(diào)試時序問題和高速通信類的代碼，JTAG幫助并不大。通信過程往往很快，通信包也是接二連三，才能完成一個完整的動作。如果是高速通訊，斷點(diǎn)是無法讓程序完成工作的。所以只能使用printf夾殺的辦法，printf夾殺辦法很好。但是也要注意幾個問題：嵌入式系統(tǒng)往往沒有屏幕，printf輸出是通過串口輸出。而串口工作模式有兩種，一種是查詢，另外一種是中斷，或DMA。不管哪種，調(diào)試輸出的printf只能使用查詢的辦法輸出，千萬不要使用中斷或DMA的辦法。不管是前后臺程序也好，還是操作系統(tǒng)也好，都有不方便的時候，也許在全局臨界內(nèi)需要打印(關(guān)閉了中斷)，也許需要在中斷里打印(不允許嵌套中斷)，也許要在一些驅(qū)動里打印(很多配合的設(shè)備沒有初始化，內(nèi)存分配和中斷并不能很好的工作)。在這些情況下，利用Uart中斷輸出字符是不明智的。所以調(diào)試輸出只能使用查詢的辦法。不要幻想著使用什么牛叉的辦法，不必了。一句話，不可靠！既然做調(diào)試，那可靠的輸出結(jié)果是第一要求。也就是因?yàn)槿绱?，printf也會影響代碼的工作效率，串口最高的波特率115200bps，越快速的CPU越是浪費(fèi)時間，因?yàn)樾枰却弦粋€字符輸出完畢，這段時間完全是通過空轉(zhuǎn)消耗這部分時間。所以使用printf要有一些技巧，在不影響一些關(guān)鍵時序的位置下再打印，而不是隨意爛打……淹沒了bug。
以上這兩種辦法并不能很好的解決全部的問題，在實(shí)際中如果嵌入式系統(tǒng)有一兩個LED燈，嘗試用IO口將其在特殊的情況下點(diǎn)亮熄滅的辦法，也可表示程序的狀態(tài)。這種辦法適合調(diào)試中斷、臨界區(qū)域這些問題。點(diǎn)量LED燈需要的時間是非常短的，基本上是一條內(nèi)存讀寫命令，如果IO口寄存器是CPU統(tǒng)一編址的話?；旧显斐傻挠绊懳⒑跗湮?。在調(diào)試一些復(fù)雜的時序的時候，還可以使用空閑的IO口，將其在特殊的情況下拉低，拔高，然后利用數(shù)字示波器或者邏輯分析儀抓取再具體分析。特別是分析一段代碼的執(zhí)行頻度，執(zhí)行時間，優(yōu)化效果等。對整體的性能提升等，有非常大的意義。對于簡單的單片機(jī)，廠商開發(fā)軟件都有個時序統(tǒng)計(jì)的功能。但對于有cache和MMU的單片機(jī)，時序統(tǒng)計(jì)并不準(zhǔn)，往往不如用示波器測得的準(zhǔn)。如果沒有示波器利用CPU內(nèi)部的時間計(jì)數(shù)器也可以實(shí)現(xiàn)時間的統(tǒng)計(jì)，需要結(jié)合printf使用。
我一個同事，調(diào)試飛利浦的ARM7，由于飛利浦ARM7外擴(kuò)的RAM全部是靜態(tài)RAM，即使在CPU死機(jī)情況下，只要不斷電，SRAM里的數(shù)據(jù)也不會丟失，由于SRAM和內(nèi)部的SRAM統(tǒng)一編址，所以，訪問起來也就是一條讀寫指令，速度很快。利用這個特性，他把程序的模塊和點(diǎn)全部標(biāo)記上，當(dāng)系統(tǒng)運(yùn)行不正常，將ARM7復(fù)位以后，ARM7上電第一個工作就是取出復(fù)位前的數(shù)據(jù)打印出來。由此可調(diào)試ARM7的代碼，非常巧妙的辦法。如果只有SDRAM的朋友們是不能用這種辦法的，因?yàn)橹灰到y(tǒng)復(fù)位，SDRAM沒有刷新，數(shù)據(jù)即會丟失。
1.一個系統(tǒng)要求連續(xù)不斷的24小時工作，即使斷電，也要保存斷電狀態(tài)。在電源正常時，就必須恢復(fù)斷電前的狀態(tài)，繼續(xù)工作。
實(shí)際中，我們也這樣做了軟件，但是實(shí)際效果并不是所想得那樣。一萬次斷電，總有那么幾十次不正常；又沒辦法重現(xiàn)，只能是猜來猜去。因?yàn)橄到y(tǒng)斷電，這個也不好調(diào)試，掛著JTAG，系統(tǒng)現(xiàn)在斷電了，目標(biāo)板也就沒電了。也就沒辦法調(diào)試跟蹤單步了。本來的設(shè)計(jì)思路是，控制電路利用電容存儲的一些些能量在斷電后繼續(xù)工作，保存狀態(tài)，保存好后，進(jìn)入待機(jī)狀態(tài)。測試檢測斷電的信號后，也是沒有問題的。后來，這個問題變成懸疑問題了……
這個系統(tǒng)分為兩個模塊，工作模塊和控制模塊。控制模塊有電容繼續(xù)供電，而工作模塊沒有電容工作；所以當(dāng)發(fā)生斷電時，全系統(tǒng)不是同一時間斷電的。當(dāng)控制模塊檢測到斷電時，實(shí)際上工作模塊早都沒電了，所以工作模塊不能正確的傳遞相關(guān)的數(shù)據(jù)回來，造成控制模塊不能正確的工作。兩個斷電的時序非常的接近，無法判斷其先后。解決的方法也很簡單，就是把斷電檢測模塊以工作模塊為主進(jìn)行同步，就沒有問題了。
2.還是斷電保護(hù)的問題，我們用繼電器模擬斷電的情況上萬次正常后，終于上整機(jī)實(shí)驗(yàn)了，結(jié)果經(jīng)常發(fā)現(xiàn)斷電無法正常保護(hù)的現(xiàn)象。仔細(xì)查看電路也沒有什么異常，都是一樣的。結(jié)果工程部指責(zé)我們研發(fā)部沒有仔細(xì)測試，發(fā)出來的東西都是有問題的東西。哎，傷心啊。后來經(jīng)過仔細(xì)的分析，我們認(rèn)為，軟件異常的可能性很小。主要問題還是在硬件上，硬件上的超級電容可能在頻繁的斷電下，沒有存儲夠足夠的能量，使得系統(tǒng)完成保護(hù)過程。那么究竟是什么造成頻繁的斷電呢？按照設(shè)計(jì)要求，超級電容在3~5s內(nèi)就會充滿到80%的能量，理論上足夠了。又有什么會不到3~5s鐘頻繁的斷電呢？
說出來都匪夷所思，使用數(shù)字示波器不間斷跟蹤控制板的電源，才發(fā)現(xiàn)。原來是三相交流電需要接一個相位保護(hù)器，相位保護(hù)在系統(tǒng)工作時會頻繁的開關(guān)(可能和系統(tǒng)的狀態(tài)有關(guān))。解決方法是，簡單的把控制器的電源接在相位保護(hù)器前面就好了。
這些問題看似都是硬件問題，也是在產(chǎn)品的調(diào)試過程中經(jīng)常碰到的問題。這些問題，需要軟件工作人員確認(rèn)軟件中的Bug是否能造成這種情況，然后，還需要硬件工程師確認(rèn)硬件。當(dāng)然，硬件的確認(rèn)過程漫長復(fù)雜，并且調(diào)試手段非常有限;嵌入式軟件的調(diào)試相對于硬件來講，成本和收效都會好一些。所以往往需要嵌入式軟件人員花很多時間確認(rèn)軟件問題，最后才懷疑硬件。作為嵌入式開發(fā)人員，能了解硬件的基本原理，結(jié)合軟件的工作原理，和硬件工程師一起配合實(shí)驗(yàn)定位錯誤，是非常有效的辦法。
- 上一篇：實(shí)邦電子2017年體檢 2017/4/20
- 下一篇：晶振決定數(shù)字電路的生與死 2017/2/9
