STM32F4discoveryでwavファイルを再生できました!!
マイコンが実用的に見えてきた初めての出来事で、私にとっては記念すべきことでした。
COIDEは、フリーで容量制限がない開発環境です。STM32F4の１Ｍｂという広大なフラッシュを使いきるのに有利な方法であるわけです（他の開発環境は有料のものが多く、その無償評価版は容量制限があります）。
しかし、直ちに動くような、音声に関するプロジェクトファイルがないのがネックでした。
つまり、COIDEは、STM32F4のプロジェクトの例として挙がっておらず、
STM社が用意したstm32068というソース一式を、COIDE用に移植しなければなりません。
その移植は、素人の私には困難を極め、いばらの道の連続でした。
エラーの数々・・・特にファイルのconflict（同一名称のファイルが2か所に存在する）、コードのコンフリクト、変数の未定義が多く困難を極めましたが、１つ１つ解決していきました。。。
そこで、今後別のものも移植できるように、その試行錯誤（STM32F4、CoIDEの環境のデバッグ）を書いておきます。（プロジェクトは、近日中にダウンロードできるようにするつもりですが、今のところ不透明です。）
１ まず、COIDEの環境の構築については、「力の技術」というサイトの「STM32F4開発環境～CoIDEの導入～」に全面的に依拠しました。
まず、簡単に説明しておくと、①COIDEは、開発するソースコードを管理するアプリケーションでエディタのようなもの、
②ビルドツールチェインというのは、そのソースをコンパイル、リンクするもので、上記COIDEから呼び出して、実行するようになっています。
これら①②の組み合わせは、多種多様のようです。たとえば、有料のものだけど、お試しで無料のものを提供しているところは、②で出来上がったファイルの容量（例えば３６ｋｂ）で、制限をかけているようです。
③ST-LINKユーティリティは、②で出来上がったファイルをマイコンへ組み込みます。
２ プロジェクトファイルの整備
開発環境が出来上がったら、プロジェクトファイルを整備します。
このステップではまだCOIDEを立ち上げなくてもいいです。
まず、開発のためのプロジェクトフォルダを用意し、そこに、stm32068の「D:\stm32f4\stsw-stm32068\STM32F4-Discovery_FW_V1.1.0\Project\Audio_playback_and_record」（D:\stm32f4はstm32068のzipを展開したフォルダ）から、inc、srcのフォルダを丸ごとプロジェクトフォルダへコピーします。
また、「旧STDライブラリ版 フレームワーク 2014/04/15」というテンプレート（「 4. CoIDEプロジェクトの作成」というページの下の方）を利用しました。
STM32F4xx_StdFrameworkについては、フレームワークをそのまま流用しました。
そのフレームワーク内には、stm32f4xx_it.c、stm32f4xx_it.hについては、
割り込みのテンプレートが記述されているのですが、テンプレートにすぎず、
当然ながら、stm32068で提供されたPLAYBACKフォルダ内のものを使うべきであることに、注意が必要です。
このplaybackは、mainではUSBの管理しかしておらず、再生の指示などの主要な動作はすべて割り込みでやっているようなので、これは、PLAYBACK固有のものでないと動きません。
mainについては、当然にsrc内のPLAYBACK固有のものを使います。
srcとincのフォルダをコピーしましたが、これも同一名称のファイルがあるなら、フレームワークよりもsrcとincのフォルダ内のファイルを優先して登録します。
さらに、「D:\stm32f4\stsw-stm32068\STM32F4-Discovery_FW_V1.1.0\Libraries」ｄ:\stm32f4はstm32068のzipを展開したフォルダ）から、「STM32_USB_OTG_Driver」、「STM32_USB_HOST_Library」、「STM32_USB_Device_Library」を上記新設したプロジェクトフォルダにコピーします。
「STM32F4xx_StdPeriph_Driver」、「CMSIS」は、上記のフレームワークのテンプレートを使ったのでコピーしません。
CMSISは、ARMコアに関わりなくコードを抽象化する働きがあるようですが、よくわかりません。
STM32F4_startupは、クロックの初期状態を定めるか何かだったと思います。
３ 次に、CoIDEを立ち上げ、新規プロジェクトを作成する。
projectタブ→new Project →ここではstm32F4vgt6を選択する。
→吹き出しが現れ、「new Project」を選択する。
次にプロジェクトのNameを聞くサブウインドウが現れるので、「use default Path」のチェックを外し、２で作ったフォルダを指定し、プロジェクト名を「Playback」など適当な名称にする。なお、ここでプロジェクト名を設定したら、Targetにも同じ名称が現れ、その名称を変える方法がないようなので、下手な名称を与えないようにする。
次に、新規プロジェクトが立ち上がったら、左に現れたmain等のファイルはすべて削除し、上記２で作ったファイルをすべて、プロジェクト名の下に組み込む。そのフォルダ内のファイルやフォルダをつかんでCoIDEの左側の欄へドロップすれば、登録される（ドラッグアンドドロップ）。
＜２０１６．５．８追加＞
管理者権限で、CoIDEを立ち上げた場合、よりCoIDEが安定するそうですが、
ドラッグアンドドロップすることはできません。
また、ＡＶＧのウイルスソフトを使っている場合、一般管理違反として捕捉されてしまいますが、
ＡＶＧのインターフェースを立ち上げ、オプション→例外で、CoIDEを追加するという方策も一策です。
ＷＩＮ８以上であれば、CoIDE２．０は不安定ですぐに落ちてしまうようで、ｗｉｎ７モード＋管理者権限で立ち上げる必要があるようです。
ここで注意すべきは、プロジェクトのファイルがあるフォルダにファイルを入れていたからといって、すべてのファイルがCoIDEに自動的に登録されるわけではなく、明示の作業で登録を行う必要がある。また、逆に、ここでの登録を削除したからといって、２で作ったファイルが連動して完全に削除されるわけではなく、あくまでCoIDEへのファイルの登録が解除されるだけである。
４ EWARMをインストールし、比較検討する。
いきなりコンパイルをしてもいいのだけれども、実際のプロジェクトは全部のライブラリを使っているわけでもなく、ライブラリ間でコンフリクトが生じることもある。
そのため、stm32068で正規に動作が保証されたプロジェクトを知らないと、コンフリクトなどのエラーが多すぎて、大変すぎる。
そこで、正規に動作が保証されたEWARMのプロジェクトをインストールし、比較検討する。
もっとも、EWARMの評価版を入手するには、住所等個人情報をさらす必要があり、
それは一応、懸念事項ではある。
ライブラリー間でファイルのコンフリクトがある一方、
上記のライブラリーの中でまったく使っていないものがあるので、登録を抹消する。
そのプロジェクトで使用しているライブラリーのツリー構造については、PDF等の資料はなく、正規に動作可能なEWARM等のプロジェクトを見て、判断するしかない。
そこで、
「D:\stm32f4\stsw-stm32068\STM32F4-Discovery_FW_V1.1.0\Project\Audio_playback_and_record」（D:\stm32f4は、\stsw-stm32068を展開したフォルダ）内のEWARMフォルダから、「.eww」という拡張子のものをダブルクリックして、EWARMのプロジェクトを立ち上げ、EWARMで使われていないファイルを確認し、CoIDE内から削除する（CoIDE上で、左欄のファイルを選択して、Deleteキー）。
５ シンボル定義を設定する
このplaybackのプロジェクトは、シンボル定義を変えることで、２通りのコンパイルが可能となっており、
それを可能にするのが、ifdefである。定義されていればそのif内を実行する。
定義といってもその項目が存在すればよく、値を定義する必要はない。
ターゲットの下の項目を右クリックすると、configurrationというのが現れ、
その中の「Conpile」タブの「Basic setting」の「Defined Symbols:」につき、
「MEDIA_USB_KEY
USE_STDPERIPH_DRIVER
USE_USB_OTG_FS
STM32F407VG」の４つを設定する（順番はどうでもよい）。
ここも、EWARMと実質的に同じにする。
EWARMの、左のカテゴリの「C/C++コンパイラ」を選び、「プリプロセッサ」タブの
シンボル定義の欄を見て、それと同じ内容にする（ただしマイコン名は、「STM32F407VG」という点が異なる）。
また、コンパイルのエラーを見ながら、足りないとされれば追加する。
ちなみに、「MEDIA_USB_KEY」というシンボル定義でコンパイルする場合、
stsw-stm32068のPLAYBACKのEWARMのプロジェクトでは、
シンボル定義は
「USE_STDPERIPH_DRIVER
STM32F4XX
USE_USB_OTG_FS
MEDIA_USB_KEY」となっている。
６ コンパイルを行い、エラーを取り除く。
ここからが、ファイルのconflict、コードのconflict、変数が定義されていないというエラーとの戦いの始まりである。
上記の４、５によってある程度は減っていると思われるが、
コンフリクトが生じた場合、stsw-stm32068で提供されたコードを優先して、それ以外をCoIDEの登録から削除する（選択してDeleteキー）。
間違っても、stm32f4xx_it.c、stm32f4xx_it.hは、上記テンプレートを使ってはならない。PLAYBACKでは割り込みが主要な動作を担っているから、中身の空のテンプレートでは、何も動作しない。
「STM32F4xx_StdPeriph_Driver」、「CMSIS」については、上記のフレームワークのテンプレートを優先するが、悩ましい。また、system_stm32f4xx.cについては、当初、テンプレートのほうのStdPeriphライブラリーの奥の方のフォルダにあるものを登録し、stm32068で提供されたsrc内のほうの登録を削除していましたが、これだとコンパイルはできるのですが、STM32に入れてみるとまともに動作しません。やはりstm32068で提供されたsrc,incにあるものが優先的に登録すべきです。ちなみにsystem_stm32f4xx.cはシステムクロックなどの初期設定を行っています。
次に、ファイル間で、コンフリクトする場合の対処について述べます。
今回では、「#ifdef USE_FULL_ASSERT」以下のコードが３か所で同じ記述がされています。
そこで、このような同じ記述は、１つのファイルだけに記述して、他はコメントアウトします。
ちなみにEWARMでは、なぜこんなに簡単にコンパイルが通るのかと思ったら、
すべて、コンフリクトなどは、警告で済ましているのでした！だからそのままどんどんスルー。警告が何十行も出ます。
CoIDE＋gcc-arm-none-eabi-4_9のツールチェインならば、エラーでストップしてしまうのに・・・
その分、CoIDE＋gcc-arm-none-eabi-4_9は、コンフリクトに対し厳格です。
７ 動作確認
コンパイルが通ったら、stLinkを用いて、コンパイルしたファイルをSTM32F4へ転送します。
ミニUSBのほうが、PCにつながります。また、電源供給を担っています。
マイクロUSBのほうは、USBメモリを刺します。ラズベリーパイだとマイクロUSBが電源供給だったので、ちょっと違います。なお、USBの通常のＡ端子は、メス―メスプラグが必要となります。なぜなら、ＵＳＢメモリはオス、マイクロUSB⇔ＵＳＢのＡ端子もオスだから、そのままでは接続できないからです。
このように接続したのち、STLINKのtargetタブの「program&Verify」でファイルを選択し、
終わったら、targetタブのdisconectを押します。
赤いランプまたは青いランプが点滅すれば、きちんと動作しています。
青いボタンで、録音、再生を切り替えます。
そうすると、赤いランプが点滅した状態で、録音モードで、何かをしゃべってみてください。
そうすると、音声が「01:record.wav」だったか忘れたが、USBメモリに記録されます。
その後、青いボタンを押すと、青点滅になり、そのしゃべったものが、ミニジャックからヘッドホンで流れます。
結構感動です。ちなみに、youtubeにも、その様子が公開されています。
８ 次に既存のCDレベル音源にチャレンジです。
４４．１ｋHZ、ステレオの音源を探して、USBメモリに入れます。
ファイル名は、１１文字までです。日本語のファイル名はできるかわかりません。
ファイル名は適宜変更しておきます。
ファイル名は「0：xxx.wav」の形式に、とりあえずしてみてください。
xxxの部分は任意です。３文字である必要はありません。
「0:」を付していないファイルでも再生できるのかは今のところよくわかりません。
その後、
「main.h」の #define WAVE_NAME “0:audio.wav”を上記USB内のファイルの名称に変更します。
そうして、コンパイル→STリンク！
青点滅のモードでは、録音したファイルではなくて、そのUSBに入れたファイルを再生できました。
DMA転送して、逐次データを取り込んでいるので、ファイルの長さはおそらく問題ありません。
元のものは、３０秒しか再生できませんが、
１曲丸ごと再生できます。繰り返し再生されます。
ファイルシステムをいじれば、別のファイルも選択して再生できるようになるはずです。
９ その後の展望
（１）文字ディスプレイを接続して、ファイルを選択、表示できるようにしようと考えます。
（２）また、外部クロックを入力できるようにしようと考えます。
STM32F4では、音声信号の伝達に、I2Sなどをサポートし、ＵＳＢメモリや、ＳＤカード、フラッシュメモリカードなどから、ＤＭＡ転送したデータを、マスターモードまたはスレーブモードで伝送する機能があります。マスターモードでは、内部で必要な信号を作成し、スレーブであるＤＡＣへデータ、クロックを出力します。スレーブモードでは、外部のクロックに合わせて、データをＤＡＣへ送信します。
スレーブモードでは、左右クロックであるＭＣＬＫの作成はなく、クロックジェネレータ、つまり分周やＰＬＬなどのモジュールは、ＯＦＦになります。このようなスレーブモードの動作はＳＰＩのスレーブモードと同じようになり（ＬＲＣＫがないという違いだけ）、ＳＴＭ３２Ｆ４ではＩ２Ｓをマスターモード、スレーブモードとも、ＳＰＩの特別な場合のように扱っているようです（ただし特別の物理的コアを用意しています）。
ここで注意すべきは、マスターモードでも、外部から正確なパルスを入力できるということです。これを使えば、内部のＰＬＬを使わずに単に内部で分周するだけで、ＭＣＬＫなど必要なパルスを作成してくれるので、ハードウェアの設計が楽になります。なんとなれば、ディスカバリーのボードからクロックを入力することもできます。後述のとおり、ＲＣＣクロック設定レジスタのビットを変えるだけなので楽ちんのように思えます。DISCOVERYボードは、ｄａｃも接続済みですし。ただし、入力するマスタークロックは、ｆｓの２５６倍と決まっているので、１９２Ｋｈｚをサポートするには、４５Ｍｈｚなどの高周波を入力することになります。
マスタークロックの入力は、I2S_CKINピンで行い、その信号を入力として使うには、リファレンスマニュアルのｐ１６３で、ＲＣＣクロック設定レジスタのビット２３（I2SSRC）に１を入力することにより行います。同マニュアルのシリアルインターフェースの説明のところのｐ９４４等から、かなり離れているので、見つけづらいです。上記Playbackのプロジェクトでは、「system_stm32f4xx.c」というファイルのＬ７３のところに、 「I2S input clock(Hz) 」という入力周波数を調整する項目があります。明示には記述がないのですが、このファイルにクロックを外部入力モードにする記述をすることになるのかと思います。ちなみに、スレーブモードにするには、＜２０１６．７．１３ 修正します＞ｐ９３１「ビット 9:8 I2SCFG： I2S 設定モード
00：スレーブ – 送信」にします。
１０ stm32ｆ４の上記「MEDIA_USB_KEY」による音声信号送出方法
stm32ｆ４の上記「MEDIA_USB_KEY」では、メモリに２つのバッファを用意して、usb経由でメモリへまとめてバッファのデータを落とし、メモリ内のバッファを一定速度でDMA転送しているようです。このDMA転送では、I2Sのクロックに従い、メモリからI2sというペリフェラルへ１ワードずつ送りだす。この送り出しは、２バイト（１６bit）、４バイト（３２bit）ずつになり、２４ビットのデータを送る時は、レジスタに「ビット 2:1 DATLEN：転送されるデータ長」（リファレンスマニュアルｐ９３２）に「24 ビットデータ長」をセットし、ビット 0 CHLEN：チャネル長（オーディオチャネルごとのビット数）に３２bitを設定する。ｓｔｍ３２では、i2sのペリフェラルに送り出す単位は、３２bitしかできないので、２４ビットのデータを送りだしたしたときは、残りの８bitには、強制的に０が埋められる。２４ビットのwavファイルには、左右３バイトずつ、交互に並んでいるが、自動的に０を埋めてくれるので、ペリフェラルに送り出す単位が、３２bitであることは考えなくても、レジスタを設定すれば足りる。
バッファの１つが空になれば、USB経由で、バッファがフルになるまで、媒体からメモリへまとめて転送する。
usbでなく、ハードディスクやSDカードなど他の媒体から音声データを送出するすることも、SPI ステータスレジスタ（SPI_SR）（一部i2s兼用）のビット 1 TXE：送信バッファエンプティが空になった場合に、どこから読み込むかを指示するだけで、容易に変えられるものと考えられる。
