最小のARM

数日前、私はARMアーキテクチャ用にOSを作成することについて書く計画についての記事を公開し、突然ドラフトを作成しました。 これは、HabréとG +の両方で多くの興味深いレビューを受け取ったためです。



今日は、反対側からこの問題にアプローチしようとします。独自のOSを作成するまで、または退屈するまで、複雑さが増す例を使用してARMマイクロコントローラーをプログラムする方法について説明します。 あるいは、Contiki、TinyOS、ChibiOS、またはFreeRTOSでのピッキングを飛び越えて、さまざまな面白いものがたくさんあることを知っています（TinyOSには独自のプログラミング言語もあります！）。



なぜARMなのか？ 8ビットマイクロコントローラーをいじるのは、面白いとはいえ、すぐに迷惑になります。 さらに、ARMの開発ツールは、長年の経験に基づいて実行され、作業がずっと快適になります。 同時に、ある種の「評価ボード」のLEDを点滅させ始めるのは、Arduinoの場合と同じくらい簡単です。

アーキテクチャへの小さな余談

ARMはライセンスに成功した素晴らしいアーキテクチャを推進していますが、どのデバイスにこの会社の製品が存在しないかを想像するのは本当に難しいです。 スマートフォンには、ARMアーキテクチャに基づいた複数のコアがあることが保証されています。 最近のラップトップ（およびCPUでなく、一部の周辺機器の付属コントローラーでもあります）には、さらに2、3があります。 また、他の家庭用品にもあります：電子レンジとテレビ。



この柔軟性は、最も基本的なバージョンではARMコアが非常にシンプルであるという事実によって実現されています。 現在、このアーキテクチャには3つの種類があります。 アプリケーションは、「汎用」デバイスで使用されます-スマートフォンまたはネットブックのメインプロセッサとして。 このプロファイルは最も機能が豊富であり、本格的なMMU（メモリ管理モジュール）、ハードウェアでJavaバイトコード命令を実行する機能、およびDRMスキームのサポートもあります。 マイクロコントローラーは、アプリケーションプロファイルの正反対であり、（突然！）マイクロコントローラーで使用されます。 ここでは、最小消費電力と確定的な動作が関係しています。 そして最後に、 リアルタイムは、保証された応答時間を持つことが重要なタスクのマイクロコントローラープロファイルの進化として使用されます。 これらのプロファイルはすべて、1つまたは複数のCortexコアに実装されました。たとえば、Cortex-A9はアプリケーションプロファイルに基づいており、iPhone 4Sのプロセッサの一部であり、Cortex-M0はマイクロコントローラープロファイルに基づいています。

鉄片！

ターゲットプラットフォームとして、Cortex-Mを使用することを検討します。それぞれが最も単純であるため、より少ない質問を掘り下げる必要があります。 テストデバイスとして、NXP製のLPC1114 MCUを提供します。この回路は文字通り膝の上に組み立てることができます（ただし、MCU自体、3.3 V FTDIケーブル、複数のLEDおよび抵抗器のみが必要です）。 LPC1114はCortex-M0に基づいているため、これはプラットフォームの最も簡略化されたバージョンになります。







別の方法として、 mbedプラットフォーム、具体的にはLPC1768に基づくモデル（つまり、内部にもう少し洗練されたCortex-M3があること）を使用します。 このオプションはすでにそれほど予算がかかりませんが、バイナリをチップにアップロードしてデバッグするプロセスは可能な限り簡素化されています。 はい、mbedプラットフォーム自体をいじることができます（要するに、これはオンラインIDEであり、arduinoレベルでプログラミングできるライブラリです）。

さあ始めましょう

最新のARMの興味深い機能は、アセンブラの挿入を使用せずに完全にCで完全にプログラムできることです（アセンブラはそれほど複雑ではありませんが、Cortex-M0には56個のコマンドしかありません）。 一部のコマンドは原則としてCから使用できませんが、CMSIS-Cortex Microcontroller Software Interface Standardはこの問題を解決します。 これは、それを管理するすべての基本的なタスクを解決するプロセッサーのドライバーです。



プロセッサーはどのようにロードしますか？ 典型的な状況は、アドレス0x00000000からコマンドの実行を開始するだけです。 私たちの場合、プロセッサはややインテリジェントで、メモリの先頭で特別に定義されたデータ形式、つまり割り込みベクトルのテーブルに依存しています。





プログラムは次のように開始します。プロセッサは0x00000000の値を読み取り、SPに書き込みます（ SPはスタックの最上部を指すレジスタです）。その後、0x00000004の値を読み取り、PCに書き込みます（ PCは現在の命令+ 4バイト）。 したがって、一部のユーザーコードの実行が開始されますが、既にメモリのどこかを指すスタック（つまり、Cプログラムを実行するためのすべての条件）があります。



テスト演習として、LEDを点滅させます。 mbedには4つあり、LPC1114（以下「ボード」と呼びます）を使用した回路では、LEDを手動で取り付けます。



