STM32L4+

STM32 CubeMXが更新されたようなので、早速インストール。先日はまったSTM32L452のHSICalibrationValueを確認してみたものの、まだ修正が反映されていないようです。相変わらずディフォルトが16で、これ以上の値が指定できません。64が指定できればいいんですが。。

さてMCU Selectorを見ると、どうやら近日中にSTM32L4+シリーズというのが発表される模様。特徴はOCTOSPIとGFXMMUとかいう機能らしい。OCTOSPIはまぁ察しがつきますが、GFXMMUって何でしょうね？グラフィックスのアクセレータか何かでしょうか。ルックアップテーブルを持つようなので、何か変換に使うもののようです。

上位機種ではLTDCだけでなくDSI Host機能も持つようです。Low powerでもGUIの時代ということですね。

micro:bit

秋月を始め、各店でmicro:bitの販売が始まったようですね。いわゆるTelec版というやつで、日本の工事設計認証を受けたタイプが製造されるようになり、国内での販売が開始されたようです。



で、ホームページの写真を見て気づいたことが２点。

1. ボード上には証明番号の表示はないようである。どうやら、説明書には記述があるが、ボード上にはラベルやシルクでの表示はないようである。
2. これまではWiFiやBLEのボードって、大概は認証を受けたモジュールを搭載したものだったのですが、こいつはボードとして認証を受けているんですね。

国内で販売されているモジュールは、ほとんど金属シールドで覆ったカンになっていますが、その背景には無線機部分を改造されることを防止する効果も期待されていたのではないかと思います。今やRF内蔵のマイコンにPCBのパターンアンテナで足りる時代なので、むき出しで良ければ当然コストダウンになります。今後は、むき出しのモジュールも大手を振って販売されるようになるんでしょうか？

BM20ではモジュールの裏側に証明番号のシルクが印字されていましたが、番号さえ控えておけば、何も恥じることなく、正々堂々と人前に出せるということですね。安心しました。

i.MX RT 1050

NXPがi.MXファミリーの新しいシリーズとしてi.MX RTを予告しています。i.MXなんだけどコアはCortex-M7で、MCUとMPUの間を埋める Crossover Processorと称しています。

なかなか実際の製品が出こないSTM32H7を凌駕する600MHzを謳っています。この速度は内蔵のRAMにコードを置いて実行するということかな？
10x10 BGAで24bit LCDやカメラI/Fもあるようですが、それだけで50ピン使うと思うんで、同時使用できるのか、外付けDRAMは使えるのかとかもきになるところです。

10月には出荷開始予定とのことですが、どうなるでしょうか。安価な評価ボードもでるみたいなので、FRDM並みの値段になることを期待したいです。

DCMIでカメラをつなぐ -- その2

ハードが用意できたので、続いてソフト編です。OV2640のSCCB制御にはI2C3を割り当てました。カメラに供給するクロックはTIM12を使ってSystemClockを分周して15MHz (90MHz / 6)を作っています。OV2640の初期化ルーチンは以前作ったものを使うつもりでしたが、STM32CubeF4の中のサンプルプロジェクトでカメラを使うものがあり、そこで使用するためにDrivers/BSP/Componets/ov2640というディレクトリがあり、ドライバーが入っていることに気がついたので、今回はこれを流用することにしました。ただし、このドライバではカメラから取り込んだ画像データをそのままLCDに送って表示することを想定しているようで、カメラの出力データ形式がRGB565になっていましたので、これをYUV422に変更して使っています。

画像データの取り込みにはDCMIを使い、そのデータはDMAでメモリに転送します。STM32CubeMXでの設定は次のようにしました。VsyncとHsyncの極性指定は、映像データの出力信号が無効な期間の極性を指定することに注意。

OV2640にはJPEGで画像データを取り込む機能がありますが、今回はその機能は使わずに無圧縮でデータを取り出し、UVCでホストに送信することにします。


