最小のARM：何時ですか？

今日は、CMSISでより効率的なコードを記述する方法と、プロセッサ速度を正しく計算する方法という2つの重要な質問に対処します。 2番目のパートから始めて、LPC1114で発生するプロセスを調べて、クロック周波数を生成します。


クロック周波数はプロセッサの「労働」の主な原因であり、その発生器は人の心と比較できます。 プロセッサの異なるコンポーネントは異なる周波数を使用できますが、通常は同じ水晶（または共振器）から発生します。

ほとんどのプロセッサには、共振器が内蔵されており、外部共振器または水晶を接続できます。 なぜこれが行われるのですか？ 基本的に、プロセッサのコストを削減します。 通常、内蔵の共振器には約1％の誤差があり、これは多くのタスクには十分かもしれませんが、そのような精度が許容できないほど多くのタスクがあります。 実際、たとえば、内蔵の共振器で時間をかけると、1日あたりのエラーは14分に達する可能性があります。 ネットワーク上で約30分に1回パケットを送信する場合-これは重大なエラーではありません。 アラームを作成する場合の別のこと。


（ LPC111xユーザーマニュアルからの画像）

コンポーネントに分割されたクロックジェネレーターの概要図を上に示します。 次に、それぞれを個別に扱います。

⓵メイン周波数

MAINCLKSELは、基本周波数を設定します。これは、他のほとんどの人が依存します。 いくつかのソースの1つに基づくことができます。

まず、IRC-内部共振器です。 動作周波数は12 MHzです（実際、小さな制限内で調整できます）。誤差は約1％です。 ここから、起動時にプロセッサクロック周波数が生成されるため、すべてのブートコードは12 MHzのクロック周波数で実行されます。 このオプションは可能な限りシンプルであり（機能させるために何もする必要はありません）、追加の外部コンポーネントは必要ありません。 残念ながら、それには独自の問題があります。私が述べたように、共振器はやや不正確です。さらに、50 MHzで完全に動作するとき、12 MHzでコアを駆動することに特に興味はありません。

第二に、メイン周波数はもう1つの内部ジェネレーターで設定できます。これは通常、ウォッチドッグ動作に使用されるウォッチドッグ発振器です。 この発振器は、9.4 kHz〜2.3 MHzの速度（±40％の精度）で動作します-これは、メイン周波数の最適なソリューションではないようです。 一方、これは、周辺機器の一部を動作させたまま、カーネルをスリープモードにする必要がある場合に、まさに素晴らしい、エネルギー効率の高いソリューションです。

第三に、 PLLの前または後にシステム発振器から基本周波数を取得できます。 これはかなり膨大なトピックであるため、PLLの詳細については掘り下げません。 興味のある方は、セクション「3.11システムPLL機能の説明」をご覧になることをお勧めします。

⓶システム発振器

システムオシレーターは、ハードウェアの変更なしでは動作しないプロセッサーの一部であり、オシレーターの主な機能を欠いています-水晶（または水晶振動子）は外部に接続する必要があり、最新のプロセッサーにはXTALIN / XTALOUTピンがあります。

具体的には、LPC1114（ただし、LPC111xラインの他のプロセッサと同様）は、1 MHz〜25 MHzの発振周波数の水晶をサポートしています。 水晶自体に加えて、2つのコンデンサも必要になります。コンデンサの値は、選択した水晶のパラメータによって異なります。 ここで、 データシートを参照します。セクション12.3（XTAL入力）には、接続図と推奨コンデンサ容量の表があります。 テスト回路では、周波数12 MHz、負荷容量20 pF、2つのコンデンサ39 pFの水晶を使用しようとしましたが、この動作モードはこれ以上考慮されません。

信頼できる外部クロックソースがある場合は、システムオシレーターをスキップして、XTALINピンからクロック周波数を取得できます。

システム発振器は、基本周波数発生器として直接使用することも、以前にPLLを介して渡すこともできます。

⓷PLL

電気機械学に入ることなく、PLLは入力クロック周波数を最初に乗算してから分周するデバイスです。 入力では、PLLはIRCまたはシステムオシレーターから周波数を受信でき、出力は基本周波数に使用されます。

PLLパラメーターの設定は、プロセッサー内部にとって潜在的に危険です。したがって、 NXPユーティリティ （Googleドライブで正常に変換して動作します）を使用して必要なパラメーターを選択し、入力発振器周波数と受信したい最終周波数を設定するだけで、可能なオプションを計算することをお勧めします。

ネットワークには、IRC周波数を上げてPLL出力で50 MHzを生成する方法に関する興味深いメモがありますが、この結果をデバッグするにはオシロスコープが必要です。

