WT32をつなげる -- SAIの設定

随分と前になってしまいましたが、前記事ではWT32をUARTにつなげたので、次はPCM信号をI2SでSTM32L476につなげます。もともとSTM32ではSPIがI2S機能をサポートしていましたが、近頃の新しめのデバイスではSAI (Serial Audio Interface)という機能が備わっているので、こいつを使うことにします。SAIにはPCM u-Law/A-Lawの圧縮/伸張機能も備わっていたりするので、W-SIMのようなデバイスをつなげるのにも適しているのですが、W-SIM自体が無くなってしまったのが残念なところです。

SAIはBlok AとBlock Bで一組になっており、片方をもう片方に同期して使えばSAI_CLKとSAI_FSを共有することができます。SLIC側とつなぐADC/DACも同じPCM_SYNCで外部トリガをかけて変換動作をすることで、WT32側とSLIC側の処理が同期して進み、音声が流れることになります。SAI, ADC/DACは全てDMAを使って動かします。SAIで受信したデータを直接 DMAでDACに渡すことはできませんし、この記事で述べたようにPCM信号の符号反転処理も必要になるので、間にバッファを置いて処理を行います。

この方針でSTM32CubeMXを使ってSAIの設定をしようとしたのですが..



Output ModeでMonoを選択できません。I2SなのでHFPの音声がステレオのフォーマットで送られてきますが、そのうちの片方のデータだけを受信してDACに送りたいので、SAIではMono modeを選択したいところなんです。SAIの設定としては、Monoを選択するには、Slot数を2にしておかねばならないようなのですが、そのようにしてもOutput ModeではStereoしか選択できません。どうやら、CubeMXのバグのようです。

CubeMXの生成する .ico ファイルを修正すれば何とかなるだろうと考えたのですが、ico ファイルを見てもそれらしいパラメータが出力されていません。コード生成された main.c を開いて SAIの初期化コードを修正して対応するしかなさそうです。

Hexiwear

最近ではMicrochipのCuriosityやXpressボードでmikroBUSが採用されたこともあり、その知名度も上がったのではないかと思われるMikroElektronikaですが、KickstarterにてHexiwearなるデバイスのプロジェクトを開始しました。



MikroElectronikaは、これまでもKickstarterに登場したプロジェクトの製造請負を担当していたのですが、今度は自社ブランドでの登場です。NXPを味方につけて、NXP製品のデモプロジェクトとしての側面も持っているハードウェアとなっています。メインのMCUは Kinetis K64で、BLEはKW40となっており、主要なデバイスは旧Freescaleの製品で構成されているようです。センサー山盛りなので、結構楽しめそうです。回路図もソフトウェアもGitHubで公開されています。

2016/2/24追記
NXPにもReference Designとして紹介ページができていました。

10代工学

YouTubeを見ていてTeenage Engineeringのポケット・オペレータを見つけました。80年代を意識した製品コンセプトがとってもクールで、LCD表示も愉快です。"PO-24 オフィス" は、80年代のオフィスで使われていたフロッピーやFAX、プリンタの音を模したとのこと。シリーズで何種類かがあるようですが、つなげて同期演奏することもできるようです。

製品にはEFM32が使われているようで、LCDの下にMCU, スピーカ、DACを配置して電子部品を見えないようにしているというこだわりの作り。逆にタクトスイッチは剥き出しにしているのはデザイン上の演出でしょうか。別売でシリコンカバーケースも用意されています。

プログラミング担当の方のブログはこちら. この方も Linusさんなんですねぇ。

WT32をつなげる

しばらく作業時間が取れなかったSLICを使ったプロジェクトを再開。次の段階として、WT32を使ったHFP通話をSLICとつなぐことにします。まずは、WT32をSTM32L476のUSARTと接続。





改めてSTM32のUSARTの仕様を確かめると、FIFOがないんですね。SPIやSAIにはFIFOが用意されているのですが、USARTにはFIFOが無いのは従来のデバイスとの互換性を考慮してのことでしょうか。あるいはDMAを使うことを前提としており、FIFO無しで構わないということなんでしょうか。STM32L476にはDMAが14チャネルもあるので、迷うこともなくDMAを使ってUSART送受信することにします。STM32L4のDMAにはサーキュラーモードがありますので、これを使うだけでリングバッファへの受信処理が実現できてしまいます。

