STM32F4のADC

　いつものようにCubeでADCの初期化を行う。
　ADC変換を行いたいところでADC_Startを呼び、ADC_PollForConversionで変換終了までループさせる。PoolForConvの戻り値で変換できたかどうかがわかるので、HAL_OKならGetValueでデータを受け取る。
　VREF+が3.3Vの場合、value * 3.3f / 4096で電圧になるはずだが、ウチの環境ではprintfの浮動小数点が正常に動作しないので、未確認。スタックサイズをいじっても変わらないし、いよいよコンパイラなりライブラリの異常を疑いたい感じ。あとでコンパイラのバージョンを変えて試してみたい。

　他のペリフェラルと違い、ADC_Startで開始した後に、ADC_Stopで停止する必用はない。消費電力を可能な限り下げたい場合は、ADC_StopでADCペリフェラル自体を停止することが可能。ただしADC停止中にADC_Startを呼ぶとウェークアップ時間のループが有るので、タイミングクリティカルな部分ではStopしないように。そもそもタイミングクリティカルな部分では外部トリガ使えという話だが。

HAL_ADC_Start(&hadc1);
HAL_StatusTypeDef status = HAL_ADC_PollForConversion(&hadc1, 10);

if (status == HAL_OK)
{
    uint32_t value = HAL_ADC_GetValue(&hadc1);
    uint32_t tmp = value * 3300 / 4096;

    printf("%4d %4d\n", (int)value, (int)tmp);
}
else
{
    printf("ERROR:%d\n", (int)status);
}

***

　次はTIMで定期的に変換と、DMA転送かなー。それができるようになればADCである程度高速な波形(数kHz)のサンプリングができる。
　超音波風速計のリベンジ。さすがにF103CBではRAMがもうちょっと欲しい感じだし、FIRとか通すなら浮動小数点演算ができるF4のほうが良いはず。あとF4のほうが時間分解能が高い。
　おそらくF4のDACで正弦波を出して、ということはやらなくて良いはず。矩形波でもある程度ちゃんと動くのはF1で確認済み。もっとも、全く悪影響が出ていないとは言い切れない感じなのだけど。

***

　Windows10のWindows Subsystem for Linux(WSL)が開発者モードでなくても使えるようになる、らしい。STM32の開発環境をWinに構築するのは、おそらくWSLを使うのが一番楽だと思うので、これは良いな。WSLならaptでARM GCCを入れられるし、Unixライクコマンドも当然のように使えるし、仮想マシンと違ってWin10で管理するファイルもLinuxから使用できる。
　クリーンなWin10でSTBee F4miniのLチカやUART通信ができるようになるくらいの薄い本があればSTM32ユーザーが増えるかな? どうだろうか。やる気がある人は勝手にやるだろうし、やる気がない人はそもそも電子工作をやらないだろうし、嫌々やってる人はArduinoやmbedやRasPiを使うだろうし。STM32じゃなきゃダメ！といったウリはあんまり無いからねぇ。
　Arduino比ではかなり高速、mbed比ではGPIOが多い、RasPi比では気軽に電源ブッチできる、あたりかな。あとArduinoやmbedやRasPiに比べて安価、といったところか。ただし手間がかかる。ArduinoやmbedやRasPiは手間をお金で解決する感じのスタイル。
　F4miniでNETMFが動けばArduino・mbedキラーになりそうな感じだけど、NETMFはやる気ないみたいだし。Win10IoTはさすがにワンチップで走る規模ではないだろうし、細かいところにチップ1個入れてネットに流すという用途なら、NETMFをしっかり育てていったほうが良いと思うんだけど。