8ビットマイクロコントローラーと32ビットマイクロコントローラーのプログラミングの違いはどれですか

そうですね、現時点ではこの世界に8ビット、16ビット、32ビットのマイクロコントローラーがあります。それらはすべてよく使用されます。8ビットと16ビットのマイクロコントローラーをプログラムするのはどのくらい違いますか？つまり、異なる技術やスキルが必要ですか？たとえばマイクロチップを見てみましょう。8ビットマイクロコントローラーから32ビットマイクロコントローラーに移行する場合、どのような新しいことを学ぶ必要がありますか？

一般に、8ビットから16ビット、32ビットのマイクロコントローラーに移行すると、リソース、特にメモリ、および算術および論理演算の実行に使用されるレジスターの幅の制限が少なくなります。8、16、および32ビットモニカは通常、内部および外部データバスのサイズと、算術および論理演算に使用される内部レジスターのサイズの両方を指します（アキュムレーターと呼ばれる1つまたは2つだけに使用されます） 、現在は通常16または32のレジスタバンクがあります。

I / Oポートのポートサイズも一般にデータバスのサイズに従うため、8ビットマイクロには8ビットポートがあり、16ビットには16ビットポートがあります。

多くの8ビットマイクロコントローラーは、8ビットデータバスを備えていますが、16ビットアドレスバスを備えており、2 ^ 16または64Kバイトのメモリをアドレス指定できます（実装された場所に近いという意味ではありません）。しかし、ローエンドPICなどの一部の8ビットマイクロは、RAMスペースが非常に限られている場合があります（例：PIC16では96バイト）。

限られたアドレッシングスキームを回避するために、一部の8ビットマイクロはページングを使用します。ページングレジスタの内容によって、使用するメモリのいくつかのバンクの1つが決まります。通常、ページレジスタの設定に関係なく、使用可能な一般的なRAMがいくつかあります。

16ビットマイクロコントローラーは通常64Kのメモリに制限されていますが、ページング技術を使用してこれを回避することもできます。もちろん、32ビットマイクロコントローラーにはこのような制限はなく、最大4GBのメモリに対応できます。

さまざまなメモリサイズに加えて、スタックサイズもあります。ローエンドのマイクロでは、これはメモリの特別な領域に実装され、非常に小さい場合があります（多くのPIC16には8レベルの深いコールスタックがあります）。16ビットおよび32ビットのマイクロでは、スタックは通常、一般的なRAMにあり、RAMのサイズによってのみ制限されます。

また、さまざまなデバイスに実装されているメモリの量（プログラムとRAMの両方）には大きな違いがあります。8ビットマイクロは、数百バイトのRAMと数千バイトのプログラムメモリしか持っていない場合があります（たとえば、PIC10F320には256ビットのフラッシュと64バイトのRAMしかありません）。16ビットマイクロは、数千バイトのRAMと数万バイトのプログラムメモリを備えている場合があります。多くの場合、32ビットマイクロは64Kバイト以上のRAMを持ち、おそらく1/2 MB以上のプログラムメモリを備えています（PIC32MZ2048には2 MBのフラッシュと512KBのRAMがあり、グラフィックス用に最適化されたPIC32MZ2064DAH176は2 MBのフラッシュとなんと32MBのオンチップRAM）。

アセンブリ言語でプログラミングしている場合、レジスタサイズの制限は非常に明白です。たとえば、2つの32ビット数を追加するのは8ビットマイクロコントローラーでは面倒ですが、32ビットマイクロコントローラーでは面倒です。Cでプログラミングしている場合、これは大部分が透過的になりますが、もちろん、基礎となるコンパイル済みコードは8ビターでははるかに大きくなります。

さまざまなCデータ型のサイズがマイクロサイズごとに異なる場合があるため、私はほとんど透明だと言いました。たとえば、8ビットまたは16ビットのマイクロを対象とするコンパイラは、「int」を使用して16ビットの符号付き変数を意味し、32ビットのマイクロではこれは32ビット変数になります。そのため、多くのプログラムは#definesを使用して、符号なし16ビット変数の「UINT16」など、目的のサイズを明示的に示します。

Cでプログラミングしている場合、最大の影響は変数のサイズになります。たとえば、変数が常に256未満（または符号付きの場合は-128〜127の範囲）になることがわかっている場合、8ビットマイクロ（例：PIC16）で8ビット（符号なしcharまたはchar）を使用する必要があります）より大きなサイズを使用することは非常に効率が悪いためです。同様に、16ビットマイクロ（PIC24など）で16ビット変数を再作成します。32ビットマイクロ（PIC32）を使用している場合、MIPS命令セットにはバイト、ワード、ダブルワードの命令があるため、実際には違いはありません。ただし、一部の32ビットマイクロでは、そのような命令がない場合、8ビット変数の操作は、マスキングのために32ビット変数よりも効率が低い場合があります。

