Arduinoの質問に

適切な一貫性とエネルギーで実装された間違った決定でさえ成功につながります

そもそも、この投稿にはないものです。 LEDを点滅させるプログラムを書くのがどれほど簡単かという話はありません。 素晴らしい会社の素晴らしいボードをどこで、どの価格で購入できるかについての情報はありません。 この地獄の悪魔が現れる前の空の青さや、今のすべてがどれほど悪いのかについての話はありません。 また、このようなすばらしいソリューションが登場するまで業界がどれほど混oticとしていて、すべてがうまくいったという話もありません。 注目を集める写真すらありません。 私はこのすべてのためにここにいるわけではありません。Habréには同じような投稿が十分にあります（著者を怒らせるつもりはありませんが、他のことについて少し書いています）。



Arduino（A）が必要な理由、その方法、さまざまな問題が解決された方法、およびそれら（解決方法）を改善するために試行できる場所を理解する試みがあります。 間違いなく、異常な問題の議論に関連する価値判断、主観的な見た目、味、およびその他の喜びが多数あります。 さて、Aがいつもどこでもケーキではない理由と、それを（A）からケーキ（ケーキ）に変える方法についての議論があります（この問題を右側、つまり私のものから見ると）。



まず、専門フォーラムの非公開セクションで情報を検索せず、Aの開発者にインタビューせず、内部ドキュメントを読まず、他のインサイダー情報を使用しないことを直ちに予約します。 さらに述べられているすべての考えは、開発者の立場に身を置く試みであり、「もし私が大臣だったなら」というスタイルの反省です。 そしてもちろん、特定の経験の成果は、Aと、組み込みソフトウェア（Bまたはファームウェア）を開発するための他のシステムの両方の協力を得て、私は専門的に行っています。 まあ、私は前文が終わり、偏見の問題がadvanceりで事前に却下され、ビジネスに取り掛かることを願っています。



したがって、開発業界Bで実りある（つまり、少なくとも何かを行う）には、次のコンポーネントが必要です（本当に必要です。つまり、これがないと機能しません）。



1）Bが動作しているハードウェアプラットフォーム、

2）このプラットフォームでの操作のためにBを準備できるソフトウェアプラットフォーム、

3）このプラットフォームにこのBを配置できる通信コンポーネント。

4）このプラットフォームでこのBが機能するプロセスを制御する手段。



最初の3つのコンポーネントですべてが明らかであると思われる場合、通常、4番目のコンポーネントは少し見えなくなります。これはデバッガーでもモニターでもありませんが、それらの存在は大歓迎ですが、Bの操作を開始したりハングを制御したりする基本的なプロセスでもあります。 ニーズを決定したので、システムAでそれらを実装する方法と、より良い方法（当然のことながら、見知らぬ人はいないので）の実装を検討し始めます。



議論を始める前に、考慮すべきいくつかの重要なポイントがあります。 オープンソースからの情報、および私が知っているすべての情報がそれと矛盾しないと信じている場合、最初はAはプログラミングマイクロコントローラ（MK）の基礎を教えることを目的として開発されました。 そのため、主なタスクは、学生（つまり、未熟な人員）にとってできるだけシンプルなデバイスを入手することでした。



もちろん、経済的要因も考慮されましたが、決定的なものではありませんでした。 現在、Aの範囲は大幅に拡大しており、経済的要因も重要ではないプロトタイプとしてのDIYセクターと、状況が多少異なる完成したデバイスの両方で積極的に使用されています。 これらの側面を念頭に置いて、ナレーションを続けていきます。



1.ハードウェアプラットフォーム

システムは、電源を除き、完全な開発サイクルを確保するために必要なすべてのコンポーネントを含むボードです（一部の予約はありますが、後で検討します）。 後者はシステムAの外部に実装されており、接続するのに特別な困難はありません。場合によっては、キットに接続するか、スタンドアロンの標準接続ケーブルを購入するだけで十分です（USBケーブルは奇抜です）。



