mbed LPC1768でインバータ制御できるか？

　久々の更新です。紆余曲折で「青mbed（mbed LPC1768）でインバータ制御信号を出せるか？」といった質問を何回か受けているので、一回まとめておこうかと思います。

　結局、やりたいのは

こんな感じの信号を出力したい、ということです。Tを1周期として指定されたA～Gの各タイミングで対象の信号をHighにしたりLowにしたりします。Tは数us～数十us程度になります。

　細かく考えるとより多いch数、運転モード・停止モードの遷移、ソフトスタート、ソフトストップ、周期固定 or 変動、などいろいろありますが、そのあたりは後回しということで。

　私が考えたところでは、答えは「mbed LPC1768では出力できない」です。

　厳密には割り込みとGPIOを使えば出力できそうに思いますが、この方法は除外して、それなりのペリフェラルが主導して動作する構成を考えていきます。

　「LPC17xx User manual」を見たところ、使えそうなペリフェラルは

• Timer
• Pulse Width Modulator (PWM)
• Motor control PWM

になります。

　Timerは周期的な信号を出力させられますが、結局は無理そうです。もっと単純なパターン、例えばデューティ比50%の信号、なら出せそうです。

　PWMはうってつけのモジュールですが、対応ch数がきわどく足りません。User manualにも書いてありますが、3chまでなら出力できます。

　User manualの「24.4 Sample waveform with rules for single and double edge control」で説明されている通りなのですが、もう少し説明するために「Fig 119. PWM block diagram」を引用すると

ここで色をつけた部分が動く箇所になります。Matchレジスタがもっとあれば、実現可能かもしれませんが、足りないものは仕方ないですね。

　残るはMotor Control PWMですが、これは基板の配線の都合でmbed LPC1768では使えません。Motor Control PWMの出力ポートMCOA0, MCOB0, MCOA1, MCOB1, MCOA2, MCOB2どれも未接続だったり別用途に使われていて、DIPnに接続されていません。

　ただ、もしMotor Control PWMが使えるなら所望信号が出せるかというと出せそうです。実際に試してはいませんが…。mbed LPC1768に近いLPCXpresso1769ならMotor Control PWM出力が取り出せるので試せそうに思います。Motor Control PWMを使えば、4ch信号でなく、3相インバータの6ch信号を出力することも可能です。

HP ProLiant ML310e Gen8 v2にUbuntu Server 14.04LTS

職場のオフィス内サーバーをそろそろリプレースしないとな、というのでHP ProLiant ML310e Gen8 v2を購入してもらって、Ubuntu Server 14.04LTSをセットアップしたりしています。

いくつか気づいた点などあったので、ブログに書いてみようと。

トルクスドライバーが付いてない

HPのサーバー(MicroServerなども)では、HDDの固定にネジ穴が星形のネジが使われています。以前はL字型のトルクスドライバーがサーバーに付いてたのですが、ML310e Gen8 v2からは付いてないそうです。

HPのサポートページに「注意：一部の ProLiant Gen8 サーバー - HP ProLiant Gen8 サーバーからの T-10/T-15 トルクスドライバー工具の除去」と説明されています。

結局、トルクスドライバーを購入しました。

HDDの取り付けはT-10というサイズのトルクスネジでした。トルクスネジはネジ穴中央に突起があるパターンもありますが、サーバに使われているのは突起無しでした。

RAIDコントローラー

HP Dynamic Smartアレイ B120i コントローラーというのが搭載されています。結局は、IntelのチップセットのRAID対応機能をベースにしたものらしいのですが、BIOSの初期設定では、Ubuntuは起動できないようです。

サポートページをあさったところ、RHELやSuSEでは、ドライバが提供されるようなのですが、Ubuntuなどではサポートされないようです。というので、BIOSでB120iコントローラーの動作モードを非RAIDなAHCIモードに設定すると、Ubuntuも動くようになりました。

LPC15xxのSCT(2)

その後もLPC15xxのSCT (State Control Timer)についてアプリケーションノートなども見て考えましたが、結局、やりたいことは実現できそういないかな、というのが今の結論です。

結局、一番やりにくいのが
「ソフトウェアからイベントのトリガを生じさせられないのでは？」
という点です。見落としているのかもしれませんが…。

変則な手としては、ソフトウェアからGPIOに出力し、SWM (SWitch Matrix)経由でSCT inputに信号を入れる、というのができるかもしれません。感覚としては、何かな～、というところです。

デューティ比を更新すること自体は、reload register (別のマイコンだとshadow registerって言うのかも)があって、割り込みなど連動させてうまくreload register更新していけば、デューティ比更新していけそうです。これは、cookbookにもサンプルがありました。

そんな感じで、最近は横道にそれて、他のマイコン(dsPICとか)ではどうか?とあちこちデータシートをつまみ食いして回ったりしてます。

LPC15xxのSCT(1)

