聲明：本處所說的菜單是用在128*64這種小屏幕的菜單，例如下面這種，不是彩屏上的GUI。
作為一個底層驅(qū)動工程師，驅(qū)動寫完了，是要寫硬件測試程序的。 這個測試程序，一般給測試部/硬件工程師用來測試硬件， 也會給工廠產(chǎn)線測試準(zhǔn)成品。
開始的人偷懶，不想一秒就直接上，所有菜單都這樣做，一層套一層
void test_main(void) { while(1)
{
get_key(&key); switch(key)
{ case 1:
test_key(); break; case 2:
test_lcd(); break;
....
}
}
}
當(dāng)菜單越來越多，就開始糾結(jié)了，這樣寫維護不便，看起來也不美，還浪費程序空間。
作為一個天天看《編程之美》的碼農(nóng)，決定改變現(xiàn)狀。 酷狗百度一番，找到了兩個參考： 《基于二叉樹的多層的液晶菜單界面設(shè)計》 《基于節(jié)點編號的通用樹狀菜單設(shè)計方法與實現(xiàn).pdf》 按照他們的設(shè)計方法，鼓搗了一個版本，能用，挺好，但是也糾結(jié)。 因為他們用了樹這種數(shù)據(jù)結(jié)構(gòu)。對于程序運行來說，非常好，效率高。 但是對于我來說，菜單代碼是一次性的，但是菜單內(nèi)容，卻是會經(jīng)常改的。 讓我用人腦去維護一個包含幾十個上百個菜單的樹，不容易。
想來想去，這些菜單到底有什么不好？對于我來說，為什么不好用？ 得出下面結(jié)論：
-
管得太寬 菜單，你就管菜單切換就行了，到了最低一層，也就是實際的測試功能，就不要管了。 菜單切換是類似的，實際測試都是不同的。比如在菜單中，按鍵1，是進入第一個菜單。但是在測試中，按鍵1，功能都不一樣。 如果菜單連這個也要管，相同動作功能太多，無法進行統(tǒng)一抽象，就很難模塊化。
-
出發(fā)點不一樣 上面說到的菜單，出發(fā)點都是如何設(shè)計一個好的菜單數(shù)據(jù)結(jié)構(gòu)，讓程序快速，高效運行。 我想要的卻是一個容易維護的菜單結(jié)構(gòu)，至于菜單的代碼有多亂多糾結(jié)，沒關(guān)系， 而且，幾百上千個菜單，就算用輪詢的方法，也不過幾百us吧，沒關(guān)系。
根據(jù)需求，我重新設(shè)計了一個菜單結(jié)構(gòu)體
/**
* @brief 菜單對象
*/ typedef struct _strMenu { MenuLel l; ///<菜單等級 char cha[MENU_LANG_BUF_SIZE]; ///中文 char eng[MENU_LANG_BUF_SIZE]; ///英文 MenuType type; ///菜單類型 s32 (*fun)(void); ///測試函數(shù) } MENU;
是的，就這么簡單，每一個菜單都是這個結(jié)構(gòu)體 用這個結(jié)構(gòu)體填充一個列表，就是我們的菜單了
const MENU EMenuListTest[]=
{
MENU_L_0,//菜單等級 "測試程序",//中文 "test", //英文 MENU_TYPE_LIST,//菜單類型 NULL,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 MENU_L_1,//菜單等級 "LCD",//中文 "LCD", //英文 MENU_TYPE_LIST,//菜單類型 NULL,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 MENU_L_2,//菜單等級 "VSPI OLED",//中文 "VSPI OLED", //英文 MENU_TYPE_FUN,//菜單類型 test_oled,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 MENU_L_2,//菜單等級 "I2C OLED",//中文 "I2C OLED", //英文 MENU_TYPE_FUN,//菜單類型 test_i2coled,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 MENU_L_1,//菜單等級 "聲音",//中文 "sound", //英文 MENU_TYPE_LIST,//菜單類型 NULL,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 MENU_L_2,//菜單等級 "蜂鳴器",//中文 "buzzer", //英文 MENU_TYPE_FUN,//菜單類型 test_test,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 MENU_L_2,//菜單等級 "DAC音樂",//中文 "DAC music", //英文 MENU_TYPE_FUN,//菜單類型 test_test,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 MENU_L_2,//菜單等級 "收音",//中文 "FM", //英文 MENU_TYPE_FUN,//菜單類型 test_test,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 MENU_L_1,//菜單等級 "觸摸屏",//中文 "tp", //英文 MENU_TYPE_LIST,//菜單類型 NULL,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 MENU_L_2,//菜單等級 "校準(zhǔn)",//中文 "calibrate", //英文 MENU_TYPE_FUN,//菜單類型 test_cal,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 MENU_L_2,//菜單等級 "測試",//中文 "test", //英文 MENU_TYPE_FUN,//菜單類型 test_tp,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 MENU_L_1,//菜單等級 "按鍵",//中文 "KEY", //英文 MENU_TYPE_FUN,//菜單類型 test_key,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 /*最后的菜單是結(jié)束菜單，無意義*/ MENU_L_0,//菜單等級 "END",//中文 "END", //英文 MENU_TYPE_NULL,//菜單類型 NULL,//菜單函數(shù)，功能菜單才會執(zhí)行，有子菜單的不會執(zhí)行 };
這個菜單列表有什么特點和要求呢？ 1 需要一個根節(jié)點和結(jié)束節(jié)點 2 子節(jié)點必須跟父節(jié)點，類似下面結(jié)構(gòu)
-----------------------------------------------
根節(jié)點
第1個1級菜單
第1個子菜單
第2個子菜單
第3個子菜單
第2個1級菜單
第1個子菜單
第1個孫菜單
第2個孫菜單
第2個子菜單
第3個子菜單
第3個1級菜單
第4個1級菜單
第5個1級菜單
結(jié)束節(jié)點
------------------------------------------------
第2個1級菜單有3個子菜單，子菜單是2級菜單，其中第1個子菜單下面又有2個孫菜單（3級菜單）。
維護菜單，就是維護這個列表，添加刪除修改，非常容易。 那菜單程序怎么樣呢？管他呢。 定義好菜單后，通過下面函數(shù)運行菜單，
emenu_run(WJQTestLcd, (MENU *)&WJQTestList[0], sizeof(WJQTestList)/sizeof(MENU), FONT_SONGTI_1616, 2);
-第1個參數(shù)是在哪個LCD上顯示菜單， -第2個是菜單列表， -第3個是菜單長度， -第4個四字體， -第5則是行間距
注意： 運行這個菜單需要有rtos，因為菜單代碼是while(1)的，陷進去就不出來了。 需要有其他線程(TASK)維護系統(tǒng)，例如按鍵掃描。
代碼托管在github：https://github.com/wujique/stm32f407/tree/sw_arch
相關(guān)文件：emenu.c、emenu.h、emenu_test.c
當(dāng)前代碼：
1實現(xiàn)了雙列菜單，用數(shù)字鍵選擇進入下一層。每頁最多顯示8個菜單（4*4鍵盤用1-8鍵）
2 實現(xiàn)了單列菜單，通過上下翻查看菜單，確認鍵進入菜單。 3 天頂菜單未實現(xiàn)，誰有興趣可以加上。
3 基于LCD驅(qū)動架構(gòu)，這個簡易菜單自適應(yīng)于多種LCD。
效果如下，有需要的盡管拿去，不用謝。
顯示效果
128*64 OLED
128*128 tft lcd
320*240 tft lcd
總結(jié)
類似菜單在我開發(fā)的產(chǎn)品上已經(jīng)推廣使用。 經(jīng)測試，可以明顯減少測試程序代碼量，節(jié)省程序空間。 并且易于修改和維護。
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
