改用免費軟體來開發。所以重新試工具。
就簡單編個LED控制程式，程式是沒有問題，因為HAL都限定好名字。
比較有問題的是除錯。
Run為下載後全速跑。好像沒有中間停下來。
Debug是可以單步。也可以看裝置設定。也可以下載記憶體內容。
剩下的就是適應及功能組合。
2020年9月13日 星期日
2020年3月31日 星期二
手遊轉PC趨勢分析
最近微軟大放送無線搖桿，這不算什麼，也許在清庫存。
然後Bee還在玩為數不多的手遊都開始出PC版本，基本上都支援無線搖桿。
這就怪了! 怪事不會連著來，一定有事。
資訊不足，改用反推法。
若手遊要移植到PC，應做那些事?
- 使用的電腦語言可以換去PC重編，沒人會想重寫，又會有維護問題，沒有相同的程式碼一定不可能。
- 驅動程式要相容，這個不保證，但工一定比第一項來得小
- 引擎要相容，主要是3D引擎或是物理引擎。若有同套問題就小。
個人認為2,3項看運氣，但game數量如此多，一定有符合的。
再來就是第1項了。PC軟體主導是微軟，若是微軟的compiler打通這條路，後面會自然生成。
微軟如何造這場局往微軟想要的地方發展?
搖桿是XBOX的! 也就是局勢要往XBox走微軟才有商機。XBox也是一種PC。
這樣路就明顯了，若是手遊轉PC很簡單，同時轉成XBox也會很方便。
重點是PC的操作和XBox有點不同，這個坎要弄平，怎做?
就大量撒搖桿給PC。這下就串起來了。
嗯，這局有很多行銷行為，值得再研究。
2020年3月19日 星期四
手機上C compiler應用心得
算是記錄，因為還沒有找到理想的。
個人目標是做MCU上的程式試跑及除錯用。
(老婆逛街時放置狀態)
Mobile C
簡中介面，範例多。也可以連上手機部分裝置。
但只能單檔，在移轉應用上不方便。
移轉來的程式要另外作業，不容易作這樣的準備。
Cxxdroid
可以使用CMake，但試跑我的直譯器時，出現segment fault，不知道是那裏有問題。VS2019下沒有什麼問題。同程式在Mobile C下沒有問題。
CPP N-IDE
也可以用，相容性不錯。但缺少可以用的make，所以目前也是只能單檔。
2020年2月19日 星期三
工件語言及工作語言的功能及插件功能設計
DXP或是SVG都是工件語言，它只描述工件的樣子，但沒有說是如何做加工。
機器手動作語言是有加工程序，但它有它自己的語言及函式，和工件語言並不相同。
且各家機器人使用的工作語言也都不相同。
所以MCU製作的機器人就有二套語言，一個是工件語言解析器，另一個是它自己動作用的工作語言解析器。
工件語言解析器分解後變成工作語言格式，這是一般工作。
但現在軟體都流行插件，也就是使用者可以加工作程序。很多軟體會後加工DXP檔，就是要加入一些機器才有的工作行為。
若是沒有將工作語言獨立出來，插件功能就無法成形。
所謂的插件，就是工作語言函式，它由使用者從機器操作界面輸入，然後在指定的工件語言指令中插入。
對於使用者來說是工件語言指令插入，實則是分解成工作語言後才插入，只是使用者看不到工作語言層的狀況下會以為是工件指令插入。
本來是想以巨集方式解決，就是使用文章插入的方式做。
但後來想到有可能要解析工件語言參數的狀況，改成用函式插入，這樣就可以在執行時取得參數做判定。
有了工件語言，也有機會做使用者新加指令的可能。
在解析工件語言，若遇到無法解析指令，就轉跳去工作語言的使用者新增指令掛勾，就有機會利用工作語言去做新指令解析並插入對應函式。
在實際上這個插件功能可以做什麼? 主要用在加工中插入檢查功能。
機器手上除了加工手指外，還有camera手指，工件語言不會使用機器檢查機制，就要用插件來做。
變成加工到一半，可以叫camera進來看，簡言之就是拍照存證。
這樣的機器可以由使用者加檢查點，或是改變部分加工行為。
照顧用機器人工作及需求分析
機器人取代人的工作，個人是認為取代照顧工作最多。
此類工作需求量大，照顧對象固定，可以寫成標準照顧程序。
問題出在辨識能力，先不管需求多少計算力，依辨識反應時間可以應用的需求就不同。
一般檢知仍以camera識別為主，其他環境檢知為輔。
辨識反應時間定義為：輸入新的影像資料，辨別出目標物的狀況，並找到對應的處理行為。
依據反應時間不同，應用的目標就不同。
反應時間級的定義：1分鐘級，表示可以在1分鐘到10分鐘內完成。
若是反應等級為10分鐘級的，可以做為植物照顧用，應用於自動化農場。
若是反應等級為1分鐘級的，可以照顧魚類，應用於自動化水產養殖。
若是反應等級為1秒級的，可以照顧動物，應用於自動化畜牧。
反應到0.1秒級的，可以照顧人。
反應到0.01秒的，可以開車。
所以MCU做機器人再和AI聯合，後面還是有很多事可以做。
2020年2月18日 星期二
機器人座標轉換規劃
主要是幾個工作座標轉換之間的關係。
目前機器人都是吃工件檔案，機器手再輸出。中間其實沒有如此簡單。
因為機器人都是由馬達控制，所以馬達要做加減速控制。
馬達吃的指令其實是移動量/單位時間。
將馬達吃的指令也當成是指令，MCU的角色就是直譯器。
主要是將工件指令一路分解到馬達指令。
工件指令可能是DXF檔一類的，實驗或是模擬也可以用SVG來做。
目前有數個轉換在中間。
1.工件指令轉成工件座標：主要是轉成簡單向量，因為向量圖檔有一大堆高階指令，主要是分解成單一向量座標。
2.媒體座標分割：有時輸出座標過大，可能要做分次輸出，或是和檢知器對位做座標修正。
3. 分割/分檔管理：可以做輸出管理，或是重覆次數管理
4.裝置映射：機器人指尖轉換，因為機器人指尖是可以變換的。加工用的和檢查用的不會在同一個座標上。這個就要套上不同的裝置映射。例如鑽頭和camera可以在同手臂上，但看的位置不同，加工中檢查，可以快速轉換。
5.工區座標轉換：因為加工手指可能可以控制，也有被動控制，在這一階完成轉換。平移式手臂比較好轉換，轉軸式手臂就要解反向機器人運動學矩陣。另外機構座標檢查及保護也在這一層。
6.馬達路徑規劃：向量轉成馬達指令，馬達加減速路徑解析，才可以產出移動量/單位時間的指令列表。
2020年2月5日 星期三
2020年1月21日 星期二
MCU上直譯器的應用
直譯器(Interpreter)在電腦語言上的應用已超過編譯器，但MCU工程師卻沒什麼在用。
主因在於RAM空間不足難以放入實際應用。
MCU大部分應用的RAM都是受限的。它是稀缺資源，而正統語言編譯都是用RAM很多的，二者互斥下，難有發展。
但就算是簡單直譯器，在MCU的應用中，都是很好用的方案，對於動態的事件及實務實驗有很大的幫助。
再來就是個人實務上所使用的及評估的。
終端命令直譯器
用xprintf函式很容易做。也可以轉成各式通信。再加上xmodem傳輸，可以將PC檔案直接對應到MCU內部可以管理的裝置上。
在MCU使用外部儲存上會很好用，不管是用SPI Flash或是SD卡，會很好驗證MCU的工作環境遇什麼。
有時還會看到客戶在操機器，有次從MCU讀回來的log檔中，看到客戶在做開機穩定性測試，它上電一分鐘後斷電，再一分鐘後再次上電，好在STM32有內建RTC，所以時間錄得一清二楚。問題是這種log不是一二筆，而是一整天，所以才會認為客戶在測試。
簡單語言實現
這個要用到的RAM就比較大，對於加工機器來說，常會遇到CNC指令或是其他簡單語言。大部分是用手寫程式做解析，但傳久了，往往也不符合時代(使用者會想要加自己的指令)，此時就可以用到compiler-compiler，它可以吃語法解析，免去人工解析及維護的痛苦。
常用的就是flex, bison的組合，使用的RAM還可以控制。
編程於Flash?
前面都是工作做完就結束，沒有程序控制所以無需做編程。但要實現真的語言就有編程再調用，但編程後要存在那，MCU的RAM是有限的，比較沒有問題就是Flash，有無可能在執行後再加程式於flash ROM上，覺得有機會，但實在不想自造語言，光是找可以改的就找了很久。
Forth改造於Flash ROM編程
Forth語言的編程動作很像C巨集。C巨集主要是文字取代，就是找到指定的字，就進入巨集定義。若是遇到巨集定義字，就進行巨集取代。Forth有點不一樣的地方在巨集定義時以函式指標做編程，巨集取代則改成函式指標執行。
它沒有傳統的compile行為，且大部分是單次寫回，所以改成寫入flash是有機會的，因為flash ROM也可以一小筆一小筆寫回。
但要去改forth編程，將原先bit flag write以flash ROM寫回單位取代。不過有小部分功能也有問題，但是用在高階定義上，先不管，了不起變成子集語言。這樣修改後，可以成功，真的可以在未用的flash ROM上添加新的函式。但再來的問題就卡住，以致無法公開。
因為MCU界面受限，只能用串列通信來做，所以PC端一定有終端機，我在上面試用中文做為函式名，它以Big5為編碼(2 byte編碼)，程式本體是函式指標這個沒有問題。但用手機終端機連上，發現它丟的是unicode(3 byte編碼)，平台問題卡到，暫時先放著了。
MCU可用小型語言
RAM若是更大到1MB(STM32H7系列就有)那就可以放入一般用的小型語言。eLua是最早移入MCU的高階語言，所以lua早就鎖定很久了。但高階語言移入MCU不是沒有優勢，它可以實現從網路直接載入函式庫，就是網路函式庫可以直通MCU，這功能最早實現的就是microPython，也因為網路函式庫直通MCU，使得microPython大為流行。所以傳統MCU工程師一直看不起的直譯器，經由網路函式庫直接對應，改變的MCU直譯器的使用觀感。
2020年1月14日 星期二
STM32免費C，MCU再進化
免費，會造成經濟系統新變化。
STM32也將C變成免費，所以MCU的生態又有新變化。但這個改變不是憑空來的，個人是認為是因應RISC-V的對應行為。
其實免費的MCU C Compiler一直都在，但沒有人整合，不易上手，所以一直沒有流行起來。
這次不同了，由晶片供應商直接供應免費C，看來MCU由ARM一統再次轉成由單一晶片商一統。
C的免費，變成取用C函式庫的障礙會完全消失。再來只剩下電子問題。
在經濟學上的免費，會加速經濟發展。
簡單的模型，障礙如同河，分割二地，二地的物產交換代價大。利潤由特別管道知識的人所獲取。
第一代就是由渡船人取得，對應工程師大約是會電子又能寫組語的人，以及可以設計MCU的人。
後來造橋技術出現，可以造出直接連通的橋，就會變成很方便。
第二代由造橋人收過路費取得，對應工程師大約是會電子又會C的人，因為不用再造基礎運行單位，基本上可以設計MCU的人等於不再有任何優勢。
C的免費，等於沒有過路費，你想會如何?變成只要會C又懂電子的都會進來做生意。生意大爆發。
MCU的使用只要懂電子就行了，因為C是一般人都會的基本技能。
若是C免費是由單一廠商先行發動，又會如何?
等於各大廠商本來都是造橋人，不同的橋大家都因位置不同收不同費用，使用者要精算如何過橋才能省時省錢。現在突然有座橋不收過路費，你想會如何?
再來就要看其他做MCU的廠商如何因應了。基本上非ARM的MCU可以不用考慮了，因為組語維護困難，只能隨時代消失。
訂閱：
文章 (Atom)