Arm Mbed OSを専用コントローラーに移植する

Arm Mbed OSは、モノのインターネット（IoT）用のデバイスの開発を促進する人気のあるオープンソースプロジェクトです。 独自の一意のプロセッサデバイスを作成した場合、最初のタスクはそれに何らかのオペレーティングシステム（OS）を移植することです。



NXP Kinetisファミリのマイクロコントローラを搭載したボードでArm Mbed OSを起動する方法を順を追って説明します。

Arm Mbed OSプロジェクト

ARMのプロパティであり、ARMアーキテクチャ専用です。 一般的な信念に反して、 Mbedは完全にC ++で書かれているわけではなく、 Cortex-M専用に調整されておらず、それほど新しくもありません。 その起源は、 KeilがI8051のリアルタイムオペレーティングシステム（RTOS）であるRTXを作成した90年代に遡ります。 その後、 RTXはKeilによってARM7およびARM9に転送され、Cortexが登場しました。



ARMはKeilを買収し、RTOSはCMSIS-RTOSと名付けられました 。 まだ完全にCで書かれていました。 最後に、 IoTとArduino ブームの到来により、 Mbedが登場しました。 Arduinoの動きは、 C ++シェルと、数十本のピン、UART、LEDの使い慣れたセットで簡素化されたAPIに影響を与えました。一方、IoTは、プロジェクトをTCP / IP、Bluetooth Low Energy、6LoWPAN、Thread ... OS



Keilブランドは引き続き存在し、Keil開発キットの配布では、Mbedが提供するよりも幅広いマイクロコントローラファミリへのミドルウェアと移植例を豊富に取り揃えたCMSIS-RTOSを見つけることができます。 ただし、これは非公開の商業プロジェクトです。

専門委員会

ここでの移植は一例であり、そのスキームはそれほど重要ではありません。 さらに重要なのは、インストールされているマイクロコントローラーです。 これは、 NXPのMKE18F512VLL16 Kinetisファミリです。 主なパラメーター：

カーネル-ARM Cortex-M4F 32ビット

最大コア周波数-168MHz

フラッシュ512KB（512K x 8）

RAM 64 KB

100-LQFP（14x14）

マイクロコントローラーの内容

このマイクロコントローラーは、サポートされているARM Mbed OSのリストに含まれていません。 それは比較的新しいという事実によって説明することができます。



マイクロコントローラーは、かなり手頃な価格と高いコア周波数で優れた周辺機器を備えているため、興味深いものです。 FlexIOモジュールを使用すると、従来のマイクロコントローラーでは利用できない非標準インターフェースを作成できます。

ステップ1. NXPツールをダウンロードする

• MKE18F512xxx16ファミリ向けにMCUXpressoソフトウェア開発キット（SDK）のバージョンをwww.nxp.comでオンラインで構成します。
• Toolchain / IDEを指定する必要がある場合は、 IAR IDEを選択します。 IAR IDEではさらなる作業が検討されます。
• 使用可能なすべてのソフトウェアコンポーネントを選択します。
• 結果のMCUXpresso構成ツール、Windows 64ビットパッケージをサイトからダウンロードします。
  
  
  
  これは、次のコンテンツを含む30メガバイトのアーカイブMKE18F512xxx16.zipです。
  
  
  
  
• -MCUXpresso Config Tools v4.1 for Windowsもダウンロードしてください。 それを使用して、マイクロコントローラーのクロックサブシステムを構成します。

ステップ2. RTOSなしでアプリケーションプロジェクトを取得する

• MCUXpresso Config Tools v4.1 for Windowsを起動します
  
  
  
  
• テンプレートとして、最も単純なデモプロジェクトの1つであるled_blinkyを選択します。
  
  
  
  
• クロッキングスキームを設定し、クロック初期化ソースを生成するコマンドを提供します。 初期化ソースは、プロジェクトディレクトリで直接更新されます。
  
  
  
  
• IDE IARの下のソースを使用して、受け取ったプロジェクトをディレクトリにコピーします。 プロジェクトで、 SWDインターフェイスを介してJ-Linkデバッガー、デバッグチャネルを選択します。 LEDポートへの書き込みコマンドを変更し、ボード上でコンパイルして入力します。
  
  

ステップ3. Mbedプロジェクトを構成および変換する

• プラットフォームセクションのos.mbed.com/platformsにあるMbedプロジェクトのWebサイトにアクセスします。
  
  
  
  そこで、選択したものと可能な限り類似したマイクロコントローラを備えたボードを探しています。
• FRDM-K66Fボード-os.mbed.com/platforms/FRDM-K66Fを選択します。 選択は偶然ではなく、そのようなマイクロコントローラーでは実務経験があります。
• ボードのプレゼンテーションページで、デモを選択します-mbed-os-example-blinky-os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-blinky/?platform=FRDM-K66F
  
  
  
  これは最も単純な例であり、別のボードに適合させるのが最も簡単です。