考えとかまとまってないですが、たまにはブログ更新しようかなというので、メモ的な内容です。

最近、NXPのマイコンLPC15xxのSCT (State Control Timer)をいじってみています。ひとまずの実機はLPCXpresso 1549です。

SCTは1個で出力10chあって(Largh SCTの場合)、かなり複雑な信号生成ができそうです。電源制御やモーター制御の場合、3相で6ch、ブレーキなどがあっても7chで足りることが多そうなので十分そうです。

が、私が以前仕事で作ったのは12ch以上必要で、そういう場合はSCT 1個では足りないので2個以上を同期連動させることになりそうです。電源制御などでは、単にchごとのデューティ比がそろっていればいいのではなく、各chが同期している必要があるので考慮が必要です。厳密にいうと

• 運転開始時の信号の挙動がきっちり決まること
• 運転中にノイズなどによっても信号の位相がずれないこと
• 運転停止時の信号の挙動がきっちり決まること

といったことが求められます(私が関わったのは試作品だったので、実際の製品だともっと厳しいかもしれませんが)。

その仕事の時は別のマイコンを使っていたのですが、複数のPWMモジュールを同期させる仕組みがきっちりしていたので、若干のひねりは必要でもユーザーマニュアルやアプリケーションノートを見れば実装できました。

LPC15xxのユーザーマニュアルやSCT関連のアプリケーションノートをあたった限りでは、複数SCTの同期についてドンピシャな説明は見当たりませんでした。SCTの場合、SCT0とSCT1でカウンタを同期させるという説明は無かったですが、SCT0とSCT1間での信号接続はあるので、それを使って同期させるのかなと考えています。ユーザーマニュアルによれば下図のような接続関係があるようです(UM10736 "LPC15xx User manuarl"より引用)。

そこら辺から考えて、以下のような方法でいいのではないかなと (まだ実機で試してはいませんが)。

• SCT1のHALTはソフトウェアで解除しておいてSTOP状態にしておく
• SCT0からカウンタクリアされる時にSCT1にパルスが出るようにしておく(SCT0のイベント2つ使う?)
• SCT1ではSCT0からの信号でSTARTするようにしておく（SCT1のイベント1つ使う)
• SCT1でSCT0からの信号とSCT1カウンタがずれたらエラーとして止まるようにしておく(SCT1のイベント1つ使う)
• SCT1でエラー検出したら割込か制御信号経由でSCT0も止める

運転開始時はSCT0に対してSCT1が1周期だけ遅れそうですが、制御信号の振り分けを選んで、ソフトスタートにすれば対処できるかなと。

いずれにしても、もちょっとドキュメント読み込んで実機でも試してみないとな、というところです。

PWM信号だけなら、FPGA使えば10chでも20chでも簡単に出せるのですが、A/Dとか通信とかの総合的な部分ではマイコンがやりやすいので、LPCの系列で実現できればmbedなどとの絡みでも良好かなと。

GNU Screenの日本語表示ズレ

ブログが放置状態なので、何か書こうかなというので、GNU Screenの日本語表示ズレについてです。

Putty + Screen + Vimで日本語を表示していると、表示がずれることがあります。

具体的には以下のような文字が含まれる行を編集したりコピーペーストしたりした場合です。

×÷○□※

調べてみると、どうもScreenに問題があるようです。

ちなみに各ソフトウェアのバージョン・設定等を抜粋するとこんな感じです。

• Putty
• バージョン: 0.63-jp20130916
• リモートの文字セット: UTF-8(CJK)
• CJK用の文字幅を使用する: Off
• 端末タイプを表す文字列: xterm-256color
• リモートPC
• CentOS 6.5 (x86_64)
• $LANG: ja_JP.UTF-8
• GNU Screen
• yumでインストールした screen.x86_64 0:4.0.3-16.el6
• screen -Uで起動
• Vim
• yumでインストールしたvim-enhanced-7.2.411-1.8.el6.x86_64
• ~/.vimrcでset ambiwidth=double

特にPuttyのUTF-8(CJK)というのと、Vimのambiwidth=doubleはこう設定していないと、上記以外の文字("～"など)でも表示に影響が出るようです。

それでもズレるというので、これまでは表示がずれたらCtrl-lで再描画させて凌いでいたのですが、ふと気になって調べて対策してみました。

ズレですが、FreeBSDでは起こらなくて、CentOSでは起こるというのの気がつき、FreeBSD Portsに含まれているopt-cjkwidthというパッチが効きそうというのが分かりました。

それで、手動でパッチをあててビルドしたら解決かと思いきや、CentOS上でScreenがconfigure & makeではビルドできず、手間がかかりました。

さらに調べてみると、yumでインストールされるパッケージは、素のscreen-4.0.3にいくつかパッチが適用されてビルドされているようです。ということで、最終的には以下の手順でビルド・インストールしました。