STM32CubeF4が提供するHALのAPIとしては、HAL_DCMI_Start_DMA()が用意されています。引数のDCMI_MODEとしてDCMI_MODE_CONTINUOUSを指定してやると画像データを連続してDMA受信してくれます。DCMIの使い方を示すサンプルプロジェクトを見ると、1フレーム分のバッファを用意しておいてフレーム単位で受信する使い方をしているのですが、そのためにはSDRAMのような外部メモリが必要となってしまいます。今回の実験であるUVCカメラでは、受信したデータはすぐUSBから送信してしまえば良いので、フレーム分のバッファは不要です。そこで、２ラスタ分のバッファを用意しておき、これをダブルバッファリングで使うことにしました。つまり、１ラスタの受信が終わったら、そのデータをすぐにUSBから送信し、その間にもう一つのバッファにカメラからのデータを受信しておきます。

ラスタ単位での受信完了はDCMIのIT_LINE割り込みで検出することができ、HALのAPIではHAL_DCMI_LIneEventCallback()が呼ばれますので、この時点で受信できているデータをUSB UVCで送ってやります。 またUSB UVCではフレームの区切りをパケットのヘッダー情報として示してやる必要がありますが、この区切りはIT_VSYNCとHAL_DCMI_VsyncEventCallback()で検出してやります。

このようにしてなんとかOV640からのVGA画像をMac上のQuick Cameraアプリで表示できるようになりました。






室内で実験していますが、XPCLK=15MHzにておよそ9fpsとなりました。XPCK=22.5MHzにすると13.7fpsくらい出るのですが、PCに画像が表示できません。そこでカメラが出力している信号を確認してみると...





Hsyncの間隔が短い箇所では111.4usecしかありません。受信した1ラスタ分の画像信号を１マイクロフレームに入れて送っていたのですが、USB High speedのマイクロフレームの間隔は125usecですので、画像の取り込み速度に間に合っていません。Hsync信号自体は、1msに最大８回しか出ていないので、USBに出力するパケットデータをキューに溜めてから出力するようにしたところ13.7fpsの画像も表示できるようになったのですが、時折画像が乱れます。

画像が乱れる原因としては次のような事項が挙げられます。

1. DCMIで受信した画像データを一旦USB送信用のバッファーにコピーしているため、その処理に時間がかかっている。DCMIとUSB送信処理でバッファを共有してコピー不要にすれば、改善できるはず。
2. USB送信用バッファからSTM32F446のPDCの送信FIFOにデータを送る際にソフトでコピー処理を行っているために時間がかかっている。DMAを使えば改善できる。

無駄なデータコピーが２度も行われており、そのためにCPUサイクルが消費されてしまっているのが原因です。DMAを使うだけでも13.7fpsでの画像が安定することはわかっているのですが、 そうするとどういうわけか UVC のインターフェース切り替えを行なった際にUSBのスタックの動作がおかしくなってしまいます。USBスタックのDMA動作に問題が残っているようです。

今回の実装では、１ラスタ分のデータを1マイクロフレームに入れて送信しています。１ラスタ分のUVCデータ量は、YUVデータ(640*2) + ヘッダ(12) = 1292バイトになりますが、アイソクロナス転送での１トランザクションの最大データ量は1024バイトなので、１マイクロフレームの期間に２トランザクションを使ってデータを送っています。カメラが出力するHsync信号が1msあたり8回ですので、このような簡単な処理でも表示ができています。画像データサイズが大きくなったり、取得できる秒間フレーム数が増えた場合には、できるだけ多くのデータを１マイクロフレームで運ぶ必要が生じます。そのためには、２トランザクション分の容量2048バイトに画像データを詰め込んで送信したり、それでも足りない場合には１マイクロフレームあたり、３トランザクションを送るようにする必要があります。本当はそのあたりも挑戦してみたかったのですが、DMAで安定して1トランザクションで３パケットが送れるようにならないと無理ですね。DMAについてはSTM32 Forumでもバグ報告されているので、今後のリリースに反映されることを期待したいです。

EERAM

MikroElektronikaの新製品としてEERAM clickというのが出ていたのがきっかけで、MicrochipがEERAMという製品を出していることを知りました。

EEPROMへのバックアップ機能のついたI2C NVSRAMという製品です。電源断を検出して自動的にRAMの内容をEEPROMに保存してくれます。もちろん、電源ON時には自動的にEEPROMの内容をRAMに読み出してくれます。こりゃ手軽に使えて面白そうです。自動保存のためのエネルギーはコンデンサから供給してもらいますが、16Kbit容量(47L16)の場合でも最低8uFあれば良いらしい。

