FT311Dの設定

　引き続き、チップ単体そのままでADKが実現するFT311Dについてです。

　ADKは機器をAndroidに接続した時に機器を区別して立ち上げるアプリを別々にできるように文字列を送る仕組みになっています。
FT311Dのデフォルトは以下のようになっているそうです。

• Manufacture : FTDI
• Model (FT311Dのモードに以下のいずれか)
• FTDIGPIODemo
• FTDIUARTDemo
• FTDIPWMDeomo
• FTDISPISlaveDemo
• FTDISPIMasterDemo
• Version : 1.0
• Serial : VinculumAccessory1
• Description : Vinculum Accessory Test
• URL : http://www.ftdichip.com

データシートによれば、これらは設定ユーティリティを使ってWindowsPCから書き換えられるそうです。

確かに設定ユーティリティがダウンロードできます。

こんな画面です。

　ですが、Development ModuleとどうやってPCと接続するのか分かりません。基板はUSB Type-Aコネクタですから、USBケーブルでは繋がりませんし…。

ユーティリティのドキュメントは「AN212 User Guide for FT311 Configuration Utility V1.0」らしいのですが、FTDIのウェブサイトにはまだ上がっていないようです。

　もしかして「VNC2 Debugger/Programmer Module」が必要なのかも?

ひとまずは、デフォルトのままでも困らなさそうなので、このまま使おうと思います。

FT311D Development Moduleを動かしてみました(その2)

　前回に引き続きFT311DのDevelopment Moduleを動かしてみました。

今回は簡易ロジアナを接続してどんな波形が出てるか見てみました。

GPIOモード

　まずはGPIOモードを見てみました。

モードは基板の3つのジャンパプラグで選べるようになっています。

下図の丸で囲んだ部分です。基板のシルク印字に従ってOpen/Closeを設定してから電源入れるとOKです。

　GPIO0とGPIO6を出力にして波形を見てみました。

まったく同タイミングで立ち上がっているようです。

　どうせ後で簡易ロジアナを使うならGPIO0～GPIO6全部を観測すれば良かったのですが、この時点ではオシロで測ってました。

おそらくですが、GPIO0～GPIO6は全て同一タイミングで変化するんじゃないかと想像してます。

　力業で何かのプロトコルを実現するのもできそうですね。

　GPIOの状態ですが、Androidのアプリが終了しても維持されるみたいです。

AndroidとのUSB接続が切れた時にFT311D側がリセットされるようで、出力に指定していたピンもハイインピーダンスになるみたいです。

PWMモード

　次はPWMモードで動かしてみました。

簡易ロジアナでPWM0, PWM1, PWM2を見てみました。設定は

• 周期1ms
• PWM0 デューティ 20%
• PWM1 デューティ 40%
• PWM2 デューティ 60%

としてます。

周期は1～250msを1ms単位で、デューティは5～95%を1%単位で指定できるみたいです。デモアプリの動きを見ると、デューティは0%も指定できるみたいです。

　波形はこんな風でした。

チャンネル間で立ち下がりが一致する形で動いているのが分かります。

　PWMモードもAndroidのアプリが終了しても信号出力は維持されるようです。

AndroidとのUSB接続が切れた時点で全チャネルLowになるみたいです。

SPI Masterモード

　最後にSPI Masterモード (FT311Dがマスターになる) を試してみました。

　デモアプリから何バイトかWriteしてみてSS0, CLK, MOSIを観測してみました。

上から3Byte, 4Byte 8Byteを送出した場合です。

3Byteの時は時間分解能が異なります。

　SSをかなりがっつりアサートしているようです。まぁ、きわどいのよりはいいです。
若干不思議なのは、送出バイト数によってSSの立ち上がりタイミングが遅くなったり早くなったりするみたいです。細かいことですが…。

　1Byteを送出した時のCLKとMOSIはこんな感じでした。
SPIはモードが4つありますが、FT311Dでは Androidのアプリ側から設定して切り替えられるようです。

　アプリの準備などができたら、どのくらいのレートが出るか測ってみたいな、と考えています。

FT311D Development Moduleを動かしてみました

　ZedBoardも触ってはいるのですが、
FTDI社のFT311D Development Moduleが届いたので、とりあえずAndroidに接続してみました。

