welcom ! Handel home

2018年10月16日 星期二

NodeJS PM2 Note

https://github.com/Unitech/pm2

PM2 is a production process manager for Node.js applications with a built-in load balancer. It allows you to keep applications alive forever, to reload them without downtime and to facilitate common system admin tasks.
Starting an application in production mode is as easy as:
$ pm2 start app.js

人工智慧是物聯網時代之核心


人工智慧(AI)是物聯網及工業4.0發展的核心。尤其,當特斯拉(Tesla)推出電動車及蘋果(Apple)發表新機iPhone X推出FaceID之後,讓市場體驗到AI晶片的無限商機。同時,AI應用接受度越高的國家,將對其GDP產生貢獻愈大。我國在既有半導體及ICT技術優勢及競爭力的基礎上,迎合各產業的需求不斷增加,開發出各種新應用晶片,不僅讓台灣在半導體的競爭力絕對在全球可扮演關鍵的角色,同時將為台灣的經濟帶來未來30年的新榮景。

AI晶片包含三大類市場,分別是數據中心(雲端)、通信終端產品(手機)、特定應用產品(自駕車、頭戴式AR/VR、無人機、機器人...)。當前機器學習多採用 GPU圖像處理,尤以Nvidia 是此一領域龍頭,但是,有些業者認為GPU處理效率不夠快,而且因應眾多特定新產品的不同需求,於是,推出NPU、VPU、TPU、NVPU...等等。目前還不清楚哪種架構的晶片會在 AI 大戰獲勝。但(手機)終端市場對於AI晶片的功耗、尺寸、價格都有極為嚴格的要求,難度上比雲端數據晶片更高。為搶未來AI應用市場商機,科技巨鱷如Google、微軟、蘋果企圖建構AI平台生態模式吃下整個產業鏈。

目前來看,未來AI發展有八大新趨勢



趨勢一:AI 於各行業垂直領域應用具有巨大的潛力
人工智慧市場在零售、交通運輸和自動化、製造業及農業等各行業垂直領域具有巨大的潛力。而驅動市場的主要因素,是人工智慧技術在各種終端用戶垂直領域的應用數量不斷增加,尤其是改善對終端消費者服務。

當然人工智慧市場要起來也受到IT基礎設施完善、智慧型手機及智能穿戴式裝置的普及。其中,以自然語言處理(NLP)應用市場佔AI市場很大部分。隨著自然語言處理的技術不斷精進而驅動消費者服務的成長,還有:汽車資通訊娛樂系統、AI機器人及支持AI的智慧手機等領域。

趨勢二:AI導入醫療保健行業維持高速成長
由於醫療保健行業大量使用大數據及人工智慧,進而精準改善疾病診斷、醫療人員與患者之間人力的不平衡、降低醫療成本、促進跨行業合作關係。此外AI還廣泛應用於臨床試驗、大型醫療計畫、醫療諮詢與宣傳推廣和銷售開發。人工智慧導入醫療保健行業從2016年到2022年維持很高成長,預計從2016年的6.671億美元達到2022年的79.888億美元年均複合增長率為52.68%。尤其,台灣累積了20年健保資料,還有正在創建的台灣人體基因資料庫,再加上硬體製造能力等,只要能有效串聯、處理與分析,輔以法規鬆綁、籌建平台與跨領域合作,台灣朝AI醫療發展將很有機會。

趨勢三:AI取代螢幕成為新UI / UX介面
過去從PC到手機時代以來,使用者介面都是透過螢幕或鍵盤來互動。隨著智慧喇叭(Smart Speaker)、虛擬/擴增實境(VR/AR)與自動駕駛車系統陸續進入人類生活環境,加速在不需要螢幕的情況下,人們也能夠很輕鬆自在與運算系統溝通。這表示著人工智慧透過自然語言處理與機器學習讓技術變得更為直觀,也變得較易操控,未來將可以取代螢幕在使用者介面與使用者體驗的地位。人工智慧除了在企業後端扮演重要角色外,在技術介面也可承擔更複雜角色。例如:使用視覺圖形的自動駕駛車,透過人工神經網路以實現即時翻譯,也就是說,人工智慧讓介面變得更為簡單且更有智慧,也因此設定了未來互動的高標準模式。

趨勢四:未來手機晶片一定內建AI運算核心
現階段主流的ARM架構處理器速度不夠快,若要進行大量的圖像運算仍嫌不足,所以未來的手機晶片一定會內建AI運算核心。正如,蘋果將3D感測技術帶入iPhone之後,Android陣營智慧型手機將在明年(2017)跟進導入3D感測相關應用。

趨勢五:AI晶片關鍵在於成功整合軟硬體
AI晶片的核心是半導體及演算法。AI硬體主要是要求更快運算速度與低功耗,包括GPU、DSP、ASIC、FPGA和神經元晶片,且須與深度學習演算法相結合,而成功相結合的關鍵在於先進的封裝技術。總體來說GPU比FPGA快,而在功率效能方面FPGA比GPU好,所以AI硬體選擇就看產品供應商的需求考量而定。例如,蘋果的Face ID臉部辨識就是3D深度感測晶片加上神經引擎運算功能,整合高達8個元件進行分析,分別是紅外線鏡頭、泛光感應元件、距離感應器、環境光感測器、前端相機、點陣投影器、喇叭與麥克風。蘋果強調用戶的生物識別數據,包含:指紋或臉部辨識都以加密形式儲存在iPhone內部,所以不易被竊取。

趨勢六:AI自主學習是終極目標
AI“大腦”變聰明是分階段進行,從機器學習進化到深度學習,再進化至自主學習。目前,仍處於機器學習及深度學習的階段,若要達到自主學習需要解決四大關鍵問題。首先,是為自主機器打造一個AI平台;還要提供一個能夠讓自主機器進行自主學習的虛擬環境,必須符合物理法則,碰撞,壓力,效果都要與現實世界一樣;然後再將AI的“大腦”放到自主機器的框架中;最後建立虛擬世界入口(VR)。目前,NVIDIA推出自主機器處理器Xavier,就在為自主機器的商用和普及做準備工作。

趨勢七:最完美的架構是把CPU和GPU(或其他處理器)結合起來
未來,還會推出許多專門的領域所需的超強性能的處理器,但是CPU是通用於各種設備,什麼場景都可以適用。所以,最完美的架構是把CPU和GPU(或其他處理器)結合起來。例如,NVIDIA推出CUDA計算架構,將專用功能ASIC與通用編程模型相結合,使開發人員實現多種算法。

趨勢八:AR是工具且成為AI的眼睛,兩者是互補、不可或缺
未來的AI需要AR,未來的AR也需要AI,可以將AR比喻成AI的眼睛。為了機器人學習而創造的在虛擬世界,本身就是虛擬現實。還有,如果要讓人進入到虛擬環境去對機器人進行訓練,還需要更多其它的技術。

結語



至於 CPU是否會被TPU、NPU、VPU….等之類新類型處理器取代,答案應該不會。因為,新出現的處理器只是為了處理新發現或尚未解決的問題,而且未來傾向將CPU整合。同時,晶片市場期望能有更多競爭及選擇,不要英特爾、高通獨大。

迎物聯網時代來臨,以往大家認為摩爾定律最後會走到極限,但未來矽世代是異質性及跨界的整合,還有很多需求未出現。NVIDIA執行長黃仁勳則表示,摩爾定律已經是舊時代的法則,GPU的計算速率和神經網路複雜性都在過去2到5年內呈現出爆發性成長。

展望未來,隨著AI、物聯網、VR/AR、5G等技術成熟,將帶動新一波半導體產業的30年榮景,包括:記憶體、中央處理器、通訊與感測器四大晶片,各種新產品應用晶片需求不斷增加,以台灣在半導體的競爭力絕對在全球可扮演關鍵的角色。(2025字;圖1)



引用來處: http://iknow.stpi.narl.org.tw/Post/Read.aspx?PostID=13837

