端的に言えばRTS/CTSでフロー制御するクロスケーブルがインターリンクケーブルであり、 DTR/DSRだけでフロー制御するクロスケーブルがヌルモデムまたは一般のクロスケーブルです。 シリアルポート利用ではRTS/CTSでフロー制御することが一般的だと考えられますので、 可能な限りインターリンクケーブルを採用するべきでしょう。
RTS output signalはUARTに繋がれたデバイスから送信をしてもらうために、UARTから見て送信を許可することを相手に伝えるために使用します。 CTS input signalはUARTに繋がれたデバイスが送信を許可することを示し、UARTから見て送信が許可されていることを相手から受け取るために使用します。 CTS inputがアサートされていれば、UARTからの送信が許可されていることを示します。 CTS inputがネゲートされていれば、UARTからの送信が禁止されていることを示します。
CTS inputはハードウェア制御される可能性を想定したほうが良い信号です。 CTS inputがアサートされるまではハードウェアレベルで送信を実行しないという趣旨で設計されたUARTチップも過去にはあったと記憶しています。 ですからデバイスにRTS/CTSが存在するとき、その処理をサボってはいけません。 必ず何らかの信号を与えて、良きに計らわなければなりません。 82C51A USARTのデータシートが読めるのであれば読んでみると良いでしょう。 その他、心当たりの半導体のデータシートがあったら読んで調べてみると良いでしょう。
半二重通信においてRTS/CTSはどうなるのかというと、これはイマイチよくわかっていません。 RS-485では送信要求にRTSを使うことが考えられます。そこではソフトウェアに互換性がありません。
通常用いられるフロー制御としてはRTSとCTSだけであり、DTRとDSRの利用はイレギュラーです。 DTR output signalがアサートされていれば端末ソフトウェアが立ち上がっていて通信準備ができていることを通信相手に示すことができます。 DSR input signalがアサートされていれば通信相手側の受け入れ準備ができていることを認識できます。 これらの制御端子は、意味としては機器の電源が入っているかどうかを検知する程度のものです。 ヌルモデムケーブルはモデムがないのでRTS/CTSをループバックしています。 ヌルモデムケーブルはDTR outputとDSR inputでフロー制御することを想定して設計されていると言うことができます。
DCD input signalはモデムからのキャリア検出を示し、通常はオンラインになっていることを機器側からMCU側に通知します。 組み込みのコンテキストではキャリアという概念は無いでしょう。 インターリンクケーブルではDCDを配線しません。 ヌルモデムケーブルではソフトウェアを騙すためにDCD inputをDTR/DSRから拝借します。 UNIX系システムではDCD inputがネゲートされると端末との回線が落とされたものと認識して(SIGHUP)、 インタラクティブなプロセスを終了させる動作をします。
RI input signalはモデムを経由したPSTNの呼び出しが受け取られており、 MCU側がモデムに対して何らかの応答をすべきことを示す信号です。 これもモデムで通信を行っているときは意味がありますが、 MCUとMCUをダイレクトに繋ぐ組み込みのコンテキストの場合は意味がないため、 通常は結線されません。
ラインの信号レベルはUARTデバイスの入出力を反転したものとして定義されます。 UARTの端子は制御端子について負論理で定義されます。 UARTの端子のうちデータ端子については正論理で定義され、負論理として見立てて制御できるようにアイドル状態ではハイレベル、イチとなります。 ラインレベルの通常は正の電圧が掛かっていればアサートです。 負の電圧または接地されていればネゲートされています。 このような歴史的経緯を持っているため、ラインの制御信号は正論理ですが、ラインのデータ信号は負論理となります。
FT232とUSB-CDCは似て非なるものです。 FT232はプロプライエタリな通信規約を使っています。
MIDI inputに用いる光学素子としては2023年現在はTLP2361が良い選択となるようです。 フットプリントは異なりますが回路図上はPC900Vと置き換えて使うことができ、 トーテムポール出力のためにプルアップが必要ないように読めます。 単価50円であれば悪く無さそうですが、モノが表面実装部品なので、 実装方法によっては変換基板に対するコストが余分に掛かることに注意が必要です。 変換基板を買うと10円や20円では効かないことがよくあります。 多少高くても最初から貫通穴部品を買ったほうが良いかも知れません。
伝統的なフォトカプラが欲しいのであればH11L1という一般型名の製品がマウザー等で取り扱われています。 プリント基板を起こせるなら、TLP2361を素直に採用したほうが安価でしょう。 表面実装部品は実装が手間なところがあります。 貫通穴部品であれば無造作に実装できます。 どちらを選ぶか悩ましいところですね。
MIDI outputは、通常、LEDのカソード側をトランジスタで構成したインバータで接地するように駆動します。 インバータと書きましたが、UARTからLEDに繋がる回路は全体としてノンインバートでなければなりません。 LEDのアノードを電源端子に吊ります。 保護抵抗は220Ωと定められており、ソース側とシンク側の双方に抵抗を入れます。 さらに受信側でもLEDのそばに220Ωの抵抗を入れるため、3本直列となり、都合660ΩがLEDの電流制限抵抗になります。 フォトカプラは赤外線LEDがほとんどであることを考えると、おおよそ4mA流ほど流れると見積もります。
UART output (TxD)がhigh (== 1)であればLEDがoffでなければなりません。 また、逆の状態としてUART output (TxD)がlow (== 0)であればLEDはonでなければなりません。 PC900V/H11L1のoutputの扱いとしては、 MIDIの定常状態であるLEDがoffであればフォトカプラがGNDに対してoffになってプルアップで吊られ、outputがhigh (== 1)になります。 LEDがonであればフォトカプラがGNDに対して通電してoutputがlow (== 0)に落ちます。
UARTの出力端子はほとんどの信号線において負論理ですが、 データ端子(TxD, RxD)だけは正論理のままというややこしい設計がされています。 フォトカプラのLEDが点灯していればゼロであり、消灯していればイチなのです。 ただし、LEDの光を評価することはないので、まあどうでもいいことですね。
MIDIのDIN5端子は送信側からみて4番端子がcurrent sourceとして電源である+5Vに接続されます。 5番端子がcurrent sinkとしてトランジスタを通じて接地されます。 2番端子はシールドであり接地される端子です。 1番と3番は使用しません。
Microchip MCP2221Aは秋月で品切れになりっぱなしで再入荷する様子がありません。 どうしたのでしょうかね。 対抗馬のWCH製チップがあるので常置するものでもないという扱いでしょうか。
マウザーで探してみますと、類似品としてMCP2200がヒットします。 ただし、こちらはお値段が高めで300円を超えます。 デバイスの特徴はUSB-CDC + USB-HIDプロトコルの採用であり、 標準ドライバだけで済むためOSカーネルを選ばないことです。
USBを受けてSPIバスを制御する用途としてはMicrochip MCP2210が製品化されています。 このデバイスは何に使うために開発したのかいまいちよくわかりません。 classic AVRの書き込みに使えれば便利そうに見えますが、 それだけのような気もします。 USB経由でSPIバスを扱わねばならないようなセンサ製品の接続用なのでしょうか。
秋月で扱っているCH340EモジュールはI/Oが5Vなので実質のところArduino専用であり、 3.3VのI/Oを求める応用には適しません。 CH340の採用理由がそもそもコスト削減なのであり、 コスト削減が目的となればLDOレギュレータの搭載を見送るのは自然な考えです。 ひとまずI/Oが5Vで良ければCH340Eモジュールが費用と効果の観点からみて良好です。 550円という値段はお安いとまでは言えませんが、 小型化を極めたデバイスの実装の手間と、 最適化されたサイズを考えたら悪い選択肢ではないでしょう。
CH340系はNetBSDやLinuxではビルトインでサポートされています。 Windows11系統には最近になってようやくWindows Update catalogにデバイスベンダ純正ドライバが収録されたようです。
FT231X系モジュールをそっくり置き換えることのできるCH340系モジュールは製品化されていないようです。 CH340系にはLED端子がないので、光り物を点灯させることができません。 CH340系には余力のあるレギュレータが搭載されていないので、3.3Vを吐き出すことができません。 インジケータが欲しい場合はCH340系は適しないと言うことができます。 マイコンのピンに余裕があるなら、受け側になるであろうマイコンで点灯させると良いのでしょう。
年始で秋月の商いが始まりました。 新しく取り扱いが始まったデバイスAVR64DD28に対する潜在的な需要はさほど大きくなかったようです。 秋葉原にある秋月の店頭ですら売り切れるほどでもなく、 新商品ワゴンの箱の中に入っていたのが印象的でした。
avrdudeに実装されているserialupdiを使うためには、 下記のような回路を構成すれば良いようです。 回路の趣旨としてはプルアップしたほうが良さそうに見えますが、 リファレンス回路にそれがないのはUART IC側でプルアップされていることを期待しているのでしょう。
ここでTxD, RxDはUART ICから出ている生のTTLロジック端子を表しており、 EIA-232のようなバッファを介在させた信号ではありません。 抵抗は単なる保護抵抗でしかありません。 保護抵抗として4.7kΩを挟んだ場合は、短絡電流は最大でも1mAに抑え込まれます。 これが制限として強すぎる場合は2.2kΩぐらいに緩和したほうがよろしいでしょう。 UART ICが5mA程度の吸い込みを許すのであれば1kΩまで緩和することができます。 モジュール型のUARTを使っていて基板上に保護抵抗を搭載している場合は、 その分を加味したうえで、 外付けする抵抗をさらに緩和する必要があります。
端子構造の推薦は次の通り。
後日注記。 ソフトウェアが適切だという前提で話をすれば、TxDとマイコン側が競合することはないので、保護抵抗はオプションです。 2.2kΩだと115200bpsを通すのは(波形が鈍って)辛いかもしれないなと計算して思いました。
AVR16/32はマウザー等で取り扱いがありますので、どうしても欲しければ海外の小売商社を頼ることができます。 普通の購買規模から考えると、買ってもせいぜい10本でしょう。 これぐらいの少量購買であれば秋月価格には敵いません。 AVR64DD28を前提にソフトウェアを設計すべきなのでしょうか。 AVR16DD28でも足りるんだけどな……。 ちょっと悩ましいですね。
gccではAVR16/32DDとAVR64DDとでメモリモデルが若干異なります。 メモリ容量が許すのであれば下位品種を使ったほうが快適にプログラムが書けるはずです。
年末に端末を更新したので、年始の記事を新しい端末で書いています。 早速液体が垂れて浸水しそうになりましたが、あぶない、あぶない。 今度こそ端末を壊さないようにしないとね。
その昔、IBMが端末を設計していた頃は浸水防止の設計が施されていたと言われますが、 今はそのような配慮はありません。 浸水すればそのままメインボードに液体が垂れます。 メインボードが浸水すれば昇圧機能を含む電源回路がショートして電子部品が焼け焦げてしまいます。 浸水防止の設計が復活してくれれば安心なのですが……。 今は物損保険でカバーするというビジネスモデル、またはポリシーのようです。 寂しいですが仕方ありません。