|
Arabic
Bengali
Chinese
English
French
German
Hebrew
Hindi
Italian
Japanese
Korean
Malay
Polish
Portuguese
Spanish
Turkish
Ukrainian
Vietnamese|
無線電子工学および電気工学の百科事典 初心者向けおよびそれ以降向けのマイクロコントローラー。 無線エレクトロニクスと電気工学の百科事典
無線電子工学と電気工学の百科事典 / マイクロコントローラー 初対面 まず最初に、このサイクルのテーマが、そのタイトルから判断して、演繹的に興味がないか、または「異質」であると思われる人たちに向けて、いくつかの言葉を述べておきます。 おそらく、設計でまだマイクロコントローラー (以下、略して MK と呼びます) を使用したことがなく、近い将来にはマイクロコントローラーなしでもやっていけるだろうと考えているかもしれません。 また、問題を解決するためにマイクロコントローラー システムを構築するのは面倒で経済的に実行不可能であると考える可能性もあります。 焦らないでください。特に皆さんのために、いくつかの事実といくつかの統計をお伝えしたいと思います。 たとえば、MK に最も近いものであるパーソナル コンピューターを取り上げ、その使用頻度を比較してみましょう。 アナリスト会社ローウェンバウム＆カンパニーによると、 株式会社（米国）によると、1997年に世界で発売されたパーソナルコンピュータの台数は約20万台に達しました。 同意します、これはたくさんあります。 さて、この膨大な数が世界の MK 生産量のわずか 0,2% であると想像してください。 分析会社IC Insights Inc.によると。 (米国) 1998 年の世界市場は、そのうちの 13,5 億個以上を吸収しました。 結論はそれ自体を示唆しています。 今日でも、人間の活動の中でコンピュータが効果的に使用されない分野を見つけるのが難しいとしたら、MK について何が言えるでしょうか? なぜこれほど人気があり、文字通り欠かせないものになったのでしょうか? 答えはマイクロコントローラーの構造そのものにあります。 この概念の定義の最初の近似として、MC は単一のマイクロ回路内に配置されたコンピューターであると仮定できます。 したがって、その主な魅力的な特質は、小さい寸法、消費量、価格です。 高いパフォーマンス、信頼性、そしてさまざまなタスクの実行に適応する能力。 MK がマイクロプロセッサと異なるのは、中央処理装置 (CPU) に加えて、メモリと多数の入出力デバイス (アナログ/デジタル コンバーター、シリアルおよびパラレル情報チャネル、リアルタイム タイマー、パルス幅) が含まれている点です。 MK は、その構造と動作原理において、本質的にパーソナル コンピュータと変わりません。 したがって、マイクロコントローラーとマイクロコンピューターという言葉は同義語です。 ただし、最初の用語（英語の単語 control - manage から）の方が一般的です。これは、その主な目的、つまりクレジット カード、カメラ、携帯電話、ステレオ、テレビ、VCR などのさまざまなデバイスに組み込まれた自動制御システムでの使用を反映しているためです。ビデオカメラ、洗濯機、自動車、電子レンジ、盗難警報システム、ガソリンエンジン点火システム、機関車の電気駆動装置、原子炉など。 組み込み制御システムは、組み込みシステム (組み込みシステム - 英語) と呼ばれる経済の新しい部門が実際に形成されるほどの大規模な現象となっています。 現在、世界中で数千種類のMKが生産されています。 これらは 8 ～ 356 ピンのパッケージで提供され、-55 ～ +125oC の温度で 32 kHz ～ 200 MHz の周波数で動作し、1,2 V の電源電圧で動作することができますが、消費電流は数マイクロアンペアを超えません. . 製品の価格も下がり続けています。 現在、一部の 50 ビット MCU の価格は XNUMX セント以下であり、これは「ハード ロジック」チップ XNUMX 個の価格に匹敵します。 これらすべてが、今日、MCが適用されない人間の活動領域を見つけることがますます困難になっているという事実につながり、その配布のプロセスは雪崩のような性質を持っています。 上記の事実により、私たちの物語の主人公に対する敬意を持った態度がすでに整っていることを願っています。 実際、MC は世界的なイベントとなり、ほぼすべての種類の人間の活動に侵入しています。 25 年ちょっと前に登場したこれらの製品の人気がこれほど急速に成長したのはなぜでしょうか? これらのデバイスとは何ですか?その機能と将来性は何ですか? MC やそれに基づくシステムを活動の中でまだ使用したことがない場合は、 おそらくそれについて考える時が来ているでしょうか？ MK を適用することに決めた場合、どのような順序で行動すべきでしょうか? どのような困難があなたを待っているでしょうか?その過程で何があなたを助けてくれますか? 提案された一連の記事でこれらの質問に答えようとします。 ムーアの法則と最初のMK 1965 年に遡ると、強力なインテル コーポレーションの将来の創設者の 18 人であるゴードン ムーアは、興味深い事実に注目しました。 メモリ チップの性能の向上をプロットした結果、彼は興味深いパターンを発見しました。それは、チップの新しいモデルが 24 ～ XNUMX か月ごとに登場し、その容量が毎回約 XNUMX 倍になっていたということです。 G. ムーア氏は、この傾向が続けば、コンピューティング デバイスの能力は比較的短期間で指数関数的に増加するだろうと示唆しました。 G. ムーアの予測はその後見事に裏付けられ、彼が発見したパターンは今日でも驚くべき精度で観察されており、生産性向上に関する数多くの予測の基礎となっています。 28 マイクロプロセッサの登場 (4004 年) から 1971 年が経過し、チップ上のトランジスタの数は 12 倍以上に増加しました。Sorrettué チップでは 000 個から 2 個になりました。 1976 年、半導体技術の急激な発展により、インテルは最初の MK-8048 を開発しました。これには、CPU に加えて、プログラム メモリ、データ メモリ、27 ビット タイマー、および 8048 の I/O ラインが含まれていました。 今日、1980 はすでに歴史的なものですが、8051 年にインテルがリリースした次の製品はまだ健在です。 こちらはMKXNUMXです。 アーキテクチャMK8051 この MK は、後に他の多くの製品が作成されたイメージと類似の古典的なモデルと考えることができます。 そのブロック図を図に示します。 1. CPU - MK のメイン ノード。 それはコマンドシステムなどの重要な概念に関連しています。
命令セットは、特定の CPU に固有のバイナリ コードの固有のセットで、可能なすべての操作のリストを定義します。 このような各コードは 8051 つのオペレーションを定義し、オペレーション コードまたはコマンドと呼ばれます。 命令セットで使用されるコードが増えるほど、CPU が実行できる操作も増えます。 MK 8 は 256 ビットなので、オペコードのサイズは 8051 ビットです。 理論的には、合計 255 個の XNUMX ビット オペコードが存在する可能性があります。 XNUMX は XNUMX を使用します。 使用するオペレーションコードの数に応じて、命令システムは CISC と RISC の 8051 つのグループに分けられます。 CISC という用語は、複雑なコマンド システムを意味し、Complex struction Set Computer の英語の定義の略語です。 同様に、RISC という用語は縮小命令セットを意味し、英語の Reduced struction Set Computer に由来しています。 コマンドシステム MK 15 は CXNUMXC タイプに起因すると考えられます。 ただし、これらの概念が広く使用されているにもかかわらず、名前自体は CISC と RISC コマンド システムの主な違いを反映していないことを認識する必要があります。 RISC アーキテクチャの主なアイデアは、クロック ジェネレーターの XNUMX サイクルで実行できるオペレーション コードの組み合わせを慎重に選択することです。 このアプローチによる主な利点は、CPU のハードウェア実装が大幅に簡素化され、そのパフォーマンスが大幅に向上することです。 当初、このようなアプローチはコマンドのセットを大幅に削減することによってのみ実装できたため、RISC という名前が生まれました。 たとえば、Microchir PIC ファミリの MK の命令セットには 35 命令しか含まれておらず、RISC として分類できます。 明らかに、一般的なケースでは、RISC アーキテクチャのいくつかの命令が CISC アーキテクチャの 8051 つの命令に対応する必要があります。 ただし、通常、RISC アーキテクチャによるパフォーマンスの向上は、効率の低い命令セットによる損失を上回り、その結果、CISC と比較して RISC システム全体の効率が高くなります。 それで。 最速のコマンド MK 12 は XNUMX サイクルで実行されます。 たとえ各命令に対して XNUMX つの RISC コントローラ命令を実行する必要があるとしても、最終的には、RISC アーキテクチャによりパフォーマンスが XNUMX 倍向上します。 その過程で、RISC アーキテクチャにより多くのタスクを解決できるようになります。 確かに、CPUの簡素化に伴い、その実装に必要なトランジスタの数が減少するため、結晶の面積が減少します。 これにより、コストと消費電力が削減されます。 この時点で、「未来は RISC アーキテクチャにある!」と叫ぶ人もいるでしょう。 しかし、これら 120 つの概念の間の境界線は急速に曖昧になりつつあります。 例えば。 Atmel の AVR ファミリ MCU には、CISC タイプに対応する XNUMX 命令の命令セットがあります。 ただし、それらのほとんどは XNUMX サイクルで実行され、これが RISC アーキテクチャの特徴です。 今日、RISC アーキテクチャの主な特徴はクロック ジェネレーターの XNUMX サイクルで命令を実行することであると一般に受け入れられています。 コマンドの数自体はもう重要ではありません。 クロック ジェネレーターはパルスを生成して、デバイスのすべてのノードの動作を同期させます。 それらの繰り返しの周波数は、MK の出力に接続された水晶共振器または RC 回路によって設定できます。 一部の MK では、外部要素を使用せずにクロック ジェネレーター動作モードが提供されます。 この場合、クロックパルスの周波数は、製造時に決定される水晶のパラメータに依存します。 ROM はプログラムを保存するように設計された読み取り専用メモリ デバイスであるため、このメモリはコード メモリまたはプログラム メモリと呼ばれることがよくあります。 最近まで、マスクされた ROM とプログラマブル ROM の XNUMX つの主なタイプの ROM がありました。 情報は、MC の製造プロセス中に技術テンプレート (マスク) を使用してマスク ROM に入力されます。 生産サイクルの終了後は変更できません。 このような ROM は、プログラムの品質に疑いの余地がなく、この特定のプログラムで MK が大量に必要な場合にのみ使用されます。 マスクROMの利点は、量産（数千個から）が最も低コストであることです。 プログラマブル ROM 情報は、プログラマと呼ばれる装置を使用して書き込まれます。 このような ROM を備えた MK には、1000 回だけプログラム可能なものと繰り返しプログラム可能なもの (リプログラム可能) の XNUMX つのタイプがあります。 XNUMXつ目は、名前自体が示すように、XNUMX回限りのプログラミングを許可し、その後は情報を消去することはできません（OTPメモリを備えたMK - 英語から。One Time Programmable）。 小規模生産（最大 XNUMX 個）で使用されます。 マスク MK の使用が経済的に正当化されない場合。 繰り返しプログラム可能なマイクロ回路は、紫外線照射による消去機能を備えた ROM を備えた MK (「窓」付きのパッケージで入手可能) と、電気的に再プログラム可能なメモリを備えた MK に分けられます。 紫外線照射による消去を備えた ROM を備えた MC の欠点は、コストが非常に高いことと、書き込み/消去サイクル数が比較的少ないことです (結晶照射の総線量によって異なり、通常は 15 ～ 20 回を超えません)。 現在、ROM を実装するための新しいテクノロジであるフラッシュ メモリがますます人気が高まっています。 その主なメリットは、 それは電気的再プログラム可能性の原理に基づいて構築されているということです。 つまり、プログラマを使用して情報の複数の消去と記録が可能になります。 書き込み/消去サイクルの最小保証回数は、通常、数千回を超えます。 これにより、ライフサイクルが大幅に延長され、MC システムの柔軟性が向上します。 これにより、システム開発段階と実際のデバイスでの動作中の両方で MC プログラムを変更できるためです。 RAM はデータの保存に使用されるランダム アクセス メモリであるため、このメモリはデータ メモリとも呼ばれます。 RAM の読み取りおよび書き込みサイクル数には制限はありませんが、電源電圧がオフになるとすべての情報が失われます。 MK 8051 のアーキテクチャには、プログラム メモリとデータ メモリを個別に使用することが含まれており、ハーバードと呼ばれます。 通常、このアーキテクチャはプログラム メモリとデータ メモリのアクセス パスを分離することでシステム パフォーマンスを向上させるために使用されますが、8051 では、同じサイズを必要としないプログラム メモリとデータ メモリを実現するために使用されました。 ハーバードの対極であるフォン ノイマン アーキテクチャは、共有メモリ内にプログラムとデータを保存するもので、コンピュータで使用するために設計されたマイクロプロセッサに最も典型的なものです。 例としては、x86 ファミリのマイクロプロセッサがあります。 タイマ TO、T1 は、さまざまな機能を実行するようにプログラムできる 32 ビットのプログラム可能なタイマ/カウンタです。 これらは、時間間隔の正確な形成、MK の出力でのパルスのカウント、一連のパルスの形成、シリアル通信チャネルのトランシーバーのクロックに使用できます。 タイマー/カウンターは割り込み要求を生成し、イベントに応じて割り込み要求を処理するように CPU を切り替え、タイマーの状態を定期的にポーリングする必要性を解放できます。 MK の主な用途はリアルタイム システムであるため、タイマー/カウンターは不可欠な要素です。 一部の変更では、タイマーの数が XNUMX に達します。 シリアル ポートは、MK と外部との間の情報交換用のチャネルです。 このような通信チャネルは最小限の数の水晶ピンを占有し、最小限のハードウェア コストでかなりの距離にわたる通信を提供します。 8051 は、RS-232C 標準プロトコルをサポートするユニバーサル非同期シリアル トランシーバー (UART) を実装しており、この MK とパーソナル コンピューター間の通信を組織化することができます。 RS-232C に加えて、組み込みシステムの世界で最も一般的なプロトコルは RS-485 です。 I2C (XNUMX 線式双方向バス)。 SPI (XNUMX 線式シリアル ペリフェラル インターフェイス)。 ビットバス (シリアル コントロール バス)、CAN (コントローラー間ネットワーク インターフェイス)、USB (ユニバーサル シリアル バス) など。 現在、ほぼすべてのタイプのシリアル チャネルについて、構成内に対応するシリアル ポートを備えた MK を見つけることができます。 パラレル I/O ポートも、あらゆる MCU の重要な部分です。 通常、それらは直接の環境、つまりセンサーやアクチュエーターと通信するために使用されます。 MK パラレル ポートの重要な特徴は、いくつかの機能を実行するようにプログラムできることです。 たとえば、8051 では、ポート ピン P0 および P2 は、通常のスタティック I/O レジスタとして、または追加のプログラム メモリ、データ メモリ、I/O デバイスなどの外部デバイスを接続するためのアドレスおよびデータ バスとして使用できます。 これにより、MK アーキテクチャに柔軟性が与えられます。 RXNUMX ポートは、静的 I/O レジスタとして使用することも、シリアル チャネル、タイマー、割り込みコントローラなどの動作のための特別な機能を実行することもできます。再プログラム可能であるため、設計されたデバイスで MC のすべての出力を使用できます。最大の効率で。 割り込みシステムは、MK の最も重要な部分の XNUMX つです。 リアルタイム システムの特徴は、リアルタイム システムにとって非常に重要なパラメータが外部イベントへの応答時間であることです。 簡単な例で説明しましょう。 コンピュータで数学的計算を行うときは、通常、これらの計算を実行するように設計されたプログラムを実行し、それがコンピュータのメモリにロードされた後、問題文を入力して結果を待ちます。 この場合の待ち時間は基本的に重要ではありません (もちろん、当然のことですが)。コンピューターの動作が遅いとイライラすることがありますが、結果には影響しません。 リアルタイム システムは、開発段階で計算された、外部イベントに対する制御システムの応答速度を非常に具体的に想定しています。 ここでは、計算された遅延を超える遅延は絶対に受け入れられません。致命的な結果につながる可能性があります。 イベントへの迅速な応答の問題は、割り込みシステムを組織することで解決されます。 これは、そのようなイベントごとに個別のコードの「部分」が開発され、それに対する MK の反応が形成されることを意味します。 このコードの「部分」は割り込み要求ルーチン (割り込みルーチンという用語は、簡潔にするためによく使用されます) と呼ばれ、プログラム メモリの既知のアドレスに配置されます。 特定のイベントが発生すると、それに関する信号が割り込みコントローラーの入力に送信されます。 後者は、発生したイベントに関する入力信号と、そのイベントから割り込み要求処理ルーチンへのエントリポイントが位置するプログラムメモリのアドレスとを１対１に対応付ける装置である。 コントローラは現在のプログラムの CPU 実行を中断し、割り込みサービス ルーチンの実行への移行を開始します。 イベントが発生した瞬間から割り込みルーチンの最初の命令の実行が開始されるまでの経過時間を、イベントに対する MC の応答時間と呼びます。 処理が完了すると、CPU は自動的に中断されたプログラムの実行に戻ります。 割り込みコントローラーのもう 8051 つの機能は、イベントに優先順位を付けることです。 優先順位の概念は、実行中の割り込みルーチンは、現在の優先順位よりも高い優先順位を持つ場合にのみ、別のイベントによって中断できることを意味します。 それ以外の場合、CPU は前のイベントの処理が終了した後、新しいイベントの処理に進みます。 MK XNUMX の一部である割り込みコントローラには XNUMX つのイベント入力があります。XNUMX つは外部デバイスから、XNUMX つはタイマーから、XNUMX つはシリアル チャネルからです。 通常、彼らは MK について話すとき、必ずそれが属するファミリーについて言及します。 1 つのファミリーには、同じコアを持つ製品が含まれます。コアは、命令システム、CPU 動作シーケンス図、プログラム メモリとデータ メモリの構成、割り込みシステム、周辺デバイスの基本セットなどの概念のセットとして理解されます。 。 実際、図では、 図 8051 は、XNUMX ファミリの他の何百もの修正版を作成するための基礎となったコアを示しています。 さまざまな代表的なものの違いは、主に周辺デバイスの構成とプログラムまたはデータ メモリの量にあります。 MK によって解決されるタスクの範囲が広いため。 非常に幅広いため、メーカーは最も多様な消費者のニーズを満たすためにできるだけ多くの修正をリリースしようとしています。 多くのファミリでは、変更の数が XNUMX に近くなるか、この値を超えることさえあります。 このファミリの最も重要な機能は、それに含まれるすべての MK のバイナリ コード レベルでのソフトウェア互換性です。 これにより、システム開発者は、ソフトウェア開発を失うことなく、あるマイクロコントローラー ファミリを別のマイクロコントローラー ファミリに置き換えることができます。 当然のことながら、ファミリーに含まれる品種の数が多いほど、最適なオプションを選択する可能性が高く、開発者にとってこのファミリーはより魅力的になります。 異なるファミリの製品間のソフトウェア転送の問題は非常に複雑であり、高級言語を使用しても常に解決できるわけではないため、新しい開発のための MC ファミリの正しい選択の問題は戦略的なものです。大きな損失なしでそれが可能です。 サイクルの次の記事で選択基準の問題に戻ります。 プログラム開発は、MK ベースのデバイスの作成における最も重要な段階の XNUMX つです。 それがなければ、彼は「死んで」おり、外部の影響に反応せず、制御信号を発行しません。 電源がオンになると、MCU は接続されたプログラム メモリ (通常は ROM) にあるプログラムの実行を直ちに開始します。 その実行は、ある固定アドレス (ほとんどの場合はゼロ) から開始されます。 アドレスは単なる ROM セル番号であり、そのプロセスは次のとおりです: MCU はプログラム メモリに格納されている数値を読み取り、マシン コードと呼ばれるその値に応じて、ALU レジスタの内容に対して特定のアクションを実行します。 メモリ、ポートなど。たとえば、プログラム メモリから数値 32H を読み取ります。 MK は、入力ポート番号 2 から値を読み取り、それをアキュムレータ レジスタに入れる必要があることを「理解」しています。 多くの場合、アクションを記述するには XNUMX バイトでは不十分なため、MK はメモリから追加のバイトを読み取ります。 アクションを実行した後、MK は次のメモリセルから値を順番に読み出します。MK が実行する XNUMX つのアクションを記述するバイトの集合をマシンコマンド (命令) と呼び、MK が実行するコマンドの集合をマシンコマンド (命令) と呼びます。わかります。」 - そのコマンド システムまたは命令セット (命令セット)。 異なるファミリーの MK は異なるコマンド システムを持ちます。つまり、それらのマシン コードは、同様の動作を実行しますが、異なる意味を持ちます。 したがって、MKのプログラムは一連の数字であり、その値は実行するアクションを示します。 プログラムを開発すると、これらのマシン コードを含むコンピューター ファイルが作成されます。 ROM プログラマーの助けを借りて、MK プログラム メモリに入力 (「縫い付け」) されます。 この一連のマシンコード、つまり MK のプログラムはどのように構成されているのでしょうか? 開発者は本当にマシンコードの値を記憶し、その順序を手動で設定する必要があるのでしょうか? MK の最初のプログラムはこのようにして作成されました。 そしてそれは機械語でのプログラミングと呼ばれていました。 このプログラム開発方法が非常に時間がかかり、非効率であることは明らかです。 プログラム作成プロセスを容易にするための最初のステップは、コンピューター プログラム、いわゆるアセンブリ言語からのトランスレーターでした。 そのアイデアは、MK によって実行されるアクションをより人間が読める言語で表現し、これらの式をマシンコードに変換することでした。 ポート 2 の値を読み取ってアキュムレータに入れる上記の機械語命令の例では、実行されるアクションは大まかに MOV A.P2 として表すことができます。 ここで、命令ニーモニックと呼ばれる MOV (英語の move に由来) という単語は値の転送を表し、オペランドと呼ばれる A と P2 は値をどこから取得し、どこに置くかを示します。 この表記法をアセンブリ言語と呼びます。 そこに書かれたプログラム。 アセンブリ言語の構造をマシンコードに変換するトランスレーターによって処理されます。 アセンブリ言語プログラミングは今日まで広く普及しています。 すべての一般的なマイクロコントローラー ファミリのアセンブリ言語トランスレーターは無料です。 アセンブラでのプログラミングにはマシンコードでのプログラミングよりも明らかな利点がありますが、多くの場合、アセンブラは開発者のタスクを実装するには十分に効率的ではありません。 実際のところ、MK は整数の算術演算、転送、比較などの最も単純な演算のみを実行できます。浮動小数点数の演算など、より複雑なタスクの場合、開発者は不便な特殊なルーチンを作成する必要がありました。使うのが面倒。 MK のプログラム開発の次のステップは、特別なコンピュータ プログラム、つまり高級プログラミング言語からのトランスレータ、またはコンパイラの作成でした。 最も広く使用されているプログラミング言語は C です。 トランスレータの出現により、MK 用のプログラムの開発は劇的に簡素化されました。 たとえば、プログラム内で XNUMX つの数値を加算する必要がある場合は、a = b + c と記述するだけで十分です。 そしてトランスレータは、変数 a、b、c のタイプに応じて、この式を必要な機械命令のシーケンスに変換します。 高級言語を使用すると、開発者は特定のマイクロコントローラーのコマンド システムを抽象化し、より単純で人間にとって理解しやすいカテゴリで動作させることができます。 開発者は、マイクロコントローラーの一般的なアーキテクチャを理解することのみが必要です。 課題解決に必要な組み込み周辺機器の動作原理とC言語によるプログラミングスキルを習得します。 プログラムの機能内容は C 言語ツールを使用して実装されます。 これには、文字列を操作するための算術演算など、さまざまなサブルーチン (関数) が多数含まれています。 MK のプログラムを C 言語で作成するプロセスを考えてみましょう。 開発にはパソコンが必要となります。 タスクを理解した後、開発者はテキスト エディタを使用して C 言語でプログラムのソース コードを作成します。 次に、C トランスレーター プログラムを実行します。 ソーステキストを中間オブジェクトファイルに変換します。 トランスレータは、コマンド ラインで指定された一連のキー (説明はドキュメントにあります) によって制御されます。 開発者がプログラムの作成中に構文エラーを犯した場合、トランスレータはソース テキスト ファイルの各行番号を示すとともに、そのリストを画面に表示します。 開発者はすべてのバグを修正する必要があります。 変換が成功した後、オブジェクト ファイルはリンカー (リンカー) によって処理され、マシン コードでプログラム ファイルが生成されます。 高級言語を使用する場合には問題が XNUMX つあります。 コンパイラーは言語構造をマシンコードに変換する責任を負い、この変換はさまざまな効率で実行できます。 効率の基準は、マシン コードのサイズ (もちろん小さいほど優れています) とマシン コードの速度です。 コンパクトで高速なコードを生成するタスクは非常に難しく、コンパイラーの全体的な品質はそのソリューションに依存します。 最新の C コンパイラは、マルチレベルの最適化、特定の MK のアーキテクチャ機能を使用しており、サブルーチンの一部がアセンブラで書かれた混合プログラムを作成できます。 説明されているプロセスはかなり面倒に見えます。開発者はさまざまなプログラム (テキスト エディター、C コンパイラー、制御キーを記憶するためのリンカー、ファイル内の行番号でプログラム内のエラーを検索する) を手動で起動する必要があります。これは、開発作業を容易にするためのこれまでの最新のステップです。 MK 用プログラムの開発者は、統合環境開発 (統合開発環境。IDE) の登場です。統合開発環境は、プログラム開発のすべての段階をリンクするコンピュータ プログラムです。ソース コードを記述するためのテキスト エディタとトランスレータを組み合わせたものです。アセンブラやCから、リンカ、デバッガ、MKなど開発者に必要なツールのリファレンス情報をまとめています。トランスレータやリンカなどのコンポーネントの設定は、コマンドラインでスイッチを指定するのではなく、ダイアログボックスの形式で行います。適切な場所のボックスにチェックを入れるだけです。 統合ソフトウェア開発環境の出現により、MC 用プログラムの作成効率がさらに向上し、開発者は解決すべき問題の本質に集中し、その実装の具体的な詳細を抽象化できるようになりました。 統合ソフトウェア開発パッケージは複数の会社によって製造されています。 さまざまなメーカーのパッケージは機能的には似ていますが、サービス機能、使いやすさ、生成されるマシンコードの品質が異なります。 最も人気のある開発キットの主な特徴を表に示します。
MKのプログラムのシンボリックデバグ まれな例外を除き、MK のプログラムはエラーが含まれているため、最初から動作を開始せず、デバッグが必要になります。 開発者はさまざまな方法でデバッグの問題に対処します。 彼らの中には、ソーステキストを注意深く分析し、MK出力で何が起こっているかをオシロスコープで確認するだけで十分であり、すべてのエラーは修正できると信じている人もいます。 この方法は、開発者に豊富な経験があり、使用される MK を完全に理解しており、常に正しいコードを生成するトランスレータ (通常はアセンブラ) と十分な時間があれば適用できます。 実践で自家製のデバッグ モニターを使用する人もいます。これは、メイン プログラムとともに MK にロードされる特別なサブルーチンのセットです。 後者はチェックポイントで監視サブルーチンを呼び出し、MK リソースの状態に関する情報を提供します。 ほとんどすべてのプログラムをこの方法でデバッグできますが、重大な欠点がある可能性があります。 まず、デバッグ モニタには、作業用の MC リソースの一部が提供される必要があります。少なくとも、コードのアドレス空間の一部と一定数のスタック セル、最大で RAM とペリフェラルの一部も提供されます。 MC のデバイス。 モニターが情報を表示するために使用します。 メイン プログラム自体が MK をアクティブにロードしている場合、デバッグ モニターにリソースを割り当てるのは難しい場合があります。 たとえば、PIC 16С5х (Microchip) MK にはスタック セルが XNUMX つしかなく、デバッグ モニター サブルーチン コールを使用するのは困難です。 次に、モニター呼び出しはメインプログラムからの呼び出しに時間がかかるため、プログラムの時間が重要な部分から呼び出すことができません。 第三に、デバッグ モニターの作成自体に時間がかかります。 MK のプログラムをデバッグする最も効果的な方法は、シミュレータ デバッガやインサーキット エミュレータなどの専門的なデバッグ ツールを使用することです。 このようなデバッガが提供する可能性について話す前に、プログラムのソーステキストをマシンコードに変換するコンパイラの選択について触れておく必要があります。 ほとんどの場合、高級言語でプログラミングすることが望ましいです。 生成されるコードのサイズと速度に非常に厳しい要件が課される場合は、アセンブラの使用が必要になります。 現在、ほとんどの場合、より多くのメモリを備えた「より高速な」MK を使用できるため、そのようなケースはますます少なくなってきています。 さらに、最新のクロスツール パッケージを使用すると、一部のモジュールが C で記述された混合プログラムを簡単に作成できます。 そして、最もパフォーマンスが重要な部分はアセンブラーにあります。 C コンパイラでは、アセンブリ命令をソース コードに挿入することもできます。 アセンブラーでのプログラミングと比較した C でのプログラミングの利点は何ですか? 簡単に説明すると、次のとおりです。
高級言語で書かれたプログラムを効果的にデバッグするには、開発者は、プログラムで使用されるデータを表示したり、ソース コードからプログラムの実行を追跡したりする適切な機会を提供するデバッグ ツールを自由に使用できる必要があります。 。 これを可能にするためには、次の XNUMX つの条件が必要です。
ここで、デバッガーがシンボリック情報をどのように解釈すべきか、またこれに関連してユーザーにどのようなオプションを提供すべきかを考えてみましょう。 ソーステキストに従ってプログラムの実行を追跡する 一般に、ソース テキストの XNUMX 行はコンパイラによって複数の機械語命令に変換されます。 アセンブラ プログラムであっても、ほとんどの場合、翻訳時に複数のプロセッサ命令に展開されるマクロが含まれています。 コードの逆アセンブラを使用してこのようなプログラムをデバッグするのは不便なので、コンパイラは行番号のテーブルをデバッグ情報に挿入します。 ソーステキストの行番号とソーステキストファイル名とプログラムコードの絶対アドレスとの対応関係に関する情報が含まれています。 デバッガはプログラムのソースコードを画面に表示します。 この表に従って、プログラムを「行ごと」に実行し、現在の行に対してコンパイラーによって生成されたすべての機械語命令を XNUMX ステップで実行できます。 行番号テーブルを使用すると、プログラム テキストに対してコンテキスト アクションを実行することもできます。たとえば、プログラム テキストを「カーソルまで」、つまりソース テキスト内のユーザー指定の場所まで実行したり、指定した行にブレークポイントを設定したりできます。 コンテキスト アクションこれは、開発者がソース テキストの行に対応するアドレスを知る必要がないため便利です。デバッガ自体がテーブルからアドレスを決定します。 デバッガは、サブルーチン、関数、コード ラベルのアドレスを「認識」し、関数のソース テキストを名前で検索できなければなりません。 デバッグしたプログラムで使用されたデータの表示 完全なデバッグを行うには、開発者はプログラムによって操作されるデータをいつでも表示できる必要があります。 デバッガは、プログラムで使用されるデータを最も適切な方法で表示できる必要があります。 原則として、開発者はプログラム内で名前付きデータを使用します。つまり、プログラム内で使用される各オブジェクトには名前が付けられます。 オブジェクトは、単純なメモリセルから構造体、配列などの高級言語の複雑な構造まで、さまざまな複雑さを持つことができます。 アセンブリプログラムのデータ アセンブリ プログラムは主に単純なデータ、つまりメモリ セルを使用します。 配列も使用されます。 単純なデータを正しく表示するには、デバッガが以下を「認識」する必要があります。
上記の情報を使用すると、デバッガーはユーザーからオブジェクトの名前を受け取った後、その型に応じてその値を表示する必要があります。 最も「高度な」デバッガは、オブジェクトの残りの属性をさらに表示できます。 高水準言語のプログラムのデータ 高級言語で使用されるオブジェクトを表示することは、オブジェクトの構造、メモリ内に格納される方法、スコープが多様であるため、はるかに困難です。 たとえば、開発者の間で最も人気のある C 言語を使用します。 オブジェクトの構造 さまざまな長さの単純な変数に加えて、C プログラムでは、浮動小数点変数、構造体 (struct)、共用体または共用体 (union)、ポインター、XNUMX 次元配列および多次元配列も使用します。 後者は、単純なオブジェクトと複雑なオブジェクト (構造体、共用体、ポインター) の両方で構成されます。 プログラム内で複雑なオブジェクトを使用すると確かに便利です。 ただし、その構造は複雑であるため、デバッグ段階で適切に表示できることが非常に望ましいです。 Fiton のデバッガでは、複雑なオブジェクトを圧縮 (要素値のリスト) 形式と展開形式の両方で表示でき、各配列要素や構造体メンバーのアドレス、値、型を示します。 コンパイラごとにポインタの実装は異なります。 通常、MK には複数のアドレス空間があるという事実により、さらに困難が生じます。ポインターを使用する場合、アドレスに加えて、ポインターが指すアドレス空間を知る必要があるためです。 一部の実装では、アドレス空間識別子はポインター値の一部ですが、他の実装では、コンパイラがこれを事前に「認識」し、適切なコードを生成します。 さらに、ポインター内のアドレス コンポーネントのサイズは 8 ～ 32 ビットにすることができます。 ポインター値を表示する場合、デバッガーは各コンパイラーでの実装の詳細をすべて「認識」する必要があります。 メモリ内のオブジェクトの配置方法 高級言語で書かれたプログラムには、プログラムの実行中にアドレスが変化しない静的オブジェクトに加えて、MK スタックにメモリが一時的に割り当てられる、いわゆる自動オブジェクトが存在する場合があります。 。 このようなオブジェクトのアドレスは絶対的なものではなく、プログラムの実行段階で動的に決定されます。 これらは通常、スタック フレーム ポインター (ベース ポインターまたは BP) と呼ばれる静的変数の現在値から測定されます。 BP の値は実行時にプログラムによって動的に生成されるため、自動オブジェクトの値はそのスコープ内、つまり有効な BP 値を持つ場合にのみ使用できます。 デバッガは、自動オブジェクトの値を表示するときに、BP 値の正確さを監視するだけでなく、アドレスが決定される方法を「認識」する必要があります。 MK レジスタに変数を一時的に配置することもできます。 この場合、デバッガは、どの変数がどのレジスタにどのくらいの期間配置されるかを「認識」する必要があります。 そして最後に、同じオブジェクトが存続期間中にメモリ内に配置される方法が複数回変更される状況がよくあります。 これは、たとえば、関数が XNUMX つ以上のパラメーターをレジスターで受け取り、それらをスタックにプッシュする場合に発生する可能性があります。 可視性のオブジェクトフィールド アセンブラー プログラムと同様、C プログラムには、任意のモジュールから名前によってアクセスできるグローバル オブジェクトと、モジュール内でローカライズされたオブジェクト (これらのオブジェクトは静的として宣言されます) があります。 ただし、自動変数とレジスタ変数を使用すると、デバッガが値を表示するのが難しくなります。 事実はそういうことだ。 第一に、自動オブジェクトの有効期間はそのスコープによって制限され、第二に、囲むスコープは同じ名前を持つ独自の自動オブジェクトを持つことができます。 いくつかのネストされたスコープを持つ関数の例でこれを説明してみましょう。
「a」という名前の変数は、関数 f が実行されている限り存在しますが、関数のどの部分が実行されているかに応じて、「a」という名前は異なる変数を表します。 関数 f をトレースする場合、デバッガーはどの変数がアクティブであるかに応じて、その値を正しく表示する必要があります。 プログラムを作成するとき、開発者はプログラムで使用した概念の実装の詳細には関心を持ちません。 「当然のこと」というカテゴリに関しては、コンパイラやデバッガの開発者にとってそれらを実装することがどれほど難しいかについて、彼はしばしば疑問を抱きません。 後者は、シンプルで直感的なインターフェイス、豊富な機能、およびアーキテクチャ機能の実装と特定の MK の機能に関連するすべての詳細な調査を XNUMX つのシェルに同時に組み合わせるという問題を解決する必要があります。 デバッガが、解決する問題の複雑さに適したデバッグ ツールを開発者に提供しない場合、開発者の生産性は必然的に低下します。 私たちの中で、ソース テキスト内の迷惑なエラーやタイプミスを探すのに何時間も何日も費やさなかった人はいないでしょうか?! マイクロプロセッサ システムの開発と作成の過程では、遅かれ早かれ、それが最終的にハードウェアに組み込まれ、生命の兆候を示し始める瞬間が来ます。 ただし、ほとんどの場合、これらの兆候は予測不可能であることが判明し、システムは独自の生活を開始します。 おそらく多くのプログラマは、すべての新しいプログラムにはバグが含まれていることに同意するでしょう。 これが、新しい MK が最初は「ブラック」ボックスのように動作する理由の XNUMX つです。 システムのデバッグプロセスを容易にするために、さまざまなクラスのツールが開発されています。 その主な目的は、デバッグされた MK の機能プロセスを「透過的」にすること、つまり、開発者の意志で簡単に制御、任意に制御、変更できるようにすることです。 優れたプロフェッショナル ツールキットは、開発者に多くのサービスを追加で提供し、それによって開発者の作業を大幅に促進し、日常的な操作を排除します。 主なデバッグツールには、インサーキットエミュレータ、ソフトウェアシミュレータ、開発ボード（評価ボード）、デバッグモニタ、ROMエミュレータなどがあります。 組み合わせたデバイスとセットもあります。 インサーキットエミュレーター インサーキット エミュレータ (ICE) は、実際のデバイスでエミュレートされたプロセッサを置き換えることができるハードウェア/ソフトウェア ツールです。 VSE は、最も強力で多用途なデバッグ ツールです。 機能的には、VE は外部コンピュータ (通常は IBM 互換 PC) に接続されているものと自律的に機能するものに分けられます。 後者は独自のコンピューティングリソースと入出力設備を備えているため、同等の性能であれば前者よりもはるかに高価であり、同じ価格であれば機能やサービス能力の点で大幅に劣ります。 システムをデバッグする場合、通常、VSE はケーブルによって特別なエミュレーション ヘッドに接続されます。 比較的最近では、このようなヘッドを本体と構造的に組み合わせて、MK の代わりにデバッグ対象のシステムに挿入する VSE モデルが登場しました。 後者を取り外すことができない場合 (ピンがボードにはんだ付けされている場合)、この MC にすべてのピンが XNUMX 番目 (ハイ インピーダンス) 状態になるデバッグ モードがある限り、VSE の使用が許可されます。 この場合、VSE を接続するには、エミュレートされた MK の出力に直接接続される特別なクリップ アダプターが使用されます。 少しでも。 VSE にはデバッガー、MK エミュレーション ノードが含まれています。 エミュレーション メモリとブレークポイント サブシステム。 より高度な TSE には、トレーサ、ブレークポイント プロセッサ、プロファイラ (プログラム コード効率アナライザ)、リアルタイム タイマー、エミュレートされたプロセッサのリソースを「オンザフライ」で読み取り、変更できるソフトウェアおよびハードウェア ツールがさらに含まれる場合があります。 、同期管理を提供し、マルチプロセッサ システムでのエミュレーションに必要なソフトウェアおよびハードウェア ツール、統合開発環境。 デバッガーは、開発者とデバッグ ツールの間の一種のブリッジです。 優れたデバッガは、デバッグ中のプログラムがシステム メモリにロードされ、すべてのレジスタとメモリのステータスと内容 (および必要に応じてそれらの変更) がモニタに表示され、エミュレーション プロセスが制御されることを保証します。 より強力なデバッガ (通常、高レベルまたは高レベル デバッガと呼ばれます) では、これも可能です。
このようなデバッガを使用すると、ユーザーはプログラムの進行を制御し、ソース テキスト、マシン コードでのプログラムのイメージ、エミュレートされたマイクロコントローラーのすべてのリソースの状態の間の対応関係を同時に確認できます。 高レベルのデバッガーは、完全かつ正確なデバッグ情報を提供するクロスコンパイラーが使用されている場合にのみ、そのすべての機能のパフォーマンスを提供することに注意してください (すべてのコンパイラー、特に海賊版がこれに対応しているわけではありません)。同時に、そのプレゼンテーションの形式はデバッガにとって「馴染みのある」ものになります。 エミュレーション メモリは、開発中のシステムの ROM の代わりにデバッグ プロセスで使用されます。 さらに、実際のシステムやそのレイアウトが存在しない場合でもプログラムをデバッグできます。 デバッグ中のプログラムに変更を加える必要がある場合は、ROM を再プログラミングするのではなく、新しいプログラムまたは変更したプログラムをエミュレータのメモリにロードするだけで十分です。 VSEもあります。 これにより、ユーザーは ROM の代わりにエミュレーション メモリを全体的にだけでなく、ブロックごとに「置き換える」こともできます (一部のモデルでは、最小ブロック サイズは 1 バイトです)。 ユーザーが指定した順序で。 これを行うには、プロセッサがデバッグ対象のシステムの ROM の内容と TSE のエミュレーション メモリの内容の両方にアクセスするように、データ メモリとプログラム メモリの配分を設定するだけで十分です。このようなメモリは、通常、マッピング可能メモリと呼ばれます。 トレーサは、プロセッサと同期して動作し、実行中の命令のフローと選択された外部信号の状態をキャプチャするロジック アナライザです。 外部信号だけでなく、MC の内部リソースの状態もトレースできる VSE があります。 例: レジスタ。 このようなデバイスでは、特別なバージョンの MK (エミュレーション クリスタル) が使用されます。 ブレークポイント プロセッサを使用すると、ユーザー指定の条件が満たされた場合にプログラムの実行を停止したり、他のアクション (トレーサの開始や停止など) を実行したりできるようになります。通常のブレークポイント メカニズムとは異なり、プロセッサを使用すると、ほぼすべての条件を形成および追跡できます。ハードウェア レベルでの複雑さはエミュレートされますが、プロセスはリアルタイム スケールから推定されません。 一部の VSE モデルでは、オプションでブレークポイント プロセッサを使用してトレーサーを動的に制御できます。 プロファイラー (プログラム コード効率アナライザー) を使用すると、デバッグされたプログラムの実行結果に基づいて、プログラムのさまざまなセクションの呼び出し数と実行に費やされた時間に関する情報を取得できます。 プロファイラーによって提供される統計情報を分析すると、プログラムの「デッド」セクションや過剰なストレスがかかっているセクションを特定することができ、その結果、デバッグ中のプログラムの構造を最適化できます。 統合開発環境は、プログラムのソース コードの作成からコンパイルとデバッグに至るまで、ソフトウェア開発のすべての段階をサポートするソフトウェア ツールのセットであり、ソフトウェア デバッガ シミュレータおよびプログラマとのシンプルかつ高速な対話を提供します。 VSE ソフトウェア シェルに組み込まれたエディター、プロジェクト マネージャー、および制御システムの存在により、開発者の作業が大幅に容易になり、多くの日常的なアクションから開発者が解放されます。 彼にとって、プログラムの作成、編集、デバッグの間の境界線は曖昧です。 ソース テキスト編集からデバッグへの移行、またはその逆の移行は、対応するウィンドウのアクティブ化と同期して「透過的に」実行されます。 プロジェクト マネージャーは、必要に応じて自動的にコンパイルを開始し、対応するプログラム インターフェイス ウィンドウをアクティブにします。 既存のシミュレータ デバッガを使用してプロジェクトのデバッグに簡単に進むことも、デバッグされたプログラムで ROM のフラッシュを開始することも簡単に行えます。 一部の ITU はユーザーに他の追加機能を提供します。 その中で、特に注目すべき点は、非常に具体的ですが、場合によっては根本的に重要である、マルチプロセッサ システムのデバッグに必要なマルチ エミュレータ コンプレックスを構築する機能です。このようなコンプレックスの際立った機能は、(XNUMX 台のコンピュータからの) 同期制御です。 ) いくつかのエミュレータ。 一般に、デバッグされたデバイスの機能を制御および管理する TSE の機能は制限される可能性があります (たとえば、ステップ モードでの不正な割り込み処理、シリアル ポートの使用の禁止など)。 各 VSE モデルには、サポートされるマイクロコントローラーとコンパイラーの独自のリストがあることも覚えておく必要があります。 ただし、一般的なマイクロコントローラーの大部分では、デバッグされたクリスタルのリソースの使用に制限がない VSE が開発されています。 Fiton 社の PICE-51 モデルを例として、このような ESS の可能性を説明します。 PICE-51 は、プログラマブル ロジック IC (FPGA) を使用して作成されたデバイスです。 これにより、VSE のサイズを大幅に縮小し、エミュレートされた MC の特性からの電気的および周波数特性の偏差を最小限に抑え、33 ～ 3,3 V の電源電圧で最大 5 MHz の周波数で最大のエミュレーション精度を達成することが可能になりました。 . MCS-51 ファミリのほぼすべての MK をエミュレーションします。 ソフトウェア サポートは Windows 環境で動作します。 PICE-51 は、メイン ボード、特定の MK グループ用の交換可能なアダプタ、および特定のケース タイプ用の交換可能なエミュレーション ヘッドで構成されています。 トレーサとブレークポイント プロセッサはメイン ボードに組み込まれ、特定のタイプの MK 用のエミュレーション プロセッサが交換可能なアダプタ ボードにインストールされます。 エミュレーション ヘッドを使用すると、デバイスをユーザー ボード上の DIP および PLCC ソケットに取り付けることができます。 出力電圧が +5 V (0,5 A) のブロックまたはデバッグ中のデバイスから電源が供給されます。 コンピュータとの通信は、ガルバニック絶縁された RS-232C チャネルを介して 115 kbaud の速度で行われます。 PICE-51のその他の機能は次のとおりです。
このような幅広い機能により、VSE は最も強力で多用途なデバッグ ツールになります。 シミュレーター シミュレータ - MK とそのメモリの動作をシミュレートできるソフトウェア ツール。 通常、これはデバッガ、CPU モデル、メモリで構成されます。 より高度なデバイスには、内蔵周辺デバイス (タイマー、ポート、ADC、割り込みシステム) のモデルが含まれています。 シミュレータは、すべての一般的な形式でプログラム ファイルをロードし、シミュレートされたマイクロコントローラのリソースの状態に関する情報を可能な限り完全に表示できる必要があります。 また、ロードされたプログラムの実行をさまざまなモードでシミュレートする機会も提供します。 デバッグ中、モデルはプログラムを実行し、モデルの現在の状態がコンピューターのモニター画面に表示されます。 プログラムをシミュレーターにロードする。 ユーザーは、ステップバイステップまたは連続モードで実行したり、条件付きまたは無条件のブレークポイントを設定したり、シミュレートされたマイクロコントローラーのメモリセルとレジスタの内容を制御したり、自由に変更したりすることができます。 シミュレータを使用すると、プログラムの実行ロジックや算術演算の正確さをすぐにチェックできます。 使用するデバッガのクラスに応じて、一部のシミュレータ モデルはプログラムの高レベルのシンボリック デバッグをサポートします。 シミュレータには、外部環境インターフェイスなどの追加のソフトウェア ツールが多数含まれる場合もあります。 このようなインターフェイスの存在により、MC の外部環境のモデルを作成し、柔軟に使用することができます。 指定されたアルゴリズムに従ってデバッグされたプログラムが機能し、影響を与えます。 実際のシステムでは、MC は通常、接続されている外部デバイス (センサー) から情報を読み取り、それを処理し、アクチュエーターに制御信号を発行することに「従事」しています。 簡易シミュレーターでセンサーの動作をシミュレーションするには、実際のシステムでセンサーが接続されている周辺機器のモデルの現在の状態を手動で変更する必要があります。 たとえば、シリアル ポート経由でバイトを受信するときに特定のフラグが設定され、バイト自体が特定のレジスタに入る場合、これらのアクションは両方ともシミュレータで手動で実行する必要があります。 一部のモデルでは、この問題は解決されています。シミュレータには、情報をグラフィカルに表示するツールなど、MK に接続された外部デバイスのモデルを作成するためのツールが組み込まれています。 ソフトウェア シミュレータの明らかな特徴は次のとおりです。 ロードされたプログラムがリアルタイム以外の時間スケールで実行されること。 ただし、価格が安く、デバッグ対象のデバイスのモックアップがなくてもデバッグできるため、ソフトウェア シミュレータは非常に魅力的なデバッグ ツールとなっています。 また、シミュレータを使用しないと検出できない種類のエラーが存在することにも注意してください。 デバッグモニター デバッグ モニターは、デバッグ対象のシステムのメモリにロードされる特別なプログラムです。 これにより、MK は適用されたタスクに加えて、デバッグ機能も実行するように強制されます。
モニター プログラムはコンピューターまたは受動端末と「連携して」動作し、デバッグ プロセスの視覚化と制御が行われます。 このアプローチの利点
開発ボード 開発ボード、または海外の文献では通常評価ボード (評価ボード) と呼ばれています。 - 応用システムのプロトタイピングのためのオリジナルのコンストラクター。 最近、多くの製造会社がMKの新モデルをリリースしています。 オファーと対応する開発ボード。 通常、これは、MK がインストールされたプリント基板と、その通常の動作に必要なすべての要素、およびコンピュータとの通信システムです。 通常、ボードは開発中のユーザーデバイスを実装するための空きスペースを提供します。 場合によっては、会社が推奨する追加デバイス (ROM、RAM、LCD ディスプレイ、キーボード、ADC など) をインストールするための既製の「配線」も存在します。 ユーザーが改造したボードは、小規模製品（5～20個）に組み込まれるシングルボードコントローラとして有利に使用できます。 ユーザーの利便性を考慮して、開発ボードにはデバッグ モニターに基づくシンプルなデバッグ ツールも装備されています。 ここでは XNUMX つの異なるアプローチが登場しました。XNUMX つは MK に使用されます。 XNUMX つは外部バスを持ち、XNUMX つ目は外部バスを持たない MK 用です。 最初のケースでは、デバッグ モニタは ROM チップとして提供されます。 これは開発ボード上の特別なソケットにインストールされます。 このボードには、ユーザー プログラム用の RAM と、コンピュータまたは端末との通信チャネルも備えています。 例としては、Intel が MK MCS-51 ファミリ用に開発した開発ボードがあります。 80 番目のケースでは、開発ボードには MK の内部 ROM 用のプログラミング システムが組み込まれています。 それらはコンピュータによって制御されています。 モニタ プログラムは、それに応じて準備されたアプリケーションとともに MK の ROM に入力されます (モニタ デバッグ ルーチンの呼び出しが適切な場所に挿入されます)。 その後、試運転が行われます。 デバッグ中のプログラムを修正するには、プログラムをROMから消去し、修正したプログラムをROMに書き込みます。 完成したアプリケーション プログラムは、デバッグされたアプリケーション プログラムから、モニターとその関数へのすべての呼び出しを削除することによって取得されます。 PIC-micro (Microchip)、750C89 (Philips)、2051CXNUMX (Atmel) ファミリの MK 用の開発ボードは、このようなデバッグ アルゴリズム用に設計されています。 開発ボードには、モニターと「連動して」外部コンピューター上で実行されるデバッグ プログラムが搭載されている場合があります。 これらのプログラムは最近著しく複雑になり、多くの場合、非常に専門的な一連のデバッグ機能 (シミュレーター デバッガーなど) や、純粋な形式の統合開発環境にのみ固有のさまざまな要素が含まれています。 キットには、実際によく使用される応用プログラムも含まれる場合があります。 「開発ボードとモニター」キットのデバッグ機能は、ESS のデバッグ機能ほど汎用的ではありません。 さらに、デバッグ処理中の MC リソースの一部は、モニターが動作するように選択されます。 それにもかかわらず、時間をロスすることなく適用システムのインストールとデバッグを開始できる既製のソフトウェアおよびハードウェア ツールの完全なセットが利用できるかどうかが、多くの場合、決定的な要因となります。 特に、そのようなキットのコストが、より汎用性の高いエミュレータよりも数倍安いことを考慮すると、なおさらです。 ROMエミュレーター ROM エミュレータは、デバッグ中のデバイスの ROM を RAM に置き換えることを可能にするソフトウェアおよびハードウェア ツールです。 標準通信チャネルの XNUMX つを介してコンピュータからプログラムをダウンロードできます。 これにより、ユーザーは ROM を複数回フラッシュするサイクルを回避できます。 ROM エミュレータは、外部プログラム メモリにアクセスできる MK プログラムのデバッグにのみ使用されます。 複雑さとコストの点で、このデバイスは開発ボードに匹敵します。 それには、多用途性という大きな利点があります。 ROM エミュレータはどの MK でも動作します。 最初の ROM エミュレータでは、マスター リセットを使用してプログラムをロード、実行、停止することしかできませんでした。 さらに、特定のアドレスに到達するとオシロスコープへのトレース信号をハードウェアで生成する複雑なモデルもありました。 このような製品のエミュレートされたメモリは表示および変更が可能でしたが、MK の内部制御レジスタを制御することは最近まで不可能でした。 最近、いわゆるインテリジェントROMエミュレータが登場しています。 これらを使用すると、ユーザーのボード上の MC の内部を「見る」ことができ、デバッグ制御においては VSE と同様です。Cactus は、実際にインテリジェントな ROM エミュレータを MK シリーズの VSE として提示することさえあり、どちらで動作するかを区別することは不可能です。実際には、この場合のプロセッサは交換されず、ユーザーの有償プロセッサが使用されます。 スマート ROM エミュレータは、通常の ROM エミュレータのハイブリッドです。 デバッグ モニターと、バスを別のバスに素早く切り替えるためのシステムです。 これにより、あたかもデバッグ モニターがユーザーのボードにインストールされているかのような効果が得られ、同時に、ソフトウェア ステップの小さな (約 4 KB) ゾーンを除いて、実質的に MK のハードウェア リソースを消費しません。 このようなエミュレータは、たとえば、8051 コアを搭載しているが、さらにさまざまな入出力デバイスが飽和しているすべての既存および将来の MK 向けに Fiton 社によって開発されました。 この製品は、Philips、Siemens のさまざまな MC をサポートしています。 OKI。 統合開発環境 厳密に言えば、統合開発環境はデバッグ ツールには含まれませんが、マイクロプロセッサ システムの開発とデバッグのプロセスを大幅に促進および高速化するこのクラスのソフトウェア ツールを無視するのは誤りです。 従来のアプローチでは、プログラム作成の初期段階は次のように構成されます。 ソーステキストはテキストエディタを使用して入力されます。 入力が完了すると、テキスト エディタでの作業が停止し、クロス コンパイラが開始されます。 通常、新しいプログラムには構文エラーが含まれており、コンパイラーはそれをオペレーター コンソールに報告します。 その後、テキスト エディタが再度起動され、オペレータは特定されたエラーを探して削除します。 同時に、コンパイラによって表示されるメッセージの性質に関するメッセージは、画面がテキスト エディタによって占有されるため、表示されなくなります。 このサイクルは複数回繰り返される場合があります。 また、プログラムが比較的複雑で、さまざまな部分から組み立てられており、編集や最新化の対象となる場合は、この初期段階でもプログラマーに多大な労力と時間を必要とする可能性があります。 大量の定型作業を回避し、それによってプログラマーの生産性を大幅に向上させるために、いわゆる統合開発環境 (シェル) の開発 (統合開発環境 IDE) が登場し、急速に普及しつつあります。 一般に、優れた統合環境は、利用可能なデバッグ ツール (インサーキット エミュレータ、ソフトウェア シミュレータ、プログラマ) を組み合わせ、プログラマに「ターボ」スタイルのプログラム テキストを提供します。 統合環境では、次のことが可能です。
最近、統合開発環境の機能は、最も「高度な」エミュレータやデバッガ シミュレータのプログラミング インターフェイスの一部になりました。 このような機能を使いやすいインターフェイスと組み合わせると、プログラマーの作業が大幅にスピードアップします。 したがって、デバッグ ツールを選択するときは、次の一連の指標を考慮することをお勧めします: サポートされるマイクロコントローラーのリスト、エミュレート/シミュレートされたマイクロコントローラーのリソースの制限、シンボリック デバッグの可能性、サポートされるコンパイラーのリスト、最後にサービス能力です。 著者：Yu.Zobnin、Sh.Kobakhidze、モスクワ
庭の花の間引き機
02.05.2024 最先端の赤外線顕微鏡
02.05.2024 昆虫用エアトラップ
01.05.2024
▪ TDA8939TH - クラス D デジタル パワー アンプをセットアップするためのリファレンス ソース
▪ サイトのセクション 労働保護に関する規範文書。 記事の選択 ▪ 記事 トラクターの診断および保守担当者。 労働保護に関する標準的な指示 ▪ ヘッドライト保護用品。 無線エレクトロニクスと電気工学の百科事典
ホームページ | 図書館 | 物品 | サイトマップ | サイトレビュー
www.diagram.com.ua |
他の記事も見る セクション 
科学技術の最新ニュース、新しい電子機器：
このページのすべての言語