調光器（照明制御デバイス）の開発があります。調光器は、ワイヤレスチャネル、特にZigBee（以下ZIGと呼びます）を介してデバイスから制御信号を受信する必要があります。 また、このデバイスを設計する過程で、調光自体のメインプログラムは、ワイヤレスインターフェイスのプロトコルスタックを整理するライブラリと同じMK上で共存できないことが判明しました。 私は正直に認めなければなりません（そしてコメントでこれを行いました）議論の始めにはZIGの一般的な考えしかありませんでした（現時点ではこれはまったく正しくありません） 。
衝突の本質について考えてみましょう。 まず、一般的な考慮事項：白熱灯またはその他の照明デバイスの発光の程度（完全にオフになるまで）を変更するにはどうすればよいですか？ これを行うには、設計されているランプよりも低い電圧をランプに印加します。 この要素には大きな電力が割り当てられているため、クエンチング要素に静的な電圧降下があるオプション（線形調整）は考慮しません。 残っているのは、動的な調整（パルス変調）、つまりキー要素の使用、およびキー要素が時々閉じているという事実によるランプの平均電圧の低下だけです。 定電圧を扱っている場合、制御方法はこれによって使い果たされ、オプションは可能です：パルス幅または周波数パルス変調。 ただし、交流電圧を扱っているため、1サイクル（期間）（パルス周波数変調の変形）内で電圧のループスルー伝送/ブロッキングまたは入力電圧のブロッキングを適用できます。 このオプションには、電圧がゼロを通過した瞬間に調整要素の状態の切り替えを実行できるという点で、パルス変調よりも明確な利点があります。 ループごとの制限にはフリッカーという重大な欠点があるため、サイクル内の部分的な電圧カットオフ（通常は周期の半分）を使用するオプションがより頻繁に使用されます。 最初のオプションはトライアックに簡単に実装されるため（0を通過すると自動的にオフになる）、カットオフはサイクルの開始時（スイッチオンの遅延）と終了時（リードオフの切り替え）の両方で実装できます。これを有効なものとして受け入れます。
オンディレイを使用したサイクリック調光アルゴリズムの簡単な実装の擬似コードの概要を説明します。
while (1) { _; timer=_; while (timer) { if ~signal() { timer++}; timer--;}; // 0 timer=_; while (timer) { timer--}; // ; _ ; ; ; timer=_; while (timer && ) { timer--}; // };
この実装では、重要なセクションはメインサイクルの2行目と3行目（および4行目）です。これらの実行時間を監視することで、サイクルの開始に対するスイッチングパルスの位置決めの精度が決まるため、割り込みを禁止することでこれらの時間を制御します。 つまり、中断が禁止されているかなり長い時間間隔があり、ZIGを含む周辺機器と通信することはできません。 どんな問題がありますか？ 無線インターフェイスを介した一部の交換操作では、時間パラメーターに厳しい制限が必要になる可能性があります（この記事の執筆時点でZIGの詳細に精通していないことを再度強調します）。 このような操作の候補は、あらゆる種類の「ハンドシェイク」（操作の確認）になります。 実際、ライブラリの説明を簡単に紹介すると、65マイクロ秒を呼び出す必要があることがわかります。 中断は長時間禁止されているため、この要件を確実に満たすことはできず、衝突が発生します。 問題の解決策を探し始める前に、それが本当に存在するかどうかを知る必要があります。
必要なZIG処理を実際に提供できないと仮定します。 それで何？ この標準は賢い人々によって開発されました（対談者はあなたと反対を証明するまで常に自分自身を愚かではないと考えます、そしてこの場合でもあなたは間違っているかもしれません）、彼らは2.4 GHz帯域の空気が何であるかを完全によく知っています、そして私はそれを決して信じませんこの標準は、タイミングを含め、障害の再送信および修正のための手段を提供していません。 したがって、ランプグローパラメータの変更に関するメッセージをスキップすることを脅かすものは何ですか？ 中断が解決される次のサイクル、または次のサイクルなどでそれを受け入れます。 つまり、ランプのグローを変更する際の遅延は、最大10サイクルの動作（つまり、10 * 1/50/2 = 1/10秒）になる可能性があります（寛大です）。 ユーザーがそのような遅延にどのように気付くことができるか、私にはよくわかりません。
ところで、私たちが使用しているライブラリ（ちなみにATMELから）は、曲がりくねったプログラマーによって作成されたと仮定します（これは私の原則と矛盾しますが、思考実験の順序では行いませんが）、65μs以内に呼び出されないと本当にクラッシュしますメッセージの到着。 つまり、ZIGから制御情報を受信するときに、1行目と2行目の実行時間を保証することはできません。 それで何？ つまり、ランプの明るさを変更する必要性に関する情報を受信すると、次の制御サイクルを誤って発行する可能性があります（完全にオフになるまでグロー期間を短縮できます）。 変更が必要な場合にのみ情報が送信される場合、このようなまれな誤動作によって引き起こされるランプの輝度の変化に気付くユーザーを想像することはできません。
今、すべてが本当に悪い、つまり、情報が非常に頻繁に私たちに届き、受信後できるだけ早くそれを処理する義務があると仮定します。つまり、擬似コードの実行時間は完全に予測不可能になります（期間が長くなる方向に）。 状況は本当に不快であり、適用されたシンプルで理解可能な実装を放棄する以外に選択肢はありません。 追加のMK（<sarcasm>）を近くに置かずにできること。 まず最初に、割り込み、タイマー、PWM関連の変調器などの存在を思い出してください（このMKにはこのすべてがたくさんあります）。 次の解決策を提案します：サイクルの期間を決定し、スタートアップモードまたはシングルモード（サイクル時間よりわずかに短い時間）で対応する期間のタイマーの1つを設定します。 PWMモードを設定し、出力信号を使用してトライアックを制御します。 タイマーの動作を電源電圧サイクルと同期させます。 0から割り込みへの移行に関する信号を開始し、タイマーの期間を修正する（起動用）またはタイマーを再起動する（1回限り）サブルーチンを配置します。 このハンドラーは明らかにシンプルで短命なので（割り込みの実際の到着時間を計算するための長い操作（キャプチャモードを忘れないでください）、平均的な計算などをハンドラーの下半分に割り当てることができます）、ライブラリを起動するための要件を満たしています。 一般的に、誰もが幸せで、誰もが笑っています。
それにもかかわらず、私は、共有ソフトウェアの開発にこのような厳しい要件を提示するライブラリを将来使用することを真剣に考えます。 頭に浮かぶ唯一のもの：それにもかかわらず、そのような制限は開発者によってライブラリに定められたのではなく、それを使用したプログラマーによる記述の誤った解釈の結果でした。 特に「許容遅延の要件を減らす」機器の拡張動作モードのMCの説明で言及を考慮する場合、1番目と2番目のオプションの確率比を2〜8として評価します。 しかし、ここでは、ZIGのトピックに興味がありましたが、適切なライブラリを作成することで、より深く研究することを考えていますが、推測と推測の不安定な地面に着手しています。 確かに、議論の一部の参加者の声明にもかかわらず、そのようなライブラリ（単純なデバイスの場合は用語ZIG）はATMELからのソースコードで自由に利用できます。
おそらく、そのようなソリューションには、会社の開発者によって実装されておらず、その投稿が議論を引き起こしたため、私には明らかでない欠点があります。 組み込みデバイスの開発者としての私の視野を間違いなく広げるので、それらに精通してうれしいです。