この時点で、5つを配置できます。つまり、必要なものはすべて揃っていて、デバイスを操作できます。



それでは、改善に移りましょう。なぜなら、ご存知のとおり、完璧には限界がないからです。 ボードAの主なコンポーネントはマイクロコントローラー（MK）であり、ここですぐに疑問が生じます。 このMKはどの基準で選択する必要がありますか？



まず、最小限のコストでソフトウェアを変更できる必要があります。これは、MKに簡単に変更可能な（紫外線消去可能ではなく、使用した、理解できる）プログラムメモリが存在することを意味します。これは明確にフラッシュであり、最小量である1Kまたは2Kは受け入れられそうにありません-Aでは4+で実装されます（かつて5でしたが、時間が止まりません）。



2番目は、MKアーキテクチャの選択です。 元々は高レベルのプログラミング言語（おそらくC）を使用する予定だったため、選択したMKのアーキテクチャ機能は、コンパイラの効果的な動作を妨げない限り、それほど重要ではありません。 このため、i8048などのハードウェアスタックが制限されているシステムは受け入れられません（これらのシステムでは、スタック言語の効率的な実装はほとんど不可能です）。



これらの2つの考慮事項は、私たちの時代でも選択の余地を狭め、10年前（アクセシビリティを考慮して）、2つの会社（Atmel（AVRファミリー）とMicroChip（PICファミリー）の製品の間で実際に選択があり、選択は最初の会社のために行われました。 この選択に対する私の態度は中立的であり、AVRは優れたチップを製造しますが、PICはそれほど悪くはありません（または、より良いのは好みの問題です）。 そして、特定のMKファミリを選択するという問題がありました。ここでは、I8051チームと互換性のある89ファミリを好むでしょうが、著者はよく知っており、MEGA AVRファミリからクリスタルを取得しました。 このソリューションには長所と短所の両方がありますが、それらの議論はより専門的な投稿（および絶え間ない聖戦）の主題ですが、ツリーのトップのみを調べます。



3番目の前提条件は、ISP（In System Programming）テクノロジの形式で実装されたMKのソフトウェア変更のシンプルさです。これにより、製品の構造的整合性の違反に関連する影響にさらされることなく、ボードの一部としてMK上のソフトウェアを変更できます（ロシア語、不必要に翻訳）ボードからMKを削除します）。 開発者が選択したものを含む、多くの水晶がこの要件を満たしています-固体5。



それにもかかわらず、MKはブロック内のボード上にあり（元のソリューションについて話している）、もちろん、交換することで可能性のある誤動作を見つけやすくします（そしてトレーニング目的でAを使用し、これに関連するすべての状況を考えると、この問題は間違いなく関連していました）、しかし同時に、誤動作のための追加の機会を作成し、デバイスのコストを増加させます。 QFPケースのパッドはDIPとPLCCの同様のデバイスを大幅に上回るため、このようなソリューションを維持すると、選択したMKの建設的な実装に特定の制限が課せられ、後者はブロックからMKを抽出するための特別なデバイスも必要とするため、DIPオプションが選択されました-5 -。



ボードAにはまだどのコンポーネントが配置されていますか？ まず、逆極性保護回路（シリアルダイオード）を備えたパワースタビライザーです。これは、過大な電圧または負の電圧でMKを簡単に奪って殺すことができないため、最初にスタビライザーを殺さなければなりません（ただし、これは特に難しいタスクではなく、繰り返し実装されています）。 主にUSBコネクタを介して電力を供給することを目的としていたため、このソリューションは確かに受け入れられます。



コンデンサー付きのクォーツ（非セラミック）共振器を使用すると、セラミック共振器と比較して非常に安定した（妥当な範囲内で）周波数を設定できます。



