ツイストペアは、デバイス間でデータを転送するために最も一般的に使用されます。 1組のデータは双方向に送信されますが、同時にではなく、順番に送信されます。 通信する必要があるすべてのデバイスは、並行して回線に「座って」います。 インターフェイスは差動入力/出力を使用します。 ここにキーポイントがあります...
このインターフェイスを使用すると何が得られますか？ プロから：
-長距離で送信する機能。
-伝送媒体は非常に耐ノイズ性があります。
-既存の回線にデバイスを簡単に追加できます。
-高速での伝送...
マイナス面については、仲裁方針を熟考する必要があります。 2つのデバイスが同時にデータを転送しようとする状況が発生しないように、またはそのような状況から抜け出すようにプロトコルを熟考すること。 私は最初の、より単純な道を取りました。 シングルマスターコントローラーを通信するオプションを選択しました（1つのコントローラーがマスターであり、他のコントローラーに情報を送信するか、デバイスに情報を要求します）
コントローラをRS485ネットワークに接続する古典的なスキームは次のようになります。
MAX485チップ（ad485、st485など）を使用します。 レッグ1-受信したデータ、レッグ4-回線への送信用のデータ、およびレシーバーまたはトランスミッターをオンにするための2と3（図では結合）。 レベルを変更して組み合わせると、データ転送の方向が変わります（私たちにとって-私たちから）。 私は自分が額で熊手を捕まえたので、受信機がどのレベルでオンになり、どの送信機がオンになるかについて、意図的には書きません。
上記の図にすべてが正しく描かれています-ここでは、受信機は低信号レベルでオンになり、送信機は高オンになります。 私はどういうわけかそれに注意を払わず、この方法でスキームを「改善」することにしました。
ボードが配線され、デバイスが組み立てられた後にジャンブが発見されました。スタンバイモードでは、論理「1」がTxD出力で常に「オンデューティ」であり、データ転送中に「ゼロ」が表示されます。 したがって、受信機は常にオフになり、送信機はオンになります。
この状況を克服するための2つのオプションを思いつきました。
1.ソフトウェア。 ハードウェアシリアルポートを使用する代わりに、出力ですべてのデータが反転されるソフトウェアポートを使用します。 加えて、それは明らかです。ボードを再製造する必要はありません（そして、そのうちの5つがありました）。
2.ハードウェア。 コントローラーの出力とコンバーターの入力の間にインバーターを配置します。 プラスも明らかです。独自のシリアルポートエミュレーションカーブを記述する必要はありません。
元の「最適化されていない」スキームに戻すための3番目のオプションもありましたが、ボードの変更とプログラムの変更がすぐに必要になるため、すぐに破棄されました。 私は自分で困難を作成しました-私自身は克服します。
私は自分より先に進みます-何も書き直さず、新しいボードを育てませんでした。 彼らは真実を言う-怠inessは進歩のエンジンです。 実験の観点から、カットトラック上で1つのトランジスタにインバータを組み立てました。
それは怖いことが判明しましたが、うまくいきました！
最終的なスキーム：
smdトランジスタと2つの出力抵抗の仕上げの色を保持するために、回路はペイントで描かれています。
ずさんで怖いように見えましたが、3層のニスを塗った後...
回路にいくつかの変更が加えられ、着陸地点を前もって植え始めたものの、一般に、私はまだ同じ方法でマイクロコントローラーの片足を節約します。
これは回路の一部です。 コントローラーの足元からの制御がない場合にトランジスターを開いた状態に保つために抵抗が追加されました。 （パネルからコントローラーを取り外しても、他のデバイスの通信に干渉することはありません）。
ちなみに、最初のシステム、3年目、どのように機能するかは、もうすぐです。