Python 自動化測試

http://www.qa-knowhow.com/?p=1936

Selenium自動化測試技術文章彙整(140+篇!)


http://www.qa-knowhow.com/?p=2531

https://medium.com/@jemmy1234/%E5%88%A9%E7%94%A8-python-%E5%81%9A%E7%B6%B2%E9%A0%81%E8%87%AA%E5%8B%95%E5%8C%96%E6%B8%AC%E8%A9%A6-902d6361b4e3

http://icodding.blogspot.tw/2015/11/pythonselenium-web.html

2018年8月14日 星期二

2018年6月6日 星期三

物聯網、雲計算、大數據、工業4.0、人工智慧和互聯網之間是什麼關係?

轉載 自 https://www.getit01.com/p20171223464751048/
從2007年開始,科學院相關研究團隊發表論文提出互聯網未來趨勢:「互聯網正在向著與人類大腦高度相似的方向進化,它將具備自己的視覺、聽覺、觸覺、運動神經系統,也會擁有自己的記憶神經系統、中樞神經系統、自主神經系統。」。並由此產生互聯網雲腦(Internet Cloud Brain)架構。
  到2017年,隨著人工智慧,物聯網,大數據,雲計算,機器人,虛擬現實,工業互聯網等科學技術的蓬勃發展,互聯網雲腦的架構也逐步清晰起來,從2008年到2017年形成4個版本的互聯網雲腦架構圖(下圖為2017年版本)
  應該說互聯網雲腦是互聯網在進化過程中形成的類大腦架構,它並不是一開始就成熟和完整的,而是在科學探索和商業創新過程中逐步發育而成。web2.0,物聯網,雲計算,工業互聯網,大數據,人工智慧。。,它們不是脫離互聯網的新事物,而是互聯網雲腦發育過程中,由於各神經系統發育的不均勻導致的波浪式高峰,往往是一個技術或模式成熟後,下一個技術或模式才有蓬勃發育的基礎。我們可以看一下人工智慧熱潮產生之前的互聯網進展。
  1.物聯網本質上是互聯網雲腦的中樞神經系統和其控制的感覺神經系統和運動神經系統
  2.雲計算本質上是互聯網雲腦的中樞神經系統,它通過伺服器,網路操作系統,神經元網路(大社交網路),大數據和基於大數據的人工智慧演算法對互聯網雲腦的其他組成部分進行控制。
  3.大數據本質上是互聯網雲腦各神經系統在運轉過程中傳輸和積累的有價值信息。因為在過去50年隨著互聯網的快速進化而急速膨脹,體量極其巨大。是互聯網雲腦產生智慧智能的基礎。
  4.人工智慧本質是互聯網雲腦產生產生智慧智能的動力源泉,人工智慧不僅僅通過演算法如深度學習,機器學習與大數據結合,也運用到互聯網雲腦的神經末梢,神經網路和智能終端中。使得互聯網雲腦各個神經系統同時提升能力。
  5.工業4.0和工業互聯網本質是互聯網雲腦的運動神經系統,這將是互聯網雲腦未來非常龐大的組成部分,它也將包含6中介紹的各種前沿技術。
  6.智能駕駛,雲機器人,無人機,3D列印本質上是互聯網雲腦運動神經系統中最活躍的部分,他們通過延展運動和機械操作,幫助人類完成對世界更強有力的探索和改造。
  7.邊緣計算本質是互聯網雲腦神經末梢的發育和成長,人工智慧技術不但應用在中樞神經系統中的大數據,神經元網路中,也分布到神經系統的末梢。讓互聯網雲腦的感覺神經系統,運動神經系統的末梢控制變得更為智能和健壯。
  8.移動互聯網本質是互聯網雲腦神經纖維種類的豐富,讓互聯網用戶更便捷,更不受地域限制的鏈接到互聯網雲腦中。
  9。大社交網路(Big Sns)是互聯網雲腦神經元網路,也是互聯網雲腦最重要的部分。它由互聯網傳統社交網路Facebook,微信,微博發育而成,從鏈接人與人,發展到鏈接人與物,物與物,甚至包括鏈接人工智慧軟體系統
  10.雲反射弧(Cloud reflex arcs)是互聯網雲腦最重要的神經活動現象,與人類神經系統相仿,也包含感受器、傳入神經纖維、神經中樞、傳出神經纖維和效應器。是互聯網雲腦智能智慧與現實世界互動的重要運行動作。它的種類有7種。將在以後的文章中專門介紹。
  11.智慧城市本質是互聯網雲腦與具體的地域結合的結果,是互聯網雲腦的縮小版應用,智慧城市的建設,從互聯網雲腦的架構看,需要關注城市居民,單位,機構,企業建設統一的神經元網路(大社交)的情況,也要關注城市的雲反射弧的反應速度和健壯情況,譬如防火雲反射弧,金融雲反射弧,交通雲反射弧,新零售雲反射弧,能源雲反射弧等。
1、物聯網:智能家居、智能櫃檯、掃碼飲料機等都屬於物聯網,硬體的機動性配合軟體的操作系統,通過網路傳遞指令的是物聯網。
2、雲計算:將龐大的計算量及較多數據處理邏輯,由程序梳理分發到多個硬體資源,通過軟體程序整體調度,各硬體資源僅負責一部分計算體量,從而實現同時間同步計算,來提高計算效率的一種技術實現方式。
3、大數據:用戶訪問並操作軟體的各項行為記錄及採集用戶的各維度資料等數據,通過時間的沉澱、積累,單個用戶會產生較大的數據量,而幾百萬用戶或上億的用戶更會產生天量級數據,通過演算法邏輯和社會科學能從這些數據里分析出更多的潛在價值,利用這些潛在價值發揮商業作用或解決社會問題的一種資源,叫做大數據。
4、工業4.0: 主要是以提升製造業智能化水平,建立具有適應性、效率性、質量監察性、問題可追溯性智慧工廠的一種理念,主要還是物聯網的思維,將生產中的供應、製造、銷售、效率產生的信息數據整合。最後實現的效果是:人力成本越來越低、風險越來越可控、營銷越來越精準、決策越來越科學。
5、人工智慧:能夠表達的釋義有很多,物聯網也叫人工智慧,軟體產品也叫人工智慧。其實人工智慧是指通過軟體演算法程序,計算出某一項結果後,把該結果運用到決策程序中用於決策。並根據特徵決策出人類所認為的科學答案。比如百度的圖片識別機器人,就是將圖片數據化之後,通過演算法進行匹配並最終找到相似度百分之80以上的結果,通過軟體決策程序進行決策。外行人看到這個功能後會說:「這個機器人還能識別圖片,太TMD智能了」。
6、互聯網:這個其實是一個名詞,從早期的電話線上網,到如今的光纖上網,路由設備只是硬體的承載,伺服器也只是用於資源傳遞、共享、訪問的各個媒介,軟體技術也是基於這些媒介不斷萌生的產物,人類基於這些共同搭建起來的媒介環境下,把生活的方方面面都融入了進去,仿似一張龐大的資源網路,名詞稱之為互聯網。

物聯網的代表就好比摩拜單車就是物聯網的產品體現之一,在不久的將來包括電視都可能和手機等終端進行聯網。雲計算的體現就是阿里雲,給互聯網小公司,政府提供計算能力自己伺服器託管。大數據,任何行為,商業活動只要每秒產生數以億計的數據,需要運算分析用戶行為自己習慣都屬於雲計算範疇。工業4.0簡單說就是依靠以上東西進行C端消費者的需求定製,然後B端工廠再進行定製生產,進行配送。人工智慧就是以深度學習為基礎,演算法為依據的機器學習,機器開始有了自己的學習能力。以上這些都依靠互聯網這個基礎服務在進行。