⓸システム周波数

通常、コア（Cortex-M0であるという事実）はメイン周波数で動作しますが、必要に応じて、メイン周波数を分割（最大255まで）できるため、システム周波数になります。 コア自体に加えて、フラッシュメモリ、RAM、およびすべての周辺機器は、SPIおよびUARTを除き、この周波数で動作します。 ここでの最大周波数は50 MHzです。

SPI SPIとUARTはどうですか？

これらのインターフェイスの特性により、たとえばUARTに専用の分周器があり、目的のビットレートを選択できます。

回路のいくつかの非自明性にもかかわらず、メインではなく、システム周波数が分周器の入力に到達します。

ビットレートの除数を計算するのはかなり難しい作業なので、もう一度「13.5.15 UART分数分周レジスタ（U0FDR-0x4000 8028）」という指示に送ります。 計算式、追加の分数引数の説明、および特定のビットレートに必要なパラメーターを見つけるためのブロック図といくつかの例があります。

SPIでは、すべてがやや単純になります。おそらく、バス上のマスターが周波数を設定し、残りのデバイスがその周波数で動作するためです。壁外の同期は不要です。 したがって、できることは除数を設定することだけです。 重要なポイント-プロセッサがマスターモードの場合、最小分周器は2、つまり48 MHzのシステム周波数では、SPIでのデータ転送速度は24 MHzになります。

UPD ： valeriykが正しく指摘したように、この分周器だけが出力周波数に影響を与えるものではありません。 たとえば、SPIの場合、キャリア周波数は次の式で計算されます： PCLK / (CPSDVSR * (SCR + 1)) 、ここでPCLKは周辺周波数です。 CPSDVSR-「プリスプリッター」。 SCR-出力ビットごとのプリローダーサイクルの数。

life命を守る番犬

ウォッチドッグは、その特異性により、孤立したコンポーネントです。 したがって、主要な周波数として、システム、IRC、または別のオシレーターを使用できます。 同様に、ウォッチドッグには専用の除数があります。

ウォッチドッグに別のクロックが必要なのはなぜですか？ もちろん、プログラムが誤ってメインジェネレータを壊してしまった場合は、もちろんです！ その後、彼女はウォッチドッグタイマーによってリセットされる可能性があります。

exit終了するには

最後に、プロセッサはCLKOUTピン（GPIO 0.1の代替機能の1つ）でクロック出力信号を生成できます。 主要な周波数として、発振器（IRC、システムまたはウォッチドッグ）またはシステム周波数（オンになっている場合はPLLの後）から利用可能な任意のものを使用できます。 さて、もちろん、あなたの除数。

mbedについて

LPC1114のクロック生成プロセスを詳細に検討しましたが、LPC1768はどうですか？ 実際、各プロセッサラインには独自の特別なアプローチがある可能性があります（したがって、独自の特別なアプローチがある可能性が高いため、このトピックの手順は非常に慎重に検討する必要があります。LPC1768には内部オシレータIRCもありますが、 （メイン）システムオシレータと同じオシレータmbedでは、12 MHzの水晶が接続されています最後に、リアルタイムクロック（RTC）発振器がありますが、水晶は接続されていません。

また、メインPLLに加えて、USBの動作周波数を生成するために使用される追加のPLLがあります。 すべての周辺コンポーネントには、動作周波数に対して独立して調整可能な分周器があります。

周波数変化の実用的なニュアンス

動作クロック周波数を変更すると、いくつかの結果が生じます。 最も明らかなのは、タイマーを再調整する必要があることです。 また、キャリア周波数（UART、USB）を修正することが重要な場合、プロトコルで動作する周辺機器の再初期化が必要です。 最後に、フラッシュメモリにアクセスするための手段の数も重要な役割を果たします。 LPC1114のデフォルト値は3クロックサイクル（50 MHzまでの動作周波数、FLASHCFGレジスタのドキュメントを参照）であり、これはタスクに十分です。 ただし、LPC1768のデフォルト値は4サイクルで、動作周波数は最大80 MHzであり、これでは十分ではありません。

ただし、より高い周波数での動作が有益である可能性があります。 組み込みプロセッサはほとんどの時間をスリープモードで使用するため、ウェイクサイクルの処理が高速になるほど、最終的に消費するエネルギーが少なくなります。

働くために！

これで必要な理論上の荷物ができたので、知識を実践に移す準備ができました。LEDを1秒に1回、確定的に点滅させます。