• 登録して、コンパイラのオンラインセクション（ os.mbed.com/compiler）にアクセスします。
• まず、プラットフォーム-FRDM-K66Fを選択してから、us- mbed-os-example-blinkyが選択したデモをインポートします。 プログラムパネルでは、このデモはmbed_blinkyと呼ばれます 。
  
  
  
  
• この例をコンパイルして検証し、エクスポートします。

IDE IAR向けの形式でエクスポートします







これで、 IARの Mbed開発プロジェクトのソースコードができました。 ただし、結果のプロジェクトは作業に不便です。



プロジェクト内のすべてのファイルが1つのグループに収集され、混合されました。 どのファイルがどの機能パッケージに属しているかを検索して識別することは不可能です。 このプロジェクトには、 Mbedプロジェクトのほぼすべてのミドルウェアのソースが含まれますが 、それらのほとんどは現在必要ありません。

ステップ4. IARプロジェクトを標準形式に変換する

-Pythonで特別に作成されたユーティリティを使用して、いくつかの変換操作を実行します。



まず、デモプロジェクトのディレクトリから、プロジェクトに分類されなかったすべてのソースを削除します。 ソースリストは、ファイルmbed-os-example-blinky.ewpから取得されます。 このユーティリティはClear_from_unused_files_and_dirs.pyと呼ばれます 。 また、ファイルを削除した後に作成された空のディレクトリも削除します。



次に、 Convert_ewp_file.pyユーティリティを使用して、プロジェクトファイルmbed-os-example-blinky.ewpを再構成し、その中のグループがプロジェクトディレクトリに対応するようにします。 パッケージを削除または追加できる、より理解しやすい構造のプロジェクトを取得します。 ここで、プロジェクトの名前を変更できます。 これを行うには、タグを編集します

<configuration> <name>mbed-os-example-blinky</name>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

mbed-os-example-blinky.ewpファイル内 。 ファイルmbed-os-example-blinky.ewp （この場合はTest_proj.ewp ）の名前を変更し、タグを修正します

 <path>$WS_DIR$/mbed-os-example-blinky.ewp</path>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルmbed-os-example-blinky.eww （この場合、 Test_proj.ewp ）でファイルmbed-os-example-blinky.ewwの名前を選択したもの（この場合Test_proj.eww ）に変更します







その結果、このようなプロジェクト構造を持っています











-ソースコードを調べて、マイクロコントローラーの機能に依存するソースコードを特定します。 このため、SlickEditやEclipseなどのより専門的なエディターを使用する方が便利です。 エディターは、 IDE設定で宣言されたマクロについても通知する必要があります。 これを行うには、追加のヘッダーファイルExtra_options.hを作成し、 IDE IARからExtra Optionsの内容をコピーします。

ステップ5. Mbedプロジェクトの編集

プロジェクトを編集する準備ができました。 Extra_options.hファイル内のマクロを分析することから始めましょう。 対応する機能を備えたエディターでこれを行い、IAR環境で行うことができます。



-未使用のマクロを削除して、さらなる分析中に注意をそらさないようにします。 残りをソートします。 マクロの約半分は未使用であることが判明しました。



-[ 追加オプション]に新しいマクロTARGET_MKE18Fが導入されました。 mbed_rtx.hファイルでスタックの開始アドレスを定義します。 スタックはアドレスを減らす方向に成長しています。 Mbedでは、使用可能なRAMの上限からスタックを開始するのが一般的です。 MKE18Fの場合、この境界線を0x20008000ULに設定します



-ディレクトリTARGET_K66Fを見つけます。 マイクロコントローラーのタイプに依存するファイルがそこに保存されます。 それらの非常に多く-136ファイルがあります。 TARGET_K66Fディレクトリの横に、 TARGET_MKE18Fという名前の独自のディレクトリを作成します。



-デモプロジェクトSDK led_blinky \ CMSISのディレクトリから、 次のファイルをMbedディレクトリにコピーします -os \ targets \ TARGET_Freescale \ TARGET_MCUXpresso_MCUS \ TARGET_MKE18F \ device ：

•fsl_device_registers.h。 （追加オプションのマクロCPU_MK66FN2M0VMD18はCPU_MKE18F512VLL16に置き換えられます）

•MKE18F16.h

•MKE18F16_features.h

•system_MKE18F16.h

•system_MKE18F16.c

-ファイルを削除する

•MK66F18.h

•MK66F18_features.h

•system_MK66F18.c

•system_MK66F18.h

-TOOLCHAIN_IARディレクトリで 、内容をstartup_MKE18F16.sおよびMKE18F512xxx16_flash.icfファイルに置き換えます 。