其實在這些名詞里關鍵詞就是數據什麼是數據呢打個比方我們人就是無時無刻都在收集數據比如用眼睛看就是收集圖像數據用耳朵聽就是收集音頻數據等等那麼收集了數據有什麼用呢就是用收集來的數據再經過對數據的處理來優化我們的行為更好的完成某些任務比如吃飯走路開飛機等等你不收集數據都是無法完成的大數據也是一樣它通過互聯網物聯網等等來收集數據再把收集來的數據通過大算力的計算機處理變成有用的數據就能使互聯網更聰明就可以更好的服務於用戶比如做電視劇的可以從人們搜索那類電視劇多決定他去做什麼電視劇醫生可以根據網上搜索發展流感爆發還有商家根據你的喜好推送產品或是服務當然我說的都是比效簡單的大數據還可以訓練人工智慧未來大數據和人工智慧的深度結合與發展這個潛力是不可限量的還要說一下處理數據主要就是用各種演算法來完成的非常複雜簡單理解就是歸類對比

2018年1月31日 星期三

神經網路加速器大戰開打

神經網路加速器大戰開打

http://www.eettaiwan.com/news/article/20170726NT01-neural-accelerator-battle-begins?utm_source=EETT%20Article%20Alert&utm_medium=Email&utm_campaign=2017-07-27

隨著許多嵌入式系開始變得「智慧」且「自主」,以人工智慧(AI)神經網路為導向的嵌入式系統市場即將起飛,神經網路加速器大戰一觸發…
嵌入式神經網路加速器市場持續升溫,從智慧音箱、無人機到智慧燈泡等越來越多的系統準備在本地執行神經網路,以取代傳送至雲端進行運算的途徑。
Movidius副總裁兼總經理Remi El-Ouazzane日前在接受《EE Times》訪問時,將這個成長中的趨勢定義為「讓事情變得更智慧與自主的一場競賽」。
20170726_Movidius_NT01P1Remi El-Ouzaane,Movidius副總裁兼總經理Remi El-Ouazzane
英特爾旗下子公司Movidius在上週推出了一款採用USB外形的獨立式人工智慧(AI)加速器。El-Ouazzane說,這款名為Movidius神經運算棒(Neural Compute Stick)的AI加速器設計,可輕鬆簡單地插入Raspberry Pi或X86 PC,讓大學研究人員、獨立軟體開發人員與程式增補人員易於為嵌入式系統進行編譯、調整以及加速深度學習應用。
Movidius在去年秋天被英特爾收購後,如今已成為英特爾新技術部門的一部份。Movidius之前曾經開發出業界首款視覺處理器——Myriad 2 VPU。如今,El-Ouazzane表示,推出這款運算棒的最終目標在於讓Movidius VPU成為可在邊緣執行神經網路的「參考架構」。
20170726_Movidius_NT01P2Movidius Myria 2 VPU方塊圖 (來源:Intel/Movidius)
儘管目標遠大,但業界分析師隨即指出,Movidius Myriad 2 VPU當然不是嵌入式系統中可在邊緣執行神經網路的唯一選擇。

催生新產品類別:神經加速器

Tirias Research首席分析師Jim McGregor表示:「從技術上來看,您可以使用任何具有處理元件的開發板,並用於執行一種模型。例如機器學習(Machine learning)/AI模型已經執行於各種廣泛的處理器和SoC了,特別是針對行動領域。」
高通(Qualcomm)以Snapdragon系列實現的影像辨識可說是最佳的例子。高通從Snapdragon 820開始採用自家開發的模型,McGregor說:「Snapdragon基本上就是推理引擎」。
具有平行處理元件(如GPU、DSP和FPGA)的處理解決方案非常適於作為推理引擎。McGregor解釋說,許多正在開發中的客製化晶片解決方案都採用可內建於SoC的DSP或FPGA。
Linley Gwennap首席分析師Linley Gwennap對此表示贊同。他在最近出刊的《微處理器報告》(Microprocessor Report)中寫道:高通、蘋果(Apple)和英特爾(Movidius)都在「打造一種新的產品類別:神經加速器。」
Gwennap解釋說,對於這些以客戶端為基礎的加速器需求來自於要求極低延遲的自動駕駛車。Gwennap在該報告的評論中指出,在本地進行處理的新技術將會開始「滲透至一些較低成本的應用」。他預測,「在消費裝置中,小型的神經加速器可能是SoC中的一個重要區塊,就像是繪圖核心或影像處理器一樣。幾家智慧財產權(IP)供應商開始提供這一類加速器,期望盡可能地降低額外的硬體成本。」
Gwennap在《EE Times》的訪談中指出,Movidius Neural Compute Stick對於開發人員幾乎沒有什麼不同。「對於開發人員來說,這並沒什麼不起。典型的PC就能產生至少100GFLOPS,特別是如果它還內建繪圖卡,直接在PC上進行開發會更好。對於需要較低功率處理器的嵌入式系統,高通Snapdragon 835提供超過250GOPS的效能,對於大多數的推理應用來說都夠了。」
20170726_Movidius_NT01P3(來源:Movidius)
不過,Movidius的El-Ouazzane並不贊同這樣的看法。
首先,Movidius Neural Compute Stick利用USB讓神經網路更易於存取,有利於製造商或程式增補人員用於開發深度神經網路原型或進行調整。
其次是電源效率的問題。El-Ouazzane指出,Movidius的解決方案可讓神經網路在邊緣運算時旳功耗小於2瓦(W)。
然後,還有成本的考量。El-Ouazzane說:「我認為這是一個殺手級因素。Movidius Neural Compute Stick要價79美元,可望讓神經網路的發展變得『超級普遍』。」
他預期開發人員能使用Movidius的神經運算平台(Neural Compute Platform)應用程式介面(API),「將經過訓練的Caffe、前饋卷積神經網路(CNN)輸入工具套件中,並進行配置,然後編譯成一種可用於嵌入式部署的調整版本。」

以AI為導向的嵌入式應用?

隨著許多嵌入式系開始變得「智慧」且「自主」,El-Ouazzane預計以AI為導向的嵌入式系統即將爆發。
但是,不久的將來即將出現什麼樣的AI裝置?
McGregor預測,「我認為在2025年以前,每個人所接觸的每一款新系統/平台都將具有某種程度的AI元素,它可能內建於裝置本身,或存在於網路、雲端,或是分散在其間。」
他補充說:「它可能就像是使用者介面或應用一樣簡單,或者是像虛擬助理或自主控制般複雜的某種裝。目前已經有許多應用已經導入了AI,包括虛擬助理、搜尋引擎、財務建模、與文章寫作.....等等。」
他說:「而在裝置上,AI將因各種不同的原因而持續成長,特別是資料的安全、即時互動/處理以及頻寬限制等。然而,在裝置上進行訓練才是真正的挑戰,最終可能需要新的處理模型。」

英特爾想掌握一切…

當然,Movidus現在是英特爾的子公司,但其目標並不僅限於有更多嵌入式系統在邊緣執行神經網路。El-Ouazzane將其產品發佈架構在英特爾端對端AI產品組合的更大脈絡之下。
他指出,英特爾擁有廣泛的AI產品組合,並為其提供一整套完整的開發工具和資源。
「無論是在英特爾Nervana雲端上訓練AI神經網路、最佳化新興的工作負載(如AI、、VR和AR),以及使用英特爾Xeon Scalable處理器實現自動駕駛,或是以Movidius視覺處理器技術將AI導入邊緣,」英特爾宣稱該公司已為下一代AI驅動的產品和服務提供了全面的AI產品組合、工具、訓練和部署選擇。
然而,Movidus是否真的能在即將變得無所不在的AI嵌入式系統中成為其關鍵參考架構,目前還不而知。
Tirias Research的McGregor儘管認同Neural Compute Stick是「一款可在新設計中快速評估AI模型訓練效能的有利工具,」但他仍指出,「設計人員仍然必須在最後的系統設計階段執行類測試,特別是如果他們並未使用Moviduis的晶片和/或Caffe架構。」
The Linley Group的Gwennap還認為,Movidius無法達到其目標——實現在邊緣運算神經網路的嵌入式系統設計。

