參照：
多謝 master 點到重點，我把顯示字串函數改成上述的作法將所有的字串建立陣列，再呼叫顯示，可以成功組譯執行，目前顯示多達 15 種畫面都沒什麼問題，再來將逐步加入一些數學計算，若有其他發現再 PO 上來報告。

以前以為 Real time OS 只是做電腦主機板的人才需要去看的，從不知道對單晶片寫作也有幫助，因為以前以看單晶片的書為主，而且並沒有提到所謂的 OS 觀念。

1.不需更新時那就把顯示LCM的TASK停掉就好。需要不斷更新的，更新率也不用太高。這你很自由的決定...

2.SHOW_STR("Auto Protect");<--這樣的隱誨行為最好少用

寧願多打一些碼類似：
const rom char str1[]="Auto Protect";
//...
SHOW_STR(str1);

就算是寫單晶片，用不到OS，不過建議還是把OS的書念一念，對單晶片程式能力會提升。亞瑪遜打RTOS或Real time OS就很多書可以看了，這些投資不要省。一般中文翻譯的恐龍書一類也可以看。

當你程式寫到很複雜或很進階的時後，很多單晶片的書其實是「無三小路用」...

參照：

請問 master 大大：
上述的作法是不是類似七段顯示器或矩陣 LED 掃瞄的方式，每 0.5 秒將「顯示位置變數」內容取出來刷新一次畫面？由於我的畫面大約有 4 種，而且通常是顯示一次之後資料就停留很久，直到下次變更到其他畫面，不知道這樣還需不需要定時去更新一次？

我現在用的 LCM 顯示字串函數是從 Hi-Tech C 安裝目錄裡面的範例看到的，我把主要部分貼出來一下，SEND_CHARC 因為沒有問題且有點長，所以暫時沒貼出來。

請問這些字串在編譯時是放在 ROM 裡面嗎？而當他傳給函數時，會不會用到 BANK0 的資源，我懷疑這是和數學計算相衝突的原因，請問還有其他的方法將字串傳給顯示函數嗎？謝謝。

在中斷函式裡作xxx，這是一個很好的題目，因為本身就有一大堆規則，還要能達到「漂亮」的演算與程式，等未來工作之後可以好好想想，咱兒再來討論。現在太早了。

一般用 3) 的一個分支，即Eigen兄與版大所提及的，我寫白話一點

UART interrupt function // 或其它 TIMER 類似與適當的
{
...
*rev_buffer++ = UART_RECEIVER
...
if(rev_buffer_is_full){ LCD_entry_flag = true 合併 strcpy(...) etc.}
...
}


在 main() 裡面
do while()
if(LCD_entry_flag == true)
{
LCD_print()
disable_interrupt
LCD_entry_flag = false
enable_interrupt
}

基本的C教學用程式，一般不會有這類玩意，請找大型的實用程式，這通常不會是 for PIC 甚至不是 for MCU，也不必然是 for LCD/LCM。還有，通常不會是中文，甚者有時連英文的註解都沒有……

至於後面提到的算是程式組織與架構，以及演算法改良的問題，這是屬於「軟體工程」的領域，這書對生手等同無字天書。還是那一句，善用google，看別人寫的程式，了解他們的想法與作法，是最快也是最輕鬆的方式。

比如說Voltage RMS 計算，DSP使用加乘法與布林運算就搞定它，但如果直接套用課本上的公式，一定是一堆浮點加三角函數在跑，問為什麼？「這就是專業不一樣的地方。」「這就是吃飯的傢伙。」

如果google上找不到，得等看看有沒有善心人士要供養啦。

「OH MY GOD! 這年頭還有人不會google嗎？」學會寫程式前，先學會使用google找程式碼。為什麼我隨便按「vrms calculation .c」就一堆？

那，請努力地按吧！

參照：

這是不可能的事情，LCM寫入的速度跟LCM本身有關係，就算不用delay去用check busy flag那也要花時間，若寫入的資料很長那要花的時間就更久了。一般我再更新LCM畫面的時間間隔是0.5秒更新一次，對人來速度也足夠了，更新在快的話，變動的數值也「糊」成一團，沒啥意義了。

現在我用的uC大多是PIC18或是16bits元件，遇到需要LCM顯示，都會偷懶用RTOS。像uc/so提供Delay(H,m,s,ms);這類OS專用Delay函數。

要不然就是LCM顯示的工作放在最後才作。

通常有個小訣竅就是不要使用範例顯示字串的function，自己配置顯示區域的RAM空間和顯示位置變數，每次大迴圈只顯示一個字元，然後遞增顯示的指標，或利用timer中斷控制LCM的TASK，然後LCM的task工作就是不斷顯示位置變數指到顯示空間的RAM空間的Data。您可以用timer控制顯示週期。以16*2LCM為例，10ms顯示一個字元，整個畫面320ms就能更新完畢，而且畫面也不會太花。和前面Eigen是一樣的...，我看過老外寫的TIP，有用環狀佇列也是一個不錯的點子。

