マイコン工作実験日記

Microcontroller を用いての工作、実験記録

MMA9555L

2016-06-28 23:58:41 | Weblog
Digikeyの新製品紹介を見ていて、今更ながらMMA955Lというセンサーがあることを知りました。

品番がMMAで始まることからもわかるように加速度センサーなのですが、データシートではIntelligent Motion Sensing Pedometerと謳われています。「なるほど、歩数計機能が追加されているんだな。」と思ってデータシートを覗いてみてびっくり。歩数の計測だけでなく、移動距離や移動速度、消費カロリーの計算、出力までやってくれる「活動量計」になっています。身長、体重、性別データをレジスタに設定しておけば、加速度センサーの出力を解析して、各活動量を算出してくるようです。解析、演算処理のために、内部にはColdFireのコアが組み込まれています。

センサーのレジスタを読みだしてLCDに表示したり、BLEで飛ばしたりするだけで、ちょっとした活動量計の出来上がりですな。今度、何か買い物する時に、ついでにポチってみようかな。うまく半田付けできるかどうか自信ないけど。
コメント
この記事をはてなブックマークに追加

SystemViewerでタスクの動作状況を確認する

2016-06-17 17:37:10 | Weblog
3ヶ月ほど前から使っているので、そのうちに記事にしようと思っていたのですが、ずいぶんと遅くなってしまいました。。。

ここのところ、STM32 CubeMXでコード生成させて FreeRTOSを使っているのですが、FreeRTOSの動作状況を視覚化することのできる便利なツールがSEGGERが提供しているSystemViewerです。FreeRTOSで使っている割り込みハンドラーや各タスクの動作状況を視覚化してリアルタイムで表示してくれるので、一度使い始めたらもう手放せません。なんか、見ているだけでも楽しいですし。SilverTel SLICを使ったプロジェクトをSystemViewで見てみると次のような画面が得られます。




プログラムを実行中はこの画面表示が刻々と変化して流れていくのですが、記録表示動作を止めて蓄積したデータを保存することができますので、後から動作状況をゆっくりと確認することができます。




この画面絵はTime Line表示の高さを増やして見やすくしてみました。割り込みが意図した間隔で正しく発生していることを目で見て容易に確認することができるのは嬉しいですね。これまでは、ハンドラーの中で未使用のGPIOを反転させて、その様子をオシロやロジアナを使って確認していたような作業がJTAGだけで出来てしまいます。割り込みの発生に伴って関連するタスクが実行する様子もよくわかります。電話の通話処理はDMA完了割り込みを契機としてWT32とSLICとの間で相互にデータを送りあえばいいだけなのでタスク処理もとても短くてすみます。そのため、ほとんどの時間、CPUはIdleしていることもわかります。

そんな中で、たまにしか走らないんだけど、結構処理に時間がかかっている奴がいます。




赤く表示されているPhoneTaskですが、優先度が低いので、他のタスクに割り込まれつつも3500μ秒ほど走っています。実は、このタスクはRTCからのAlarm割り込みを契機として走り始めており、1秒おきに時刻表示を更新している部分に相当します。実際にLCDに対してコマンド/データを送信している部分はSPI DMAの部分ですので、ほとんどの時間は送信すべきデータの準備に費やされていることになります。どうやら、拝借したLCDのライブラリのフォントデータ処理が遅いようです。

このようになかなか便利なSystemViewerですが、SEGGERが提供しているコードで対応しているFreeRTOSのバージョンは現在 8.2.3となっています。FreeRTOSは先日 9.0が正式にリリースされたようですが、ErichさんはすでにRTOS V9.0と、それに対応したSystemVierを組み込んだPEXコンポーネントを配布しています。SEGGERからはSystemViewerとターゲットのRTOS間で使用するAPIの仕様が開示されているので、自分の好みのRTOSやOS無しシステムにSystemViewerを適合させて利用することができるのです。こちらのRKさんは、Nordic SemiのnRF52のSoftDeviceに合わせて使ってみた結果を報告されています。

SystemViewerを使って動作状況データを取得するにはSEGGERのJ-Linkが必要ですが、ST-LinkをJ-Link化したものでも使えます。同様にFRDMのOpenSDAをJ-Link化したものでも使えるんじゃないかと思います。
コメント
この記事をはてなブックマークに追加

Nucleoボードのジャンパ加工

2016-05-29 18:13:21 | Weblog
仕事で使うモジュールの動作確認をするためにNucleo-F303REを使ったので、その際に必要となったジャンパの変更についてのメモ。
使う上での要求項目は次の通り。
  • ST-Link部分は、J-Linkに書き換えて使うこととし、切り離さずに使う。本体部とのUSART接続もそのまま使う。
  • クロックはNucleo本体側に実装する8MHzクリスタルを使うこととする。
  • 電源は外部から3.3Vを供給することにする。
  • USBを使いたいので、外部にミニBコネクタを追加。

必要となった作業は次の通り。
  • 外部3.3Vからの電源供給
    • SB2を外して、ボード上のレギュレータと切り離す。
    • SB12を外してST-Link部分からのNRST信号を切り離す。
    • 3.3VはCN7のPin12とPin16から供給。
  • 8MHzクリスタルの追加
    • C33とC34に20pFを実装。
    • R35とR37に0オームを実装。
    • SB50を外してST-Link部からのMCOを切り離す。
  • ミニBコネクタの追加
    • PA11(CN10 Pin 14)をUSB DMにつなぐ。
    • PA12(CN10 Pin 12)をUSB DPにつなぐ。
    • USB DPを1.5Kでプルアップする。