區隔推理引擎與訓練

Gwennap指出,「值得注意的是,新的AI時代並不會有『參考架構』。諸如TensorFlow和Caffe等架構將會把軟體(神經網路)和硬體分開來。」他補充說:「映射到Myriad VPU的網路可以輕易地映射到Snapdragon或其他處理器上。因此,AI處理器將在性能和效率的基礎上進行競爭,而不是鎖定於指令集。」
同樣地,他也不認同「同樣的工具適用於訓練和推理」的論點。Gwennap說:「一旦網路開始接受訓練,就可以輕鬆地部署在支持主流架構的任何平台上。而且,主流的架構都是開放源碼,以避免單一家廠商鎖定。」。
El-Ouazzane看好AI處理器抽取底層硬體的能力,它讓設計者可將推論與練訓分離開來。但他重申先前的觀點,從長遠來看,能夠使用相同的工具進行神經網路的訓練和部署,才有助於系統設計人員。
他以Movidius的開發藍圖為例表示,未來三年,深度學習的效能預計將會增加50倍。「為了在不增加功耗的情況下實現這一目標,我們可以在訓練方面設計許多架構技巧。」El-Ouazzane補充說:「當你在斟酌這些技巧時,讓學習和推理方面置於同一平台是至關重要的。」
編譯:Susan Hong
(參考原文:Neural Accelerator Battle Begins,by Junko Yoshida)

CANBUS 總線原理介紹 CAN1.2 ,CAN2.0A,CAN2.0B

CAN總線原理介紹2015/05/08 來源:電子技術應用

CAN是Controller Area Network的縮寫,即「區域網控制器」的意思,可以歸屬於工業現場總線的範疇,通常稱為CAN BUS,即CAN總線,是目前國際上應用最為廣泛的開放式現場總線之一。
CAN總線最早用在汽車電子領域,世界上一些著名的汽車製造廠商都採用CAN總線來實現汽車內部控制系統與各檢測和執行機構間的數據通信。由於CAN總線在數據通信方面表現出來的高可靠性、實時性和靈活性,其應用領域已經成汽車電子領域擴展到自動控制、航空航天、航海、工業控制、醫療器械、安全防護等領域。

CAN總線規範從CAN1.2規範發展為兼容CAN1.2規範的CAN2.0規範(CAN2.0A為標準格式,CAN2.0B為擴展格式),目前應用的CAN器件大多符合CAN2.0規範。

?CAN總線發展史

1986年,Bosch在SAE(汽車工程人員協會)大會上提出CAN總線概念;

1987年,Intel推出第一片CAN控制晶片82526,隨後Philips半導體也推出82C200;

1993年,CAN的國際標準ISO11898/ISO11519公布。ISO11898為高速應用,ISO11519為低速應用;

1994年開始有了國際CAN學術年會ICC。同年,美國汽車工程師協會以CAN為基礎制定了SAEJ1939標準,用於卡車和巴士控制和通信網絡。

?CAN總線特點

1).可以多主方式工作,網絡上任意一個節點均可以在任意時刻主動地向網絡上的其他節點發送信息,而不分主從,通信方式靈活。

2).網絡上的節點可分成不同的優先級,可以滿足不同的實時要求。

3).採用非破壞性位仲裁總線結構機制,當兩個節點同時向網絡上傳送信息時,優先級低的節點主動停止數據發送,而優先級高的節點可不受影響地繼續傳送數據。

4).可以點對點,一點對多點及全局廣播幾種傳送方式接收數據。

5).直接通信距離最遠可達10km(速率4Kbps以下)。

6).通信速率最高可達1MB/s(此時距離最長40m)。

使用非屏蔽雙絞線傳輸時,傳輸速率與傳輸距離的關係如下圖所示。
7).節點數最多可達110個。

8).採用短幀結構,每一幀的有效字節數為8個。

9).每幀信息都有CRC校驗及其他檢錯措施,數據錯誤率極低。

10).通信介質可採用雙絞線,同軸電纜和光纖,一般採用廉價的雙絞線即可。

11).節點在錯誤嚴重的情況下,具有自動關閉總線的功能,切斷它與總線的聯繫,以使總線上的其他操作不受影響。

?CAN總線的仲裁

CAN總線採用CSMA/CD(Carrier Sense Multiple Access with collision Detect,載波監測多路訪問/衝突檢測)技術。「載波監測」的意思是指在總線上的每個節點在發送信息報文前都必須監測到總線上有一段時間的空閒狀態。「多路訪問」的意思是一旦此空閒狀態被監測到,那麼每個節點都有均等的機會來發送報文。「衝突檢測」是指在兩個節點同時發送信息時,節點本身首先會檢測到出現衝突,然後採取相應的措施來解決這一衝突情況。此時優先級高的報文先發送,低優先級的報文發送會暫停。這就是CAN總線的仲裁,仲裁過程是不會對報文產生破壞的。
CAN總線上每個設備都有一個11位的ID信息,各設備的優先級是根據其ID來確定的,ID的序號越小,其優先級越高。下圖為CAN總線上傳輸的數據幀格式,從圖上可知,傳輸開始標識符SOF後面緊跟的就是11位標識ID,CAN總線就是據此進行仲裁工作的。
?CAN總線的拓撲結構

CAN總線的拓撲結構如下,CAN hub是用於多分支擴展用的,可以省去。CAN總線和分支的末端都需要垮接一個120歐姆的電阻來終結,防止信號反射。
?CAN總線的邏輯電平

CAN總線具有兩種邏輯狀態,隱性和顯性。隱性狀態下,VCAN_H和VCAN_L都被固定為平均電壓電平,兩者之間的電壓差為0;顯性狀態下,VCAN_H和VCAN_L的電平分別為3.5V和1.5V,兩者差分電壓大於2V,如下圖所示。
?常用CAN總線晶片

CAN晶片有CAN控制器和CAN收發器,在實際電路中,這兩種晶片需要配合起來應用。

常用CAN控制器晶片有:P87C591,XAC37,SJA1000;

常用CAN收發器晶片有:PCA82C250,PCA82C251,PCA82C252,TJA1040,TJA1041,TJA1050,TJA1053,TJA1054。

Controller Area Network (CAN BUS) 通訊協定原理概述

Controller Area Network (CAN BUS) 通訊協定原理概述

發表日期: 一月 04, 2017 | 3 人評分 | 4.67 分/共 5 | 
Read in English
  | 列印

概觀

Controller Area Network (控制器區域網路,CAN BUS) 是一種通訊協定,工業應用廣泛。本技術文件將詳細介紹 CAN BUS 通訊協定的發展、運作原理、優點及其日益廣泛的應用。

目錄

  1. CAN BUS 的沿革
  2. CAN BUS 的優點
  3. CAN BUS 應用
  4. CAN BUS 的實體層 (Physical Layer)
  5. CAN BUS 專有名詞
  6. CAN BUS 資料庫檔案
  7. CAN BUS 通訊作業的原理
  8. NI CAN 工具
  9. NI-XNET 驅動程式
  10. NI-CAN 驅動程式

1. CAN BUS 的沿革

由博世 (Bosch) 公司於 1895 年所開發的 Controller Area Network (CAN) 通訊協定,本是要用於車內網路 (In-vehicle network)。在此之前,汽車製造商均是透過點對點接線系統,以連接車內的電子裝置。而由於車輛使用越來越多的電子裝置,因此大量的傳統接線除了將佔據許多空間之外,亦將提高成本。有鑑於此,製造商開始以車內網路取代實體接線,藉以降低接線成本、複雜度,與體積/重量。CAN BUS 即為高密度的序列匯流排系統,其原理是建構智慧型裝置的網路功能,现已成為車內網路的標準。CAN 因而迅速普及於汽車工業,而接著在 1993 年成為 ISO 11898 的國際標準。在 1994 年已發展出多項以 CAN 為標準的進階協定,如 CANopen 與 DeviceNet。其他市場也已廣泛採用這些衍生協定,並成為目前工業級通訊作業的標準。此篇技術文件將著重於車內網路的 CAN。