　FT311DはそのままでAndroidに接続するだけでADKが使えるというチップです。
FT311D側がUSB Hostになって、Androidに給電しながら動く形です。

コンフィグピン(3bit)の設定で

• GPIO (7bit)
• UART (1ch)
• PWM (4ch)
• I2C (1ch)
• SPI (1ch, FT311Dがスレーブ)
• SPI (1ch, FT311Dがマスター)

のどれかで動作させられます。(追記:PWMが抜けてたので直しました2012/12/13)

　これまでAndroidに何か繋ぐとなると、Arduino, PIC, mbedなんかでMicroBridgeかADKという感じでしたが、

簡単なGPIOや、ともかくUARTでいいって場合には、もうこれでいいんじゃない、というお手軽なモノです。

　FTDIサイトでデモアプリのソース、APKを配っています。

ひとまず、GPIODemoを試してみました。

　Nexus7 (Android4.2.1) で動かすとこんな感じで、すんなり動きました。

• OUT BITMAPで0, 1をチェック
• CONFIGをクリック
• OUTDATAを操作して、WRITEをクリック

とすると、LEDが反応しています。

　次はNexus S (Android 4.1.1) に接続してみると…、動きません。というか画面が変です。

こんな感じです。

　どうもレイアウトがダメっぽいです。これでは右にあるはずのCONFIGやWRITEがクリックできません。

　ソースも配布されているので、手っ取り早くレイアウトをいじってみました。

手抜きですがこんな感じになりました。基本的にWidthとかMarginとかを小さい値にした感じです。

　これでなんとかCONFIGやWRITEがクリックできます。

　実際、接続してみると、操作しにくいですが動きました。

　このままGPIOなんかで使ってもいいのですが、
今後はFPGAとAndroidの接続に使ってみようかと考え中です。
Twitterで情報が流れてて、「あ、それがいいな」と。

　今までは

• Android --(USB)-- PIC --(SPI)-- FPGA (PICでMicroBridgeを実装)
• Android --(USB)-- MAX3421E --(SPI)-- FPGA (FPGA上のNiosIIにMicroBridge or ADKを実装)

とかやっていたのですが、FT311Dを間に挟むのがトラブらなさそうで良いかなと期待しています。

ZedBoardのDDR3 SDRAMチップ

　ふと気づいたのですが、ZedBoardの2012/08/24版の回路図にはDDR3 SDRAMチップは

MT41K128M16HA-187E

となっています。　ですが、Hardware User's Guideには

MT41J128M16HA-15E

と書かれています。　Board Definition Filesのzedboard_RevC_v2.xmlにも

MT41J128M16HA-15E

と書かれています。

　結局、-187Eなのか、-15Eなのかどっちだよ。

　実物は……、直接の型番は刻印されてないんですよね。これに限らず、最近は小さい部品が多くて、刻印見ても型番分かりづらいですよね。

　でも、調べてみると、MicronはWebページにFBGA Decoderというのがあって、FBGAのチップ刻印とパーツ型番の対応を調べられます。

　結論としては、FBGAの刻印 D9LGQ は -15E と対応するので、搭載チップは-15Eの方でした。

　さらに、ZedBoardのサイトをチェックすると、2012/11/08版の回路図が提供されていて、それでは、型番が直っていました。ボードにも色々Errataがあるらしく、赤字でいろいろ書かれていて不安になる回路図です。

　ところで、-187Eと-15Eで何が違うのかというと、主には最大動作周波数みたいです。PCパーツ風に言えば、DDR3-1066かDDR3-1333かということですね。-15Eを666MHzで動かす場合はCL=9ですが、-187Eを533MHzで動かす場合はCL=7になるとのこと。-15Eは533MHzで動かせば-187EとコンパチになりCL=7で動かせるみたいです。

　ということで、ZedBoard開発では実物が-15Eでも、533MHz動作なのでCL=7にセッティングするのが、CL=9に比べて、ホンのわずかアクセスが速くてお得そうです。実際にSDKにExportされるhw_platformのサマリを見た限りでは、-15E設定でもCL=7になっているので、デフォルトで大丈夫みたいです。

Xilinx ISE 14.3