フォーラムメンバーvszが指摘したように、デフォルトのレジスタサイズより大きい変数（8ビットマイクロの16ビット変数など）があり、その変数は2つのスレッド間またはベーススレッド間で共有されるシステムで割り込みハンドラは、一つはしなければならない任意の変数に（ちょうど読ん含む）操作アトミック一つの命令として行われるように見えるようです。これはクリティカルセクションと呼ばれます。これを軽減する標準的な方法は、クリティカルセクションを無効化/有効化割り込みペアで囲むことです。

したがって、32ビットシステムから16ビット、または16ビットから8ビットに移行する場合、このタイプの変数に対するデフォルトのレジスタサイズよりも大きい（ただし以前はなかった）操作は、重要と見なす必要があります。セクション。

あるPICプロセッサから別のPICプロセッサに移る別の主な違いは、周辺機器の処理です。これは、ワードサイズではなく、各チップに割り当てられたリソースのタイプと数に関係しています。一般に、マイクロチップは異なるチップ間で使用される同じ周辺機器のプログラミングを可能な限り同様にしようとしました（timer0など）が、常に違いがあります。周辺ライブラリを使用すると、これらの違いが大幅に隠されます。最後の違いは、割り込みの処理です。繰り返しになりますが、ここにはMicrochipライブラリからのヘルプがあります。

8ビットと32ビットのマイクロコントローラーの一般的な違いの1つは、8ビットのマイクロコントローラーには、実行コンテキストに関係なく、単一の命令でアクセスできるメモリとI / O空間があることが多いことです。複数命令のシーケンスが必要です。たとえば、一般的な8ビットマイクロコントローラ（HC05、8051、PIC-18Fなど）では、1つの命令を使用してポートビットの状態を変更できます。典型的なARM（32ビット）では、レジスタの内容が最初は不明だった場合、4命令の命令シーケンスが必要になります。

    ldr  r0,=GPIOA
    ldrh r1,[r0+GPIO_DDR]
    ior  r1,#64
    strh r1,[r0+GPIO_DDR]

ほとんどのプロジェクトでは、コントローラーは個々のI / Oビットを設定またはクリアする以外のことを行うのにほとんどの時間を費やします。そのため、ポートピンをクリアするなどの操作に多くの命令が必要になることは重要ではありません。一方で、コードは多くのポート操作を「ビッグバン」する必要がある場合があり、単一の命令でそのようなことを行う能力は非常に価値があることがわかります。

一方、32ビットコントローラーは常に、メモリに格納できる多くの種類のデータ構造に効率的にアクセスするように設計されています。比較すると、多くの8ビットコントローラは、静的に割り当てられていないデータ構造へのアクセスが非常に非効率的です。32ビットコントローラーは、1つの命令で、通常の8ビットコントローラーで半ダース以上の命令を必要とする配列アクセスを実行できます。

実際の最大の違いは、チップ全体を完全に理解するためのドキュメントの量です。ほぼ1000ページのドキュメントが付属する8ビットのマイクロコントローラーがあります。1980年代の8ビットCPUと、それが使用される一般的な周辺機器チップに相当する約200〜300ページに相当します。周辺機器が豊富な32ビットデバイスでは、部品を理解するために2000〜10,000ページのドキュメントを読む必要があります。最新の3Dグラフィックスを備えたパーツは、2万ページのドキュメントに対応しています。

私の経験では、現在の32ビットコントローラーについて知られていることをすべて知るには、現代の8ビットパーツの場合と同じように、約10倍かかります。「すべて」とは、型にはまらない方法ですべての周辺機器を使用する方法を知っており、機械語、プラットフォームが使用するアセンブラー、その他のツール、ABIなどを知っていることを意味します。

多くの設計が部分的に理解されて行われていることはまったく考えられません。些細なこともあれば、そうでないこともあります。プラットフォームの切り替えは、より強力なアーキテクチャから得られる生産性の向上に対して支払う短期および中期の生産性の価格があることを理解して行う必要があります。デューデリジェンスを行います。

個人的には、同じファミリーのuCのアップグレード（8ビット-> 32ビット）についてあまり心配することはなく、全面的にスペックを増やしています。一般に、データ型については通常通りに何もしません。なぜなら、将来的にはメンテナンスが難しいからです。

デバイスコードのダウングレードは別の話です。

32ビットMCUの方が、1つに比べてはるかに多くの電力を消費します。より多くのサポート回路が必要です。

1つは8ビットから32ビットに実際に移行するわけではありません...両方を、しばしば一緒に使用し続けるでしょう。一番下の行は、仕事に適したものを使用（および学習）する必要があるということです。ARMを学びましょう。組み込みの世界を今すぐ揺るがし、それを続けていくからです。また、AVRまたはPICについても学びます。これらはすばらしいボードコントローラーだからです。

とにかく、ARMからx86への切り替えと同様に、AVRからARMへの切り替えは苦痛を経験するでしょう。バスのサイズはそれほど大きな違いはありません。しかし、すべての特別な高度なハードウェアはそうします。標準の割り込みから6つの優先度レベルを持つベクトル化された割り込み配列に移行することは、40億までカウントする方法を考え出すよりもはるかに困難です。