-IDE IARプロジェクトで、リンカにも、新しいファイルMKE18F512xxx16_flash.icfへのパスを指定します

-ディレクトリMbed-os \ターゲット\ TARGET_Freescale \ TARGET_MCUXpresso_MCUS \ TARGET_MKE18F \ドライバーの内容は消去され、MKE18F512xxx16ファミリのSDKにあるデバイス\ MKE18F16 \ドライバーディレクトリのファイルでいっぱいになります。

-ファイル\ mbed-os \ targets \ TARGET_Freescale \ TARGET_MCUXpresso_MCUS \ fsl_common.cを、 MKE18F512xxx16ファミリのSDKにあるdevices \ MKE18F16 \ driversディレクトリにある同様のファイルに置き換えます。 ディレクトリMbed-os \ targets \ TARGET_Freescale \ TARGET_MCUXpresso_MCUS \ TARGET_MKE18F \ driversで同じファイルを削除します。

-ディレクトリmbed-os \ targets \ TARGET_Freescale \ TARGET_MCUXpresso_MCUS \ TARGET_MKE18F \ driversから 、FreeRTOSが存在する名前のファイルを削除します。

-新しいマイクロコントローラにはEMACがないため、 \ mbed-os \ features \ netsocket \ emac-driversディレクトリから、K66マイクロコントローラのEMAC周辺機器に関連するすべてのファイルを削除します。

-再びConvert_ewp_file.pyユーティリティを使用します

-コンパイルして267エラーを取得します。 これらはすべてTARGET_MCUXpresso_MCUSディレクトリにあるファイルにあり、ほとんどのファイルには名前にapiサフィックスが付いています。 各ファイルは個別に処理する必要があります。 合計12個のファイルにエラーが表示されます。

ステップ6. Mbedファイルの編集

fsl_clock_config.cファイル

これは、この段階で最も重要なファイルです。 チップのすべてのサブシステムのクロッキングを初期化します。 RTOS初期化関数mbed_sdk_initは、このファイルからBOARD_BootClockRUN関数を呼び出します。 fsl_clock_config.cファイルを led_blinkyプロジェクトの検証済みファイルに置き換えます。 そこではclock_config.cと呼ばれ（ fsl_clock_config.hにコピーした後に名前を変更し、必要に応じて#includeを修正します）、最大周波数168 MHzでチップを起動したいので、RTOSファイルのBOARD_BootClockRUN関数の呼び出しをBOARD_BootClockHSRUNに置き換えます 。



-残りのファイルを考慮します。 すぐにその必要性について疑問を提起します。 実際、それらの多くは、単純化されたインターフェースを備えた周辺機能の単純なラッパーです。 最も可能性が高いのは、Arduinoに基づくAPIシステムの類似性が重要である初心者プログラマーを対象としています。 これらのファイルはペイロードを運ばないものとして無視することができますが、このため、Mbedコミュニティには受け入れられません。



削除するファイル：

API

•analogin_api.c

•analogout_api.c

•dma_api.c

•i2c_api.c

•pwmout_api.c

•spi_api.c

•dma_api_hal.h



ドライバー

•AnalogIn.cpp

•I2C.cpp

•I2CSlave.cpp

•SPI.cpp

•SPISlave.cpp

•AnalogIn.h

•AnalogOut.h

•I2C.h

•I2CSlave.h

•PwmOut.h

•SPI.h

•SPISlave.h



ハル

•analogin_api.h

•analogout_api.h

•i2c_api.h

•pwmout_api.h

•spi_api.h

• mbed.hファイルを編集して、削除したファイルの接続をコメント化します。 object.hも編集します 。
• システムがクラッシュしたときに呼び出されるmbed_die関数を編集しましょう 。 デフォルトでは、LEDが点滅します。 点滅を削除します。このようなLEDはありません。
• このファイルの前に削除されたAPIに関連付けられたピンと構造の宣言から、PinNames.hおよびPeripheralNames.hファイルをクリアします
• PeripheralPins.cファイル内の不要な配列を削除した後、その中のUARTのピンマップを編集するためだけに残ります。
• ディレクトリの構造とターゲットのサブディレクトリ内のファイルの場所をわずかに変更して、ファイルの命名と断片化のランダム性を減らします。

修正が必要な残りのファイルのリスト：

•serial_api.c

•trng_api.c

•flash_api.c

•sleep.c

•us_ticker.c

重要なRTOSサービスはファイルに依存しているため、これらのファイルを単純に削除することはできません。 問題は、主に、 MKE18F512xxx16ファミリがMK66FN2M0VMD18とは異なる周辺名を使用していることですが、メインAPIの周辺は実質的に変更されていません。

ファイルserial_api.c