RCタイミングチェーンの形式の起動回路（ただし、何らかの理由で放電ダイオードがない場合、トレーニングモードでの電源の機能を考慮しているものの、特に必要ではありませんが、常に電源が入っているデバイスの実装には、クローンAも必要です） ）電源をオフにせずにデバイスを再起動できる追加のボタンと、コンデンサ絶縁を介したプログラマーからの追加のリセット信号を使用します（後者については後ほど説明します）。



すべてのMKコンタクト（サービスコンタクトを除く）に追加のデバイス（シールド）を接続するためのパッドと、電源およびリセット信号が出力されます。



ボードAのさまざまなノードの電源とアクティビティの存在を示すLED、および多数のマニュアルで点滅することが提案されている汎用LED。

一般に、必要なものはほぼすべて必要なので、5-と入力します。



そして、最後になりましたが、重要なこととして、ハードウェアコンポーネント-プログラマーに進みましょう。 まず第一に、一般的なプログラミング手法についてのいくつかの言葉。



MKでのマルウェアのダウンロードは、ハードウェアローダーを使用して（または組み込みのまま呼び出す）、またはソフトウェアを使用して（外部で呼び出しましょう）行うことができます。 ここでの用語の問題は決して単純で曖昧なものではありませんが、話していることに同意する必要があります。



ビルトインブートローダーの主な違いは、その機能の可能性がMKの生産段階で提供され、ユーザーが変更できないことです（むしろ、変更することはできますが、このプロセスは重要であり、可逆的です）。 これは、実際のハードウェアモジュールでも、プログラムメモリの特別な領域にあるソフトウェアモジュールでもかまいません。 いずれにせよ、組み込みのブートローダーが機能している間は、通常のMK操作（ユーザープログラムの実行）はできません。 純粋にハードウェアブートローダーを検討する場合、次のインターフェイスに基づいて実装できます（必要な連絡先の数が減少する順）JTAG、（4/5 + 1（0））、SPI（3/4 + 1）、SWD（2+ 1）、DebugWire（1）、もちろん、グラウンドをカウントせず、入力Reset（+1）が与えられます。 これらのインターフェイスはすべて、MKリソースへの完全なアクセスを提供し、一部は引き続きBの実行を制御するために使用できます（デバッグ用）。



また、動作中の外部ブートローダーに近い組み込みソフトウェアモジュール（いわゆるブートローダー）を実装することもできますが、多くの違いがありますが、ハードウェアのものよりも一般的ではありません（これはAが作成された時代に当てはまりましたが、現在は状況はそれほど明確ではありません） 。



外部（ソフトウェア）ブートローダーは、操作の点でBと区別できない特別なソフトウェアであり、プログラムメモリを変更するためにMKの特別なハードウェア機能を使用してMKリソースにアクセスします。 この場合、必要な情報は、MKの一部であるUART、USB、イーサネット、ワイヤレスインターフェイスなどの標準インターフェイスを介して取得されます。 このオプションを実装すると、解決できないだけでなく、それらの存在を知る必要がある多くの問題が発生します。 その中には、Bの共同機能とプログラムメモリの変更プロセスの保証、プログラミングプロセスで障害が発生した場合のプログラム情報の整合性と復元の監視、ローダーからメインプログラムへの制御の転送の問題があります。 最後の質問をもう少し詳しく検討しますが、今のところは2つのアプローチの長所と短所についてです。



組み込みのブートローダーの利点は何ですか：



1）殺すことはできません。つまり、ユーザーは、特別な非自明な手順なしにそれを使用できないようにすることはできません。 質問に答えたユーザーの中には成功したと主張する人もいますが、これは利用可能な機器が限られているためにのみ可能であると信じています。 個人的に、私はかなり長い間Atmel MCで作業しており、簡単ではありませんがクリスタル全体を殺すことは可能であると全責任をもって宣言しなければなりませんが、デバッグインターフェイスを「破損」させることはできませんでした（物理的な損傷の場合は考慮しません）。



