開發3rd Party NXT周邊裝置RobotC API的Xander日前發表了 ROBOTC I2C How To, 以Step by step的方式教導如何撰寫RobotC程式來控制NXT的 I 2C周邊, 這使我回想起2007年第一次嘗試使用NXC來撰寫NXTCam程式時的摸索過程, 雖然當時John Hansen的NXC Programmer’s Guide中已經有Low speed communication API的介紹, 然而NXT的I 2C功能對於我而言仍是全新的探索領域, 而在當時也很難找到實際使用這些API的NXC範例, 最後好不容易參考到了Mindsensors MTRMX-Nx的RobotC sample code, 將程式的寫法套用到NXC之後再加上一些摸索與測試, 終於才弄清楚了實作以及API的用法, 從此藉由對NXC使用的逐漸熟悉, 也同時對於NXT I 2C裝置特性的掌握始有了一個豁然開朗的認識.
NXT具備的I 2C處理能力相較於前一代的RCX算是相當程度的功能升級, 這也促使自NXT上市以來各式有趣又好玩的I 2C周邊不斷的推陳出新, 無論Mindsensors或HiTechnic常會有意想不到的新產品推出, 使用方面雖然原廠都會有NXT-G block可供下載, 不過對於一些較複雜的進階產品, 這些NXT-G block往往只有提供到部分特定的功能而未能充分的發揮產品的特性. 所以惟有使用能夠對於裝置直接進行I 2C操作的程式軟體才能有機會突破這一層的限制, 也因此 具有完整的I 2C API呼叫函數同時免費又容易上手的NXC就成為一窺NXT的這個強大功能的最佳入門工具了!
提到NXC不免要對開發的John Hansen致敬與感激, 除了提供好用的IDE外, 而他所著的Lego Mindstorms NXT power programming應該是目前對於NXT的official firmware解說最詳細完整的書, 而這本書的2nd版在上個月也收到了, 主要增加了NXT 2.0新功能(float資料類型’Lego new color sensor…)以及第一版之後上市的幾個新I 2C裝置API的介紹,以後會找機會整理,在此先回到本文討論的主題.
本文主要將對於過去在NXT I 2C操作方式以及NXC AP I用法等的使用經驗作一個整理, 一方面除了可以提供作為筆記參考之外, 亦方便後續若有新資料補充時能有一個現成的架構可以利用, 內容方面則預計將分成3個部分:
(1) 首先對於NXT I 2C裝置的特性與用途先建立基本的認識.
(2) 接下來以NXT firmware中Lowspeed Module的3個System call methods來說明NXT如何進行I 2C操作的方式與步驟.
(3) 最後說明NXC I 2C API的實作用法.
NXT I 2C裝置簡介
雖然NXT的I 2C裝置都是連接在input port, 不過以裝置所實際具備的功能而言, 則未必僅作為NXT讀取資訊的輸入來源, 事實上部分裝置還可以由NXT寫入控制指令以執行特定的功能, 反而應該界定成為output device. 這是由於NXT的4個input ports具備I 2C的通訊處理能力, 因此可以對於具備同樣介面的周邊裝置進行讀取以及寫入資料的動作, 所以只要是使用標準的I 2C通訊協定也就能發展出各式各樣NXT可以運用的周邊裝置, 以下幾個之前的測試文可以用來說明部分NXT I 2C週邊的應用實例:.
l 讀取I 2C裝置資料的應用:
測試Hitechnic IR Receiver的回傳狀態及行為
l 寫入控制指令資料到I 2C裝置的應用:
mindsensors NXTHID 人性化介面裝置測試( Lego mindstorms NXT based HID)
Hitechnic IRLink I2C details(NXC實作範例)
Mindsensors MagicWand 組裝測試
l 有些I 2C裝置則同時兼具回饋資訊以及輸出控制的功能, 如Mindsensors的NXTServo,除了可以控制RC Servo的動作外, 還可以回饋它的位置資訊.
NXT I 2C通訊的特性
I 2C通訊是產業標準, LEGO在導入到NXT時再加上部分規範並對外公開, 提供3rd party廠商能夠開發適用於NXT的I 2C裝置, 這裡先摘要說明NXT處理I 2C通訊的一些特性, 以對於後續的討論先有一個初步的了解:
1. I 2C通訊在NXT也稱之為Digital I/O Communication或Lowspeed Communication, 為運用NXT firmware中Lowspeed Module功能來進行相關操作.
2. I 2C 通訊是Master-Slave架構, Lego界定NXT必為Master端, 而I 2C裝置則為Slave端, 因此會由NXT來主控雙邊間的資料通訊(包含:初始化’讀’寫等動作), 而裝置則被動的回應來自NXT的相關要求.
3. NXT I 2C通訊每一次操作時最大的資料傳輸量為16 Bytes, 對於存取擁有大量資訊的周邊裝置時, 必須留意這個限制.(如:Mindsensors NXTCam’ NXTServo)
4. 每一個I 2C裝置都具有一個特定位址, 稱為Device address (或I 2C bus address), 會在出廠時由廠商預設, 當NXT對Slave裝置進行I 2C讀寫操作時, 它的”通訊標的”即為：Slave裝置所接的input port + 裝置的Device address.
l 每一種裝置的Device address設定值通常可以由廠商的產品文件/網頁中取得, 不過, 有些I 2C裝置因為功能複雜, 原廠可能會因為支援能力問題只提供NXT-G block而不提供NXC API 所需的Device address資訊.
l Lego定義的I 2C Device address為7-bits編碼, 所以最多可以有127組編碼, 而在I 2C通訊時傳送的data payload會放在bit 1-bit 7, bit 0則作為R/W動作指示, 因此, 原廠所公佈的Device address事實上已經是left shift 1之後的值(也就是乘以2), NXC為採用原廠值, 但於LeJOS若需要自行撰寫I 2C Device Class時, 必須將原廠值除以2還原成真正的Device address.
5. 每一個I 2C裝置事實上都是具體而微可以執行特訂功能的微型設備, 因此會有內部記憶體用來存放所需的資料稱為Internal register(或register), 而裝置對於記憶體中資料存放的布置方式稱為Register Layout, 至於每一個特定資訊在記憶體的參照位置則稱之為register address, 因此, 若NXT需要對於裝置存取特定的資訊時, 也就是對通訊標的(Port + Device address)內資訊所在的register address參照位置進行存取.
l Lego對於register layout有特定的memory model, 亦即會規範特定的資訊應存放的register address, 如: 0x00-0x07 存放裝置的軟體版本(Sensor version number), 0x08-0x 0F 存放廠商ID(Manufacturer), 0x10-0x17 存放裝置ID(Sensor type).
l 參考Hitechnic IRReceiver Sensor的register layout, 表格中的每一列代表存放於裝置記憶體內的特定資訊, 舉例: 當IRReceiver若偵測到Channel 1’ Output A的IR控制信號時, 會將之轉換成對應值後存放至0x42的register address(Motor 1A control), 所以, 我們就可以透過I 2C Read讀取這個位置的值來得知IRReceiver偵測到的結果
IRReceiver Register Layout
Address Type Contents
======= ====== ====================
00 – 07H chars Sensor version number
08 – 0FH chars Manufacturer
10 – 17H chars Sensor Type
18 – 3DH bytes Not used
3E – 41H chars Reserved
42H byte Motor 1A control
43H byte Motor 1B control
44H byte Motor 2A control
45H byte Motor 2B control
46H byte Motor 3A control
47H byte Motor 3B control
48H byte Motor 4A control
49H byte Motor 4B control
- 留言者: CAVE
- Email: zero.five@msa.hinet.net
- 網址:
- 日期: 2009-12-15 17:53:07
[版主回覆12/15/2009 22:01:06]
謝謝!
整理這些文章的目的, 主要是夠將過去玩過的心得能夠保存下來, 如果不嫌棄, 還望多多指教
您是CAVE的阿吉嗎? 對於NXC的推廣也相當用心ㄛ, 加油!
沒有留言:
張貼留言