2. CAN BUS 的優點

CAN BUS 可提供低價位且耐用的網路,以溝通多組 CAN 裝置。舉例來說,電子控制單元 (ECU) 僅需單一的 CAN 介面,即可取代系統中所有裝置的類比與數位輸入。如此即可降低汽車的整體成本與重量。網路中的各組裝置均具備了 CAN 控制器晶片,因此更具智慧型功能。在網路中的所有裝置均可接收相關訊息。各組裝置亦可自行辨識該筆訊息是否相關並予以篩選。此外,各筆訊息均具有其優先性。若有 2 個節點同時嘗試傳送訊息,則具有較高優先性的訊息將先行發出,低優先性的訊號將延後傳送。

3. CAN BUS 應用

CAN BUS 最初應用於汽車產業,因此最常見的應用即為車內電子網路。然而,由於最近 15 年來,已有越來越多的產業了解到 CAN 的優點,因此 CAN BUS 的應用越來越廣泛。如有軌電車、地下化捷運、輕軌鐵路,與長距離火車的軌道應用,均已採用了 CAN。在這些車輛之中,均可發現多種 CAN 所建構的網路,如車門系統、煞車控制器、乘客計算系統,還有更多。CAN BUS 協定亦可應用於飛行器,如飛行狀態感測器、導航系統,與座艙之中的搜尋電腦。多種航太應用亦可發現 CAN 匯流排的蹤跡,從飛行資料分析到飛行器引擎控制系統,如燃料系統、幫浦,與線性致動器。

CAN BUS 還被可應用於醫療設備行業:設備製造商使用 CAN 建構醫療裝置中的嵌入式網路。事實上,某些醫院已經使用 CAN 管理整個手術室。透過 CAN BUS 通訊協定架構的系統,醫院可控制手術室的燈光、手術台、相機、X 光機,與病患床鋪。電梯與電扶梯亦使用嵌入式的 CAN 網路。而 CANopen 協定可連接電梯裝置,如面板、控制器、電梯門,與擋光器 (Light barrier),並進行控制作業。CANopen 亦可用於非工業應用,如實驗室設備、運動相機、望遠鏡、自動門,甚至咖啡機。

4. CAN BUS 的實體層 (Physical Layer)

CAN BUS 通訊協定具備多個不同的實體層。這些實體層均以 CAN 網路的概念進行分類,如電子層 (Electrical level)、訊號產生架構、連接線阻抗、最大鮑率,還有更多。最常見且廣泛使用的實體層如下列所述:

高速 (High-Speed) CAN

High-speed CAN BUS 為目前最常見的實體層。High-speed CAN 網路包含 2 組接線,並可進行最高 1 Mb/s 的通訊傳輸率。High-speed CAN 亦稱為 CAN C 與 ISO 11898-2。典型的 High-speed CAN 裝置包含反鎖死煞車系統 (ABS)、引擎控制模組,與排放系統。

低速/容錯 (Low-Speed/Fault-Tolerant) CAN
 硬體
Low-speed/fault-tolerant CAN BUS 網路包含 2 組接線,可達最高 125 kb/s 的通訊傳輸率,並為接收器提供容錯功能。低速/容錯 CAN 亦稱為 CAN B 與 ISO 11898-3。汽車中的典型低速/容錯裝置則包含舒適度 (Comfort) 裝置。必須穿過車輛車門的接線,即屬於低速/容錯 CAN,以較輕壓力的系統進行開/關車門的動作。同樣的,對較高等級的安全系統 (如煞車燈) 而言,低速/容錯 CAN 亦可建構解決方案。

單線式 (Single-Wire) CAN 硬體
單線式 CAN BUS 通訊介面可溝通裝置達最高 33.3 kb/s (高速模式可達 88.3 kb/s) 傳輸率。單線式 CAN 亦稱為 SAE-J2411、CAN A,與 GMLAN。汽車中的單線式裝置往往並不具有高效能。常見應用即包含如座椅調整與後照鏡調整裝置的舒適度裝置。

可透過軟體進行選擇的 CAN 硬體
透過 NI CAN 硬體產品,即可設定由軟體進行選擇的 CAN 介面,以使用任何的快取 (On-board) 接收器 (高速、低速/容錯,或單線式 CAN)。針對需要整合多個通訊標準的應用,具備多重接收器的硬體將可提供完美解決方案。而可由軟體進行選擇的 CAN 硬體,使用者亦可自行選擇所需外接式 CAN 接收器。

5. CAN BUS 專有名詞

CAN 裝置透過 CAN 網路,以封包傳送資料即稱為框架 (Frame)。CAN 框架包含下列要素。
  • CAN 框架 (Frame)  完整的 CAN 傳輸作業:仲裁識別號碼 (Arbitration ID)、資料位元,與回應位元 (Acknowledge bit) 等。框架亦可稱為「訊息」。

  • 框架起點 (Start-of-Frame,SOF) 位元 – 以強勢位元 (Dominant bit) – 亦為 Logic 0 – 為開頭的訊息。
  • 仲裁識別號碼 (Arbitration ID) – 可識別訊息與其優先順序。框架共有 2 種格式 – 標準格式使用 11 位元的仲裁 ID;延伸格式則是使用 29 位元的仲裁 ID。
  • 識別子延伸 (Identifier Extension,IDE) 位元 – 可區隔標準與延伸框架。
  • 遠端傳輸要求 (Remote Transmission Request,RTR) 位元 – 可從資料框架中區隔出遠端框架。強勢 (Logic 0) RTR 位元即表示 1 組資料框架。弱勢 (Logic 1) RTR 位元即表示 1 組遠端框架。
  • 資料長度碼 (Data Length Code,DLC) – 指出資料欄位所內含的位元數
  • 資料欄位(Data Field) – 包含 0 ~ 8 位元數的資料
  • 循環冗餘校驗 (Cyclic Redundancy Check,CRC) – 包含 15 位元的循環冗餘校驗碼與弱勢分隔符 (Delimiter) 位元。CRC 欄位可用於除錯。
  • 認可字元 (ACKnowledgement,ACK)  – 任何正確接收訊息的 CAN 控制器,均將於訊息末端附加傳送 1 組 ACK 位元。傳送節點將檢查匯流排中是否具有 ACK 位元,而若未偵測到 ACK 則將重新嘗試傳輸。NI Series 2 CAN 介面則具備唯接收 (Listen-only) 模式。因此,若透過硬體監控而傳輸 ACK 位元,則是為了避免其受到匯流排的動作所影響。
  • CAN 訊號 – 為 CAN 框架資料欄位所內含的獨立資料片段。亦可將 CAN 訊號視為通道 (Channel)。由於資料欄位可包含最多 8 位元的資料,因此單一 CAN 框架可包含 0 ~ 64 筆獨立訊號 (對 64 個通道而言,可能全為二進制)。
下圖則顯示單一 CAN 框架的資料欄位,共包含了 6 個通道。各組訊號則包含 8 位元的資料。

6. CAN BUS 資料庫檔案

CAN 資料庫檔案為文字式檔案,包含 CAN 框架與訊號定義的資訊。NI的 NI-XNET 資料庫編輯軟體,可識別 FIBEX 資料庫檔案 (.xml)、Vector Database 檔案 (*.dbc),與 NI CAN 資料庫檔案 (*.ncd)。

針對各筆訊號,CAN 資料庫可定義工程單位的轉換規則。下列資料將儲存於資料庫中:
  • 通道名稱
  • 已知訊息中的通道位置 (開始位元) 與大小 (位元數)
  • 位元組順序 (Byte order) - (Intel/Motorola)
  • 資料類型 (已簽、未簽,與 IEEE 浮點)
  • 縮放比例 (Scaling) 與單元字串 (Unit string)
  • 範圍
  • 預設值
  • 指令