2）メーカーによって標準化されており、原則としてドキュメントに非常に詳細に記載されています。したがって、水晶メーカーとサードパーティの両方からのプログラミングデバイスとブートプログラムにはかなりの範囲があります。 それらがあなたに合わない場合は、ByteBasterデバイスと自作プログラムに基づいて以前に行ったように、独自のプログラミングシステムを作成できます。



3）Bのロード機能に加えて、他の目的、特にターゲットプログラムのステータスの監視、Bのデバッグに使用できますが、この機能はどこにも実装されていません。



4）プログラムメモリの特別なセクションにあり、ライブラリとして機能するためのターゲットプログラムへのアクセスを提供できます（Cubeで行われます）。リンカーの観点からは特定の困難がありますが、それらは完全に解決可能です。



今、欠点について少し-それらのいくつかはありますが、それらは、すなわち：



1）それは不滅であり、したがって、修正不可能です;これから生じる欠点は明らかですが、それほど重要ではありません。 本当にブートローダーが必要な場合は、常にダブルブートに頼ることができます-最初に、組み込みのブートローダーを使用して、セカンダリ（ご使用の）ブートローダーをロードして実行すると、必要なすべてが実行されます。 確かに、ページ構成のフラッシュメモリの場合、MKリソースを削減する二重消去が必要になる場合がありますが、これは非常に重要であり、この事実は重要ではありません。さらに、内蔵ブートローダーの結果を使用して対応するページを消去できます。 要約すると、この方法はお勧めしません。形式を組み込みのブートローダー形式に変換し、受信したデータを標準モードで転送する外部プログラムを使用する方法が望ましいようです。



3）モニタリングに使用できますが、同時に特別な措置が講じられない限り、ユーザーデバイスとの通信にインターフェイスが利用できなくなりますが、私は個人的にジャンパーを解決策とは考えていないため、Aで行われません



4）プログラムメモリにあるため、特定の状況で問題になる可能性のあるターゲットプログラムの場所を奪います。



2番目の興味深い質問は、コントロール転送の観点からのブートローダーとターゲットプログラムの相互作用です。これは、MKが常に新しいコンテンツの読み込みから始まるとは限らないためです。 この問題の解決策は、ブートローダーを使用するという選択されたパラダイムのフレームワーク内にあります。 流域は、最初のインクルージョンのラインに沿って通過します-機能を開始するものをオンに切り替えた瞬間にメインプログラムまたはブートローダーを選択します。これには、MKコンフィギュレーションフットなどのハードウェアリソースが必要になります。再び外部信号の制御下で、または通常は外部インターフェースの非アクティブ期間である特定の条件に達したときに、ターゲットプログラムに制御を移すことを決定する必要があります。 これらの方法はどちらも欠陥がないわけではなく、悪いものと最良のものではないものとの選択を表しており、外部ブートローダーにのみ固有のものです。



Aで問題を解決したことがわかりました。ここでは、非アクティブの遅延後にユーザープログラムに移行する外部ブートローダーのオプションを採用しました。情報フローのチェーンはUSBから始まり、UARTになり、MKに進み、ブートローダーによって処理されます再プログラム可能なメモリMK。 このソリューションをより詳細に検討してください。



USBインターフェースの選択は、間違いなく開発者の幸運です。現時点では事実上の標準の周辺機器インターフェースであり、ほぼすべての可能なデバイスが装備されているため、Aモジュールのパワーを整理するという観点からも優れたソリューションです（5+）。



FTDIチップ上のプログラミングインターフェイスへのコンバーター-ここでの私の態度はやや複雑です。 もちろん、このクリスタルは市場のこのセグメントのトーンを設定しましたが、ブランドバージョンは低価格で違いはなく、多くのクローンがブランドドライバーと衝突しました（会社がOSの標準シリアルドライバーを好きではないことを誰かが理解していれば、情報を共有し、私はそのような解決策を理解できません）。 しかし、それは下り坂になりました-ビットごとの操作モードはこのクリスタルの利点に起因するものではなく、シリアルポートは簡単になり、次の実装につながりました。