　これまでZedBoard用にはXilinx ISE 14.2を使っていましたが、14.3をインストールしてみました。

　WebPackライセンスでXPS立ち上がるときにラインセスエラーのダイアログ出るのは相変わらずでした。

　とはいえ良くなっている点はあって、まず、新規プロジェクト作成時のボード選択にZedBoardが追加されていました。

　これまではZC702で進めていって、後でZedBoardの情報をImportさせる、としていたので、一手間減りました。

　他にもPlanAheadでも見た目など微妙には変わっているようです。ですが、大きな落とし穴が……。

　BitGenまで進むと、

ERROR:Bitstream:188 - Bad time stamp "MON 29 OCT 10:2:52 2012". Expected "YYYY/MM/DD HH:MM:SS".

といったエラーが出ます。 既にXilinxのサポート情報にも載っていて、「ISE 14.3 - 「ERROR:Bitstream:188 - Bad time stamp"」というエラー メッセージが表示される」によると、

• エラーと出てもbitファイルは生成される
• LANGUAGE環境変数がJapaneseだと発生する
• 14.4で修正予定

だそうです。エラー内容自体がどやねん、って感じですが、エラーと言っておきながらbitファイルは生成されるって……。

　それでも、発生条件が分かったので、回避できるか試してみました。
PlanAheadはバッチファイル(私の場合C:\Xilinx\14.3\ISE_DS\PlanAhead\bin\planAhead.bat)から起動しているので、それの最初の方に

set LANGUAGE=usenglish

と追記してみると、エラー出なくなったみたいです。

　Linuxでは試していないですが、同様の状況なら、LANG環境変数をCかen_USあたりにすれば回避できるように想像できます。

　長く使っている人ならCADツールのロケール周りの問題は珍しくはないですね。

　最近は、よく海外に行く人と話していると「シリコンバレーとか中国系とインド系の人ばっかり」とか聞きますので、ツール開発には英語ネイティブじゃない人が多く加わっていそうですが、それでもソフトウェアのインターナショナル対応は進まないものですね。

ZedBoard未使用ピン

　ZedBoardというかZynqについてなのですが、PL部分の未使用ピンはどうなるのかな？と思ったので調べました。

　Xilinxの開発フローでは未使用ピンの状態はBitGenの時点で決まります。
BitGenはフローの最後に.bitファイルを生成するステップです。

　「コマンドラインツールユーザーガイド」のBitGenの章によると-gオプションで、サブオプションUnusedPinというところになります。

　Version 14.1については、Pulldown, Pullup, Pullnoneのいずれかが設定でき、デフォルトはPulldownだそうです。(デフォルト値はツールバージョンによって変わったことがあった気がします。XilinxじゃなくてAlteraの話だったかもしれませんが…)

　ZedBoardのチュートリアルなどでは、特にBitGenにオプション指定していないので、デフォルトのPulldownになっているのだと思います。

　ZedBoardのような開発ボードでは、FPGA外にいろいろ繋がっているけど全部は使わない、ということが多いので (例えば、SSRAM繋がっているけど使わない、とか)、変なことにならないようにしておきたいです。
　まぁ、気になるなら、使ってないデバイスについてもポート宣言キッチリしてCS#なんかをHigh固定でネゲートするとかすればいいんですが。

　DC特性によれば、Zynq側でのプルアップ/プルダウンは10kΩ以上の抵抗値みたいです。ということで、それより十分に小さい抵抗でプルアップ/プルダウンしている分には外付けのプルアップ/プルダウンが優先されそうです。うーん、でも、それはそれで、電流消費が増えたり、プルアップ/プルダウンに逆らってドライブするのが大変とか、相手のVILとVIHの範囲が云々…、と色々悩ましい感じもしますが。

　ま、ともかく、簡単にZedBoard回路図を見てみると……、

• スライドスイッチ、プッシュスイッチ、LEDは変に電流流れたりすることは無さそう
• Audio Codec、HDMI Transmitterは細かくは見てない。I2Cの外付けプルアップとZynq内部のプルダウンがぶつかっていて少し気持ち悪いかも
• OLED(信号部分)も細かくは見てない
• OLEDの電源スイッチのN-MOSのゲート信号が外付けプルアップ 10kΩとZynq内部プルダウンがぶつかっていて、上のI2Cより気持ち悪い気が