機会があれば使ってみたい。

Serendipitous Circles

当初はSTM32F446のUVCがまっとうに動くよになったら、DCMIを使ってカメラをつなげてUSBカメラを作ってみようと企んでいたのですが、High speedが安定動作せずに作業が停滞している間に、カメラを繋げようという意欲が萎えてしまいました。

文字表示はできたので、今度は簡単にグラフィックス表示をしてみようと考えて、512x512ドットのモノクロ表示のグラッフィック表示機能を追加してみました。このサイズなら 512/8*512 = 32KB のRAMをフレームバッファとして使うことで表示が行えます。モノクロ表示で、それなりに楽しめる題材を考えていたら、その昔 BYTEマガジンに掲載されていたプログラムを８ビットマイコンで動かして楽しんでいたことを思い出しました。

Serendipitous Circlesという記事なのですが、今でもアーカイブにて読みことができます。素晴らしい!! 楕円上の座標を導出する差分方程式をベースとした簡単なアルゴリズムを使っているのですが、始点の座標を変えたり、わざと演算オーバフローを発生させることで描画する座標をラップさせたりすることで、簡単な演算で思いもよらない描画結果を楽しめます。基本的な処理は

int16_t xpos, xpos;

xpos = initial_x;
ypos = initial_y;

while (1) {
  plot(xpos, ypos);
  xpos = xpos - ypos /2;
  ypos = ypos + xpos /2;
}

と、するだけです。画面の大きさは512ドットしかありませんので、上位の９ビットの値を使ってプロットしてやります。例えば、(0x6000, 0)を初期値として上記の処理を繰り返すと、画面中央を原点とした次のような楕円を描くことができます。

同じ演算結果を、今度は画面の左下を原点として表示し、はみ出した部分は画面上でラップして表示してやると、次のように楕円を４隅に分割して描くことができます。

また始点座標を大きくとってやると、16ビット演算のオーバフローが頻繁に発生し、その結果が画面上でのラップ表示として反映され、予想もしないような結果を得ることができます。

その他詳しくは　元記事を参照していただくこととして、デモ動画を作成したので、こちらをご覧ください。

• このデモではプロットする際にXORを使っています。そのため、演算結果の座標が以前プロットした点と同じ座標になった場合には、その点が点滅することになります。画像がチラチラしたり、時には円が回っているように見えたりすることもあって面白いです。画像の大半が消えかけそうになることもあります。
• 動画はQuick Cameraというアプリでカメラからの画像を表示している様子をキャプチャしたものです。最初はMacbookの FaceTimeカメラでボードとUSB PHYを撮影していますが、途中でカメラ入力をこのボードで動いているUVCカメラに切り替えることでデモ画像に切り替わっています。
• いくつかのパターンを順番に表示していますが、全て中心となる演算は同一です。(X, Y)の初期値、原点の取り方、演算結果の表示ビット位置を変化させることで、表示パターンが変化しています。
• 演算で使用する係数を変えてやれば、結果の画像にも変化が生じます。BYTE MagazineのApril 1978に、いくつかの例が紹介されている記事が掲載されています。

High speed を確かめる - その5

どうも動きが不安定で頓挫状態だったUSB High speedを確かめる実験ですが、ちょっとしたことがきっかけで動きが安定してきました。

コネクタや配線の接触不良を疑って、コテを当ててみたり、ハンダを盛り直してみたりしていたのですが、全く改善は見られませんでした。コネクタ部分に指を触れると画面表示ができるようになることに気がついたので、調べて見たらPHYのRESET端子に指を触れた状態で動かし始めると、画面表示ができることが判明。そこで、試しにPHYのRESET端子に 0.01uFをつけて見たら安定して動くようになりました。

使用しているPHYであるUSB3300のRESET端子は正論理であり、USBの初期化前に一度だけパルスを加えているだけです。これまでカラーバー表示では問題なく表示できており、文字表示をしようとするとうまく動かなかったことを考えると、初期化時というよりは動き始めてからRESETが誤って発生していたのではないだろうかと想像しています。どうしてこのような問題が発生しているのかわかりませんが、ひとまずコンデンサを追加しただけで、文字表示は安定して動くようになりました。