同時に、専用ドライバーへの依存の欠如がポップアップします-ブートローダーがMKのどの状態からでも起動するように、UARTから情報を追跡するための信号を供給することによりシステムの再起動が使用され、他のコンバーターのクローンAが不安定であるため、非標準的な方法で実装されます（厳密に言えば、一般的に動作しませんが、ボード上のリセットボタンで解決できます）。



実装のもう1つの欠点は、再起動後、ブートローダーが常に動作を開始し、待機後に直接終了することです。この間、ブートに直接関係しないすべてのピンが3番目の状態になり、機能上の特定の問題につながる可能性がありますレベルに敏感な回路の設計中に外部プルアップ抵抗器が配置されていない場合、接続されたデバイス。



プログラミング用の交換デバイスとしてのシリアルポート-標準インターフェイスが使用されます。これにより、ローダーを備えた1つのデバイス（+）を介してターゲットプログラムとの通信チャネルを実装できますが、このインターフェイスを使用して外部デバイスと通信することは困難です（-）。



既存の実装を確認したので、改善された実装を提供できます。同時に、USBインターフェースを保存し（良いものを探していません）、標準のOSドライバーを使用する機能を実現し、

少なくとも2つのインターフェイスでMKとのやり取りを整理します-ブート用のSPI（MKの組み込みローダーを使用）とターゲットプログラムとのやり取りのためのUART、両方ともユーザーのコマンドとしてドライバーを無効にする機能、I2C、1wire、SWDなどの追加インターフェイスの実装（追加のハードウェアを必要としないすべての人）。実装されたすべてのインターフェースについて、監視機能が非常に望ましいため、ボードをマイクロラボの基盤に変えます（ANDと呼びましょう）。これらすべてのウィッシュリストを標準のインターフェイスコンバーターのチップに実装することはほとんど不可能です。したがって、PCへのインターフェイスは、USBを内蔵した安価なコントローラーに基づいています（1つのMKには既に同様の実装がありますが、インターフェイススタイルのみを保持しています）。



このオプションの代替策は、既存のものと同じ外部ブートローダーを実装することですが、同じチップ上にインターフェイスコンバーターとターゲットMKの両方であり、ボードの重量とサイズとコスト特性を改善できますが、ここではそのようなブートローダーに固有の欠点を考慮し、それらをできるだけ弱くする必要があります、標準インターフェイスの監視も困難です。



Aで私が本当に嫌いなのは、機能3と4に関連する独立した機能（オンザフライでの作業）の間に常に需要があるとは限らないコンポーネントのボード上の存在です。そのようなコンポーネントは常に（ほぼ常に）外部のプログラミングデバイスと接触しますが、この場合、私は個人的にそれらはいくらか冗長であると考えています（FTDIチップ）。これはコスト、ボードサイズ、およびデバイス消費の増加につながります。ボード上のミニUSBコネクタの存在は大きな問題になります-電源を供給するだけですが、ここでそれについて考える必要があります。



原則的に言えば、プログラマーを別のデバイスとして作成することになります。これにより、ユーザビリティがある程度低下するため、ボードのコストとサイズが削減されます。ちなみに、他の多くの開発システムBは特定のハイブリッドを実装しています。組み込みのプログラミングデバイスを備えたボードの拡張バージョンと、拡張バージョンが使用される制御のためのボードの切り捨てバージョンがあります。そのため、特に、評価セットでTIを使用します。おそらく、そのようなオプションはいいでしょうが、実際のデバイスの基盤としてボードを使用するオプションについてのみ、トレーニングの目的で、このアプローチは明らかに不便です。



