トレンドの問題へ

「どこから始めたらよいかわからない場合は、最初からやり直してください。ほとんどの場合、間違いはありません。」

ですから、最初はアマチュアエレクトロニクスの設計とプログラミング（「Arduino」と言ってクラスを辞めるために）を専門とするサイトの1つに関するトピックがありました（言葉はありませんが、たくさんの言葉があります）。このようなプロファイルのサイトは、特定のハードウェアプラットフォームでの特定のライブラリ（ベビーエレファント、つまりLiquidDisplayI2Cでしたが、指で指すことはありません）の低速動作専用でした。 トピックは面白そうで（通常の読者は速度が私の流行であることをすでに理解していました）、それについて議論することで（同様のリソースでよくあることですが）すぐにバナナ投げに変わり、誰が本当にクールなマッチョで誰が1分が経過し、技術的な側面がごくわずかな量に変わったため、この問題の独立した研究が行われ、その間にいくつかの興味深い状況が明らかにされ、尊敬されている人々の注目を集めました。



調査中の問題を明確にします-できるだけ少ないMKレッグを使用して、パラレルインターフェイス（この場合は別のデバイスである可能性がありますが、インジケーター1602）を使用してデバイスとの相互作用を確立する必要があります。 0（ゼロ）レッグを介した相互作用は実装が不十分なアプローチのように思えるので、必要な最小は1（1）レッグとして認識される必要があります。



このような実装が行われ、WS2181を思い出すだけで十分ですが、情報をエンコードする合理的に実行可能な唯一の方法は時間操作であるため、このアプローチの速度は理想からはほど遠いでしょう。 このアプローチの実装の成功例は数多くありますが、特にUSBおよびイーサネットインターフェイス-高速な単線インターフェイスに注目することができますが、最小限のコストで比較的簡単にハードウェアで使用できますが、非常に遅い1ワイヤです。



2（2）レッグの使用を開始すると状況が根本的に変わります。これにより、クロック信号とデータを分離した古典的なスキームを使用できるようになり、大幅なハードウェアコストなしで速度を上げることができます。 実際の候補は、送信モードのSPIとI2Cです。 残念ながら、実際には最初のピンは2線式ではなく、特定のデバイスを選択するために1つ以上のピンが緊急に必要です。または、カスケードデバイスを使用して、対応するチャネル帯域幅を減らす必要があります。 さらに、SPIはハードウェアレベルでの配信が保証されたチャネルではないため、常に（より正確に言えば、常に）便利ではありません。 この点で、2番目の候補者は、組み込みのアドレス指定と送信制御を持っているため、望ましいです。 唯一の欠点は、伝送速度が遅いことです（ユニットに対して高速モードで100 kHzまたは400 kHzまたは数十MHzでも）が、この世界のすべての費用を支払う必要があります。 さらに、接続されたデバイスの機能を考慮すると、パフォーマンス情報を表示するには、100 kHzでも1秒あたり10キロバイトで十分です（9600の速度に相当し、24 * 80ディスプレイでかなり高速の画像を表示します）。 両方のインターフェイスは、ほぼすべてのMKの標準セットに含まれています。何らかの理由でハードウェアリソースを使用できない場合、通常のピンに簡単に実装できますが、再び速度が低下するか、プロセッサの負荷が増加します。 したがって、I2Cインターフェースの選択は、私たちのタスクにとって非常に正当で合理的であると考えることができます。



次に、インターフェイスが両側に固定されているため、コンバーターチップを選択するという疑問が生じます。いわゆるI2Cポートエクスパンダーが必要です。このチップはNXPによって提供され、PCF8574と呼ばれます。 Mxxは手頃な価格であり、市場で広く紹介されており、そのベースに基づいて、デバイスの設計機能を考慮してディスプレイインターフェイスとインターフェイスするボードが既に構築されているため、この選択が正当化され、1つの機能がありますが、それについては後で詳しく説明します。



