STM8 Low Power Run引發的問題

STM8 Low Power Run是最省電的執行模式，省電省到連Flash ROM的電都關閉，只使用SRAM執行程式。
但引發一個有趣的問題：如何將程式載入到RAM中。

有些編譯器支援inram這個函式修飾字。
但bee個人是覺得1KB的RAM中若是有幾個函式都是inram，是會有問題的。
因為inram也是有分不同狀況，不會全部狀況的都是要用到inram。
也就是不同狀況inram的函式不同，為了節省RAM，都是要用時才使用Flash複製到RAM。

這樣就會產生程式是存於Flash中，但執行時在RAM中。
這樣子並不符合一般編譯器運作原理，且會引發程式重定位問題。
比較簡單的方式是，在RAM中執行的程式用另一個專案去編。
再將Machine Code以data的方式存於Flash ROM中，執行inram前再將程式複到到RAM中。

MCU多功能IO應用

確定STM8是6502進化版，沒想到是在這種狀況下學到6502。
不管其核心，ST的周邊系統是不錯的。

在使用開發板的觸控應用，發覺效果不錯。
可是其上的STM8使用的是一般GPIO腳。
原理是將GPIO設定高電位、低電位及高阻抗之間變換做RC充放電。
並應用輸入位準變換來測RC充放電時間。
真是將GPIO用到極致。

要不是從信號上來看，光看程式應是無法看懂是如何做觸控檢測。
所以MCU程式，並不是純軟體，而是信號產生及處理的程式。

STM8使用評估

STM8是一個8位元MCU。
所以，它和8051及Cortex M0+的關係造成Bee做為評估的原因。
其實又和MSP430也有一點關係。

就價格來說，Cortex M0+已將8位元及16位元MCU價格給封頂了。
所以只能在Cortex M0+無法達到的地方才有考量其他微控器的需求。
Bee就遇到，主是功耗考量。

在具有功耗考量的環境，其實就是使用電池電力的環境。
長期以來一直是MSP430的天下。
不過MSP430和Cortex M0+的價格已經開始重疊。
再低價下去，就要往8051做為考量。不過8051的功耗似乎是低不下來。
此時Bee想到FAE曾經告知，現行新的8位元MCU其功耗不比MSP430來得差。
這是有可能的，因為不考量效能的狀況下，8位元MCU其邏輯閘數是較低，功耗也可較低。
所以就去評估STM8L051F3這個MCU。

STM8除核心外，其週邊架構和STM32是同一套結構。
這個架構會使得習慣使用STM32的C語言使用者容易去習慣STM8。
週邊從STM32來的特性沒有降太多。
有12位元ADC、USART、SPI、I2C及RTC，放了不少。
還有DMA，可以節省通信上的控制。這點Bee還蠻喜歡的。
另一個可以利用UART做軟體更新，只需利用原先UART通信，不像MSP430是另外一型通信格式。

只是8位元MCU的價格及功能，Bee看了只是覺得做MCU硬體的錢還真難賺。

如何在VS2010下編譯64位元組合語言

查了一些資料，自己試了一下。簡單記錄以免又忘記。
1. 在VS2010下面開一個新Project，選用Empty Project，這點和開純C的程式一樣。
2. Platform改為x64
3. 點專案名右鍵，找到Build Customization，將其masm選項打勾
4. 在Source File下加入 *.asm。若為新檔，可以先選用C++，再將副檔名改為asm。
5. 修改Proprety內的設定:
   a. 在Advanced下的Entry Point寫上啟始函式名
   b. 在System下的SubSystem選一個型別

看起來容易，問題是不好查。
除錯時只要將Disassembly打開就可以了。
有了除錯器，再來就簡單了。

64位元組合語言讀書心得

除了介紹X64組合語言外，也介紹了Win64 ABI。
看了Win64 ABI終於了解為何Win32的程式在Win64下是無法使用的。
因為改了基本的C函式呼叫的動作。
為了增加C函式呼叫的速度，將原先參數堆放在Stack的動作，部分改到暫存器中。
這確實會增加執行效率，而Bee在ARM處理器也看到是用這樣的動作。
Win64 ABI是使用四個暫存器 RCX, RDX, R8, R9。
一時好奇去查了一下Linux ABI用了六個RDI, RSI, RDX, RCX, R8, R9。
看來大家都是用同一招做C函式呼叫加速。

其他的，就和一般處理器差不多。
再下來就是我自己的作業了：寫一個程式。

程式寫好，非但沒有讚美，反而被罵！

這是以前公司真實事件。

公司機器從我進公司以來，一直有生產調精準度問題。

機器程式到我手上已有四年，產品必須改善功能才能追上市場腳步。

在新加功能中，多了一個檢知器，可以看到工件上標記，並進行加工。

開發過程中，發現系統使用3*3矩陣做映射對位。這塊程式古老到超過十年未有人去動。

為了符合新觀察到的現象，我使用4*4矩陣來做映射對位。

效果出奇的好，精度提高4倍。且生技工程師也稱讚比以前好調很多。

這次修改只動用到軟體，沒有增加任何硬體，等於未加入任何成本。

我認為這是件不錯的事。

 

主管列入績效，卻沒有下文。

去追結果，此項似乎被老闆刪除了。

 

半年後，主管提出我升職申請，再次列入績效內。

很怪的是，我升不了。要不是主管拼了命一再申請，我根本升不了。

 

既然升了，總要報告我的工作績效。

一提到此項功能，我總算了解我升不了的原因。

在研發會議上，老闆指著我這個項目，對著四十幾位工程師面前說：

"這明顯就是一個軟體錯誤，只是修正錯誤，根本不是功能。你根本不夠格談這件事。"

好吧！這件事老闆如此說，我也不回嘴。

接下來，我便報告目前我手上維護機器數目及名稱。大約有五十多機種。

 

三個月後，我離職了。還好接手工程師程度好，沒有問我太多問題。

公司機種大約一百多種，在我手上快一半，銷售數量佔產出機器70%。

 

真不知老闆到底在想什麼?

新工作一年感想

一句話：突飛猛進。

工作量大，新技術不斷出現。部門人口暴增三倍。
所以就沒有多少時間寫文章了。

一邊工作，一邊找人。只是，人難找。
找嵌入式系統的人，都是做手機，不想來碰硬體。
找單晶片的人，不懂RTOS。
找馬達控制的人，幾乎沒有工作經驗。
找影像處理的人，不幸的目前無空缺。
有合的真的不多。