工作中，很少使用stm8s，但是由於這顆u在通用u中的**實在太誘人，在乙個非常簡單的應用中使用了它。
需求：根據主控板的串列埠指令，控制風扇轉速。
技術要求：1. 風扇為兩線普通風扇，24v供電，功率3w，三個併聯使用；2主控板與該風扇控制板通過串列埠485通訊；3.風扇速度設定三種a停轉 b低速靜音 c 高速。
電路設計：1使用mc34063設計24v轉5v給stm8供電；2.由於ssop20引腳的晶元手工焊接容易不良，選擇lqfp32封裝的stm8s005k6；3. 使用75176通訊晶元；4.使用tip122晶元驅動風扇。5.設定乙個微控制器口控制的led指示燈。
軟體設計：很簡單，串列埠接收指令，如果指令中改變了風扇的速度，則，通過改變控制tip122的pwm，達到控制轉速的目的。
第二步，串列埠通訊，沒收到一次翻轉led控制電平。使用ust to 485模組，電路板上電後，通過串列埠助手傳送資訊測試通訊。ok
第三步，編制串列埠通訊協議，用第二步方法測試，每收到完整一幀，led翻轉。ok
第四步，整合所有程式，其中led用來只是串列埠收到完整一幀資料。用串列埠助手測試ok。
第五步，跟主控板連線，實際應用，偶爾會出現風扇板led不亮的問題《即未成功接收到指令》，且出現led不亮後，不斷電的情況下，無論怎麼插拔串列埠無法讓led亮起《即永遠的不正確執行了》。
該現象偶然出現，使用串列埠助手測試，永遠好事，百思不得其解。於是先給主控板和風扇板單獨供電，之後再連線通訊電纜，百試不爽，不會出現問題。看來問題出在初始化附近，猜測是不是初始化設計的**不合適，開了串列埠就收到資料會出現宕機問題。
於是將串列埠的初始化放在最後，等所有初始化完成後，放置一段led閃爍程式，再來初始化串列埠，再實際聯機，仍然會出現此問題。這個時候，真的摸不到頭腦了，除錯陷入僵局！怎麼辦，沒辦法，先放著去吧......
晚上洗澡的時候，把整個stm8的啟動過程從加點開始系統串聯一遍，突然腦子裡意識到似乎少算了乙個東西，這個東西因為stm32的緣故，而忽略了stm8與stm32的不同！！那就是bootloader。stm32的boot，需要改變兩個管腳boot0，boot1，實現從boot啟動還是使用者程式啟動，而stm8的boot，沒有硬體的選擇，工作過程是上電，檢查是否有boot指令，有則進入boot，在一段時間內無，則進入使用者程式，想到這裡，和我們未初始化就宕機好像能對應的上，如果上電進入了boot，而我們又實際沒有進行boot操作，則stm8一直會再boot內出不來，進不去使用者程式，就會體現處死機現象出來。好，明天繼續試驗，估計差不多就是它了！
ok，第二天來了之後，通過配置項把stm8的boot選項設定為bootloader disabled。重新上電，very good ，成功。
事了之後回顧排除過程，依然是經驗主義導致思維禁錮，潛意識就認為這裡不可能出問題，結果排查的時候總是讓真正的元凶漏網。跳出程式設計和排錯的環境後，整體把所有環節列出，再來排查，就很輕易找到問題！所以，除錯的過程，第乙個要對所有的部分持有懷疑精神，第二個不要埋頭苦調，而是應該跳出局外思考全域性。以此為戒
STM8S的can波特率設定
為了掌握如何設定stm8 32 can的波特率，首先我們得先了解一下位時間特性。位時間特性邏輯通過取樣來監視序列的can匯流排，並且通過跟幀起始位的邊沿進行同步，及通過跟後面的邊沿進行重新同步，來調整其取樣點。它的操作可以簡單解釋為，如下所述把名義上的每位的時間分為3段 同步段 sync seg 通...
簡單介紹下關於STM8S的幾種低功耗模式
stm8s105的低功耗模式總的來說有四種 分別是等待模式，停機模式，快速活躍停機模式和慢速活躍停機模式 1 等待模式 可執行指令wif 進入等待模式，該模式下主cpu停止工作，但其外設不停，嚴格來說只能算是降低功耗而不能算低功耗，該模式可由amu或外部中斷喚醒 2 停機模式 可執行指令half 進...
k8s中namespace的使用
namespace 命名空間 是kubernetes系統中的另乙個非常重要的概念，namespace在很多情況下用於實現多租戶的資源隔離。建立namespace root k8s master k8s kubectl create namespace qiangge namespace qiangg...