それまでの間、マイクロサーキットの選択に関連する最初の驚きについて世界に伝えたいと思います。 実際には、指定された会社に加えて、TIは同じ名称で同様のmxxを作成しています。 さらに、少なくとも3種類のケース（DIP16、SO16、SSOP20）の脚のレイアウトは、両社で同一です。 すべてが順調であるように見えます。2番目のサプライヤを用意することは常に素晴らしいことですが、悪魔は細部に隠れて注意を払っています。 まず、NXPチップのドキュメントを見てみましょう。すべてが明確に明確に記述されており、シリアルインターフェイスを操作するアルゴリズムは標準と完全に一致しています。 1つの通信セッションのフレームワークでデータを繰り返し記録できることに注意してください。これは後で非常に役立ちます。 また、説明の14ページにも注意してください。ここでは、他のタイプの超小型回路（この特定の超小型回路には100 kHzの制限があります）に移行してパフォーマンスを改善する方法を示します。 要約すると、このような明確で包括的なドキュメントを提供してくれた会社に感謝します。



さて、今悲しいことについて。 TIチップのドキュメントを開き、すべてが方向を変えました...実際、フォーラムでは、交換頻度を400 kgHz、さらには最大800 kHzまで上げることができると投稿しているため、可能な限り高い交換レートとの混乱を明確にするためにそこに行きました実際、それは640 kHzでしたが、何らかの理由で1 MHzが機能しませんでした。NXPのドキュメントで最大周波数100 kHzが明確に示されており、技術仕様を超えようとする試みは常に不承認であるため、 、まあ、そのような 私は習慣です。 したがって、TIオプションの方が高速になる可能性があることを示唆しました。 これはそうではなく、その動作も100 kHzの標準速度でのみ保証されていることが判明しました。これは明確に規定されています。 さらに、標準モードに加えて、高速モードの負荷抵抗の計算が存在することに多少驚きましたが、明らかにこのセクションは単にI2Cに関連するマイクロ回路のドキュメントをローミングしているだけであり、このリファレンスセクションは何も約束しません。 魚やノミについての冗談を連想させるが、致命的ではない。



しかし、その後、機能の特徴の説明が始まる12ページに目が行きました。 そして、おもしろい定式化を見つけます。「データバイトには、デバイスによって発行された確認信号が付随しています。 他のデータバイトがマスターによって送信され、確認が続く場合、それらはデバイスによって無視されます。 データは、合計バイト数が受け入れられ、確認された場合にのみ出力されます。」-翻訳に誤りを犯した場合、それほど多くはありません。 それはやや不可解に聞こえます-合計バイト数は何バイトになり、マスターによって発行されない場合はどうなりますか？ 幸いなことに、13ページには、説明ページの代わりに1つの適切な一時的な場所が使用されるため、明確にするためのタイムラインがあります。 しかし、この場合ではありません-最初に、後続のバイトが無視されないことは明らかですが、テキストで示唆されているかのように、少なくともデバイスによって確認されます。 さらに、2番目のバイトのデータは出力に明確に関連していることがわかります。これは、2番目のバイトのデータが最初のバイトと同じ指定、つまりP0〜P7を持っているためです。 第三に、データがパラレルポートに出力されるのは2番目のバイトを受信した後です。これは、前述のように、何らかの理由でPではなくBとして指定されます。 不明な理由により、出力とともに、ポートAの値が変更されます。これは、デバイスアドレスの可変部分を設定するように設計されています。 サイクルの最後に設定され、デバイスから電源が切断されるまで、明らかにハイレベルのままである割り込み信号に特に満足しています。 そして今、私たちは質問をします-この未知のゴミとは何ですか、私が見たものの他の定義はありません（ただし、「ゴミ、廃棄物、ソドミー」です）。 なぜ2番目のバイトが必要なのか、どこから来たのか、出力ポートが1つある場合、その中に何があるべきなのか、最初のバイトの5番目のビットが1に等しいのはなぜか、2番目のバイトが送信されない場合はどうなるのか、その他多くの興味深い質問があります。