透過此資訊,即可輕鬆將「原始」資訊 (往往為位元組) 轉換為「實際」值。下圖則顯示轉換範例。
CAN 資料庫檔案可能包含整組車輛的框架與訊號定義。各組網路亦具有其專屬的資料庫檔案。此外,這些資料庫檔案為各個製造商所專屬,且往往具有其機密性。
只要於 CAN 網路上針對多個框架使用資料庫檔案,則多個 CAN API (如 NI-XNET) 亦可自動將框架資訊直接轉換為實際數值。此可簡化應用開發作業,且不需擔心原始的框架數值。

7. CAN BUS 通訊作業的原理

如先前所述,CAN BUS 屬於點對點網路。意即當獨立節點要讀寫 CAN 匯流排上的資料時,並不需要透過主機控制器 CAN BUS 的基本原理是當節點準備傳送資料時,將先檢查匯流排是否處於繁忙狀態,接著將 CAN BUS 框架寫入至網路中。而傳輸完畢的 CAN 框架,將不包含傳輸節點與任何預設接收節點的位置。反之,是由整組網路的專屬仲裁 ID 標記該框架。CAN BUS 網路上的所有節點均將接收 CAN 框架,而根據該完成傳送框架的仲裁 ID,網路上的各個 CAN 節點均可決定是否要接收該框架。

若有多個節點於同時嘗試將訊息傳送至 CAN 匯流排,則最高優先度的節點 (即為最低的仲裁 ID) 將自動先進入匯流排。較低優先度的節點必須等到匯流排完成作業,才會再次嘗試進行傳輸。依此方式,即可確保 CAN 網路中的 CAN 節點,將進行精確的通訊作業。

8. NI CAN 工具

針對 CAN 應用開發作業,NI 提供多款硬體與軟體工具。NI 對不同的平台提供 CAN 介面,包含 PCI、PXI、PCMCIA,與 NI CompactRIO。而 PCI、PXI,與 PCMCIA 介面,均有其高速、低速/容錯,與單線式的實體層。在 PCI 與 PXI 方面,NI 提供業界首款可由軟體進行選擇的 CAN 介面。針對單一裝置的各組通訊埠與機板,即提供高速、低速/容錯,與單線式收發器。此亦表示,僅需透過軟體即可選擇所要使用的模式。
NI PCI-8513 – 可透過軟體進行選擇 (XS) 的 CAN 介面卡

此外,NI 所提供的各組介面卡均內附合適的驅動程式。NI CAN 介面的驅動程式細節將如下所述。

NI ECU 量測與校準工具組,可擴充 NI LabVIEW、NI LabWindows/CVI,與 Microsoft C/C++ 開發環境,以支援量測與校準應用,適於設計並校準電子控制單位 (ECU)。ECU 量測與校準 (Measurement and Calibration) 工具組則是以 CAN 校準協定 (CCP) 為架構,提供簡單易用的高階函式,可讓 ECU 工程師建立所需的客制化量測與校準應用。若需要進一步資訊,請參閱下列 ECU 量測與校準 (Measurement and Calibration) 工具組資源。

9. NI-XNET 驅動程式

NI-XNET 軟體已內含於 PCI/PXI-851x 硬體系列,並可至 ni.com 免費下載。此新的驅動程式可於 Windows 與 LabVIEW Real-Time 作業系統中,透過 NI LabVIEW、NI LabWindows/CVI,與 C/C++ 開發 CAN 與 FlexRay 應用。PCI/PXI-851x 系列屬於 NI-XNET 平台的 1 部分,可即時且高速操作數百種 CAN 框架與訊號,如硬體迴路 (HIL) 模擬、快速製作控制系統原型、匯流排監控、自動化控制,還有更多。
NI-XNET:單一 API 即可建構多個嵌入式網路
NI-XNET 平台可針對多款高效能的 CAN、FlexRay 介面,整合 NI-XNET API (簡單易用的函式集),以讀寫 CAN/FlexRay 的框架與訊號。
以更少的程式設計作業達到更高效能
NI-XNET 介面,整合初階微控制器程式設計,還有 Windows 與 LabVIEW Real-Time 作業系統的開發速度。針對電腦架構 CAN 介面的常見缺點,申請專利中的 NI-XNET 裝置驅動 DMA 引擎,可將系統潛時從毫秒 (Millisecond) 縮短到微秒 (Microsecond)。此引擎可透過快取 (On-board) 處理器,於介面與使用者程式之間搬移 CAN 架構/訊號,而不需透過電腦 CPU 進行處理;此可省下主機處理器處理複雜模型與應用的時間。

10. NI-CAN 驅動程式

NI 已於所有 NI 舊款 CAN 介面 (Legacy CAN) 中附加 NI-CAN 驅動程式,亦可至 ni.com 免費下載該軟體。若搭配其他 CAN 介面,即便並未購買關鍵的軟體工具,亦可利用少部分的相關功能。然而,所有的 NI CAN 介面卡均具備完整功能,因此使用者可選擇所需的程式設計語言,建立客制化的應用。NI-CAN 驅動程式並具備簡單易用的高階函式,可迅速開發 CAN 應用,省下成本與時間。

NI –CAN 驅動程式即具備 2 種應用程式設計介面 (API)。Frame API 為 CAN 程式設計作業的原始 API。透過 Frame API,即可傳輸並接收已包含原始資料位元組的 CAN 框架。而程式必須能夠分析語法並調整這些位元組,以搭配調整過後的工程單位。若要進一步了解 Frame API 的程式設計作業,可參閱 NI CAN 硬體與軟體手冊的「Using the Frame API」章節 (請見下方)。

NI 則於 NI-CAN 2.0 驅動程式中首次發表 Channel API。透過於資料庫檔案 (.dbc 或 .ncd) 中所定義的通道名稱,即可讀寫 CAN 通道。Channel API 具有下列優點:
  • 高階程式設計功能
  • 簡單易用的實體單元 (Physical unit)
  • 主要用於簡易的 CAN/資料擷取的同步化作業
  • 可整合 Vector 資料庫的檔案

CAN BUS

CAN

Introduction

控制器區域網路 (Controller Area Network, 簡稱 CAN 或 CANbus)是一種網路,其特點是允許網路上的多個微控制器或設備直接互相通訊,網路上不需要主機(Host)控制通訊,並且提供高安全等級及有效率的即時控制。更具備了偵錯和優先權判別的機制,網路訊息的傳輸變的更為可靠而有效率。訊息的ID並不是定義在節點,而是定義在訊息上,所以只要在軟體上修正就能夠輕易增加或移除節點,增加了在升級網路時的便利性。實作上又因為只需雙線溝通的特性,也降低線路複雜易造成錯誤的發生機會。總而言之,CANbus具有高擴充性 、高可靠度且低成本等特性。

Features

Network Topology(CANbus網路架構)

CANbus是一種匯流排網路,他的匯流排是由兩條線路所實現,當兩條線路電位差小的時候為1,電位差大的時候為0。

MESSAGE TRANSFER(CAN通訊的資料格式)

CAN2.0有兩種版本,CAN2.0A(Standard),CAN2.0B(Extended)。

1.DATA FRAME(資料通訊格式):

資料通訊格式主要用於傳送資料,主要分成5個部分。
  • Start of Frame(SOF):送出1位元dominant(0),用來同步。
  • Arbitration Field:表示節點的優先權,用來判別優先權。若多個節點同時傳送,在仲裁欄位逐一比對優先權,位元為dominant(0)可優先傳送。長度有兩種11bits(Standard identifier)和29bits(Extended Identifier)。
RTR 則為優先判斷與資料接收與否的識別,RTR=dominant(0),表資料要傳出,RTR=recessive(1),表要接收資料。
  • Control Field:資料的長度。
IDE: 標準格式(Standard identifier)為dominant(0);延伸格式(Extended Identifier)為 recessive(1)。
R0:保留
  • Data Field:0-8bytes的資料。