さて、機器のレビューが完了したようです（何かを忘れた場合、コメントで思い出してください）、今は開発環境Aについて少しです。これはGCCコンパイラのシェルとして構築されており、もともと訓練されていないユーザーの作業を促進することを目的としていました。シェルは少し構文的な砂糖を実装し、Cプログラムの作成で実際に行われるいくつかのルーチンアクションの必要性を排除しますが、同時に、すべての欠点を備えた標準のプリプロセッサとコンパイラの使用に制限されます。さらに、ユーザーにはMK機器とのやり取りを容易にする標準ライブラリが提供され、それらへのインターフェイスが説明されています。これらのライブラリの品質が議論の対象になる可能性があることに注意してください（ピン管理のトピックに関する私の投稿を参照してください。しかし、それらはあなたが何かをすることを可能にし、予定の要件が実装されるように、4を置きます。



Aは独自のプログラミング言語Wiringを持っているという一般的な意見があります。マーケティング担当者による不当な発言に起因する誤解に過ぎず、ライブラリへのインターフェースしかない。残念ながら、高度なメタプログラミング機能を備えたプリプロセッサの導入は非常に役立ちます。また、機器を操作するいくつかの機能は、標準Cよりもはるかに簡単で信頼性が高いため、この位置で



このアドオン言語で非常に役立つのは、ハードウェア設定の一般化された記述と、そのような記述（STキューブのようなもの）の視覚化ツールを備えた特定のMKに必要なコードの生成ですが、そのような製品の作成は明らかに開発者の意図（そしておそらく機能）を超えた手段ですプラットフォーム。事実、近年、互換性のあるシステムがさまざまな企業の結晶に登場しています。これらはSTMとTI、およびESPやIntelなどのエキゾチックなシステムです。そして、私にとって後者についてすべてが明確な場合-市場がなく、そのようなコネクタとSUCH価格を備えたA互換ボードは必要ありませんが、SUCH機能を備えている場合、残りの言及されたものは組み込みハードウェアユニットとその機能の点で元のAクリスタルと比較して有利です（低コストを維持）、しかし、この世界のすべての費用を支払う必要があり、そのようなブロックを正しく使用するには、ドキュメント（このオプションを素晴らしいとマークします）またはAとは完全に異なるレベルのライブラリを注意深く調べる必要があります。



開発環境とハードウェアの相互作用-プログラミングプロセス自体は悪くありません（ドライバーに関するコメントを考慮して）、受け入れられたパラダイムを考慮してブートローダーをカスタマイズすることができます-5、エラーメッセージの情報内容の欠如、および標準配信でのプログラム可能なデバイスのタイプの検証の欠如



ただし、プログラムの作業を管理するだけでは十分ではありません。ターゲットMKプログラムの状態に関係なく、いつでも再起動することができます。提供されていないため、標準のデバッグインターフェイスは関係ありません。一般に、このような場合、礼儀から、デバッグツールは複合体に存在すると言います-堅固な3-（すべての評価は5段階で与えられます）。



さて、投稿の最後に（締めくくりの時間で、すでに計画していた以上に判明しました）読者が提起したはずの質問に答えたいと思います-私は賛成か反対かです。当初、私は客観性を維持しようとすることを少し示唆したようですが、誰の方向に向かうのでしょうか？だから、私はAの憎しみや崇拝者のどちらにも属していません。一方から、Aの使用はプロフェッショナリズムと両立しないという声明があります一方、温度センサーからデータを読み取るためのスケッチを書いた人は（原則として、書いていない、既製のソリューションを使用したユーザー）は、プログラミング全般、特に組み込みシステムの分野で彼のスキルをさらに向上させる必要はありません。



真実はいつものように真ん中にあり、非常に優れた特性を持ち、Aが特定の複雑さのデバイスを迅速に構築できる優れたエントリーレベルキットであり、サブジェクトエリアの開発を開始するための優れたプラットフォームである（ここでも、私の意見では）しかし、このプラットフォームの制限を十分に理解し、長い階段の最初のステップで停止する必要はありません。



PS。 組み込みプログラミングのコースを作成することを考えています。その不可欠な部分（最初のコース）は修正されたArduinoボードであり、そのようなプロジェクトに対するあなたの態度は調査で表しています。