私はこれらの質問に答えがなく、推測と推測の不安定な立場にあり、評判の良い会社が私をそこに連れて行く必要がある理由を理解していません。 一連の矛盾した発言を見ると、3人のカメ（またはアリ）についてよく知られている冗談を思い起こさせます。 研究所の後の最初のボスが言ったように、私たちはこのシャレードを解決しようとしますが、まったくそうする必要はありません。「あなたが勤務時間中に支払われないことをするとき、あなたは支払われることをしません」この投稿は勤務時間外であるため、このような仕事からの注意散漫を許します。

個人的には私にとってより魅力的な最初のオプション-実際、マイクロサーキットはNXPのガールフレンドとまったく同じように機能し、16ビットの兄弟pcf8575からこのデバイスに一時的なハックを誤ってブロードキャストした曲がったテクニカルライターのために、すべての混乱が生じました、さらに、彼女への質問もあり、まったく同じです。 その後、さまざまな企業のデバイスに互換性があり、すべてが正常です。正しい説明を使用するだけで、間違った説明についてはTIフレンドリーな「FU」としましょう。



デバイスが一時的な出入り口に従って動作し、説明どおりに動作することを信じる必要があるため、それを呼び出すことができ、出力ポートに1バイトを書き込むには2つを送信する必要があり、2つ目はエンドマーカーとして使用されるため、2番目のオプションはより悪いです伝送。 このような絶妙なソリューションの唯一の説明は、前述の16ビットデバイスとの互換性を確保したいという願望かもしれませんが、「Aと言って、アルファベットの残りの文字を言う必要がある」と言うように、24ビットバージョンと104ビットおよび内部レジスターを備えたデバイスもあるため、すべての場合に単一のプロトコルを作成し、1バイトを書き込むために20個、できれば25個のピース​​を転送します。そのうちの24個は空で、将来のバージョンと互換性があるように設計されます。 同時に、テクニカルライターの曲率に関する仮定は依然として有効です。なぜなら、8ビットバージョンと16ビットバージョンでの機能の説明は明らかに異なるためであり、16では理想的ではありませんがはるかに健全ですが、8では単純にひどいです。



開発者が疑わしい利益のために非常に最適な決定を下したという事実に加えて、このオプションが最初のオプションよりも悪いのはなぜですか（つまり、私は間違いなくそのような決定をしたことはないでしょうが、おそらくすべてを知っているわけではありません）-同じ指定、同じ目的、同じ脚のレイアウトであり、同時に異なるアルゴリズムに従って動作します。 そして、私はSOが可能であることを知りませんでした。 純粋に理論的には、両方のバージョンのデバイスで正しく機能するアルゴリズムを書くことができます。これは好奇心reader盛な読者のための演習として残しておきますが、松葉杖はarbitrarily意的であっても生きた脚に取って代わることはありません。 この場合の推奨事項は、TIのデバイスの存在を単に忘れて、正しいデバイスと正しい説明を使用することです。ちなみに、アリはNXPのみと取引しているという事実に基づいて、この推奨事項はやや遅れています。



TIのドキュメントは、「最初のページではまだスズメの餌と見分けがつかないほど混ざっており、すでに忘れられていました。これは、学者の目覚めた考えに興味があるかもしれないこの重要なオブジェクトではなかったからです」、ライブラリ自体の分析に進むことができます。機能を加速するために。 最初に、最適化の主な方向を決定します-100、400、640、800、1000 kHzの速度ではデータのバイトを送信するために少なくとも9ビット間隔が必要であるため、機能全体の時間を決定するのは送信時間です。 1バイトパケットの送信中にインターフェイス周波数が1 MHzであっても、8 MHzの周波数で8 * 9 = 72のプロセッサ命令を実行できるため、インターフェイスを介して送信されるバイト数の減少につながるプログラムのほとんどすべての複雑さが正当化されます。 同様の立場を明確にする考慮事項が1つありますが、それについては後で詳しく説明します。