基本的に、K66チップから継承された関数と列挙の名前を変更します。 このファイルは、UARTを介してRTOS出力をデバッグするための低レベル関数を定義します。

Us_ticker.cファイル

RTOSのティックで正確な時間を取得するメカニズムを決定するという点で重要です（この例では、ティック値は1μsです）。 このAPIは、RTOS遅延関数と、タイムラインで指定されたアクティベーション時間を持つイベントキューサービスで使用されます。 連続時間カウンターを編成するには、PITモジュールの関連チャンネル0および1が使用されます。 チャネル0の周期は1μsで、チャネル1は429秒後にサイクルを終了します（0xFFFFFFFFがロードされ、チャネルカウンタがデクリメントされます）。 イベントキューを整理するには、PITモジュールのチャネル2と3を使用し、チャネル3からの割り込みを使用します。したがって、MbedはPITモジュール全体を占有し、他には使用できないことがわかります。

Trng_api.cファイル

ハードウェア乱数生成を実装します。 MKE18F512xxx16チップにはそのようなジェネレーターがないため、標準C関数randからスタブを配置します。 SSLおよびTLSデータ暗号化プロトコルには、適切な乱数ジェネレーターが必要です。 これまでのところ、ボード上でそのようなものを使用する予定はありません。

Sleep.cファイル

スリープモードの開始と終了の機能を実装します。 この場合、フラッシュメモリを操作するためのアクセラレータの動作が影響を受けます。 フラッシュメモリキャッシュを有効または無効にする関数の名前を調整する必要があります。

Flash_api.cファイル

内部フラッシュメモリをプログラミングするための関数を実装します。 ここで、 MKE18F512xxx16ファミリのチップには、フラッシュメモリの2つのセクションが存在する可能性があるという事実に出会いました。 セクション0で選択された作品。



-ファイルsystem_MKE18F16.hのチップの内部周波数の値を使用してマクロを修正します。

リンカーファイルMKE18F512xxx16_flash.icf。

__VECTOR_RAM文字の宣言が必要です。 これは、RAM内の割り込みベクターのテーブルが配置されるアドレスです。 Mbed OSでは、動作中にシステムによってプログラムによって変更できるため、割り込みベクターテーブルは常にフラッシュからRAMにコピーされます。

好奇心

彼らは、ベクトルSVC_Handlerにスタブがあり、それ自体に固定されているという事実に遭遇しました。 そして、 Mbed OSの初期化はこの特定のベクトルを呼び出します。 どこかで正しいベクターのインストールの瞬間を逃しています。 大文字の拡張子を持つアセンブラファイルをIARに接続するのを忘れていたことがわかりました。 そして、コンテキストスイッチで最も重要なファイルはirq_cm4f.Sです。 Pythonに感謝します。 Convert_ewp_file.pyユーティリティを修正して、再度実行します。 プロジェクトを再コンパイルします。

死んだチップを復活させる方法

GPIOポートを初期化するとき、誤ってデバッガーとクォーツのI / Oラインを誤って初期化する可能性があります。 この場合、チップはデバッグを停止し、J-Link SWDアダプターでのプログラミングも停止します。 この場合、問題は簡単に解決できます。 外部クォーツの1つの出力をグランドに短絡し、電力を除去してから再度印加します。 私たちのプログラムは、クォーツの包含を待って立ち往生するため、GPIOの誤った初期化に到達しません。 この時点で、SWDアダプターのプログラミングが再び使用可能になります。

不正確な待機時間遅延機能の待機の問題

LEDの点滅周期を測定することにより、 待機機能の実行のスローダウンが、予想よりも2回長く検出されました。 内部周波数設定の正確さを確認するために、出力を8で割った内部PLLブロックの外部出力に初期化します。21MHzの周波数を確認します。 すべて正しいです。



RTX_Config.hファイルでパラメーターが設定されているRTX ティック周波数を初期化するとき、 SystemCoreClock変数が使用され、システム初期化中にBOARD_BootClockHSRUN関数で割り当てられ、 168000000に等しくなります。ここでも、すべてが正しいです。



IARデバッガーのTimeLineウィンドウで確認すると、システムティックの中断の頻度は1 KHzで、これも正しいです。



PITモジュールが誤って初期化されたことが判明しました。 彼は、 RTXがスリープモードに入ったときにカウントを停止しました。 また、アクティブなタスクがない場合、 RTXはティックごとにこのモードに切り替わります。 したがって、タイマーは停止しましたが、最も正確な遅延を確保するために、その値が待機機能で使用されました。 しかし、K66の公式Mbedポートからこのエラーを継承しました！



3日目に、 ARM Mbed OSの移植が正常に完了し、LEDが点滅します。

github.com/Indemsys/Mbed_led_blinky_MKE18F