ただし、USART受信においてDMAを使う場合にはタイムアウト処理が必要となります。受信バッファが一杯になった場合には、DMA完了割り込みでそれを知ることができますが、バッファが一杯になる前に相手からのデータ送信が止まった場合には、 タイムアウトにて受信待ちを打ち切らないとせっかく受信できたデータを処理することができません。今回は、FreeRTOSを使っているのでイベント待ちをタイムアウトすることで、受信待ちを打ち切ることにします。

タイムアウトが発生したら、どこまでDMAが進んだかを調べれば、受信バッファのどこまでデータを受信できたのかがわかります。STM32L4ではDMA_CMARxがDMA転送先のメモリアドレスを示しますが、このレジスタはDMAの先頭アドレスをを示すだけで、DMAが進んでも更新されるわけでは無いということに気づかずにハマってしまいました。DMAがどこまで進んだかを調べるには、転送数を示すDMA_CNDTRxの値から求める必要があります。

こうしてWT32の出力するイベントメッセージをUSARTでDMA受信した内容を、まずはそのままRTTを使って出力してみました。




なお、受信DMAのタイムアウト処理に関しては、AN3109にても言及されており、ここではUSART_RX端子をタイマーの入力キャプチャー端子につないで、入力のアイドル時間を監視するという方法が紹介されていました。機会があれば、試してみようかな。

STM32CubeMX Eclipse pling-in

STのリリースによると、STM32CubleMXがSystem Workbench for STM32にインテグレートされて、Linuxでも使えるようになったという。もともとSTM32CubeMXは単独のWindows版ソフトウェアとしてとしてだけでなく、Eclipseのプラグインとしても提供されています。そのため、Windows以外の環境においてもEclipseのPerspectiveのひとつとしてして、STM32CubeMXを開くことが可能だったのですが、実際にはWindows以外の環境においては不具合があってうまく動作しない部分があったようです。今回のリリースにタイミングを合わせて、STM32CubeMXの新しいバージョン(4.13.0)がリリースされたので、改めてMac OS環境での動作を確認してみました。

もともと、ひとつ前のバージョンである4.12.0でMac OSX上でもほぼ問題なく使えるようになっていることを知っているので、今回の4.13.0では動かない所の確認をしているようなものです。わたしが気になっていたのは外部クロックの周波数を指定する箇所です。


いちばん左の Inout frequency のボックスにて水晶の周波数を指定できるハズなのですが、Mac OSではなぜか入力を受け付けてくれません。残念ながら今回の4.13.0でもこの問題は修正されていませんでした。幸いなことに STMCubeMXが生成する .ico ファイルはテキストファイルですので、エディタで修正が可能です。手でエディットして、再度プロジェクトをロードしなおせばクロック周波数が変更されますので、実用上は若干不便ではあるものの致命的な問題ではないので、ほぼ問題なく使うことができます。

HFP1.6の動きを確認してみる

ずっと記事にしようと思っていた事を思い出したので、遅まきながら記録として残しておくことにします。

昨年、スマホを更新してAndroid 5.0.2になりました。HFP1.6に対応しているので、WT32と接続しての動作確認です。
WT32とHFP接続してから、スマホから117番へ発信してみました。



呼がつながると、CODECとしてMSBCが選択されていることが確認できます。WT32のCODEC設定は、I2Sマスターとしてあるので、その出力信号を確認してました。




フレーム同期信号が16KHzになっていることがわかります。HFP 1.5まではMSBCがなかったのでフレーム同期は8KHzと決まっていたのですが、HFP 1.6を使うとつなぐ相手端末や実際の呼によって8KHzあるいは16KHzのどちらになるかが動的に決定されることになるようです。WT32ではMSBCを使わないようにも設定できますので、その場合には8KHz固定で動作させることもできます。