sdk demo一大堆沒用的代碼,有各種各樣的api又沒資料教怎麼使用,封裝又太亂,求出個像esp8266一樣的接口SDK,不知道搞這麼多庫進去幹嘛,是別人沒網去找庫嗎?太惡心了,連一個延時函數也要封裝一下!,rtos那些優先級被使用 ,等等用的不清不楚,高一大堆亂七八糟的代碼!
很多時候呢,埋怨並沒有用,資料文檔確實挺少,畢竟生態還在建設嘛,你認為demo沒有用,可能僅僅對你沒有用而已,只是我覺得還是挺好用的。有這時間還不自己多摸索一下,不用那麼浮躁嘛,現在不是有問答社區了,不會用的問就好了嘛,大會看到能幫忙的都會幫忙回答。
Makefile工程模板可以麼?我正在調試,調試OK後共享給大家
我這邊搞了個MakeFile的模板,可以參考 http://ask.winnermicro.com/article/57.html
SDK確實用起來不是很方便,各個模塊耦合性很強,很難單獨拿出某一塊來用。官方的想法可能是想做一個大而全的平臺,想讓用戶可以傻瓜式的開發。但是離目標還很遠。這一點其實我覺得完全可以仿其他廠家成熟的模式,就像國內為什麼那麼多和STM32類似的芯片,就是因為大家已經熟悉那個框架了,容易上手。個人提幾點建議,也許有助於該芯片的發展:
1、SDK分層模塊化,底層包裝寄存器等硬件外設,各個功能模塊完全獨立。應用層再根據功能劃分包裝,可以綜合多個模塊實現一定複雜功能模塊。這樣既適合裸機基礎應用開發,也適合頂層複雜應用軟件開發。
2、SDK需要可裁剪,類似前面所說,做一個LED閃爍,編譯出來都有幾百K了,雖然有些宏定義可以關掉,但是有些不管有用沒用都不能關掉,否則報錯。我覺得沒用的模塊不能關掉就是SDK的最大的BUG,比如藍牙和WIFI,如果說設計這個芯片的時候就是設計成必須開啟藍牙和WIFI才能工作,那我無話可說,否則就是SDK設計的問題。
3、資料的問題以及軟件BUG,如果說官方沒精力維護和更改,完全可以發動大家群策群力。發布懸賞,發現一處資料問題或一個軟件BUG,獎勵若幹元,相信改進起來比官方效率高很多。官方還可以節約一筆不菲的養人費用。就好像我現在摸索這個芯片,都找到好幾個BUG了,但是沒地方講,講了也不知道有沒有用,只能讓BUG繼續存在了。
本人整理了一下 SDK,弄了個 VSCode + CMake + Ninja 的項目模板,有需要的可以去試試
研究了幾天了,發現咱們這SDK以及對應的教程有如下特點:
1、大而全
2、多而亂
有點像頭腦風暴,不管先後順序,都有了,感覺虛無缥缈,一點也不踏實。
希望針對以上問題進行改進,尤其是介紹清楚以下內容:
1、各個功能函數各種前綴是啥意思?
2、針對示例重新完善,主要是示例是否在操作系統下運行,建議參考下RT-THREAD的教程。
第一: 用demo SDK 開發代碼混亂。
第二: SDK集成的第三方庫不易維護、升級、擴展。
第三: 有些功能往往不需要太複雜,用的也不多。自己寫的代碼效率高,導致自命名文件名被集成的第三方庫占用(不得不另起文件名)。
第四: 開發自己程序往往都是針對性的功能,你實際用的功能不及 SDK 中的庫十分之一。
第五: 程序越大,下載燒錄越慢,比如:明明就點一個LED程序,程序實際只需一秒下載完成,偏偏花了十多秒下載完成。
第六: SDK 越複雜,問題越多,因為不是你寫的代碼,那些功能怎麼樣處理和使用的都不清不楚,如果不買 調試器 很難查到bug. 這就又涉及到你必須花個70多買個調試器。
對於喜歡精簡代碼、強迫症的我、用著很不爽!
官方要是少花時間去集成第三方庫,如果開發一個SDK只提供芯片的接口,將接口、芯片資料文檔寫好,總比去弄這些花花草草好,因為第三方庫是通用庫,網上什麼資料沒有,網上沒有的資料,你集成進去也沒有用,除非官方自己寫第三方庫教程,不然別人還是不知道怎麼用,這也是國內芯片永遠比不了國外芯片是有原因的!