R&D daily

Ethernet 、EtherCAT かTCP/IP かになりますが、実際ソフトウェアプロトコルスタックを入れても速いということですか？
今、RS485 使っています。中身はUART。この時点であーっていうのが目に浮かびます。
同期通信でも良いんですが、半二重通信ってのが足を引っ張ります。
そもそも、通信の処理・パース・実行を同期したい、通信コストがかかるので非同期にしたい、通信自体はいつ来るか分からない非同期（相手はwin）。いろいろ矛盾しています。
通信コストを下げるのが最適解なのかもしれません。

半二重でUARTで通信コストですか、無線系かな...

処理が重いかどうかは、実装したプロトコルスタック次第でしょうが。

EtherCATもアリってことは、あんまり高位のプロトコルじゃないんでしょうね。
IP通信でも、データグラムなら、通信中の負荷は非常に低いです。

受信なんかだと、設定だけすれば、あとはすべてEtnerMACとDMAで処理されて、
メインメモリの指定したアドレスに、パケットが丸ごとごろりと入って来るだけです。

割り込みすら、あんまりいらなくて、
フラグをポーリングで見に行く程度で十分回ります。

あとは、適当にヘッダ部分を見て、必要なデータにアクセスするだけです。

UARTだとDMA使うにしても、いろいろ処理が必須になりますから、
パケット受信するのに必要なCPUリソースは、全く比べ物になりません。

厳密にはACK ではなく、「RS485（半二重）で必ずレスポンスがある通信かつ複数台バス接続されている」ですね。
通信の内容は大したことないですね。

ずっとEther を食わず嫌いしていましたが、そろそろちゃんと向き合わないといけない気がしてきました。
始めるとEther でいいじゃん、となりそうと感じました。

いわゆるACK/NCK が返ってくる通信、複数通信タスクがある処理系には合わないですね。
ですが、相手方（デバイス側）が購入品になると途端にそこがネックになってきますね。本来はそこも含めて開発してしまった方がトータルコストは安く済みそうな気がしますが、チーム内に経験者がいない or 覚悟がないとその決断をしない、という印象です。

購入品、納入仕様とかが有るような物だといいのですが。
商社あたりがどっから見つけてきたようなのって、技術的問い合わせ不可だったりしますよね。
そういうのに限って、ナゾな実装してあったりするもんです。目に浮かびます。

Etherは、Ethernet自体はシンプルですよ。
レジスタの設定とかがたくさんあるだけで、USBとかと比べてもソフトウエア面ではメチャクチャシンプルです。

ただ、消費電流は今どきの周辺からすると大きめになりがちです。でもまあ電池駆動でも許容できる程度ですが。

Etherの上に乗っかってるIP通信が、すべてを叶える魔法なのですが。
UARTの置き換え程度だと、UDP通信がぴったりで、固定IPでLAN内でUDPを動かすだけなら、
ARPとIP、UDP、あとおまけでICMPあたりをピンポイントで実装すれば動いてしまいます。
それぞれのプロトコルは、C言語のソースで10～50行くらいで実装できます。

何がうれしいって、マイコン側でなく、PC（ホスト）側が、socket使えば終わりで、メチャクチャシンプルなんですよね。

エラー処理とかなければ、コード記述10行くらいでマイコンとパケットやり取りできます。
同期でも非同期でも...

シリアルポートなんて、カッタルくて使えなくなります。