ソーステキストを開き、多くのシェル関数を実行します（プログラマの給料は関数シグネチャの数に依存するようです）。 たとえば、public init関数はprivate関数init_privateを呼び出し（それ以外は何もしません）、public beginメソッドを呼び出します-なぜこれを行っているのかはわかりませんが、おそらくすべてを知っているわけではありません。 データは書き込み関数によって書き込まれ、コマンドはコマンドです。コマンドはsendメソッドのラッパーであり、write4bits関数を呼び出し、expanderWriteおよびpulseEnableを呼び出し、expanderWriteを使用し、printIIcを呼び出します。これは、TwoWireクラスのwriteメソッドの代わりにインターフェイス自体と連動しますそのソースコードはWireファイルにあります（これは明らかなソリューションです）。 expanderWrite関数を慎重に検討し、期待どおりの結果を見つけます-データの各バイトは、独自の開始ビット、アドレス指定、および停止ビットのコマンドとともに送信されます。つまり、チャネルの1 + 9 + 9 + 1 = 20ビットが8ビットの情報の送信に使用されますレベル、明らかに最適なソリューションではありません。



ところで、プログラミングスタイルの1つの考慮事項-C言語を習得したとき、ファッションは古いスタイル（関数シグネチャなし）と呼ばれるものでした。このスタイルはFortranから発展したものであり、このアプローチには明確な利点があります。それ以外の場合、コードは単にコンパイルされなかったため、関数を複雑度の高い順に並べることを強制されました。 ファイルの最後に、メイン関数を見つけるのが自然であったため、このアプローチは論理的に完了しました。 そのため、実装を検討する際、これで使用される関数のコードを探すのが自然でした。テキストの上位にあり、最上部にライブラリの有効性を決定する基本関数（この場合は出力関数）がありました。 署名の使用をまったく拒否することは強くお勧めしませんが、このような呼び出しが有効になることはほとんどありませんが、署名があったとしても、誰も関数の実装を任意の順序で配置することを強制することはありません。 ）および問題のライブラリで作成されます。



そして、Arduino環境の関数シグネチャに関連するもう1つの興味深い状況です。 関数プロトタイプの作成を忘れると、このエラーが明らかにない行のエラーについて、コンパイラーから非常に奇妙なメッセージが表示されるリスクがあります。 実際には、環境には関数のプロトタイプが必要であり、指定しなかった場合、プリプロセッサはエラーメッセージを表示せず（単純すぎてこれはArduinoスタイルではありません）、署名自体を生成し、プログラムの最初に配置されますエラーメッセージの行番号をシフトします。 関数がカスタムタイプを使用している場合、シグネチャは定義される前に配置されるため、エラーメッセージは保証されます。 非常に便利ですよね、昔のジョークを思い出します。「正しいこと、間違っていること、海軍のやり方-何かをするには3つの方法があります。」



転送の実装に戻りましょう-データの各バイトにアドレスバイトが付随しないという事実により、20/9 = 2でパフォーマンスを改善する方法がすでにあります。もちろん、この見積もりは上からであり、正確な計算は6 * 20 /（11 + 6 * 9）= 120/65〜1.8倍ですが、これはほんの始まりです。



続行するには、デバイスに接続されているインターフェイスの説明に目を向け、画面とのインターフェイスを検討する必要があります。 これには4または8ビットのデータ（この場合は4）を含めることができ、トラッキング信号を交換できます。その中で、動作確認ストローブであるEN信号が重要です。 4ビットのデータのみが使用されるため、情報バイトの送信には2つのニブルの転送が必要になりますが、これは少なくとも8 + 1 = 9の出力ポートを必要とするため、容量を増やすことで削除できますが、このチップでは不要です、しかしそれについては後で。 ストロボを形成する必要性を考慮するために、問題のライブラリが最初にセットアップされ、次に記録パルスのリーディングエッジとトレーリングエッジが安定したデータで形成されるため、インターフェイスを介した3バイトの転送が必要です。 一方、ディスプレイインターフェースでドキュメントを注意深く読むと、リーディングエッジでのみ安定したデータが必要であることがわかります。したがって、トレーリングエッジの形成を次のデータの形成と組み合わせることができます。念頭に置いておくべき唯一の状況はリセットすることですセッションの終わりにストロボは低くなりますが、これは必須ではありません。



