インターネットでこの輝かしい場所を訪れたすべての訪問者を再び歓迎し、ささやかな貢献をします。
今回は、かなり論争の的となっているややハッキングされたトピックに関するものであり、問題に関しては、すべての実装が特定のタスク、特定の人、特定の条件に合わせて調整されているか、まったく機能しないことが判明しています。
Atmelマイクロコントローラー
AVRの UARTのソフトウェア実装について話しています 。Atmelマイクロコントローラーの知的財産は、しばらくの間
Microchipが所有していました。
だから、伝統に従って、言って
この記事のトピックに関する私の頭の中の考えは、内部ジェネレーターで実行されるマイクロコントローラーのソフトウェアUARTは非常に不安定であり、9600ボーを超える速度では高精度を得ることができないというコメントの1つの議論のおかげで、長い間忍び寄っていましたこの非常に内部的なジェネレータの周波数。
そしてもう一度、私はこの論文を確認したかった（残念ながら、議論された記事や議論は見つかりませんでした。これはHabréで起こっていたと確信していますが）。
- エラーをどれだけ減らすことができますか。
- デバイスが通信できる最大転送速度。
- すべての知識を使用してコードを圧縮できますか。
したがって、この作品の最初の意味はスポーツの興味でした。
しかし、最初の結果が得られたとき、私はTelegramメッセンジャーの
アナキスティックエレクトロニクスチャネルで初期コードサイズを実証することにし、突然話題が共鳴し始めました。 新しい人々が議論に参加し始め、すぐに議論は通常のコースに戻りました。チャンネル@ RT_1_98のユーザーは、この作品の破産を強く主張しました（彼への特別な感謝、彼は私をより激しく怒らせただけです-反対を証明してください））一方、チャンネルの管理者である@Byte_kgdは、そこで停止するのではなく、その作業を論理的な結論に導くことを申し出ました。レシーバーもトランスミッターに書きます！
そして、挑戦は受け入れられました...
さらに苦労せずに、私は単純な道を選びました。 
いいえ、私は困難を恐れているのではなく、結果を他の人にも適用したい、コードを読みやすくしたい、アイデアのシンプルさのために、他のマイクロコントローラに合うように修正できるからです。 そのため、9600から57600ボーの周波数グループに対してキャリブレーション遅延定数を作成し、タイマー割り込みを完全に破棄して、データバイトを回線に送信するトランスミッター関数を作成しました。
もちろん、座ってお気に入りの
IDEであるAtmel Studioに書き込みました。 元のバージョンでは、関数の本体コード（インラインアセンブラー）は約90バイト（45命令）かかりました。そのおかげで、遅延定数を設定し、Proteusシミュレーターで実行をテストしました。
他のどの実装よりも少ないコードサイズをすでに満たしているため、効率性に非常に刺激を受けました。
少し考えて、ゼロで終わる文字列を送信する関数を書き直しました。これにより、＃defineディレクティブを使用して特定のサイズの事前に準備されたバッファーを送信でき、さらにコードサイズを76バイト（38コマンド）に減らすことができました！ この時点で、テスト結果をTelegramで表示することにしました。その後、受信機を作成することにしました。
私は長い間自分の考えを集めました...
1つの主な考えは私を悩ませました：私は送信機のタイマー割り込みを放棄することに決めたので、同じ原理で受信機を構築することは素晴らしいでしょう...しかしどのように！
そして、私は必死のステップに決めました。1回の呼び出しで受信全体が行われるように割り込みハンドラを作成します。
はい、これは悪い習慣であり、はい-これはわいせつな行動です！ しかし、第一に、マイクロコントローラーのメモリ容量では大きなバッファーを保存できません。これはメインコードには不要です。第二に、ハンドラーを記述して処理できるようにしました。
- バッファオーバーフロー（境界に達したときに割り込みを終了することで実装）;
- 受付回線の中断（プロテウスのテストエミュレーション、完全なハングを示した結果、この状態を制御する決定が下された）。
- そして、実際には、正常な動作（正常なデータ受信のフラグを埋める）;
割り込みコードの書き込みが完了したら、Proteusでこのようなモデルを構築して、安定性の受信/送信のテストを実施しました。
1つのマイクロコントローラーが、テスト内容を含む所定のバッファーを転送しました。
char Rx_Buf[Buf_Size]={'T','e','s','t','0','1','2','3','4','5',10,13,0};
そして、それを受け入れた2つ目は、参照のものと比較し、不一致の場合、メッセージ「
エラー！ 」をデータライン
経由で 2つ目の端末に送信し、その後、シミュレーションを開始して就寝しました...
...午前中
目が覚めたとき、私は失望しました：ターミナルに不要なエラーメッセージが散らばっていました...しかし、それらを数えると、すべてがそれほど悪くないことが判明しました：9時間の作業で、57600ボーの速度で11のメッセージがありました。 これは、3888000バイトの場合、発生したエラーが143個を超えないことを意味します（完全なバッファーミスマッチの場合）。
...これが成功です！...
実際、エラーの確率は数桁低いことが判明しました。これは、プロテウスシミュレーションの高精度に起因します。
レシーバーとトランスミッターのコードを再度確認した後、トランスミッターを60バイト（30命令）に減らし、レシーバーを最適化しました。
それから彼は@Byte_kgdにコードを渡しました。@ Byte_kgdはテストに参加したいと熱心に望みましたが、わずかに余談ですが、ATtiny2313のみが利用可能です。
そして、彼は私に栄光と悲しみを告げました：「...サフセムは失業中です！Vaapsche！...」
それは大失敗です、仲間...
...新年が到来し、オリビエ全体が食べられ、シャンパンがすべて飲まれ、窓の外のクリスマスツリーがすでに燃えています。
しかし、コードは機能しません...それは何にも役立たない！
そして最後に、コードの半分を書き直し、半分を書き直し、残りの半分を裏返しにする必要があることがわかりました。
そして、Ostapは苦しみました！ （c）I. Ilf E. Petrov。まず、トランスミッターコードが54バイト（26命令）に削減され、次に、致命的な割り込みエラーが解消されました：符号なしフラグ（プロテウスがログに報告することなくそれをダイジェストしました。これがシミュレーションの2番目の不正確さです。 ATtiny13A MK）については、3番目と4番目に見つかりました-誤ったフラグの戻り、ジッター、送信期間と受信期間の不一致などのアーキテクチャエラーが除去されました。 受信機のコードは、STOPビットに従って自己同期化されて書き換えられ、間違いなく受信品質が改善されました。
さらに、最終的にロジックアナライザーを取り出し、プログラマー、UARTコンバーターを発見し、貴重なATtiny13Aをビンから取り出し、ハードウェアでのパフォーマンスを分析するために、今回が初めてであることに決めました！
これから先、私は言います：
奇跡が起こりました！ステッチされた「tinka」はターミナルで「ping」を示し、笑顔で答えました：Test012345。
ロジックアナライザーを使用すると、Proteusと実際のハードウェアの遅延に矛盾が見られました。 このため、レシーバーとトランスミッターの1つの定数で遅延を統一できました。
また、通常の条件下での最大伝送速度の理論的な制限を見つけることができました。
割り込み
スペルのプロローグとエピローグの実行には開始ビットをスキップする時間があるため、意図的に別の画面を選択せず、レシーバーのエラーを表示しましたが、そのような速度では機能しませんでした。 ただし、わずかに変更されたバージョンでは、512ボーの速度で信頼性の高い受信を実現できましたが、客観的な理由から、250ボーの受信/送信の制限でコードをそのままにすることにしました。
まとめ
非常に骨の折れる仕事の結果として、
- 結果は、世界で最もコンパクトなコードです！
- マスク不能（INT0およびINT1）割り込み
- タイマー割り込みを使用せず 、利用可能なすべてのPWMチャネルを解放する
- ポート設定を柔軟に操作し、データ送受信ラインに必要なピンを選択できます
- 9600〜250,000ボーの速度でデータを安定して送受信できます。
- 対応する機能のおかげで、フラッシュメモリからラインを転送
- 対応する機能のおかげで、バイナリ、16進数、および10進数でデータを変換および送信します （後者の場合、バイトおよびデータワードを転送するための2つの機能が実装されます）
この画像は、デモがデモプロジェクトの合計サイズである920バイトのフラッシュメモリを使用して、使用可能な一連の関数全体を使用していることを明確に示しています。 適切に編成すれば、必要な機能のみを使用できるため、メインプロジェクトのコストを大幅に最小限に抑えながら、UARTを介してマイクロコントローラーをデバッグできます。 コードは、他のコントローラー（たとえば、ATtiny85A）用に簡単に変更できますが、メインタスクのパフォーマンスとパフォーマンスを損なうことなく、バッファーのサイズと使用する関数の数を増やすことができます。 分析とトレーニングの明確さと利便性のために、コードはライブラリに送信されませんでした。 バッファオーバーフロー制御は、完全には実装されていません。 これは、オーバーフロー中にオーバーフローフラグが設定されず、代わりに割り込みが終了し、着信フローがさらなる動作を決定することを意味します。
したがって、マイクロコントローラは再び中断し、受信したバッファを新しいデータで上書きします。 これを回避するために、特定のバッファサイズより長いデータのチャンクをフィードする必要はありません。 ハンドラーコードを膨らまさないように、いくつかの議論の後、これで停止することが決定されました。 主な条件が満たされている-マイクロコントローラーはフリーズせず、正常に動作し続けます。
今回の伝統からの別の逸脱は、スクリーンショットの形でのコードの抜粋の欠如でした。 前回の記事で、このトピックに関する最初のコメントは怒っていました:)
その場合、コードをGithabに配置し、その結果、すべての美しさを書式なしの形式で表示します。
Atmel Studio 7.0用のプロジェクトバージョン2.0これはプロジェクトの2番目のバージョンであり、最新バージョンです。 実行可能なすべての変更は、キャリブレーションの遅延のみに関係します。 現時点では、範囲全体に対してテストが実行され、正常に完了しています。
あなたの家で、あなたの路上で、そしてあなたの心の中で、あなたが暖かさの早い始まりを願っています！
すべての成功、創造、成果！
商用利用、ソースコードの転売、営利目的およびmerc兵目的での使用は禁止されています。 ソースコードはそのまま無料で配布されます。他のサイトまたは他のソースで使用する場合は、著者の指示と配置の通知が必須です。