コードを直接記述する前に、もう1つ、つまり、メモリのどこに何を配置する必要があるかを見つける必要があります。 ある種の「標準」OSを使用していないため、コンパイラ（または、リンカ）は、スタックが必要な場所、コード自体、および場所-束を見つけることができません。 幸いなことに、コアのCortexファミリには標準化されたメモリカードがあり、このアーキテクチャの異なるプロセッサ間でアプリケーションを比較的簡単に移植できます。 もちろん、周辺機器との連携はプロセッサに依存したままです。



Cortex-M0のメモリカードは次のようになります。







（ Cortex™-M0デバイスの一般ユーザーガイドからの画像）



Cortex-M3では、基本的に同じですが、多少詳細になります。 ここでの問題は、NXPがこの問題について独自の個別の見方をしているため、プロセッサのドキュメントでメモリカードを確認することです。







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



実際、SRAMは0x10000000から始まります！ そのため、いくつかの標準、他の標準はありますが、ドキュメントボリュームをスクロールする必要があります。



この知識を武器に、コードを作成します。 まず、割り込みテーブル：

.cpu cortex-m0 /*      */ .thumb .word _stack_base /*      ,    */ .word main /* Reset:         */ .word hang /* NMI         */ .word hang /* HardFault */ .word hang /* MemManage */ .word hang /* BusFault */ .word hang /* UsageFault */ .word _boot_checksum /*   */ .word hang /* RESERVED */ .word hang /* RESERVED*/ .word hang /* RESERVED */ .word hang /* SVCall */ .word hang /* Debug Monitor */ .word hang /* RESERVED */ .word hang /* PendSV */ .word hang /* SysTick */ .word hang /*   0 */ /* ... */ /*    32   LPC1114  35  LPC1768,     ,         */ .thumb_func hang: b . /*    :   */ .global hang
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このテーブルをboot.s



保存します。 ここで、実際には、アセンブラー挿入は1つしかありません-ハング関数は、プロセッサーの無限ループを配置します。 リセットを除くすべての割り込みはそれを指しているため、不測の事態が発生した場合、プロセッサは単にハングし、理解できないコードを実行することはありません。



テーブル自体はもっと長くする必要がありますが、実際にはResetベクターの後でも終了できますが、この例では残りは機能しません。 ただし、念のため、テーブルをほぼ完全に埋めました（ユーザーの割り込みを除く）。



次に、メイン関数の実装を記述します。

 #if defined(__ARM_ARCH_6M__) /* Cortex-M0  ARMv6-M,   LPC1114 */ #define GPIO_DIR_REG 0x50018000 /* GPIO1DIR     GPIO 1 */ #define GPIO_REG_VAL 0x50013FFC /* GPIO1DATA     GPIO 1 */ #define GPIO_PIN_NO (1<<8) /* 8-    8-  */ #elif defined(__ARM_ARCH_7M__) /*      LPC1768 */ #define GPIO_DIR_REG 0x2009C020 /* FIO1DIR     GPIO 1 */ #define GPIO_REG_VAL 0x2009C034 /* FIO1PIN     GPIO 1 */ #define GPIO_PIN_NO (1<<18) /* 18-    18-  */ #else #error Unknown architecture #endif void wait() { volatile int i=0x20000; while(i>0) { --i; } } void main() { *((volatile unsigned int *)GPIO_DIR_REG) = GPIO_PIN_NO; while(1) { *((volatile unsigned int *)GPIO_REG_VAL) = GPIO_PIN_NO; wait(); *((volatile unsigned int *)GPIO_REG_VAL) = 0; wait(); } /* main() **   ! */ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

mbedでは、最初のLEDはGPIO 1.18ポートに接続され、ボード上でLEDをGPIO 1.8に接続しました。 同じピンは異なる機能を実行できます。これらはデフォルトでGPIO（汎用I / O-汎用I / Oライン）と同様に機能します。



LPC-shy Userマニュアル（ 1枚目と2枚目 ）を手元に置いておけば、コードは比較的簡単です。 まず、GPIO_DIR_REGレジスタを介してGPIOの動作モードを示します（プロセッサでは異なる場所にあり、実際、LPC1768はGPIOでより効率的に動作できます）。1は出力、0は入力です。 次に、値0と1（それぞれ0 Vと3.3 V）を交互にポートに書き込む無限サイクルを開始します。



「一時停止」機能は、比較的長いサイクルをスクロールするだけでランダムに機能します（ volatile int



は、コンパイラがこのサイクル全体を最適化するのを防ぎます）。