私の意見では、明らかな変更の提案の結果、端末デバイスに送信される1バイトあたりの必要な送信時間が120ビット間隔から1 + 9 + 4 * 9 +（+ 9）+ 1 = 47（56ビット間隔のストローブのリセット）の場合、速度の合計増加は2倍以上になります。問題のライブラリの作成者がこれを行わなかった理由-おそらく、以前のソリューションをディスプレイに直接接続して使用し、変化する条件に適応させる必要はないと考えたが、無駄だったためです。



それにもかかわらず、ソースコードにあるように、インタラクションが実装された場合でも、転送レートは100/120 = 0.83キロバイト/秒（送信バイトあたり1.2ミリ秒）である必要があり、これはデータ転送レートと非常に匹敵するという事実に注目しますシリアルポート9.600 / 11 = 0.87キロバイト/秒で、画面を再描画するのに十分なはずです16 * 2 = 32文字。一方、元の投稿によると、バイト転送時間は1.5ミリ秒であり、これは予想よりもやや（25％）短くなっています。したがって、研究を継続する必要があります。



そして確かに、PulseEnable機能を再度検討し、1μsのアクティブゲートレベルの形成後、および50μsでのゲートの除去後、PulseEnable機能の遅延を見つけます。これらの遅延の必要性は、プラグインディスプレイの技術要件によって説明でき、パラレルインターフェイスを介した直接の相互作用を備えたライブラリでは非常に適切でしたが、この特定のケースでは、次のコマンドがアドレス指定フェーズで開始されるため、少なくとも最初の遅延は完全に冗長です少なくとも1 + 9 = 10クロックサイクル、したがって、達成できない1 MHzの周波数で10 * 1 = 10μs。この間、ディスプレイに供給される信号の変化は保証されません。しかし、2番目の遅延では、もう少し複雑です。100kHzの周波数では、アドレスバイトによる保証遅延は10 * 10 = 100μsです。しかし、別のより高速なインターフェイスエクステンダーで非常に可能性のある400 kHzの周波数では、2.5 * 10 = 25μsだけが問題になりますが、入力データを変更し、画面入力でストロボを削除することは、別のインターフェースバイトと50マイクロ秒が保証されています。これは、両方の遅延を削除できることを意味し、各データバイトの転送で2 * 50 = 100μs節約できます。各データバイトの転送で2 * 50 = 100μs節約できます。各データバイトの転送で2 * 50 = 100μs節約できます。



つまり、1バイトのデータに必要な推定転送時間（2ニブル* 3ステージ= 6送信バイト*（1 + 9 + 9 + 1）クロックサイクル= 120クロックサイクル* 10マイクロ秒/クロックサイクル= 1200マイクロ秒+ 100マイクロ秒= 1300マイクロ秒）のライブラリバージョンがありました、これは観測された1,500マイクロ秒とよく相関し、必要な時間のバージョンになりました2ニブル* 2ステージ= 4送信バイト* 9クロック/バイト= 36クロック+（1 + 9 + 1）クロック= 47クロック* 10マイクロ秒/クロック= 470マイクロ秒2.6倍高速。



理論的な部分は終了し（ソーステキストを分析することでできることはすべて完了しました）、私たちの研究を実践でテストするときです（ある程度、マルクス主義者であり、「実践は真実の基準」であることに同意しますが、このフレーズは数学には適用されませんが、プログラミングに非常に適用可能です）。ソースと変更されたコードをArduinoボードにロードし、オシロスコープを使用して、相互作用信号の結果の時間パラメーターを確認します（最近、私が要求している会社からのマイクロ回路のドキュメントで、「一時ACパラメーター」の魅力的な定義が提案されました。同様の用語を採用するためにやや時代遅れです）。



私は元のボードを持っていないので、解決策を探す必要があり、完全に魅力的なオンラインシミュレーションプログラムcircuit.ioを使用するようになりました。Arduinoボードを持っている人にも強くお勧めします。このプログラムは、ライブボードでのデバッグよりも優れています。このプログラムは、デバッグ環境でブレークポイントを設定し、ステップバイステップデバッグを実行し、プログラム変数の値を表示することさえできるため、ソースコードからファームウェアをはるかに高速化するためです。元のArduino環境で働いていた人は、私がここで賞賛することを理解するでしょう、残りは戸惑いながら肩をすくめることができます。もちろん、私はこのプログラム（特に、その構成におけるオシロスコープ）についても主張していますが、この記事ではまったく異なるものの欠点を説明することに専念しています。