1. ScreenのSRPMパッケージをダウンロード、インストール
2. opt-cjkwidthパッチをコピー
3. SPECファイルを変更
4. RPMパッケージを作成
5. 前から入っているScreenをアンインストール
6. 生成したRPMパッケージから修正版Screenをインストール

詳細な手順は以下のようになりました。

ScreenのSRPMパッケージをダウンロード、インストール

手っ取り早くwgetでダウンロードし、rpmコマンドでインストールします。

wget 'http://vault.centos.org/6.5/os/Source/SPackages/screen-4.0.3-16.el6.src.rpm'
rpm -ivh screen-4.0.3-16.el6.src.rpm

一般ユーザ権限で実行して、~/rpmbuild/にファイルが展開されます。

opt-cjkwidthパッチをコピー

FreeBSDの/usr/ports/sysutils/screen/files/opt-cjkwidthを~/rpmbuild/SOURCES/にコピーします。
手元にFreeBSD PCが無くても、Web上からopt-cjkwidthパッチは取ってこれると思います。

SPECファイルを変更

~/rpmbuild/SPECS/screen.specを編集します。

opt-cjkwidthパッチを適用するように他のパッチを真似て以下2行を追加します。

Patch15: opt-cjkwidth
...
%patch15 -p0 -b .cjkwidth

他のパッチはほとんどが-p1となっていますが、opt-cjkwidthは-p0にします。

RPMパッケージを作成

rpmbuildコマンドでビルドを行いRPMパッケージを作成します。

rpmbuild -bb ~/rpmbuild/SPECS/screen.spec

必要なパッケージが足りない場合はエラーメッセージが出ますので、パッケージをインストール後に再度rpmbuildコマンドを実行します。私の場合は以下のように不足パッケージをインストールしました。

sudo yum install ncurses-devel pam-devel libutempter-devel texinfo

ビルドできると~/rpmbuild/RPMS/x86_64/screen-4.0.3-16.el6.x86_64.rpmができています。

前から入っているScreenをアンインストール

yumでインストールしたScreenをアンインストールします。この作業が必要なのかよく分かっていませんが念のため。

sudo yum remove screen

生成したRPMパッケージから修正版Screenをインストール

以下のようにrpmコマンドで作成したRPMパッケージからScreenをインストールします。

sudo rpm -ivh ~/rpmbuild/RPMS/x86_64screen-4.0.3-16.el6.x86_64.rpmd

ZedBoardでDSLiteを拡大表示

今回はZedBoardでの作例を書いてみます。
ずいぶん前に製作してたのですが、写真の用意など遅くなって今更ブログに載せてみることになりました。

全体像がこんな感じです。

DS Liteを改造して表示画像をFullHD級にリアルタイム拡大する、というものです。
いわゆる偽トロキャプチャの亜流って感じでしょうか。
拡大等の処理はZedBoard上のZynqで行ってます。
Androidと接続していて、Android側を操作することで拡大率や拡大アルゴリズムを切り替えられるようにしています。

残念なのは改造の都合で、上下2画面の下側しか取り出せなかったことです(^^;

ブロック図にするとこんな感じです。

元の画像は256✕192ピクセルです。対して、表示モニタは1,920✕1,080。
上の写真は拡大無しで表示しているので、左上に小さく出てるな～って感じです。
一応、よって写真とるとこんな感じ。

これを拡大率をあげていくと……こんな風になります。

最終的に縦幅をフルにしたところで5倍ちょっとです。
写真撮ってないですが、もっと高い倍率でも動きます(その場合、当然、元画像の一部分が画面いっぱいに表示されることになります)。

拡大率だけじゃなくて、拡大アルゴリズムも切り替えられます。
両方とも、教科書に載ってる基本のアルゴリズムです。
上がニアレストネイバ、下がバイリニア(ちょっとエッジ強調入れてます)です。
あんまりうまく写真撮れてませんが……。

DS Liteの改造はこんな感じです。
液晶へのフラットケーブルこねくたの半田付け部分にUEWを半田付けしてます。
あと邪魔だったので、GBAカセットのコネクタは取っちゃってます。
半田付けがめちゃ疲れました……。

Android周りは一旦PICマイコン(PIC24FJ64GB002)に接続してからZedBoardに接続してます。
Android-PIC間はMicroBridgeで接続しています。
PIC側の実装は石井さんのmicrobridge-picではなくて、自分で実装したものを使ってます。
PIC-Zynq間はPIC側がマスターのSPIで接続しています。

Androidの画面はこんな感じです。

拡大率をシークバーでずるずるできます。
見た目では分からないのですが、下の黒い領域でピンチイン/ピンチアウトしても拡大率が変わるようにしてます。

とりあえず、わーっと写真披露した感じです。
お小遣いで買えるぐらいのFPGAボードでもFullHD(1,920✕1,080) 60fpsとかが扱えるんだぜ、ということで。

後日、部分部分で取り上げて、もう少し詳しく書くかも?です。

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」が必要なのかも?

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