資料長度0-8 bytes
  • CRC Field:錯誤檢查。
  • ACK Field:接收正確,接收端送出1位元dominant(0)。
傳送端送出一個recessive bit(1)當接收端正確收到一個訊息,則在ACK Slot中回傳一個為dominant(0)位元,告知傳送端。
  • End of Frame(EOF):通訊格式結束的欄位。
每一個資料都是由7個連續的recessive(1)位元作為結束。

2.REMOTE FRAME(遠端通訊格式):

遠端通訊格式用來請求遠端節點傳送資料。
遠端通訊格式基本上就是資料長度為0的資料通訊格式,指示設定上略有不同。當A節點需要B節點送出資料時,可藉由送出一個遠端通訊格式來完成,將B節點的ID寫入仲裁欄位,在RTR填入recessive(1)。

3.ERROR FRAME(錯誤通訊格式):

當接收到的訊息有錯誤時,節點會發送錯誤通訊格式通知其他節點。
  • CAN有5種錯誤檢查來確保收發資料的正確性,在偵測到錯誤的當下決定要在資料的哪個位元回傳錯誤訊息(一定是在Data資料不完整的狀態下)。
  • 在節點的狀態方面共有3種(主動,被動,關閉)。通訊格式上,則有主動和被動之分,差別在於Error Flag的值不同。主動是6個dominant(0),被動是6個recessive(1)。

4.OVERLOAD FRAME(過載通訊格式):

通知其他節點延遲傳送資料的格式
節點處理資料中,對於下一筆資料需要延遲時使用,通常接在遠端通訊格式或資料通訊格式後面。

5.INTERFRAME SPACING(通訊格式間隔):

與前一個資料間隔的格式
  • 有3bit的intermission和一直處於recessive(1)的Bus Idle
  • 除了過載通訊格式和錯誤通訊格式之外,訊息之間至少都要有intermission

CAN的錯誤處理

Error Detection(資料偵錯機制)

  • BIT ERROR
發送資料中的節點會比較發送的資料和bus中的電位高低變化是否一致,如果不一致則直在位傳完的訊息後方接著傳送Error Frame。這種偵錯機制僅限於SOF,control,data,CRC field。
  • STUFF ERROR
bit stuffing,就是接收端和傳送端約定連續傳幾個相同的bits就要傳送一個相反的bit,用來和訊息中的某些delimiter 做區隔,避免錯亂。在CAN當中是規定某些資料格式中最多只能有5個連續相同的bit,下一個bit就會自動安插相反的bit,並且在接收端會做de-stuffed的動作來把這個bit清除來還原資料。
CAN只在Data Frame中的SOF, ARBITRATION FIELD, CONTROL FIELD,DATA FIELD 和 CRC SEQUENCE這些非固定格式的部分有bit stuffing 的機制。所以當訊息中的這些部分連續偵測到6個相同的bit的時候,就會從下一個bit開始傳送Error Frame。
  • CRC ERROR
CRC是一種checksum機制。主要用來檢測數據傳輸後可能出現的錯誤。生成的數字在傳輸之前計算出來並且附加到數據後面,然後接收方進行檢驗確定數據是否發生變化。
CRC的計算方式是假設M(x)是原始的message polynomial,K(x)是n階的generator polynomial,那麼CRC就是 M(x)*x^n對K(x)做模二除法(modulo 2 division:二進位多項式除法,並且用xor運算取代減法運算)的餘式R(x)。所以各個polynomial之間有以下關係:
M(x)x^n = Q(x)K(x) + R(x)
在接收端就是在確認K(x)能不能整除(M(x)*x^n - R(x)),如果可以就表示資料正確,反之代表資料錯誤。
ex:假設資料位元(message polynomial)為10101010,generator polynomial為x4+x2+x^1+1 (10111)
1100為此資料在以x4+x2+x^1+1為generator polynomial之下的CRC。
在CAN當中M(x)是下圖中的Fields所產生的message polynomial,K(x)則是x^15 + x^14 + x^10 + x^8 + x^7 + x^4 + x^3 + 1。
  • FORM ERROR
CRC,ACK Field 都有delimiter,甚至EOF本身就是Data Frame的delimiter,這些bit都預設為recessive(1),如果在這些bit上讀到dominant(0),那從下一個bit開始就傳送Error Frame。
  • ACKNOWLEDGMENT ERROR
傳送端會傳出2個bit的recessive(1)為ACK Field,前者為ACK Slot後者為ACK delimiter。當傳送端在ACK Slot送出recessive(1)的時候,接收端要回傳dominant(0),告知傳送端。如果沒有那就在ACK delimiter後面傳送error frame。

FAULT CONFINEMENT(節點錯誤機制)