最後に、これらすべてを正しくまとめる必要があります。

 _stack_base = 0x10002000; _boot_checksum = 0 - (_stack_base + main + 1 + (hang + 1) * 5); MEMORY { rom(RX) : ORIGIN = 0x00000000, LENGTH = 0x8000 ram(WAIL) : ORIGIN = 0x10000000, LENGTH = 0x2000 } SECTIONS { .text : { *(.text*) } > rom .bss : { *(.bss*) } > ram }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リンカスクリプトは、フラッシュの場所、RAMの場所、それらのサイズを説明しています（LPC1768のサイズが最も多いため、幸いなことに、シフトは同一です）。 メモリカードを決定した後、コピーするセグメント、.text（プログラムコード）がフラッシュに入る、.bss（まだない静的変数）-メモリにあるセグメントを示します。 さらに、boot.sで使用された2つの文字を指定します。_stack_base-スタックのトップを示し、_boot_checksum（説明のためZuyに感謝します！）-ブートローダーcxumを書き込みます。 チェックサムは、次の式で計算されます：上記のフィールドの合計（つまり、スタックのアドレス、およびチェックサム自体へのすべての割り込み）からの追加コード（2の補数）。 ファームウェアのユーティリティ（以下を参照）自体がチェックボックスを正しいものに修正しますが、アプリケーション自体からコードをフラッシュした場合、再度ブートすることはできません。



これで、boot.s、main.c、mem.ldの3つのファイルができました。すべてをコンパイルして、最後に実行します。 GCCをツールチェーンとして使用しますが、おそらく、LLVMでも同じことを行う方法を示します。 OS Xユーザーの場合、 Linaroからツールチェーンを取得することをお勧めします-リストの最後にあるベアメタル GCC ARM Embedded。 他のOSのユーザーの場合は、ツールチェーンを使用することをお勧めします:-)（gentushnikがcrossdevを保存してGCCをコンパイルする方が簡単でない限り）。

 arm-none-eabi-as boot.s -o boot.o arm-none-eabi-gcc -O2 -nostdlib -nostartfiles -ffreestanding -Wall -mthumb -mcpu=cortex-m0 -c main.c -o main-c0.o arm-none-eabi-gcc -O2 -nostdlib -nostartfiles -ffreestanding -Wall -mthumb -mcpu=cortex-m3 -c main.c -o main-c3.o arm-none-eabi-ld -o blink-c0.elf -T mem.ld boot.o main-c0.o arm-none-eabi-ld -o blink-c3.elf -T mem.ld boot.o main-c3.o arm-none-eabi-objdump -D blink-c0.elf > blink-c0.lst arm-none-eabi-objdump -D blink-c3.elf > blink-c3.lst arm-none-eabi-objcopy blink-c0.elf blink-c0.bin -O binary arm-none-eabi-objcopy blink-c3.elf blink-c3.bin -O binary
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで興味深い点は、GCCのすべての標準ライブラリの使用を無効にすることです。 確かに、最終的なバイナリに到達するすべてのコードは、私たち自身が書いたコードです。



質問：割り込みテーブルを配置する場所をリンカーはどのように知るのですか？ そして彼は知らない、それはそこに書かれていない:-)。 ゼロアドレスから始まる行にリンクしているだけなので、ファイルの順序（boot.o、次にmain-c0.o）は非常に重要です！ 別の方法でリンクするか、boot.oを2回リンクして、lstファイルの出力を比較してください。



最終リスト（lstファイル）を確認するか、バイナリを逆アセンブラーにドロップすることをお勧めします。 ARM UALを話さなくても、少なくとも割り込みテーブルが設定されていることを視覚的に確認できます。









また、面白い瞬間に注意を払うことができます-Cortex-M3でコンパイルするとき、GCCはCortex-M0でのバージョンよりもwait（）関数を生成します。 確かに、最適化を有効にすると、頭脳が整います。

点滅！

あとは、テストプラットフォームにバイナリをアップロードするだけです。 mbedを使用すると、すべてが可能な限り簡単になりますblink-c3.bin



を仮想フラッシュドライブにコピーし、リセットを押します（mbedで）。 ボードでは、すべてが少し複雑です。 まず、ブートローダーに入るために、GNDとGPIO 0.1の間に抵抗が必要です。 第二に、直接ファームウェア用のプログラムが必要です。 Flash Magic （Win、OS X）を使用でき、コンソールユーティリティ-lpc21ispを使用できます。

 lpc21isp.out -verify -bin /path/to/blink-c0.bin /dev/ftdi/tty/device 115200 12000
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファームウェアプロセスは次のとおりです。

• j5とj7の間に抵抗を配置します（10 kOhmでも可能です）。
• リセットを押します。
• lpc21ispを開始します。
• 抵抗器を取り外します。
• リセットをもう一度押します-アプリケーションが起動します。

異なるデバイスでサンプルを実行する機会がある場合、それらの点滅速度は同じではないことに気付くでしょう。 これは、デバイスごとにコア周波数が異なるため、異なる時間にwait()



を実行するためです。 次のパートでは、振動の問題をより詳細に研究し、明確なカウントダウンを行います。



PSテキスト内のエラーを修正するために時間を割いてくださったpfactum habrayuzerに感謝します:-)。



ARMベースのテストプラットフォームをお持ちの方へのPPSリクエスト-コメントに記入してください-どの1つ。 さらなる記事については、ハードウェアベースを確認できます。