そして、ここで私たちは理解できない待ち伏せに直面しています（私たちの研究の最初の方法ではありませんが、その予期しないために二重に不快です）、つまり、修正されたモジュールのパフォーマンスは、メッセージフラグメント間に遅延があるため、つまり、開始ビットの後、コマンドバイトの後、および各データバイトの後、約40マイクロ秒、合計送信時間はほぼ40％増加します。元のプログラムのエミュレーターで実行すると、同じ追加の遅延が表示されます。



私たちは何が起こっているのかを扱い始めます。まず、TWIインターフェースに関連する部分で、ボードで使用されるMK、すなわちATMega32のドキュメントを調べます。私はすぐに、一般的に私はドキュメンテーションについて苦情を言わない、すべてが明確に、明確に、そして詳細に記述され、他の人が持っているようなものではないと言う必要があります。ただし、それでも、表119の290ページで、インターフェイスの動的特性を決定するときに、やや奇妙な現象が見られます。つまり、スタートパルスの形成中に信号を確立および保持する時間の最小値のみが示され、最大値にダッシュが設定されます。この要件の組み合わせは、入力信号を記述する際に完全に自然ですが、この場合には出力ドライバーもあり、最大値を未定義のままにすることはやや奇妙です。また、最小整定時間の要件は、100 kHzを超えないインターフェース周波数（4μs、これはクロック間隔の半分の持続時間とよく相関します）、および100 kHzを超える周波数（0.6μs、明らかにマジックナンバーと一般的な周波数を表します）に対して個別に設定されます独立）。時間特性の同様の要件を満たすI2Cインターフェース（略語TWIに誤解されたふりをするつもりはありません）を設計するタスクが与えられた場合、2つの質問に非常に困惑します。まさにそれを行う方法、タスクは重要です。100 kHz（0.6μs。これは明らかに魔法の数字であり、周波数にまったく依存しません）を超えます。時間特性の同様の要件を満たすI2Cインターフェース（略語TWIに誤解されたふりをするつもりはありません）を設計するタスクが与えられた場合、2つの質問に非常に困惑します。まさにそれを行う方法、タスクは重要です。100 kHz（0.6μs。これは明らかに魔法の数字であり、周波数にまったく依存しません）を超えます。時間特性の同様の要件を満たすI2Cインターフェース（略語TWIに誤解されたふりをするつもりはありません）を設計するタスクが与えられた場合、2つの質問に非常に困惑します。まさにそれを行う方法、タスクは重要です。まさにそれを行う方法、タスクは重要です。まさにそれを行う方法、タスクは重要です。



文書は読むことができなかったので、明らかに何も教えてくれませんでした。さらに実験する必要があります。私は、次のコマンドを受信する準備ができているというフラグが実際の準備と比較して遅れて発生するという仮説を立てていますが、小さなテストプログラムはそれを反論します-準備調査による発行は、識別可能な値の追加遅延なしで実行されます。



次に、新しい仮説が立てられます-割り込みフラグは、インターフェイスの実際の準備状態に比べて遅れて発生するか、割り込み処理にかなりの時間がかかります。確認するために、割り込みの伝達関数の完了を待つプロセスで、追加のピンにインターフェイス準備フラグを表示し、割り込みでこのピンをすぐにリセットするテストプログラムを作成しています。このピンには40マイクロ秒の持続時間のパルスが表示されますが、パルスはまったく表示されず、データ送信プロセスでは純粋にゼロになります。一般的に、これは割り込みが発生時に処理される場合のはずですが、遅延はどこにありますか？



