mbed

Nucleo（F411RE）のSPIクロックが想定通りにならなかった。2MHzで1.5MHzs、1.5MHzで750KHz・・・。半分というとそうでもない。。。

コミュニティーで答えをもらったのだが、結論としては、データシートをよく読みなさいということだと思われます。mbedで遊んでいると、ターゲットを変えるだけで普通に動いてhしまうため、そこがどうしても、気づかなくなってしまう。それに、KL25の時はあまり気にせずほとんどがその通りに動いていた。（実際、今回の件もあり確認したが細かく設定できる）

printf(“SystemClock=%d[Hz]\r\n”, SystemCoreClock);

クロック出力できるとのことでｍNucleo-F411では内蔵発振、外部水晶時ともに、96MHzと出力される。

Nuleo-F411では、SPIクロックソースは内部クロックの分周を利用するがその設定が3ビットしかないとのことである。データシート

Nucleoの水晶振動子

Nucleo基板（F411RE）には、水晶振動子が二つあり、そのうち32.768KHz（X2）は実装されている。mbedのTickerで時間を刻むと、少し短めになった。1msに対して985usあたり、1~2%の誤差であり、これはセンシング精度としては大きい。会社業務で使用していたため、問題があった。回路図を見ると、X3は8MHzであるが実装されてない。NucleoのDocumenntには、実装すれば自動で切り替わると書いてある。Target基板を作った際、実装できるようにしてあったので、X3を実装したもののTickerの時間精度が上がらず（変わらず）外部クロックが機能していないようだった。

オシロスコープで発振子の振動波形を見たところ、まったく振動していない。しかも、X2もまったく振動していなかった。mbedの中で外部クロックが有効とされずに内部クロックで動いているように思えた。

target.json　の中の"STM32F4"に、"clock-source"の記述でHSIを使うようになっていたので、記述をまねして、下記のようにプロジェクトの中のmbed_app.jsonに記述する。

mbed-os5のUSBSerialはボーレート設定も要らず、パソコン側のOS標準ドライバで動作するようでTargetマイコンを変えても常にポート番号が同じで使いやすい。しかしprintfが遅い

mbed-os5のAPIにあるUSBSerialでprintfを使うと1バイトごとパケットに乗せられる。1ms間隔でデータを送信したかったが、間隔が1msではなかったという結果があり、気づいた。下記コードで確認してみた。USBデコードできるオシロで確認すると1byte=1packetで送信されていた。

os2からos5へ変更する際に、どうもTickerがうまく動かなかった。

Ticker tbase;
DigitalOut led(LED1);

volatile int tb_reach=0;
void tbase_t(void){
    tb_reach=0;
}
int main(){
    tbase.attach( callback(tbase_t) , 0.5 ) ;
    while (true) {
        led = !led;
//        thread_sleep_for(500);
        while( tb_reach );
        tb_reach = 1;
    }
}

mbed-os5-example-blinkyのthread_sleep_for()をTickerに変えるだけだから、動いて当然、と思ってたのに　while( tb_reach );　のところからぬけてくれないみたいな動きになった。