前に見たように、多くのタスクは同じ方法で実行されます-レジスタの書き込みと読み取り（一般に、 すべてのタスクはそのように実行されます）。 ARMは、このCMSISが存在するため、特定のプロセッサに関連付けられていないタスクを同じCコードで実行できることを確認しました。これは、プロセッサコアのドライバのセットです。 ベンダーは通常、残りの周辺機器用のドライバーで拡張します。

CMSISの難しい部分は、現在のバージョンがどこにあるかが完全に明確でない場合があることです。 ファイルの基本セットは、 ARMから直接ダウンロードできます。執筆時点では、バージョン3.01が利用できます。 ヘッダーファイルに加えて、ARMはDSP上のさまざまな複雑な計算用のライブラリを提供します（ハードウェアにはまだありません）。 特定のメーカーのドライバーでは状況がさらに悪化します。 たとえば、NXPの場合、LPC1114のCMSISはCMSIS 1.30に基づいており、LPC1768の場合は2.10に基づいています。 さらに、一連の周辺ドライバーのコードには明らかなエラーがあります。 また、TIチップのドライバーはGoogleで徹底的に検索する必要があります。

これから2つの重要な結論を導き出すことができます。第一に、ドライバーコードはほぼ完全にオープンであるため、「信頼するが検証する」という指示とデータシートは、周辺機器の操作に関する主要な文献です。 第二に、ドライバーには自分で書くことができなかったものはほとんどありません。つまり、これは優れた、そして多くの場合、実用的な参考資料です。 何かが奇妙に見える場合、主なことはそれを批判的に取るのを忘れないことです-プロセッサのマニュアルを吸ってください。

これで、ソースコードの構造が若干向上しました。 その結果、ファイル数が大幅に増加しましたが、いくつかの異なるプラットフォームをサポートするのがはるかに簡単になりました。 今日の例のソースは、GitHubで入手できます： farcaller / arm-demos （新しいアーキテクチャのプルリクエストは大歓迎です！）

ソースツリーはまだ完全にboot.sいません。特に、プリミティブboot.sとmemmap.ldしませんmemmap.ld 。 次の部分は、リンカの問題（ガベージコレクションと.dataおよび.bssの適切な初期化を含む）に完全に専念し、すべての論争のある問題の完了を扱います。 すべてのコードは3つのカテゴリに分けられます： app/は「アプリケーション」のファイルです-直接動作するサンプルコード。 setup()およびloop()関数により、arduinoスタイルでスタイルが設定されます。 Platform platform/は、さまざまなプラットフォームとプラットフォームに依存する機能の説明が含まれます（ファイルがすべてのプラットフォームにリンクされているplatform/commonを除く）。 最後に、 cpu/は特定のプロセッサー用のCMSISです。

このコンバイン全体が少し面白いRakefileになります。 たぶん、makeでうまくいくかもしれませんが、すべてを1つのファイルにきちんとまとめたいと思ったので、例をビルドするにはバージョン1.9より古いものをこする必要はありません。

時計仕掛け

タスクを実行するには（思い出させてください、LEDを1秒に1回正確に点滅させる必要があります）、何らかのタイマーが必要になります。 幸いなことに、LPCベースのプロセッサにはいくつかのタイマーが一度にあります。最も統一されたSysTickを使用します。 このタイマーはCMSISに直接記述されています。つまり、他のプロセッサーにある可能性が高いです。 OSでタスクを切り替えるときに時間の量を測定するために使用することになっていますが、単純なタスクに使用することを妨げるものはありません。

SysTickは、指定された値からゼロまでカウントする単純なタイマーで、オーバーフロービットを設定し、割り込みをプルして、再びカウントを開始します。

platform/common/systick.c ：

 void platform_systick_setup(unsigned int load) { SysTick->CTRL = 0x04; SysTick->LOAD = load < 0xffffff ? load : 0xffffff; SysTick->VAL = 0; SysTick->CTRL = 0x05; } 

構文から始めましょう。 これらのすばらしい構造はCMSISから入手でき、レジスタの場所を覚える必要がなくなり、フィールドへのアクセスがより明確に実現されます。

タイマーを初期化するには、制御レジスタに4を書き込みます。 これにより、タイマーがオフになり、オンになっている場合、割り込みがオフになり、SysTickがプロセッサー周波数の使用に切り替わります（デフォルトは12 MHzであることを思い出してください）。 次に、SYST_RVRレジスタに開始基準点をロードし、最大値を16777215に制限し、レジスタの現在の値をゼロにリセットして、タイマーを開始します。