STM32って、USB DPのプルアップが必要なデバイスと、内蔵でレジスタで制御できるデバイスとあるんですね。

SB12は外さなくても動くんじゃないかと思っていましたが、ONになったままだとなぜかUSBがちゃんと動きませんでした。外部3.3Vを使う場合にはマニュアル(UM1724)の指示通りにSB2とSB12の両方を外す必要があるようです。
コメント
この記事をはてなブックマークに追加

J-Linkを使って通話録音してみる -- その2 J-Link RTT Logger編

2016-05-21 22:47:04 | Weblog
前記事の続きです。J-Scopeを使って通話音声を記録することはできましたが、サポートするファイル形式の都合から録音/再生用途には向いているとは言えないものでした。

そこで、J-Scopeの代わりにJ-Link RTT Loggerを使うことにします。こちらのツールはRTTの特定チャネルに出力されたデータを、そのままファイルに記録するだけの極めて単純なログツールなんですが、PCM音声データを生で記録する目的にはこれだけで十分です。前記事の実験ではマイコン側ではチャネル1への出力をしていましたので、マイコン側のソフトへの変更は必要ありません。これまでRTT LoggerはWindows環境でしかサポートされていなかったのですが、今週リリースされたV.512f から OSXと Linuxのパッケージでもサポートされるようになったようです。



起動すると、必要なパラメータを逐次聞いてくるという仕様。引数で指定することはできないらしい。ディフォルトの値で良ければリターンを入れればいいだけなんですが、およそUnix環境向けの作りとは思えない仕様です。Windows版でも全く同じ動作仕様になっているのですが、どうやらマシな仕様にしたければ、「有償のSDK使えばお好きなようにできます。」ということらしい。

通話が終わったら、何かキーを押すことで動作を終了。ファイルをダンプしてみると、最初の無音部分には0とか-1が並んでいることが確認できます。



記録したデータをAudacityを使って録音状況を確認してみましょう。ファイル->取り込み->ロー(Raw)データの取り込みで、フォーマットを指定してファイルを読み込みます。





綺麗に再生できたので、録音にも問題がなかったことがわかります。このように音声信号程度のデータであれば、何の問題もなくRTTで送れるようです。
コメント
この記事をはてなブックマークに追加

J-Linkを使って通話録音してみる -- その1 JScope編

2016-05-20 19:06:33 | Weblog
J-LinkにはRTTというJTAGを介したメッセージ出力機能が用意されており、わたしはいつもデバックメッセージの出力に使っています。RTTでは、複数の論理的なチャネルを作ることができ、デバックメッセージ以外にもログデータを別のチャネルに出力することができます。今回の記事では、Bluetoothから受信した音声通話データをJScopeを使って表示、保存するという使い方を紹介しましょう。

まずはマイコン側のソフトの準備です。SEGGERが提供しているコードをプロジェクトに取り込めばいいのですが、ディフォルトでは2チャネル分のRTT Control Blockが用意されているものの、実際にバッファが割り当てられているのはメッセージ出力に使う最初の0チャネル目だけです。そこで、ログデータ出力に使う1チャネル目用にバッファを割り当てるとともに、JScopeで使うための名前をつけておきます。

SEGGER_RTT_ConfigUpBuffer(1, "JScope_i2", &JS_UpBUffer[0], sizeof(JS_UpBuffer), SEGGER_RTT_MODE_NO_BLOCK_SKIP);

JScopeは JScope_で始まる名前のバッファを探して、その中のデータを表示してくれます。i2は2バイト整数型のデータであることを示します。複数のデータを並べて送る場合には、それぞれの変数の型を示す名前をつけてやります。今回は 16bitの符号付きPCM音声データを送るだけなので、型指定もひとつだけです。

Bluetoothからの音声PCMデータは、DMAで80サンプルずつ受信しています。JScopeには、これを一度に送ってやればオーケーです。

SEGGER_RTT_Write(1, pcm_rxbuffer, sizeof(uint16_t)*80);

マイコン側の準備は、以上。続いて、J-LinkをPCとつなげて、音声データを読んでみましょう。残念ながらJ-ScopeはWindows環境でしかサポートされていないので、WindowsからJScopeを起動。



ターゲットマイコンの品番と、サンプリング方式としてRTTを選択したらOKボタンを押します。スコープのウィンドウが開いたら、赤いサンプリング開始ボタンを押してデータ収集開始。Bluetooth側を通話状態にしてやると、受信したデータが画面に現れます。



通話音声は16kHzなのですが、取りこぼしもなく綺麗に拾って表示してくれます。受信 /表示したデータは、FileメニューからExportすることができます。普通の ExportでCSV形式、Export Rawで生データをバイナリ形式で保存してくれます。Export Rawしてから、ファイルの内容を hexdump してみると....



ファイルの先頭部の無音部分です。PCMデータはすべてゼロなのですが、タイムスタンプも100刻みで記録されていることがわかります。記録時には何もタイムスタンプデータは出していないので、これはJScopeがテキトーに振ってくれているようです。

と、いうわけでで RTTを使って通話音声の記録ができることが確認できました。JScopeはとりあえずの確認には手ごろなツールですが、PCM音声データにするにはデータ内容を変換してやる必要があります。タイムスタンプのつかない、生のPCMファイルを作るにはRTT loggerを使った方が良さそうですが、この件については次の記事で書くことにします。
コメント
この記事をはてなブックマークに追加