そして突然、遅延がなくなり、開始ビットの終わりにコマンドのバイトがすぐに送信され、すべてがうまくいくことがわかりました。追加のピンへのレディネスビットのブロードキャストを削除すると、遅延が再び発生します。転送の完了を待機するプロセスで、インターフェイス状態レジスタを読み取るために遅延が完全に消失した場合、他のインターフェイスレジスタへのアクセスは無効になります。非常に理解しにくい現象ですが、さまざまな実験により、これが実際にそうであることが確認されています。原則として、このような割り込みフラグの動作を保証する回路を設計することは難しくありませんが、そのような運動の意味は謎のままです。



個人的には、この事実について2つの可能な説明があります。最初のオプションは、エミュレーションプログラムにエラーがあり、インターフェイスの同様の動作につながることです。そうであれば、実際の超小型回路（およびこの場合のように、そのフラグメント）のプログラムでの適切な繰り返しは非常に困難な作業であり、原則として解決できないことが多いため、このエラーを許す準備ができています。そうでなければ、プロトタイプボードを放棄していました。しかし、個人的には、特定の高級言語で動作記述が使用されていない限り、モデルプログラムのテキストにこのような間違いが簡単に発生することはないので、このバージョンには向いていませんが、そのようなものを誤って作成することも困難です



上記の考慮事項により、2番目の仮説を立てることができます。プログラムはデバイスを適切に説明し、実際にそのように機能します。この場合、可能性のあるエラーがマイクロ回路の腸に入り、さらに多くの可能性があり、欠陥のある機能の説明に加えて、この結果につながる可能性のある微妙な物理的効果が現れます。この場合、そのような欠陥がモデルのレベルでどのように発見され調査されたか、およびエラーのリストに記載されていない理由が不明になります。



さて、3番目の仮説が残っています-この動作は、シミュレーションプログラムの開発者が使用した内部ドキュメントで設計および適切に説明されています。その後、すべてが適切に配置され、2つの質問だけが残ります-これが行われる理由（そのような実装の利点は何か、その欠点は明らかです-実際のパフォーマンスの低下）、およびこの機能が外部ドキュメントに反映されない理由



最初の仮説の正しさを判断するには、元の（または修正された）プログラムを実際のボードで実行して遅延オシロスコープを見るだけで十分です。モデルでは、効果はUnoおよびMicroボードバージョンで発生しました。すでに前に述べたように、私はそのようなボードを持っていないので、好奇心itive盛な読者にフィールド実験を任せます。コメントで結果を共有したいと思います。 2番目または3番目の仮説の忠実度を判断するには、個人的に（明らかに誤解のため）提供されなかった会社の内部ドキュメントへのアクセスが必要でした。 TWIに関する利用可能な（私の判断で）エラーの説明は、スレーブモードで最初のビットを出力するのが速すぎるというエラーがあり、データレジスタへの書き込みと送信の開始の間に遅延を導入する必要があると主張しています。ハードウェアのこのバグを修正しようとして、観測された遅延を導入しました。



さらに、この特定のライブラリーおよび一般的な可変動作を備えたライブラリーの正しい実装についてさらに検討する必要があります。私はこのパートを書き始めましたが、金曜日の読書には少なすぎたため、後で説明します。



結論として、投稿自体がトレンドに関するものであり、脅威にさらされているということです。だから：



-最初）どのマイクロチップが設計されているかが明確ではない（これが虚偽の声明であることを願う）、

2）それらの記述が書かれていることは理解できない（そしてこれは曖昧ではない）、

3番目）読者と常識に対して明白な軽daを持つライブラリは理解できない、

4番目）マイクロ回路の説明を理解できず、ライブラリの上にどのプログラムが記述されているかが明確ではない、

5）MKでインターフェースを実装する方法が不明、

6）MK のドキュメントでこれらのインターフェースがどのように記載されているか不明

...

-xx-11）Habrエディターのタグをもう一度変更して、現代の電子機器のmodernに釘を打ち込む理由は明らかではありません。

私だけが荒廃とカオスの中で白い馬に啓発の光を運ぶ敵軍。



もちろん、「太陽が明るくなり、草が固まる前に」エルニズムを脇に置いたとしても、20年前に実施しなければならなかったであろう調査を覚えていませんが、本当に悪化したのでしょうか？