次に、1秒間待機する方法について説明します。

 void platform_systick_wait() { volatile int i; i = SysTick->CTRL; while((i & 0x00010000) == 0) { i = SysTick->CTRL; } } 

SYST_CSRレジスタからCOUNTFLAGの値を読み取ります。 COUNTFLAGは、カウンターが新しい円に移動すると1に設定され、読み取り時にゼロにリセットされます。 したがって、カウンターがオーバーフローするまでサイクルになります。

プロジェクトの他のファイルを見てみましょう。 app/systick-blink.c ：

 #include "platform.h" void setup() { platform_led_setup(); #if PLATFORM == MBED platform_systick_setup(4000000); #elif PLATFORM == PROTOBOARD platform_systick_setup(12000000); #else #error Unknown platform #endif } void loop() { platform_led_toggle(1); platform_systick_wait(); platform_led_toggle(0); platform_systick_wait(); } 

ここではすべてが明確です。 LEDとタイマーの「ドライバー」を初期化し、サイクルで遅延を伴ってLEDをオン/オフします。 プラットフォームに応じて、異なる開始タイマー値を使用します（mbedのIRCとプロトタイプボードは異なる周波数で動作します）。 しかし、LED自体のコードはどのように機能しますか？

platform/protoboard/led.c ：

 #include "LPC11xx.h" #define LED_PIN (1<<9) void platform_led_setup() { LPC_GPIO1->DIR |= LED_PIN; } void platform_led_toggle(int on) { LPC_GPIO1->MASKED_ACCESS[LED_PIN] = on ? LED_PIN : 0; } 

ご覧のとおり、CMSISを使用すると、すべてが本当に読みやすくなりました。 唯一の興味深い点は、一般的なGPIOレジスタの代わりに、マスク付きのレジスタを使用していることです。 マスクを使用して特定のピンのGPIOビットを設定できます。つまり、隣接するピンの状態を保存する必要があるとは思わずに、目的の値を書き込むことができます。 これについての詳細（および写真）については、「12.4.1データの書き込み/読み取り操作」を参照してください。

比較のために、mbedのコードを以下に示します。 platform/mbed/led.c ：

 #include "LPC17xx.h" #define LED_PIN (1<<18) #define LED_PIN_IN_B2 (1<<2) void platform_led_setup() { LPC_GPIO1->FIODIR |= LED_PIN; } void platform_led_toggle(int on) { LPC_GPIO1->FIOMASK2 |= ~LED_PIN_IN_B2; if (on) { LPC_GPIO1->FIOSET2 = LED_PIN_IN_B2; } else { LPC_GPIO1->FIOCLR2 = LED_PIN_IN_B2; } } 

ご覧のとおり、非常によく似ています。 LPC1768には、ポインタのアドレスにマスクを直接設定する機能はありませんが、レジスタへのバイト単位のアクセスがあり、アセンブラのリストが少し効率的になります。

rake build_protoboardまたはrake build_mbedを使用しrake build_protoboardプロジェクトをrake build_protoboardできます。 デバイスをすぐにフラッシュすることもできrake upload_protoboard TTY=/dev/ftdi/tty/deviceまたはrake upload_mbed MOUNT=/Volumes/MBED 。 これで、両方のデバイスでLEDが同じように点滅します。

周波数を再生しましょうか？

これでタスクは解決したようです。LEDは正しい間隔で点滅しますが、背後に何かが残っています。 LPC1114の最大動作周波数は50 MHzであり、LPC1768にはさらに100 MHzの周波数があり、3分の1の力で駆動することはほとんどありません。

プラットフォームを適切に初期化するときが来ました。 platform/protoboard/init.c ：

 #define CLOCK_MODE_IRC 0 // 12 MHz #define CLOCK_MODE_IRC_WITH_PLL 1 // 48 MHz #define CLOCK_MODE_SYS_WITH_PLL 2 // 48 MHz with external 12MHz crystal #define CLOCK_MODE CLOCK_MODE_IRC 