CAN的每個節點都有計數器來記錄錯誤的歷史(Transmit Error Counter(TEC) & Receive Error Counter (REC)。評估節點的方式則是根據不同的錯誤形式有不同的權重去計算出狀態數值,並且當節點反應正常的時候還會有下修機制避免因為長時間執行造成的錯誤。當這個評估的數值大於127這個門檻後,就會判定節點從Error active state轉為Error passive state。當節點變成Error passive state的時候,錯誤訊息格式內的flag則是從Active-error flag(6 recessives)改成Passive-error flag(6 dominants),錯誤提醒的部分則是從Error active state的主動全部節點的提醒,改成只在該錯誤節點記錄錯誤。當數值大於255,就判定此節點失效並且關閉此節點的所有行為。當失效節點偵測到128次連續11個recessive(0)bit的時候,重新出始化節點所有的TEC和REC數值歸零,以Error active state的狀態重新回到bus當中。

CAN in STM32F429 Board

Main operating modes

主要的操作模式主要是在Sleep,Initialization,Normal mode 之間轉換,轉換的方式就是去改變CAN_MSR寄存器上面的INAK和SLAK bit。
  • Initialization mode
Initialization mode,主要是用來初始化點的bxCAN設定。當INRQ bit被拉起來的時候,CAN就進入Initialization mode,在這過程當中主要是要設定CAN_MCR(mode設定)和CAN_BTR(baud rate設定)。在初始化的過程當中會停止節點對CANbus的任何傳送或接收的動作。(Filter 設定可以在Initialization mode之外完成)
  • Sleep mode (low power)
Sleep mode主要是為了省電而設計的,藉由拉起CAN_MCR裡的SLEEP bit來開啟,但是除了由拉低SLEEP bit來關閉之外,只要bus上有傳送訊息Sleep mode也會自動關閉。
  • Normal mode
最主要的工作模式。藉由拉低INAK和SLAK bit進入。

Test modes

Test modes主要是用來測試node狀態, 藉由設定CAN_BTR寄存器的SILM和LBKM bits來選擇。
  • Silent mode
就是把node設定成只進不出的狀態。就連接收成功的ACK bit也傳不出去。
  • Loop back mode
就是把node設定成只出不進的狀態。並且把自己傳出的message存回Rx mailbox之中。
  • Combined mode
自己的Tx直接進入自己的Rx,通常用來檢測node本身。

Transmission handling

用bxCAN傳送一筆資料的時候首先要做的事有3個,選擇空的mailbox,輸入傳送資料的ID和設定資料長度。然後再去拉起CAN_TIxR寄存器的TXRQ bit,對mailbox下達傳送指令。
  • Nonautomatic retransmission mode
在正常的設定之下,當傳送失敗的時候,bxCAN會不斷的嘗試重新傳送。但是如果設定成這個模式,bxCAN不管有沒有傳送成功都只會傳送一次。
  • Abort
在bxCAN傳送的過程如果收到中止命令,還未傳送的資料就會直接中止,如果是在傳送中就會等資料傳完,如果失敗在進入中止狀態。
  • Transmit mailbox states
mailbox處理主要分成3個階段,PENDING,SCHEDULED和TRANSMIT。當傳送的資料進入mailbox處理的時候,會先進入PENDING的階段找出priority最高的message,然後進入SCHEDULED階段等待CANbus回到idle的狀態。一旦CANbus回到idle的狀態,就會把message傳出去。這時候如果傳送失敗,資料就會被送回來SCHEDULED階段並且和PENDING的階段的message比較priority。如果message然有最高的priority,則留在SCHEDULED階段等待,否則就換最高priority的message到SCHEDULED階段等待。
  • Transmit priority
傳送資料不止一筆的時候,bxCAN會排定傳送順序。排定的方法有兩種,一種是依照順序,一種是依照ID。號碼小的優先傳送,如果ID一樣的時候mailbox號碼小的優先。

Reception handling

在bxCAN的接收端,有三階段的FIFO來為接收緩衝。
  • Receive FIFO states
當bxCAN接收到資料,就會直接被丟到第一階段的FIFO等待,等CPU來處理,此時是PENDING第一階段,FMP=0x01。如果還來不及處理就有新的資料進來,當下這筆資料就會被移到第二階段的FIFO去等待,新進的資料則停在第一階段的FIFO,此時是PENDING第二階段,FMP=0x10。當CPU有空的時候就先從高段的FIFO開始處理。依此類推…。總共有三個階段。
  • Overrun
Overrun處理有兩種模式。第一種是有開啟FIFO lock。當三階段的FIFO都滿了,但CPU還沒處理。接下來的資料都會遺失。此時CAN_RFR寄存器的FOVR bit會被拉起。第二種是沒有開啟FIFO lock,接下來的資料則會直接覆蓋FIFO的最後一筆資料。

Identifier filtering

由於CANbus在傳送資料的過程是類似廣播的方式,所以在node數量眾多的時候,單一node會收到所有node所傳出的各種資料。但是如果這個node的功能比較單一的話,它其實可以不需要接收每個node的資訊,只要接收跟它有相關的就好了,所以在接收端就需要filter來過濾資料,減輕node負擔。在stmf4的設計中總共有28組寄存器來當作filter使用。filter則有2種mode可以提供選擇。
  • Mask mode
在Mask mode之下,只要ID中特定的幾個bit符合filter的狀態,此筆資料就會被接收。通常用在接收某個類別的訊息用。
  • Identifier list mode
在Mask mode之下,只要ID中全部的bit都符合filter的狀態,此筆資料才會被接收。通常用在需要接收特定節點資料的時後使用。
  • Filter bank
  • Filter match index
Filter match index是一個可以更進一步減輕處理負擔的機制。當filter開啟的時候,接收的封包會在接收的時候加入此筆資料是從哪個filter所傳進來的,這樣可以在資料處理的時候節省很多辨識ID的工作。
  • Filtering mechanism
以下是一個filter操作流程的範例。當接收到一筆訊息的時候,會先在filter bank當中尋找是否有符合的資料,順序是先看list在看mask。在進入FIFO之前,先加入filter match index,然後再進入FIFO排隊等待處理。

Bit Timming

ex:假設APB clock為45Mhz如何得到1Mhz的baud rate?
選擇9為prescaler, tBS1 = 2 tq, tBS2 = 2 tq
tq = 1/(45Mhz/9) = 0.2 us
Baud rate = 1/Bittime = 1/((1+2+2)*tq) = 1Mhz

Demo

我們利用3塊STM32F429-DISCO板子裡面的L3GD20陀螺儀來量測個別板子的旋轉,然後除了用LCD顯示出來之外,同時傳送bxCAN封包告知另外的版子現在的旋轉情形。在STM32F429-DISCO上面只有CAN controller並沒有CAN transceiver 所以外接一個MCP2551才能在STM32F429-DISCO上實現CANbus網路。為了軟體維護的便利性,我們直接在硬體上做了設定ID的電路,所以可以用一樣的軟體設定不同板子的ID。
Initialization:
  CAN_InitTypeDef CAN_InitStructure;
  CAN_FilterInitTypeDef CAN_FilterInitStructure;
  GPIO_InitTypeDef GPIO_InitStructure;
  /* CAN GPIOs configuration **************************************************/
  /* Enable GPIO clock */
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOB, ENABLE);
  /* Connect CAN pins to AF9 */
  GPIO_PinAFConfig(GPIOB, GPIO_PinSource12, GPIO_AF_CAN2);
  GPIO_PinAFConfig(GPIOB, GPIO_PinSource13, GPIO_AF_CAN2);
  /* Configure CAN RX and TX pins */
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12 | GPIO_Pin_13;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
  GPIO_Init(CAN_GPIO_PORT, &GPIO_InitStructure);
  /* CAN configuration ********************************************************/
  /* Enable CAN clock */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_CAN2, ENABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_CAN1, ENABLE);
  /* CAN register init */
  CAN_DeInit(CAN2);
  /* CAN cell init */
  CAN_InitStructure.CAN_TTCM = DISABLE;
  CAN_InitStructure.CAN_ABOM = DISABLE;
  CAN_InitStructure.CAN_AWUM = DISABLE;
  CAN_InitStructure.CAN_NART = DISABLE;
  CAN_InitStructure.CAN_RFLM = DISABLE;
  CAN_InitStructure.CAN_TXFP = DISABLE;
  CAN_InitStructure.CAN_Mode = CAN_Mode_Normal;
  CAN_InitStructure.CAN_SJW = CAN_SJW_1tq;
  /* CAN Baudrate = 1 MBps  45/(9*(2+2+1))*/
  CAN_InitStructure.CAN_BS1 = CAN_BS1_2tq;
  CAN_InitStructure.CAN_BS2 = CAN_BS2_2tq;
  CAN_InitStructure.CAN_Prescaler = 9;
  CAN_Init(CAN2, &CAN_InitStructure);
  /* CAN filter init */
  CAN_FilterInitStructure.CAN_FilterNumber = 14;
  /* USE_CAN2 */
  CAN_FilterInitStructure.CAN_FilterMode = CAN_FilterMode_IdMask;
  CAN_FilterInitStructure.CAN_FilterScale = CAN_FilterScale_32bit;
  CAN_FilterInitStructure.CAN_FilterIdHigh = 0x0000;
  CAN_FilterInitStructure.CAN_FilterIdLow = 0x0000;
  CAN_FilterInitStructure.CAN_FilterMaskIdHigh = 0x0000;
  CAN_FilterInitStructure.CAN_FilterMaskIdLow = 0x0000;
  CAN_FilterInitStructure.CAN_FilterFIFOAssignment = 0;
  CAN_FilterInitStructure.CAN_FilterActivation = ENABLE;
  CAN_FilterInit(&CAN_FilterInitStructure);
  /* Enable FIFO 0 message pending Interrupt */
  CAN_ITConfig(CAN2, CAN_IT_FMP0, ENABLE);
Transmition package:
  /* Transmit Structure preparation */
  TxMessage.ExtId = (uint32_t)ID | 0x1FFF0000;
  TxMessage.RTR = CAN_RTR_DATA;
  TxMessage.IDE = CAN_ID_EXT;
  TxMessage.DLC = 4;
  TxMessage.Data[0] = p[0];
  TxMessage.Data[1] = p[1];
  TxMessage.Data[2] = p[2];
  TxMessage.Data[3] = p[3];
  CAN_Transmit(CAN2, &TxMessage);
Receive package handler
  void CAN2_RX0_IRQHandler(void)
  {
    if(CAN_GetITStatus(CAN2,CAN_IT_FMP0)==SET){
    CAN_Receive(CAN2, CAN_FIFO0, &RxMessage);
    CAN_ClearITPendingBit(CAN2,CAN_IT_FMP0);
    }
  }
Interrupt Setting:
  void CAN2_NVIC_Config(void)
  {
    NVIC_InitTypeDef NVIC_InitStructure;
    NVIC_InitStructure.NVIC_IRQChannel = CAN2_RX0_IRQn;
    NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0x0;
    NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0x0;
    NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
    NVIC_Init(&NVIC_InitStructure);
  }
source code: stm32f429_Demo_CAN

Tables

References