其他TASK要顯示資料很簡單，只要把資料寫到配置的空間就可以。

參考看看囉...

一般在而言，我是不會在中斷程式裡去做 LCD 的顯示動作，因為太花時間了，有可能會影響到系統的效率。我的做法是：如有東西要在中斷裡顯示，我會設個顯示旗號等離開中斷返回主程式後再做ＬＣＤ的顯示。

謝謝大大提供的方法，我原本的意思不是要讓 LCM 跑快一點的「效率」，只是希望能夠減少堆疊使用和程式碼，不過如果能夠再快一點也不錯。

我後來發現我的問題其實不是出在 LCM 程式需增加速度「效率」，而是因為其他的數學運算太多，因為之前沒有加入 LCM 畫面的時候組譯都沒有問題，後來把數學運算部分程式通通拿掉後， LCM 畫面寫再多都不會編譯錯誤，先入為主的觀念讓我以為是 LCM 程式在搞鬼，所以我應該想辦法精簡數學運算式才對。

颱風大大可否再詳細說明一些，尤其在中斷函數內如何控制 LCD 的部分，謝謝。

PSIR：
您的想法我可以理解，所以回這一篇，不過先話說在前頭，一般因為提問者的基礎知識不夠，所以就算是說了，往往也變成是對牛彈琴，故一般看到，這群人大都直接跳過去，因為只救可救之人是最大原則。單實作不夠，書也要多讀，程式也要多看。

一般LCD，或其它很多I/O的作法如下

input
delay 10ms
input
delay 1ms
output
...

上面問題在於 delay 太久，浪費了 CPU time，所以會有幾個方法解決

1)在RTOS下，使用 sleep()，或直接使用 suspend() 取代 delay()
2)如果TIMER或其它類似的中斷夠用，直接寫在中斷函式內
3)寫在user application area並使用semaphore一類的變數控制
4)族繁不及備載

比如說(2)，在中斷程式內的工作

{
TIMER off
switch(step)
case 0作
output 1
設定TIMER作delay,10ms
case 1作
output 2
設定TIMER作delay,2ms
case 2作
input 1
設定TIMER作delay,1us
...
case END作
直接返回
最後尾巴的地方
step++
TIMER on
返回主程式
}

如果是一的話，很直覺地寫成
output 1
sleep(10ms)
output 2
sleep(2ms)
input 1
sleep(1ms)
...

以上是演算法是概念性敘述，在實作上會更精細，不會只有這樣而已。這一類程式應該不難找才是，不過不相關的code也許更多，它也許是不寫LCD的，但概念完全相通。另，追求高速是DSP的工作，控制要求的是穩定。那，祝順利。

大家好:
樓上先進說的對,但LCD本來就比較慢,
這是目前無法改變的事實,寫個資料要幾十us,
夠久了吧!

Thanks.

有效率要看你從何而來

要容易寫，用c ，那你就很難要求 mcu 要有效率

當你追求 mcu 的極限時，你就會改用 asm

pic16 只有 8 層stack，扣掉 中斷只剩 七個，保留一個做備用

一般我們在實作上，會極力控制 call 的次數，將 stack 控制住


但是從 c 入門的，就完全沒這種概念，能call 就call，自然效率差，反應慢


你必需知道的兩個要點：

一、lcd 畫面的控制：一般的 demo 程式大概都是這樣做

移到第幾行第幾個位置，寫入，一直重復這樣的動作

當你需要產生數種畫面時，用上述的方式，你的 lcd 控制程式會非常複雜

比較好的做法是直接配置 ram ，例如你的 lcd 是 2*20，那就配個 40byte 的ram

畫面產生 和 更新是兩個不同的程式

我可以在a 程式計算畫面，更新 ram 的資料。並 set renew flag

在 b程式 檢查是否有 renew flag ，有才將 ram 的資料寫入 lcd


二、不要一直call call call，記得 call 完要回主程式。

為什麼你的 stack 會爆掉？因為你沒有回主程式的習慣，你們習慣，call A fucntion, A 裏面又call B，B 裏面又 CALL C ，CALL 到天荒地老，沒完沒了

然後沒幾下 STACK 就OVERFLOW

實際上是要 CALL a ，然後 A 裏面 SET CALL_B FLAG

主程式檢查到 CALL_B FLAG 才又去 CALL B ，B 裏面 SET CALL_C FLAG

主程式檢查到 CALL_C FLAG 才又去 CALL C

以此類推

整個程序的思考羅輯應該是這樣才對