LPC1114のソースコードには、IRCの標準12 MHz、PLLを通過したIRCの48 MHz、およびPLLを通過したシステムオシレータの48 MHzの3つのテンプレートがあります。 後者のオプションには追加のハードウェアサポートが必要ですが、これは非常に適切な使用モードであるため、検討中です。

 void platform_init() { // set up system oscillator and toggle PLL to point at it #if CLOCK_MODE == CLOCK_MODE_SYS_WITH_PLL int i; // power up system oscillator LPC_SYSCON->PDRUNCFG &= ~(1 << 5); // oscillator is not bypassed, runs at 1-20MHz range LPC_SYSCON->SYSOSCCTRL = 0; // allow circutry to settle down for (i = 0; i < 200; ++i) __NOP(); // set PLL clock source to system oscillator LPC_SYSCON->SYSPLLCLKSEL = 1; // wait for PLL clock source to be updated LPC_SYSCON->SYSPLLCLKUEN = 1; LPC_SYSCON->SYSPLLCLKUEN = 0; LPC_SYSCON->SYSPLLCLKUEN = 1; while (!(LPC_SYSCON->SYSPLLCLKUEN & 1)) ; #endif 

システムオシレーターで作業する場合は、正しく初期化され、まず最初にオンにする必要があります。 前に説明したように、すでに生成されたクロック信号がXTALIN入力に存在する場合、発振器をスキップできます。

初期初期化後、わずかな遅延が発生するはずです。 次に、PLLを（IRCの代わりに）システム発振器から動作するように転送します。これには興味深いメカニズムがあります。書き込み0、書き込み1、待機-レジスタは1を返し始めます。

 // set up PLL if it's used #if CLOCK_MODE == CLOCK_MODE_IRC_WITH_PLL || CLOCK_MODE == CLOCK_MODE_SYS_WITH_PLL // set up PLL dividers LPC_SYSCON->SYSPLLCTRL = 0x23; // M = 3, P = 12MHz // PLLout = 12MHz * (M+1) / P = 48MHz // power up PLL LPC_SYSCON->PDRUNCFG &= ~(1 << 7); // wait until PLL is locked while (!(LPC_SYSCON->SYSPLLSTAT & 1)) ; // switch main clock to be driven from PLL LPC_SYSCON->MAINCLKSEL = 3; // wait for main clock source to be updated LPC_SYSCON->MAINCLKUEN = 1; LPC_SYSCON->MAINCLKUEN = 0; LPC_SYSCON->MAINCLKUEN = 1; while (!(LPC_SYSCON->MAINCLKUEN & 1)) ; #endif 

2番目の部分はPLLを初期化し、この段階でIRCまたはシステムオシレーターから入力で信号を受け取ります。 指示の式に従って分周器を調整し、PLLをオンにして、ブロックされるまで待ちます。 ロード後の主な周波数はIRCから動作し、PLL出力から動作するように転送し、この変更が「整定」されるまで待機します。

SysTickの48 MHzでは、48000000サイクルが必要ですが、これは最大値を超えています。 1つの解決策は、 platform_systick_wait_loop関数に実装されているいくつかのタイマーサイクルを待機することplatform_systick_wait_loop （別のオプションは32ビットCT32B0タイマーを使用することです）。

繰り返しになりますが、LPC1768コードは一般的に似ています。 ここで重要な点は、PLLへの出力では、プロセッサへの入力で少なくとも275 MHzでなければならないということです-100 MHz以下です。 一般に、仕切りを慎重にチェックします。 また、デフォルト値よりも低い頻度で作業するため、フラッシュメモリへのアクセスに必要な手段の数を増やすことに注意することも重要です。

platform/mbed/init.c ：

 // if we go for clock > 80 MHz, we need to set up flash access time LPC_SC->FLASHCFG = (LPC_SC->FLASHCFG & 0xFFF) | 0x4000; // 4 cpu clocks 

この例のコードは、特定の水晶周波数に関連付けられているため、mbed上のLPC1768にのみ関連しています。 さらに、LPC1768を「直接」操作する場合、そのブートローダーはIRCをオンにして PLLをオンにして起動するため、セットアップする前にイニシャライザーでオフにする必要があります。

まとめると

また、今日はCLKOUTと、ロジックアナライザーまたはオシロスコープで周波数を制御する方法についてお話ししたかったのですが、この方法では記事が大きすぎます。 CLKOUT、32ビットタイマー、割り込み、およびスリープモード-これらはすべて将来のリリースに含まれます。

Stellaris LaunchPadが入ったボックスを入手しました。ストーリーを爆破せずに別のアーキテクチャを追加する最善の方法を考えます。いずれにせよ、LPC1114がメインのターゲットプロセッサになります。最初にすべての例を実行します。

「マルチブック」をおpoびします。それからもっと意味のある文章を書こうと思います。

PSいつものように、テキストを校正してくれたpfactumと、電気機械に関する貴重なコメントに感謝します。また、PLLについて説明します:-)。

この作品は、Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unportedの下でライセンスされています。例のプログラムテキストは、ライセンスライセンスの下で使用できます（ファイルヘッダーで明示的に指定されている場合を除く）。この作品は、教育目的のみのために書かれており、著者の現在または以前の雇用主とは一切関係ありません。