――というので、実はむしろPullup設定の方がいいのでは?という気も。

　とはいえ、ZedBoardのForumとかでも話題に出てないみたいだし。うーん、調べだしたはいいけどスッキリしない感じです……。

Stellaris LaunchPad

　すごく安いマイコン基板が出たので、反射的に買ってきました。

　Texas InstrumentsのStellaris LaunchPadです。Cortex-M4Fがのって550円の安さ！実は初入荷の後に店に行ったのですが売り切れで、再入荷との情報を得て、買いに行って何とかゲットしました。お店では

お一人様、4個まででお願いします

――と。そりゃそうですね、破格の安さだし。

　他の方に聞いた話やTIの資料によると、どうも正規価格は約12ドルなので、期間限定のキャンペーン価格なのかもしれません。もう、何枚か買っておこうかな～。

　主なスペックはこんな感じです。

• TI LM4F120搭載
• 80MHz 32-bit ARM Cortex-M4F
• 256KB Flash, 32KB SRAM, 2KB EEPROM
• オンボードUSB Debug Interface搭載
• USBから給電
• レギュレータで3.3Vをマイコンへ給電
• USB Device機能
• リセットスイッチ & 2個のユーザ用プッシュスイッチ搭載
• 16MHz クリスタル搭載
• RTC用クリスタル搭載
• フルカラーLED 1個搭載
• BoosterPack(拡張基板)用コネクタ搭載

　見た目はこんな感じです。裏面にはコネクタしかなくスッキリしています。コネクタが足になるので、基板が裏面でクリップとかに触れてショートする心配なくて良いかと。

左1/4のあたりが、Stellarsis In-Circuit Debug Interface (ICDI) を構成している部分です。よく見ると、ICDIを構成しているのも中央と同じ型番です。結局、Cortex-M4F (LM4F120)が2個載ってます!

　Micro-BのUSBコネクタは左がICDIのポート、下はマイコンがUSB Deviceになる場合のコネクタです。電源はどちらかのUSBコネクタから供給し、それを左下のスイッチで切り替えます。

　ちなみにICDIのUSBを接続すると、仮想シリアルポートも見えます。これはメインマイコンのUARTに繋がる感じです。デバッガとかと独立にシリアルポートとしても使えるので地味に便利かな～と思ってます。

　開発ツールは複数から選べるようですが(評価期間とか制限とかいろいろ異なる)、私はTIのCode Composer Studio (CCS v5)を使いました。

　定番のLチカをするには次の手順でできました。

1. TIサイトから必要なファイルをダウンロード

• EK-LM4F120XL-CCS (CCS, StellarisWare, ICDIドライバ等が含まれる)
• Stellaris LaunchPad Workshopマニュアル
• Stellaris LaunchPad Workshopファイル

の3つです。合計で約1.3GBになります。
　Workshopのは必須ではないのですが、WorkshopのLabに沿って進めるのが手っ取り早いです。

2. ソフトウェア類のインストール

• CCSv5 (開発環境)
• StellarisWare (ライブラリなどが含まれる)
• Workshopファイル
• ICDIドライバ

の4つです。上3つはセットアップを実行していくだけです。標準のままだとc:\tiとc:\c:\StellarisWareにインストールされます。

　ICDIドライバは基板をPCに接続して、ドライバを入れていきます。PowerSelectスイッチをDEBUGにして、DBG側のUSBをPCに接続します。Windowsのデバイスには都合、

• Stellaris Virtual Serial Port
• Stellaris ICDI DFU Device
• Stellaris ICDI JTAG/SWD Interface

の3つが出てきます。

3. WorkshopのLab2をする

　実は手順2でだいたいLab1をしたことになるので、Lab2をやります。Lab2がLチカそのものです。

　結局は、

• CCS起動
• 空プロジェクト作る
• main.cを書き換える(コピペ)
• プロジェクトの設定を追加する
• StellarisWareのヘッダファイルやビルド済みライブラリを使うようにする感じです
• 実行する
• デバッガモードになって、バイナリがマイコンのフラッシュに書き込まれて動き出します

って感じです。