これまで画面表示にはMacに標準でインストールされているPhoto Boothを使っていましたが、文字表示がミラー表示になってしまう上に、よく見るとVGA画面の上下が30ドット程度表示されないという問題があったので、代わりのアプリとして　Quick Cameraという単純にUSBカメラの画像を表示するだけのアプリを使うことにしました。

安さの理由

秋月でPine A64に続いてNano Pi NEOの取り扱いも始まったようです。この安さですから、入手性が良くなったのは嬉しいニュースです。これらの製品にもWifi＋Bluetoothのモジュールが用意されていたり、あらかじめ搭載したモデルが用意されていたりしますが、技適の関係で販売されないのがちょっと残念ですが。

それにしても、いくら中国製のSoCが安いからといって、 10ドルや20ドル程度の値段でこんなボードが作れたとしても儲かるわけがないとは誰もが不思議に思うところです。そうしたところが、 こんな記事を見つけました。この記事は Nano PiではなくてOrange Pi に関するものですが、内状は同じじゃないでしょうか。なんと販売価格はBOMコストでしかないんのですね。その他の経費と利益は補助金で得ているというビジネスモデルなんですね。驚き。

High Speedを確かめる - その4

USB High speedへの挑戦シリーズの4回目。アイソクロナス転送を使ってのUVCでカラーバーの表示は一応できたので、Full speedの時と同じように文字表示の実験をしてみました。今回はVGA解像度(640x480)を使っているので、YUV形式でのデータ量は1フレームあたり 640*480*2 = 600KB必要になります。STM32F446にはRAMは128KBしかありませんので、1画面分のフレームバッファーを用意することはできません。そこでRAM内には画面に表示される文字のコードと色情報だけを保持しておき、UVCのデータを送信する際に必要なラスタのビットイメージを生成してやることにしました。

処理を簡単にするために、１マイクロフレーム(125us)で1ラスタ送ることにすれば、毎秒 8000/480 = 16.66フレーム送れることになります。１ラスタには 640*2 = 1280バイトのデータが必要なので、１マイクロフレームで２トランザクションパケットを送信すればいいことになります。試しに、これをやってみたのでうが、ちっともMacの画面に画像が表示されません。試行錯誤しながらUSB PHYをつなげているコネクタのあたりをいじっていたら画面に表示ができました。




文字の表示が鏡文字になってしまっていますが、これは使用しているアプリ Photo Boothがもともと自撮り用のアプリになっているためです。それはいいとしても、なぜか意図したのとは表示されている色が違っています。コネクタをグリグリしてみても、色が代わることはありません。何度試してみても、コネクタ周りをいじらないとうまく表示しないし、色も違っています。テストバーの表示だけだったら、こんなことはなかったのですが。。。

どうも送信が安定していないようなので、１マイクロフレームで送信するパケットをひとつだけに変更してみました。それでもなかなかうまく表示ができません。やはり、コネクタをいじっていると何かの拍子に突然表示が現れます。

今度は意図した色で表示ができているようです。撮影ボタンを押して画面の表示をキャプチャすれば、文字の表示方向が正しくなった画像を取得できました。



どうにか文字は表示できたものの、全然動作が安定していません。コネクタの接触の問題なのかもしれませんが、カラーバーの表示であればいつも安定して表示できます。送信するデータの内容によってデータ化けがが生じてしまっているのではないでしょうか。PHYをつなぐワイヤ上にノイズが載っており、その影響で正しくデータが送られていないのではないかと想像しています。ユニバーサル基板でUSBハイスピードを実験するのは厳しいかな？

J-Link EDU-mini

今日見たらSEGGERのホームページが模様替えしていました。

このSEGGERが、新製品としてJ-Link EDU Miniを発表しています。機能的にはEDUと同じですが、小さくてケース無しです。お値段 $18と　EDUの 1/3になったけど、ダウンロード速度が 1/5に制限されてしまっているのが、ちょっと残念なところ。JTAGも作るよりも買った方が安いものになりましたね。

使っているのはNXPのMK22あたりでしょうか。コネクタはハーフピッチの10ピンのようですが、製品付属のケーブルは20ピンらしい。なんでやねん。