電子工作徒然草
このブログはmeron33の個人的忘備録です
地方在住の電子工作愛好家です。
「最近の人もすなるブログといふものを、私もしてみむとてするなり。」ということで
電子工作を中心に、気まぐれなものについて、気まぐれに投稿しています。
投稿初心者ですので、内容がわかりにくければご容赦ください。
個人の趣味として調べた範囲の内容ですので、誤りがある可能性がります。
何かあればあればご指摘ください。
DCDCコンバータの内部位相補償は万能じゃない
内部位相補償DCDCコンバータの理想と現実
内蔵位相補償は一見設計が楽そうに見えて、かなり大きな代償があるという話・・・
＜お詫び＞
以前のこの辺で（https://meron33.hatenablog.com/entry/2025/12/29/163524）AP64502は内部位相補償でおすすめなんて書いていましたが、このシリーズのDCDCの位相補償回路内蔵品が全くお勧めできない代物であることが判明しました。申し訳ありません。
該当部分の修正と、追加情報として掲載させていただきます。
AP64XXシリーズの注意点
64502/647352は内部補償回路の設定がいけていないことが原因で、出力を出すのが難しく、部品代が高くつくのであえて選ぶ意味がないです。自信がない限り買わない方がよいです。
その理由は以下の通りです。
・補償回路のRC（3.3～5V専用の値）をIC内搭載だけで、値もあまり適切ではない。
・内部補償で1005サイズのRとC各1個が削減できる代わりに、Lが2倍、Cが３倍必要。代償に見合う価値はほぼない。
・まともに５A出力するにはICより遥かに高い188uF のMLCCが必要
・5V以上はまともに出せないのに「(VOUT): 0.8V to VIN」と記載されている。
AP64350/64500（外部補償、fsw可変）、AP64351/64501（外部補償、570kHz固定、ソフトスタート）のほうが実際には使用しやすいです。
目次
１ 位相補償回路はDCDCの性能を決める
（０）位相補償回路は重要
（１）内部補償が弱い内部補償回路
２ AP64502の内部補償の実態
３ 出力コンデンサCoutの特性は極めて重要
４ 64XXXシリーズのラインナップ
５ 645XXシリーズの差異
１ 位相補償回路はDCDCの性能を決める
（０）位相補償回路は重要
最近140WDCDCコンバータを燃やしました。
原因は位相補償回路のはんだ忘れから、RC直列とCの並列回路になるはずが、Cだけとなり、位相補償回路が設計値とかけ離れた値となり発振したという情けない理由です。変にC3だけ機能して途中までは動いてしまって油断したと言い訳・・・
位相保証回路が不適切な値だと、28V5A140W出力可能なDCDCが、わずか9V1A程度の出力で発振して燃えます。
（１）内部補償が弱い内部補償回路
さて、同じメーカのAP64502という位相保証回路内蔵で5A出力可能なDCDCコンバータを購入して試験したところ、9V2Aくらいで表面温度65℃、12V出力を試したら焼けてしまいました。
AP64351とい3.5A出力のDCDCコンバータ以下の性能で異常です。出力電圧波形を見てみると、5Vでは2A程度まではきれいなものの、１２Vでは１A出した時点で波形が乱れて破壊します。効率もカタログスペック上は90％越えなのに80～70％で推移しておりこれでは燃えてしまうのは納得ですが理由が不明
２回燃やして気づきました。AP64351の位相補償回路（RC直列）の設定が不適切な時に起きる現象に酷似しています。内部補償なのにうまく補償できていないのです。なぜそんなことが起こるか、内部補償の現実を突きつけられました。
２ AP64502の内部補償の実態
AP64502はAP64351と同じシリーズ品であり下記特徴は類似していると考えられます
・Vo=Vi*1/2で必要L値、ピーク電流、損失等が最大になる。
・２４Vバスから５～3.3V取出が主要用途
・データシートは主要用途での解説であり、損失最大点の手前の有利な条件での定数のまま安易に出力電圧を上げるとDCDCの許容損失や、位相補償の限界を超える。 このようなﾃﾞｰﾀｼｰﾄなので、5V以上で使う場合L、Cout、位相補償回路をしっかり計算する必要があります。
データシートを見て気づきました。このAP64500も3.3～5V出力を前提とした設計であり、内部補償というのは、補償回路のRC（3.3～5V狙い）をIC内に搭載しただけです。（補償しなくていい設計に改めたわけではない）このICは12V出力とかでは使い物になりません。
外部位相補償のDCDCであれば、12Vでも15Vでも出力電圧に応じた値を計算して入れればいいだけですが、内蔵されている場合手出しができません。
この状態で、「(VOUT): 0.8V to VIN」で売るなよと。
それにしても5Vでも効率が悪いのはなぜか？
３種類のﾃﾞｰﾀｼｰﾄを見比べてみると、はっきりします。
64500/64501:推奨L3.3～3.6uH、Cout22u×3＝66uF
64502：推奨L5.5～6.8uH、Cout47u×4＝188uF
となっておりなにやら、AP64502はLが２倍やCが３倍必要なようです。しかも微妙に効率曲線も下がっている。内部補償回路のRCが幾つなのかは特定不能ですが、5V向けの値としてもギリギリの定数が入っており、Lや出力コンデンサを増やして支えているようです。
さてボード線図を比較してみましょうと思ってﾃﾞｰﾀｼｰﾄを比べたら、AP64502には載ってない。単に内部補償なので出す必要がないと考えたのか、理由があって出していないのか？
３ 出力コンデンサCoutの特性は極めて重要
Cに関しては、25V 22uFは非常に高価です。なので、秋月で売っているGRMシリーズを使っています。
周波数特性的には1MHzくらいまで使えそうですが、直流電圧重畳特性がよくないです。
22uFあってDCバイアス特性がよいものはタンタルコンデンサに手を出すかとなるのですが、MLCCにこだわると1個200円以上するんですよね・・・
というわけでAP64351では、10uF or 22uF×２を投入しましたが、DCバイアスが悪いため、実質2uF程度しかなく容量不足気味となっております。それでもこちらは動いており念のため電解コンデンサを追加しました。（APK43070ではこの手法。ひと昔は大容量MLCCなんてなかったのでこの手法しかなかったはず。）
ただ、MLCCで４７uF×4が必要なAP6502ではこのような手法では容量不足となり、出力の安定性を失ったのだと思われます
内部補償にすることで削減できるのは、1005サイズのRとC各1個です。その代償にLが2倍、Cが３倍必要なのでは、基板面積逆に増えるでしょう・・・
そもそも24V-＞3.3～5Vを出すことを目的としたDCDCなので、AP64501等が位相補償回路さえ気を付ければ12V出力にも転用できる出来のいいICなだけで、
AP64502は5Vまでしか使えないのは設計の想定通りなのだと思われます。
ただ、
・まともに５A出力するにはICより高い188uF のMLCCが必要
・5V以上はまともに出せないのに「(VOUT): 0.8V to VIN」と記載
これでは残念ICとしか言いようがないです。これを買うくらいなら、
位相補償回路の計算は必須だが、22uF×２で3.5A出力が可能なAP64351のほうがまし。
4 64XXXシリーズのラインナップ
AP64xxの3.5A/5A品には以下のラインアップがあります。AP64350/64500あたりは可変周波数で Lを小さくできます。（EMCを無視すれば）ソフトスタートがないですが電源接続後のON遅延だけならEN端子にRC直列回路をつないでごまかせます。
AP64500 外部位相補償回路、fs100～2000kHz可変、ソフトスタート無、
AP64501 外部位相補償回路、fs570kHz固定、ソフトスタート搭載
AP64502 内部位相補償回路、fs100～2000kHz可変、ソフトスタート搭載
AP64350 外部位相補償回路、fs100～2000kHz可変、ソフトスタート無、
AP64351 外部位相補償回路、fs570kHz固定、ソフトスタート搭載
AP64352 内部位相補償回路、fs100～2000kHz可変、ソフトスタート搭載
64502/647352は内部補償回路の設定がいけていないことが原因で、出力を出すのが難しく、部品代が高くつくのであえて選ぶ意味がないです。
５ 645XXシリーズの差異
とはいえ、AP64502/64352以外の64XXXシリーズは極めて安定性の高いDCDCです。
両者は設計は共通で、出力電流に応じて内蔵MOSのRDSが低めにされているだけだと思います。
・AP645XX：H：45ｍΩ、L：20ｍΩ
・AP6435X：H:75ｍΩ、L45ｍΩ
2～3Aくらいの負荷であれば645XXの方が6435Xよりもちょっと損失を減らせます。とはいえ、もとより1～2Aでしか使わないことが見えていれば値段が安いので64351/64350の方がよいでしょう・
以前掲載した記事の誤りと、追加調査事項に関して上げさせていただきます。
シーケンサ（PLC）のEthernet通信をOSI参照モデルで分類
今どきのPLCはEthernetを搭載しその通信規格は多数あります。とはいえ完全なTCPベースから、リアルタイム性確保のための独自実装まであり複雑です。EthernetのHWやソフト資産がどこまで使えるのか。各規格がOSI参照モデルのどの層で実装されているかを分類して、マイコンで実装する場合のHW要件や実装難易度について検討しますという話です。調べた限りの分類ですので間違いがあればご指摘ください
また、仕様やライセンスが完全に自由なのはMODBUSTCPだけです。
それ以外はちょっとわからないのが現状です。各協会の口上を真に受ければ仕様公開が有料会員限定だったり、適合試験を受けないと公開できないとかになっています。個人の実験の範疇ならまだしも、勝手に仕様やソースコードを公開したりブレークアウトボードを頒布したりするとライセンスの問題が発生しそうです。
しかし、ethernet/ipなどではオープンソース実装でMITライセンスになっているeeip.dllがあったりします。また、RX72Mマイコンではethernet/ipやetheeCAT適合試験済みのサンプルコードが配布されており、使用できてしまうことになります。
まえがき
PLCは工業用の自動制御で用いられるものですが、電機製品の自動計測などにも用いられることがあります。
今どきのPLCはEthernetを搭載し、リモートIOやSQLサーバーと繋がったりします。その通信規格は多数あります。
0 シーケンサ（PLC）とリモートIOの接続
よく聞く「シーケンサ」とは上記写真の三菱電機のPLCの製品名をいいますが、国内シェアがあまりにも高いため、日本国内ではPLCのことをシーケンサと呼んだりします。
昔の電気実習では、プログラミングパネルとかいう専用端末でラダーを書き込むようなものでしたが、今どきはEthernet経由での書換やFTPサーバへのログ収集等が可能です。シーケンサにはリモートIOがつけられるようになっており、本体と離れた場所に入出力ポートを設置できます。以前の通信手段はRS485ベースでしたが、最近はEthernetベースへの通信への移行が進んでいます。LANケーブルで繋げられる方が圧倒的に楽で、通信速度も有利です。
Ethernetベースの通信規格の代表にMODbusTCPがあります。
MODbusTCPにはリモートIOだけでなく、計測器やリモートセンシングユニットもあり、意外と多くの機器がつながります。シーケンサを用いずともPCベースのソフトで、センシングユニットからのデータ収集と自動化用途にも使える便利な規格です
とはいえPLCの通信規格には完全に汎用品が流用出来てPCでのエミュレーションが可能なものから、事実上ケーブルしか利用できない場合までさまざまです。まずはRS485ベースの通信規格を振りかえった上でEthernetベースの通信規格について分析していきます。
１ RS４８５ベース
代表格には、CC-Link、MODBUSなどがあります。従来各企業独自規格だったものが、RS232の派生規格である2線式RS485バスで数珠繋ぎできて、マイコンやPCとの相性がよくリモートIOの実現が容易です。
・伝送速度11.5k~10M
・成端、古くは専用線やUTP・多芯ケーブル＋単なる端子台、今風な設計だとe-con端子という共通端子
・絶縁:低速な差動信号で雑音耐性は極めて強いが、信号線と端末は絶縁されていないので電気雑音や電位差がのれば弱い。
・NW形態：基本的には１直線の数珠つなぎで終端抵抗が必要。
正規の方法ではリピータを介して分岐するが、少デバイス、低速、短距離であれば電線を分岐しても動きはする。
・長距離対応：近距離な10Mbpsですが、伝送速度を落とせば何キロも届く規格があります
（１）CC-Link
日本国内で圧倒的シェアの三菱電機の規格です。RS485ベースのオープンフィールドネットワークです。Ethenet化により、中古品・未開封の予備品も大量に放出されているので手っ取り早く試しやすい規格です。物理的規格はRS485を準用していますが、仕様書はCCLINK協会会員（企業会員のみ）でしか手に入らず、解析しても公開はNGです。
（２）MODBUS－RTU
1979年にModicon社が開発したものですが、仕様が公開されライセンス料金もなく、RS485がそのまま使えることから業界標準となりました。純粋なバイナリデータを送るMODbusRTUと、ASCIIコードを送ることでDebugを容易にしたMODbusASCIIが存在します。
他に,CANopen(rs485でもないけど)、devicenet、profibusなどなどありますが今回の主題はethernetなので割愛します。
３ Ethernetベースの通信規格と実装上の違い
ようやく主題ですが、1999年以降、PCでEthernetが普及したことからシーケンサでも導入されるようになってきました。おおむね以下の特徴があります。
・伝送速度：100M~1Gbpsで接点情報や計測データの送受信には十分。
・絶縁:全端末が回線から絶縁されており、EMI，EMS共に高い。
・成端：Cat5eケーブルとRJ45なら容易に成端できるし、電気屋で買ってもよい。
・NW形態：HUBにつなぐだけ、規格によるがリング構成もスター構成もethernetで可能な構成は基本的に可能
・長距離対応：UTPでも85ｍ、SFP対応HUBなどで1000baseSX・LXに変換すれば長距離かつノイズ影響がなく伝送可能なものもある。
・実装次第ではPC用のNWと混在可能、（セキュリティの問題で実際には分離されることもありますが、PC用のNW資産が転用できることは大きい）
・規格によってリアルタイム性と実装容易性が異なる
Ethenetではリアルタイム性が厳しいため、リアルタイム性を担保するために独自プロトコルでの実装が行われる場合がありますが、実装レベルによってNW資産の流用やソフト開発が背反となってしまいます。
代表的な規格には下記のようなものがあります。
２）各規格の実装上の違い
L５（session層）での実装：MODBUS、EtherNet/IP、CClinkIE Fieldbasic
Socket通信によるコマンドレスポンスを考えた場合、OSIでいう4層のTCP/UDP以降で実装されています。MODBUSとEtherNet/IPに関しては同様にTCP/UDP上で実装されており、通常のTCP通信ができる機器であればあらゆるものが利用可能です。メディアコンバータでの光ファイバーへの変換や、(セキュリティや信頼性を一旦目をつぶれば)、無線LAN経由やVPNからでもつながる無線リモートioとかの可能性は秘めています。
PCや計測器などのTCP/IPネットワークとの混在も可能です。
シーケンサには、CPU自体が上位サーバへと通信するためのEthernetポートと工業用フィールドNW用のポートが別々にあり、混在できない場合は別回線で引く必要があります。自動計測だと同じ場所にMODbusのリモートIOとsocket通信の計測器が設置されたりしますので、Ethernet化したのに線が減らないということになりかねません。TCPヘッダは最小64バイト（内データ46バイト）であり、16bitで足りるような接点情報を送るには巨大なオーバーヘッドが発生します。コマンドレスポンス動作のMODbusTCPではリアルタイム制御は規定できません。
原理上はRXマイコンでもM3sT4tinyやLWIPを利用して実装可能です。
L３（NW層）での実装： Profinet（RT）CClinkIE_Field＆CC
ネットワーク層の専用プロトコルスタックを導入する必要がありますが、TCPIPを使用しないためオーバーヘッドのない高速通信が可能です。これにより100us単位でのリアルタイム制御が可能です。マイコンではM3sT4tinyを含むTCPIPプロトコルスタックにあたる部分を自力実装乃至改造しなければなりません。PCや計測器などのTCP/IPネットワークとの混在も可能ですが、TCPではないためL3スイッチは使用不能でL2のスイッチングHUBやケーブルは流用できます。
リモートIO用の線を別に引く必要はありますが、そもそもがセキュリティ上の問題から本番環境では混在させられない場合もあり、あまりデメリットではなかったりもします。
L２での実装：EtherCAT・CClinkTSN（classB）・Profinet（IRT）
専用MACを使う規格ではスレーブ側はPC搭載の汎用Ethernetは使用不能で専用MACを外付けする必要があり、その上位プロトコルをすべて実装する必要があります。（EtherCAT専用MACを搭載したRx72mマイコンが存在します）専用HWを用いるためマイコンのリソースに関係なくリアルタイム通信ができる利点はありますが、L2スイッチすら使用不能で、LANケーブルくらいしか流用できないでしょう。リアルタイム制御が必須のFAロボットなどでは通常のTCPでは耐えきれないので独自規格となっております。
NWトポロジは、基本はデイジーチェーンです。専用HUB（正確には分岐スレーブ）で分岐もできます。通常のTCP通信混在は規格によります。CClinkTSNではIEEE 802.1AS（TSN）HUBを使えば混在可能ですがEtherCATは無理です。EtherCATのリアルタイム制御に刺激されてProfinetやCClinkの拡張が出てきた気がします。
TCPでのキャプチャができないので、解析等は困難です。
物理層にethernetを使っているだけな状態です。
（３）ライセンスの違い
基本的に仕様が公開されていて、無条件に使用可能なのはMODbusTCPだけです。それ以外は本当に不明です。各規格で「オープンなネットワークです」と言っているものの、無料で使えるわけではないし成果物をネットに上げることもできません。有料会員にのみ仕様を公開し、適合試験を受けたもの以外は世に出さないことで相互接続性の確保や、粗悪品の氾濫によるブランドイメージ棄損を防ぐためです。（だからAliexpressで売っている怪しいリモートIOはMODBUSTCPであり、ほかの規格はほぼ見当たりません）そのまま受け取れば、仕様やソースコードを公開したりブレークアウトボードを頒布したりできないはずです。
しかし、ethernet/ipなどではオープンソース実装があり、MITライセンスになっているeeip.dllがあったりします。また、RX72Mマイコンではethernet/ipやetheeCAT適合試験済みサンプルコードが配布されており、使用できてしまうことになります。
（３）各規格の解説
・MODbusTCP
MODbusのTCP版です。PLC側がマスタで、リモートIO側がスレーブです。TCP/UDP上で動作し、マスターとリモートで1対1のコネクションを張り、スレーブはマスターからのコマンドレスポンスでしか動作しません。実装が極めて容易、仕様が公開されていてライセンス料金がないです。
PLCだけでなく、データロガーや、リモートセンシングユニットの通信に用いられていて、PLCとは無関係にPCと計測器の通信用にも転用されていたりします。TCP通信なのでPCとの混在は可能です。
1999年策定と良くも悪くも古い実装であり、マイコンに容易に搭載可能でブロードキャストも使用しないのでNWの輻輳を招きません。反面、送受信データはすべて平文でセキュリティが存在しない、端末が増えるとコネクション数が増加、送受信するレジスタの値は機器ごとバラバラでマスター側で割り付けるアドレスを管理する必要がある。大規模なシステムだと構築が苦痛という弱点もあります。Amazonやaliexpressで、「TCPIP制御リモートリレー」的なものが売られていますが、MODbusTCPであることが多いようです。PLC用途としては信頼性を欠く製品もあるのが現実です。
・EtherNET/IP
主に北米で人気な産業用イーサネット規格であり、PLC側がserverで、リモートIO側がclientです。プロトコルはCIPですが、MODBUS同様TCP/UDP上で動作します。
・TCP通信との混在が可能
・コマンドレスポンス動作だけでなくサイクリックI/O通信も可能である程度のリアルタイム性がある。
・送受信するデータは、インスタンスIDなどがあり、マスター側でアドレス計算をしなくてよい。
・clientごとのEDSファイルをスキャナに読み込ませる必要があり、これによって機器情報が把握できる
といった時代に合った要素がでています。セキュリティ機能も実装されましたが実際に有効になっている機器は少ないのが現状です。とはいえ仕様上可能なのは重要です。
用語変更が起きておりかつてはPLC側がマスタ・スキャナ・オリジネータ、リモートIO側がスレーブ・アダプタ・ターゲットなどと呼ばれていました。各社説明書に表記の揺れがあり、同じClientの設定なのにアダプタ、スレーブ、クライアント、ターゲットなどとメーカーごとに設定すべき名前が違うため複雑怪奇と化しています。(https://www.odva.org/news/odvaが仕様書における用語を改正―より包括的な産/）ようやく改正されましたが、市場に出た機器の設定項目は変えられないでしょう。
・EtherCAT
産業用イーサネットですが、スレーブ側にdatalink層の専用MACを使用してマイクロ秒単位の高速リアルタイム通信を実現するものです。トークンリングのように全端末でパケットを回しながら通信します。
マスタ側は汎用PCでの実装が可能ですが、スレーブ側は専用MACが必要で、NW中にL2スイッチは存在できません。マイコンをスレーブにする場合、専用MAC搭載品か外付けする必要があり、TCPは使えませんので、ドライバやミドルウェアをすべて構築することになります。
それでもMicrochipのEtherCATMACのLAN9252を使い、RaspberryPiでEtherCATを実装することなどが行われているようです。結局はLinuxボードならドライバとAPIを持ってこれてしまえばかなり高度な操作も容易にできてしまいます。そういったAPIはどういうライセンスなのか？不明です。マイコン内蔵MAC+メーカー提供ライブラリなら実装記事を出しても良いのか？
・PROFINET
こちらは欧州ではやっているらしいです。NT/RT/IRTで実装が異なり、RTではL3スイッチが使えず、IRTではL2スイッチもダメです。
・CCLinkIE field basic
三菱電機のシーケンサの規格です。CClinkの他の規格に比べてリアルタイム性は望めないものの、L5で実装されており通常のEthernetの機器が使用でき、混在も可能なのが大きな利点です。ただし、マスター側はブロードキャストを行うため、大規模なネットワークでは輻輳の原因となってしまいます。Wiresharkで解析することも可能と思われますが、仕様がCClink協会会員限定公開なので、勝手に公表することはできないでしょう。
・CCLinkCC/IEF
三菱電機のシーケンサの規格です。L３で実装されておりL2スイッチまでのEthernetの機器が転用できます。Ccはシーケンサ相互の通信用で、IEFはリモートio等のフィールドNW用に分かれています。
・CC-Link IE TSN
EtherCATを意識してか、リアルタイム性の高い通信規格として登場しています。ClassAでは通常のMACが使われておりL2スイッチも使えますが、ClassBでは専用MACとなります。
4結論
MODbusTCPはライセンスの問題なく実装でき、難易度も低いことから、Rx66NマイコンをMODbusTCPクライアントにしてシーケンサに繋ぐことを目指します。
RX66n/Rx65nマイコンでTCP/IP通信（LAN8720＋M3S-T4-Tiny）使用法
RX66n/65n＋LAN8720＋M3S-T4-TinyでTCP/IP通信に入っていきます。
LAN8720の動作確認から始めます。
⓪HW設計 （https://meron33.hatenablog.com/entry/2026/05/03/214631）
①LED点滅 （https://meron33.hatenablog.com/entry/2026/05/07/150319）
②シリアル通信（https://meron33.hatenablog.com/entry/2026/05/10/114522）
③TCP/IP通信 ＜－今回
今回の目標兼目次
０ NW構成、HW構成
１ Ethernet物理PHY＿LAN8720のピン設定とアドレス。
（１)物理PHYには２つの信号線がつながれている。（RMII/MIIとSMI）
２ SMCによるethernetDriverの導入と設定
（１）「M3S-T4-Tiny」「LWIP」ミドルウェアは2つある
（２）まずはM3S-T4-Tinyから学べ
（３）FITドライバ導入
①SMCでのr_t4_rxの導入
②r_ether_rx設定
④r_t4_rx設定
３DHCP取得に向けて（まずは基本）
（０）LAN8720Aモジュール接続と物理アドレスの確認
（１）LINKUP/DN検出とDHCP取得 ②セクション変更
③LINKUP/DN検出
（２）DHCP取得コード
４ブロッキング送受信（FEVR）
５ノンブロッキング送受信（NBLK）
６ノンブロッキング送受信のハーフクローズ対処とkeepallive
７ソケット通信でコールバック
今回の参考資料
M3sT4tiny導入「RX ファミリ 組み込み用 TCP/IP M3S-T4-Tiny 導入ガイド」（：https://github.com/renesas/rx72n-envision-kit/wiki/1-Ether-TCP-IP#セミナ資料）の通り進めていきます。開発者直々の説明書です。
以上の手順で進めつつ、Rx66nやLAN8720用の解説とさせていただきます。
Ethernetを使用する上での前提情報が非常に多く、TCPIP通信に最低限必要な情報の個人的な調査の記録として残します。誤り等ありましたら申し訳ありませんがご指摘ください。
今回はM3sT4tinyを使いますが、2025末で開発終了で新規採用非推奨。とはいえ、20年以上h8、M16、sh、Rxなどのマイコンを、強いては日本の産業界自体を支えたtcpipプロトコルスタックです。情報量が多いため、学習用に使用させていただきます。開発終了お疲れ様ですが、もう暫く、使わせていただきます。
０ NW構成、HW構成
（１）NWへの接続
Ethernetを扱うので、DHCP有効のブロードバンドルーターを用意します。（WANは接続せずLANのみの接続にとどめます）
PCとLAN8720搭載済みRx66n基板をルータに接続するだけです。
TCP通信以外の方法でデバック出力が必要ですので、Rx66nのSCI0は使います。
正確には、「LAN8720の直接の通信相手が、100/10BASE-TX全二重通信、Autonegotiation対応」であれば、固定IPでPCに直結できます。
ただし、今回はEthernetの物理層ICを制御する関係上、物理層のAutoMDI-Xから、ARP、DHCPの失敗などの可能性があります。
問題の切り分けが困難となるため、多くの通信規格に対応している可能性の高い、ブロードバンドルータ（DHCP有効化済み）で最小構成で構築することを推奨します。
（※特にPC直結ではMDI-Xが無かったり、FWに防がれる可能性があり通信できない可能性が高い等々・・・どのような通信障害を起こしうるのかを説明しようとすると１記事分に膨れ上がりそうでしたので割愛します。）
（２）LAN8720A配線
HWに関してはHW編の通りです。（https://meron33.hatenablog.com/entry/2026/05/03/214631）
下記サイトを参考に以下の改造済みLAN8720Aモジュールを使用（http://www.rvf-rc45.net/wordpress/?p=3023）
・MDCのVCCへのプルアップが抜けてる
・RMMID_Rx_ERが出ていないので、あいてるNC端子にとばす
１ Ethernet物理PHY＿LAN8720のピン設定とアドレス。
モジュールを買えば考えなくてもつかえる。<-甘い考えでしたという話。
r_ether_rxの設定に出現する「PHY-LSI adddres setting for ETHER0」は物理PHYもSMIのアドレスに相当、物理チップ依存です。マイコンは関係ありません。物理PHYとMACがどのような構成になっているかを理解しないと使えません。
（１)物理PHYには２つの信号線がつながれている。（RMII/MIIとSMI）
物理層とMACを分離する理由
通信には、電気、光、無線などが用いられますが、これらはアナログ信号です。３．３V単一電源では動かない場合もあります。また、同じ光でも単芯・２芯、SM/MM、使用波長にかなりの種類があり新規格も次々出ます。一方MACより上位は論理回路で構成されているので容易にマイコンに内蔵できます。
物理層ICを分離して通信規格を共通化することで、物理層の再設計なく通信媒体を変えることができるうえ、ソフト側では通信媒体を考慮せずに使用することが可能となります。
需要が多いPC用のUSB接続NICなどだと、コスト削減のための1chipだったりもします。新規格出たら再設計だと割り切っているのでしょう。
物理PHY－MAC（マイコン）は2つのバスが接続されています。
・MAC
マイコン側のデータリンク層の処理を行い、NW層以上はドライバで行われます。
MACに紐づく識別番号がMACアドレスです。
・MII/RMII
Ethernetパケットを入出力します。RMIIへの入力はポートがLINKOFFの場合でも送信されるためMDCでの状態検出が必須です。
RMII(50MHz)/MII(25MHz)です。
・MDC/MDIO（SMIバス）
MACと物理PHYの制御バスです。MACはこのバスを介して物理PHYの状態を検出します。一つのSMIバスに複数のPHYを接続可能なため、(QSFPではSGMII×４にSMI×１)
物理PHyにはSMIアドレスがあります。I2C接続のEEPROMがと同様、物理PHYのアドレス指定をしないとケーブルの接続状態すら検出不能です。
SMIアドレスは以下のパターンがみられます。
①物理PHYのアドレスは１つのみで。データシートを確認してドライバに反映。
②ピン設定等で何種類か設定可能で、設定の後にドライバに反映
③SMIアドレス自動検出可能なMAC-物理PHYで、ドライバで自動検出に設定する
これはRX以外のマイコンでも、パソコンでも、自動か手動か、（またはドライバ作成者が行ってくれているか）はさておき、同じことが行われています。
（２）LAN8720のSMIアドレスの確認
LAN8720 は前述の②にあたり、物理PHY（SMI）アドレスを「０」か「１」に設定可能。RXER／PHYAD0pin「H＝１」「L=０」となります。Waveshareのボードは「PllUP」されているので、どのようなマイコンで使用しても物理PHYアドレス設定は「１」です。
中華のコピー品も、プルアップでアドレスは１が多いです。抵抗の未実装やクラックなすると、起動時のノイズで１／０が決定され動いたり動かなくなります。動作実績のある環境で差し替えるなら良いですが、最初の導入で使うのはリスク大です。
別の物理PHYのICを使う場合はそのデータシートに従います。ピン設定や通信による初期化が必要です。
物理アドレスの確認方法と異状状態の確認は正しいと思われる物理PHYアドレスを設定して、LINKUP/DNを確認します。
２ SMCによるethernetDriverの導入
失敗したら動く状態まで戻る必要があるので、 まずは前回のプロジェクトファイルをフォルダごとコピーして取っておきます。
SMCにてFITの通信でTCP関連を探すと以下の２つが出てきます。
・EthernetDriver「r_ether_rx」＋TCP/IPプロトコルスタック「r_t4_rx」
・EthernetDriver「r_ether_rx」＋lwIP TCPIP「r_lwip_rx」
※lwipは通信で絞り込むと出てこなくなります。（通信に未分類？）
※FITのDL選択で「RXのみ」「最新のみ」にするとDLされない場合あり）
（１）「M3S-T4-Tiny」「LWIP」ミドルウェアは2つある
①「M3S-T4-Tiny」は従来のRXで広く採用されていたプロトコルスタックで、開発者本人がGitHubに開設を出しております。「https://github.com/renesas/rx72n-envision-kit/wiki/ホーム」こちらを参考に進めていくことができます。比較的RXでの情報があるのが利点ですが、2025年末で開発終了、FreeRTOSとの相性悪い、今後新マイコンへの対応はないなど厳しい状況。
②「LWIP」はオープンソースの組込み向けTCPIPプロトコルスタックのRX移植版です。最近はやりのfreeRTOSとの親和性もよいのですが、RXでの情報が極めて少なくいきなり挑戦するのは難しい。
（２）まずはM3S-T4-Tinyから学べ
今後M3s-t4-tinyの新規マイコンへの対応はないと思われ、対応プロトコルも多いLWIPへは将来的な移行が必須です。また、EthernetDriver「r_ether_rx」はどのみち使います。
HWが正しいかも不明、ソフトの情報が手探りでは進むことができないです。いったん「M3S-T4-Tiny」で開発してHWデバックと知見を得ることとします。
（３）FITドライバ導入
DHCPでやります。その理由は
※LINKUP/DN検出は 「HW＋r_t4driver＋ t4_r4_rxのcallback関数設定のみ」
※DHCPは「 上記＋DHCP設定」
※ソケット通信は「上記＋全設定」
にそれぞれ依存、デバック時点ではDHCP設定での動作確認が必要。いきなりソケット通信から始めると、HWかドライバか、プロトコルstackか単に文字列操作間違えているのかわかりません。
①先ほどのFITでのr_t4_rx選択して導入する。（Ethernetドライバr_ether_rxも同時導入されるはず）
②r_ether_rx設定
とかありますが、マイコンによってEthPHYとEthERの選択が違います。不明なので試しました。（65nも要調査）、商法がない初めて使うマイコンはこれ調べる試すしかなく・・・
Ethernetinterface：RMII（LAN8720はRMII専用）
「PHY-LSI adddres setting for ETHER0」：「1」（waveshareLAN8720モジュール）
（同項目の説明：RSK+RX65Nは30、RX７２Nは0というのは、targetボードの物理PHYアドレスがそうだというだけです。GR-ROSEはRX65ですが恐らくまた別の値です。）
「the register bus of PHY0 for ETHER 0/1」：「Use ETHER0」（Rx66nの場合）
「The link status is detected」：「UNUSE」
(※LAN8720モジュールから該当ピンが引き出されていないので必須
UNUSEにすると10msのポーリングによって接続検知する)
「Use Non Blocking」：「UNUSE」
・r_ether_r端子設定（先ほどの画面の下の方の続き）
ここでピン設定すれば、端子設定が自動で行われる
・REF50CK0端子 を「使用」（RMII送受信用のクロック）
・RMIIIxxxの8PIN分 を 「使用」
・ET0_MDC/ET0_MDIO を「使用」
※PMGIO＿MDC/MDIO「不要」
R_ether_rxで物理PHY[とのNBLK通信を有効にした時にPMGIに切り替わるようですがちょっと差が理解できていません
※ET0_LINKSTA：「不要」
「The link status is detected」：「UNUSE」にしたので使用にすると設定と不一致で動かない可能性があります。
※ET0_WOL：「不要」
WOLパケット受信時に、物理PHYが反応するので、そのピン割り込み入力です。
とりあえず最小構成で挑みます。
③r_t4driver設定：設定できる項目なし
④t4_r4_rx設定
「channel number your system has 」：「１」
「Enable/disable DHCP」：「１」
「system callbackfuncton use」：「１」
「system callbackfuncton name」：「system_callback」（default）
「TCP REPOID1 port number」：「1024」（通信端点1受信ポート番号default）
「TCP CEPID callback functino use」：「１」
「TCP CEPID callback functino 」：「t4_tcp1_callbk」（通信端点1のCB）
一旦はこの設定でDHCPまで行けるはずです。
２DHCP取得（まずは基本）
（１）LINKUP＿LINKDOWN確認とDHCP取得
①mainにコードを入れる
mainに入れます。ただ、TCPはメモリを激烈に食うのでセクション変更が必要なので、いったん最小限のコードを追加し（もはやだいぶ大規模ですが）、CALLBACK関数を用意してビルドが通るようにします。Systemcallbackは参考元サイトからの引用です。
[code]
[code]
ビルドするとこんなエラーが出るはずです。
RAM領域に入らないので、拡張RAM領域に個の変数を覆いやる必要があります。
セクション変更が必要なのですが、CS+CCはわかりにくいところにあります。
②セクション変更
プロジェクトツリーの「CC-RX（ビルドツール）」をダブルクリック
「リンクオプション」タブ-＞
「セクション」-＞「セクションの開始アドレス」をクリック
「セクションの開始アドレス」クリック後に出る「...」をクリック
これでセクション設定がようやく出る。（隠しコマンドか？）
B_ETHERNET_BUFFERS_1
B_RX_DESC_1
B_TX_DESC_1
選択して「↓D」を押すと下に移動する0x008・・・以降に移動してしまえば拡張RAMに追いやれる。
これで再度「F7」でビルドすれば通るはずです。
正常終了したならば「f6」でビルド書き込み
物理PHYと、r_therドライバが正常作動していれば、LANケーブルの抜き差しで、LINKUP/DNするはずです。
必ず、LINKUPとLINKDN両方が行われることを、HUBの別ポートでも確認してください。
これは、SMIが通信不能の状態でもLINKUPだけはします。
LANケーブル接続状態でマイコンの電源を入れると、ポート状態に関係なくRMIIにDHCPパケット再送します。そのうちルーターに届いてDHCPが通ります。
また、スイッチ側も頭がいいので同じポート、同MACアドレスの機器のLINKが切れても、一定時間で再接続されたら通信再開とみなして再度通信可能になります。
物理PHYのアドレス違いなどで、SMIバス通信不能でも、パケット通信ができてしまいます。LINK状態検出ができていないので、HUBの別のポートにさしたり長時間LINKDNすると二度とLINKUPしません。
LINKUPとLINKDNが行われることを、HUBの別ポートでも確認
すれば正常であることを確信できます。
この現象で私は２日はまりました。データシートは端からは時まで読めと言われてたのに・・・
（２）DHCP取得
さて、M3S-T4-TinyのDHCP設定が正常であれば、そのままDHCP取得を開始し
IPADDRが返ってきます。
PING発信すれば応答が返ってくるはずです。
・下記のようにLINKUPするが、DHCPが振られない場合DHCPサーバとの接続ができない。又は設定が誤っている。何をしても駄目な場合は固定IPに変更しLINKUP確認とPINGを試します。
LINKUPすらしない場合はLAN配線（特にAutoMDIX）やそもそもRMII等の配線が間違っている可能性があります。
SMIアドレス違いの場合は逆にLINKUPはするが、LINKDNしなくなります。
４ブロッキング送受信（FEVR）
ついにソケット通信に入っていきます。ここからは参考サイトにおいてある「組み込み用TCPIPの活用法.pptx」に従っていきます。
先ほどの最小限プログラム109行目「//TCP_ProtocolStack_init」以降に次のコードを追加します。
tcp_acp_cep：ソケット通信接続待ち
rcv_data_size：ソケット通信データ受信（ソケット接続先からのデータを受信）
tcp_snd_dat：ソケット通信データ送信（接続先へのソケット送信）
このコードsizeof（）をstrlen（）に変えています。
char str[32]等で宣言した場合、sizeofの戻値は常時32です。tcp_snd_datは「\0」を超えての未初期化のメモリ領域の値を送信します。
strlen()は配列の要素[0]から次に出てくる「\0」までの数を計算するので正常に作動します（printfにしても結構こういう穴がたくさんあります）
解説パワポではできているので、恐らくE2studioでは正しく実行されるのでしょう。
[code]
[code]
「F7」でビルド出来たら「F6」でダウンロードと実行します。
Eth0:wait Rcvｄが出ている、かつDHCPアドレスが出たところで、そのアドレスにteratermで接続します。接続設定はIPADDR->other->port1024 と選択して接続します。
tcp_acp_cepが実行された後でないと、接続してもマイコンはわかりません。
SCIへのprintfなどで終了を確認する。
teratermで接続して文字列を送ります。2バイト文字を送る嫌がらせもしてみましたが、teratermで送信したのち、SCIで出力され、同じ内容がteratermにコールバックされています。「tst日本語\n」が12バイトで処理されているので、見えない漢字INと漢字outもしっかり処理されています。正しく動いています。
これにて、ブロッキング通信での通信確認を終了します。
この通信方式はブロッキング通信と言い、接続待要求やメッセージ受信、送信など処理終了するまでひたすら待つ構造になっており実用的ではありません。
また現状では、電源ON後、DHCP、接続待ち、データ受信、データ送信の順にしか動かず、1回しか送受信できません。毎回teratermを立ち上げなおして厳しいです。
次はノンブロッキング通信に着手します。
５ノンブロッキング送受信（NBLK）
まずは原典のパワポにししたがって入れていきます。先ほど追加したブロッキング通信はノンブロッキングと共存できないので削除します。下記コードに従って
元の109行目の先に2行、空にしてあったER t4_tcp1_callbk(）の中身を入れます。
[code]
[code]
この状態でブロッキング通信同様、「Eth0:1:ACP_NBLK...」かつ「DHCPアドレス付与後に」teratermで接続します。接続設定はIPADDR->other->port1024 と選択。
文字を入力して改行コードを送るたびに、受信してコールバック、かつ再度受信待機に入ります。
ただし、まだ問題がります。
先ほどの接続状態でteratermを閉じると、最後に送信したデータが流れ続けて暴走。再接続のプログラムを組んでいないので、LANケーブルを抜くと、二度とLINKUPしません。今回はソケットクローズしていませんが、RX側でTCPソケットでクローズすると再接続可能まで１分待ちます。
（Rx側でクローズするとteratermが閉じられてめんどうなのでしてません）
５ノンブロッキング送受信の（ハーフクローズ対処とkeepallive）
・ソケットクローズ時間の短縮
現状はポートCLSすると再接続まで60秒待たされます。TCPの仕様によるものですがLAN内での利用にとどまるのであれば１ｓに丸めてしまうこともできます。（リモート接続等で時間がかかる場合は頻繁に接続断となるので注意）
SMCの「r_t4_rx」でmax segment life time 「60 ->1」に変えます。（後述）
・LINKDOWNを伴わない通信途絶検知の検知と自動close
いろいろな方法がありますが、LinkDownを伴わない通信途絶に対応できるよう、
SMCの「r_t4_rx」 で下記のとおり変更します。
Keepalive「有効」
max segment life time 「60 ->1」（コネクションクローズ後の待ち時間）
keep-allive start time「7200-＞5」（keepAllive送信開始時間（default2時間））
keep-allive interval time「10->1」（keepAllive送信間隔）
keep-allive sendcount「10」（切断判断回数）
標準の2時間経過後に10sおきにパケットが送信で切断を検知では、切断発生時に2時間待つことになります。（そんな機器ありますね、〇置きのPW339〇の特定のファームとかね。）LAN内のPCとの通信であれば、通信の輻輳より利便性を取ってしまうことが可能です。
・LINKUP時の接続操作導入
・ハーフクローズ検知と自動close
先ほどのコードにて実は搭載しています
ハーフクローズ時は0バイト受信の無限ループに陥るため、0バイト受信時には強制的にクローズします。39行目をコメントアウトして、38行目のコメントアウトを削除
以上構成でTCP/IPでのコールバック通信ができていると思います。
７ TCP/IP経由でのリレー制御作例と今後の課題
（１）課題
・任意にパケット送信ができない
現状はソケット送信後にすぐ受信待機に入る形でパケット送受信を実現しています。
一問一答方式での通信で。受信を待たずに送信するためには、受信待ち取り消し後に送信して、再度受信待ちに入る必要があります。
・LWIPへの移行
また、テキスト通信以外の通信を行うためには、M3s-t4-tinyでは限界があります。かつてはFTP接続などが開発ボード販売会社等から公開されていましたが、サポート終了に伴ってアクセス不能になりつつあります。
今後は、LWIPへ移行していく必要があります。LWIPに移行できればNTPクライアントやWEBserver。EtherCATなどの導入も可能となりそうですが、マルチタスク処理の必要瀬宇井が高まるためOS導入が視野に入ってきます。そうなると128K制限では厳しいか・・・
（２）TCP/IP経由でのリレー制御作例
現状の、TCPIP通信にてコマンドを送りって返答を得るプログラムを応用して、
試験としてTCP/IPで送った文字列に応じてPortD0～7の10を変化させ、リレーを制御するプログラムを作成しています。
計測器とかで言うSCPI通信（「VOLT 12.0」と送ると12.0Vが出力されるなど）に近い構成ですが、TCP/IP経由でリレーのONOFFが制御できました。
USBPDのシンクコントローラの設定電圧をリモートで変更しており、USBPD電源の自動試験に最適です。
長くなりましたがこれにて一旦終了です、
RX66n/Rx65nマイコンでシリアル通信（SCI）
RX66n/Rx65nマイコンでシリアル通信（SCI）
シリアル通信（SCIの歩調同期式通信機能）を用いてデバック出力可能な状態を作成します。Rx66NマイコンでTCP/IP通信を目指す一環としてのソフト編②です。
⓪HW設計 （https://meron33.hatenablog.com/entry/2026/05/03/214631）
①LED点滅 （https://meron33.hatenablog.com/entry/2026/05/07/150319）
②シリアル通信 ＜－今回
③TCP/IP通信 (https://meron33.hatenablog.com/entry/2026/05/18/121143)
今回の目標兼目次
１ スマートコンフィグレータ（SMC)でのFITモジュールの導入
（１）CMTでLED点滅のフォルダをコピー
（２）FITモジュールの導入
２ SCI送信
（１）1回だけ送信プログラム
（２）送信Q搭載プログラム
（３）printfの導入
３ SCI送受信（なくてもいける）
（１）SCI送受信キュー搭載 ※長すぎなので参考
（２）標準入出力のprintfは配列で文字化けする
４ 今回のプログラムは今後の開発の基本、バックアップ推奨
５ 重さは承知でprintfを使う理由
６ 課題
不完全な実装ただし、あくまで主目標はTCP/IP
M3S-T4-Tiny の開発者がrx72n-envision-kitでのTCPIP通信導入までを解説していただいております。（https://github.com/renesas/rx72n-envision-kit/wiki/1-SCI）こちらに沿って構成させていただきますが、マイコンの違いや送信cueの導入など、Rx66n/65nでの立ち上げ方法として残させていただきます。
１ スマートコンフィグレータ（SMC)でのFITモジュールの導入
（１）CMTでLED点滅のフォルダをコピー
前回のCMT_LED点滅
（RX66n/65nでLED点滅（CMT実装） - 電子計測通信徒然草）
のプロジェクトのフォルダを丸ごとコピーして使います。SCIの導入に失敗すると再度構築しなければならなくなります。コピーして使うのが重要です。
コピーしたら、「.mtpj」ファイルをダブルクリックするだけで開けます。
（E2studioは勝手にファイル移動できないです。移動したのがソフトにばれるとパス変更を促されて面倒）
スマートコンフィグレータ（長すぎるのでSMCとしておきます)でSCIモジュールを探すと２つ出てきます。初見ではどちらを使えばいいのかわかりません。SMCはこういうのが不便なんですよね。(SCI(scif)歩調同期モード
コード生成側に関しては、余談1参照)
SCIDriver（r_sci_rx)を使用します。
「Drivers」->「通信」-＞「r_sci_rx」を選択して設定に行きます。
・歩調同期式シリアル「Use ASYNC mode」 を Include
・SCIチャンネル0「include software support chanel」を Include
・SCIチャンネル0「include software support ・・・TEI」include
・「Transmit end int 」enable
としないと送信キューがつくれません。（SCIのコールバック関数が呼ばれるだけで、イベントフラグで処理を分岐します。中身を用意しなければ何も起きませんので安心して追加できます。）
・下の方の「リソース」、「SCI0」の端子設定を行います。
・「middreware」->「R_byteq」を編集します
protectqueを「USED」にしないとビルドできない。
これはデフォルトでsci_rx_configで送信・受信バッファそれぞれに80byteが割当されているためエラーになります。
以上行えばmainの構築が可能となります。
２SCI送信
（１）1回だけ送信プログラム
適切な初期化後に
uint8_t send_data[] = "Hello World\r\n";
R_SCI_Send(sci_handle, send_data, sizeof(send_data));
を実行してしまえば送信されるのですが、送信待ち処理とか送信キューが一切ないので連続実行すると落ちます。この辺でも同じ状態（https://community.renesas.com/cafe_rene/forums-groups/mcu-mpu/rx/f/forum5/42759/cg-sci）
この辺りはRX72ｎとずれていきます。
前回のCMTに以下の内容追加します。
SCI0で1回だけ送信プログラム（もう直接貼り付けは無理なのでgistです。）
[code]
[code]
以上実行すれば、シリアル出力にて１回だけ「HelloWorld」が出てきます。
これでは一回しか送信できません。なんだか中途半端なdriverです。
（２）1回だけ送信プログラム
複数回送信するためには送信Qの実装が必要です.。Q積むだけで実装が管理複雑になります。実装させると以下のようになります。
[code]
[code]
（３）Printfの導入
しれっと最後の行に追加してある「 my_sw_charput_function」が
システムコールバック処理のユーザー定義関数です。つまりprintfの出力先です。
sprintf -＞バッファに代入 -＞SCI送信キューに投げ込むと3行必要なものが
Printf()の一行で済みます。
r_bspの「enable stdio charput function」を有効にすると任意の関数に飛びます。
この関数が前述の 「my_sw_charput_function」です。SCI送信Qを作成済みなら送信Qに突っ込むだけす。
参考サイトに追いついたわけですが、その辺わかって出力先にしてねと書いてあります。1 SCI · renesas/rx72n-envision-kit Wiki · GitHub
※標準だとRx側にデバック用モジュールをincludeするとCS+CC上で見れるようになりますが、面倒なのでSCI0に流し込みます。当然Printf側に送信QUEUEを搭載するとではほかのSCIが制御できなくなる弊害や、連続送信するとQUEUEが詰まるなどあり、自力で組んだ次第です。
３ SCI送受信（参考）
(1)SCI送受信
TCPのデバックには、SCI＋printfさえできていれば実行できるので参考程度です。
printfを導入し状態で、受信Qもつけるとようやくコマンドレスポンスのようなことが可能となります。コマンドを仕込んでいます。
[code]
[code]
tst：「COMM_OK」を送る
cb:「文頭cbで送られてきた場合、受信テキストをそのまま返信する」
コールバックも効いているのでcbは2回きます。
ただ、受信文字列をそのまま printfに入力すると化けます。
（２）標準入出力のprintfは配列を代入すると文字化けする
これはprintfの送信バイト数計算がsizeof()で配列の全要素数を計算しているからでしょう。char str[32]とかに格納した文字数を計算する場合
sizeof(str)=32（常時）、strlen（str）＝文字数（¥0を含まない数）
となるのでこの辺で悪さするのでしょう。
配列に格納した文字列をprintfすると文字化けするので自作化関数が必要です。
また、連続送信を続けるとSCI送信が詰まって応答しなくなってしまいます。これが困るので自力でQUEUEを搭載しようと奮闘しました。
４ 今回のプログラムは今後の開発の基本、バックアップ推奨
1開発ごとにSMCのクロック設定からは時間を要するのと、開発の過程でコマンドを送って動作を変化させたり、内部状態を見ることは多いです。
SCI送受信プログラムは、TCPIP不使用のあらゆる開発の基本になるからです。開発の過程で軽量化で消すことはできても、逆は時間を要します。私のように趣味でやっていると開発時間は限られています。時短のためにこの辺りで、RX66N開発用フォーマットとして取っておくことを強くお勧めします。
※E2liteでブレークポイント指定すればその時点での変数の中身は見れますが、TCPコネクションの進捗とか、SD読み書きしてファイル内容が正しいかとかは難しいです？（本業の人は可能でしょうけど）増えているとはいえマイコンの書換回数も有限です。R8Cm12は開発用を数年使いまわしていたらリードバックベリファイにが稀にに失敗するようになったりしましたし。
５ 重さは承知でprintfを使う。
printfはとんでもなく重い。（余談２コードサイズ比較）複数SCIの使い分けもできていない。そもそもマイコンで
printf(”No%d浮動小数＝%f\n”,num,10.00);
みたいな贅沢な文字列操作はどうなのかということまりますが、TCPIPでデバック出力はこんなものまで出てきます。
少なくとも、tcpipプロトコルスタックのデバックができるまでは、printfが必要です。
SCIは複数ポート対応や、送信QUEUEの修正などが必要ですが。
TCPIPのデバックが主目標である以上、
シリアルやprintfは一旦置いて、次回はにTCPIPに王手をかけます。
余談
(1)コード生成（CG)のSCIドライバの特徴
CG版の場合は、SMC内でボーレート等の設定行います。
一見便利そうに見えますが、main関数で
R_Config_SCI0_Serial_Send("test\n",5);
を複数回実行すると送信が止まってしまいます。
これはCG版のSCIは送信中フラグ等を考慮していないため、送信途中で送信要求が来ると上書きされてしまう中途半端なコードが書かれているからです。BBSでも指摘されています。
コールバック関数の設定項目もありませんので、これを修正するためにはSMCで生成されたコードを編集する必要があります。ただし、SMCは実行するたびにコードを上書きしてくるので実用性がありません。
というか、そこまでして組むならば、自分でSCI組んだほうが速いです。FITで時短できる利点が・・・。
余談②printfはROMを10kB程度は食います。
M3s-t4-tiny：RAM0.2kB/ROM25kB
SCI：RAM7.8kB/ROM13kB
上記＋printfでROM55kB程度になっております。128K制限のCS+CCではなかなかに荷が重い。
他に例を挙げると
USBHID：RAM5.5kB/ROM21.9KkB
M3s-fat：RAM0.2kB/ROM6.5ｋB
SDHI：RAM0.2kB/ROM1.8ｋB
浮動小数オプション付printfは、fatファイルシステムより重い。シリアルデバックと併用すると20Kは行く、
Rx140の64ｋBとかだとなり厳しいので浮動小数オプション削除やsprintfにとどめるなどの工夫は必要です。
RX66n/Rx65nマイコンでLED点滅（CMT実装）
RX66n/Rx65nマイコンでLED点滅（CMT実装）
タイマー割込（CMT）を使用したLED点滅をおこないます。
Rx66N/65NマイコンでTCP/IP通信を目指す一環としてのソフト編①です。
⓪HW設計 （https://meron33.hatenablog.com/entry/2026/05/03/214631）
①LED点滅 ＜－今回
②シリアル通信（https://meron33.hatenablog.com/entry/2026/05/10/114522）
③TCP/IP通信 (https://meron33.hatenablog.com/entry/2026/05/18/121143)
M3S-T4-Tiny開発者様がrx72n-envision-kitでのTCPIP通信導入までを解説していただいております。（https://github.com/renesas/rx72n-envision-kit/wiki/新規プロジェクト作成方法(ベアメタル)）こちらに沿って構成させていただきますが、マイコンの違いによる部分の、Rx66n/65nでの立ち上げ方法として残させていただきます。
HWが完成しても早速TCP/IPとはいきません。renesasのEnvisionKitの説明でもCMT/SCI/TCPIPの順番が示されています。この理由を逆算して推定しますと。
・TCP/IP動作確認時点で、最低限1個のSCI（UARTつまりはRs232通信）送信、タイマー処理（CMT）が必要
（デバック時点ではprintfも必須）
・SCIのデバックにCMT実装が必要
・CMTを動かすには、Rx66nでまともにプログラムを実行できる環境が必要です。
初めて使うRx66nかつHWが正しいかも不明な状態でLED点滅させるまでが結構遠いのです。LEDつけるだけでも
（ポート定義）＝0XFF;
で点灯するはずですが、ポート方向レジスタは？IOでレジスタは別？そもそもポート定義はどうやってincludeする？不具合時には、探求がHWの間違いなのか、電源なのか、書き込みなのか、ソフト問題？、SMCってどこまでやってくれるの？
と手探りスタートになります。
今回の目標兼目次
１ 開発環境と初期プロジェクトの立ち上げ、
（１）CS+㏄のダウンロード
（２）初期プロジェクトの立ちあげ
２ スマートコンフィグレータ設定
（１）クロック設定、デバック設定
（２）コンポーネントの追加（IOポート設定とCMT導入）
３ mainプログラム
（１）なにもしないプログラムの実行
エミュレータ設定と実行
（２）バックアップは確実に
（３）LED点滅（CMT）
（４）ポート制御に便利な１行
１ 開発環境と初期プロジェクトの立ち上げ
（１） CS+㏄のダウンロード
ＣＣ－ＲＸ （ＲＬ７８、ＲＸ，ＲＨ８５０）系用をＤＬ
普通にインストールするだけです。安定してインストールできるので特に解説はありません、HEWは最近のRXでは使用できません※１
（２）初期プロジェクトの立ちあげ
① まずは基本となるプロジェクトを作成していきます
初回はCS+ for CC（RL78,Rx,RH850）を起動します。
②CS+CCを起動したら、
「ファイル」->「新しいプロジェクト」を作成
③プロジェクト作成画面
マイクロコントローラ：RXに選択してR5F566NDDFPを選択
アプリケーション（CC-RX）を選択（それ以外を選ぶ場合は要注意）
※空のアプリケーション：main関数が生成されなくて詰みます。（追加が面倒）
※C++アプリケーション：C++とCで一部ファイルの名前が変わるので、エラーで進まなくなります。
C++の場合mainの外で実行する#includeやグローバル変数の定義を、extern “C”{}の中に書かないといけません。標準で出力されるtypedfineをそのままコメントアウトするとエラーになります。なんという罠
FITで出力されるコードがC基準のようです。C++ではこの対応をしても、M3sT4tinyなど、膨大なファイルをリンクするプロジェクトの場合、エラーで進まない。
２ スマートコンフィグレータ設定
スマートコンフィグレータの立ち上げは、プロジェクト作成後左上に見える
「スマートコンフィグレータ（設計ツール」をダブルクリックで起動します。
初回はFreeRTOSを使うかが聞かれますが、CS+CCはkernelOnryなので無しで進めます。
（iot-referenceはE2studio でしか選べない）
ボード選択はカスタムボードにするほかなし
(rx66ntargetbordなら使えますが、Rx66NNHxFP(100pin)でしか使えません。選択してもボード内蔵デバッカにあったポート設定になるくらい。CK-RX65Nとかならサンプルプログラム走らせますし。あんまり使えない？）
（１）クロック設定、デバック設定
①クロック設定
動作確認は最小限で実施したいので内部発振にしますが、開発ボードは大概水晶発振子前提なので、内部発振の解説がない。
変更内容は
無効：メインクロック
有効：HOCO、LOCO（念のため、M16は低速使った気が・・・関係ないか？）
変更：MAINCLK24Mの発振子が基準だが、内臓HOCOは最大20M
PLLとPPLLのCLK元を内蔵発振切替と逓倍・分周比の再調整が必要
PLL （上側）：分周比x1、逓倍ｘ12
PPLL（下側）：分周比x1、逓倍ｘ10.0
CLOCKOUTの選択が外れているので、PLL出力を選択
USBCLKが48M、CACCCLOCKOUT25Mが合うようにすれば、周辺回路のクロックはあうはずです。
※USBは使わないが周辺回路があってないとここもずれるので確認）
※25M出力はLAN8720のクロックに使えるが、内部発振の場合は精度的に使用困難
②デバック設定
FINEでもJTAGでもよいですが、HWが未テストな場合は、FINEがピン数は少ないので、動作確認後にJTAGがよいと思います。
（２）コンポーネントの追加（IOポート設定とCMT導入）
IOポートも、CMTも、TCPIPスタックもあらゆる機能は、ソフトウェアコンポーネント設定で追加します。まずは「ポート」を選択して次へ進み機能を追加します。
出力設定と、一部ポートを１にしておけば、ポート初期化が行われた時点で[1][0]が出ます。 マイコンの初期化と、AVCC0・１が正しく行われていればです。
②CMTの追加
CMTはコンペアマッチタイマです。タイマーが特定の値になったらコールバック関数を呼び出す便利な物です。コンポーネントを追加したいときは緑の＋がついたところを押します。すぐ上に紛らわしい+ボタンがいて紛らわしい。
ソフトウェアコンポーネントでCMTを追加すると設定がいじれます。
正直LED点滅だけなら自分で分周比を設定して、割り込み内でフラグ管理をしたりするのですが、TCPプロトコルスタックはCMTに依存なので動作確認が必要です。Include software support CMT…の0～3のON/OFFは、CMT割込中の割り込みを許可です。
ON/OFFの挙動がつかめていないです
初期でCMTが出てこない場合、FITドライバのインストールをすれば出てきます。下記手順です。「Rx driver pakage」のみ表示をチェックしているとLwIPがDLされないとかあって結構癖があります。
CS+CCの起動時にログインしないと、ダウンロードに失敗する場合があります。
毎回ログインする必要はないのですが、たまにFITをインストールするときにログインします。
コード生成を押すと、セクション設定の警告が出ますが、「はい」でいくしかないです
３ mainプログラム
ようやくmainルーチンに入っていけます。
追加したコンポーネントのincludeするべきものや、参照すべき関数が反映されません。
PORTとはCMTのヘッダファイルとかにコメントがあるわけでもなく、「FITドライバの説明書を読んでね」です。
※r_smc_entry.hにIOポート定義には「"Config_PORT.h"」などのSMC生成コードのヘッダファイルが含まれます。ただし、すべてのヘッダファイルが含まれているわけではないので。別途インクルードが必要ですが判別がつきにくいです。
（１）何もしないプログラムの実行
Cアプリケーションで立ち上げたことを前提に進みます。C++だとこの後詰みます
Main前後に以下追加します。
#include "typedefine.h" //モダン型宣言
#include "r_smc_entry.h"//SMC定義のinclude
void main(void){
R_Systeminit(); //SYS_init
While();
}
②E2liteなどのデバッカ使用時には、エミュレータ設定が必要です。
デバック設定で使用しているツールを選択、
・メインクロックソース：HOCO
・動作周波数：120.0
・内蔵フラッシュメモリ操作時にクロック操作・・・：はい
・エミュレータからの電源供給：はい
・通信方式：FINE（SMCの設定に合わせる）
③デバックツールへのダウンロードと実行
最低限E2liteを所有していれば、「F6」か「デバックツールへのダウンロード」を押せばプログラム書き込みとmainまでの実行が行われます。これだけでもデバック速度が変わります。
CPUリセット後、プログラムが実行されます。
コンポーネントの追加時点でピンに「1」「0」を指定しておけば、
１になったピンが3.3Vになるはずです。 AVCC/AVSS0・1が配線されていれば
100ｐはブレットボードが使えないので、基板をつけるか、ピンヘッダとジャンパワイヤの接続で実現するしかないです。
※r_smc_entry.hにはIOポート定義"Config_PORT.h"が含まれておりincludeは不要です。
ただ、大きなドライバだとここに入っていない場合があり別でincludeする必要があります。
※1Uint32の解決（変数のモダン宣言）
//#include "typedefine.h" を有効にする(コメントアウト削除)
FITが出力するコードにはモダン宣言が多用されているので必要です。
C言語の変数の宣言って２種類の宣言方法が見受けられます。
・unsigned Long int TIME= 0;
・uint64_t TIME=0 ;（stdint.hをインクルードする必要がある）
情報工学専攻でもない古のC言語学習者は、char=8bit、int=基本cpuのビット数と教わりましたが、Uint32_tといったCPUによらない変数宣言の手法がモダン宣言が相当昔から出ています。
※SMC生成コードはSMC再実行時に消される。
SMCを再実行すると、SMC生成コードは上書きされてしまいます。Usercodeみたいないかにも消えなさそうな部分も容赦なく消されます。/* Start user code *//* End user code */で囲んだ部分は消さないはずですが、結構消されます。
SMCコード部分には手を付けないのが安心です。ｌ
（２）バックアップは確実に～早期保存はあなたを救うのです～
CS+CCはプロジェクトファイル類がが入ったフォルダを丸ごとコピーできます。
「あるいい程度動いた。」という状態で必ずバックアップしましょう。
コピーしておけば、最後のコピー時点までは戻せます。
プログラムをしていると、動いた状態に戻せないことが多々あります。動いているプログラムに少しコードを追加しただけで、クリーンビルドしても、元に戻した（筈）でも動かない。完全な詰み状態になることがあります。
PIC16F84の割り込み迷子が一周して正しく戻る奇跡のプログラムでも、保存すれば再現されます。奇跡は固定しましょう
（３）CMTの実装
ようやくCMTには入れます。
今後のLAN実装に向けて、rx72n-envision-kitでのEthernet通信の構築の参考記事をもとに進んでいきます。アプリケーションノート「RX ファミリ CMT モジュール Firmware Integration Technology」に従いますが
コールバック関数名が「cmt_c0」の場合
×：R_CMT_CreatePeriodic(10, ＆cmt_c0, &ch);
〇：R_CMT_CreatePeriodic(10, cmt_c0, &ch);
main前後に以下を追加します。
[code]
[code]
これを実行すればPORT2_0～7の値が1秒おきに0～255まで変化します。
優先度が高いの割込で固まると、CMTが実行されなくなるので、テスト用として残したまま次に進みます。８ポート使うのはもったいないので、PORT2.PODR.BIT.B0 のみを点滅させてデバックとします
（４）ポート制御に便利な一行
デバックのために１～複数個のポートを点滅させたりします。特定の行が呼び出されるたびにLEDの点滅が反転します。
PORT2.PODR.BIT.B2^= 1;//1pinだけの点滅
Rxのようなオーバーフロートとかしないマイコンなら8ポートまとめてカウントアップとかもできます。大雑把な連続作動時間や、止まった時にすぐわかるのがいいです。
PORT2.PODR.BYTE++; //8ポートまとめてカウントアップ
マイコンにより、出力ポート読出は常時0とかレジスタがオーバーフローする系だと駄目です、Rxだから、あくまでデバックだから使える手法です。よいこの皆さんはまねしてはいけません。
何とかCMTが走るようになりました。これだけでもキャラクタ液晶いじったりAD変換試したりしてもよいのですが、TCP/IPが主目標ですので、よそ見をせずにSCIに進みます
※１ HEWではRX210、RX610,RX62x、RX63xまで。もはやディスコンですあきらめです。(R8cM12とかR8c35の保守用に残してあります。)
※２
Rx66NマイコンTCP/IP通信試験ボードの作成（HW編）
Rx66Nマイコン用TCP/IP通信試験ボードの作成（HW編）
Rx66N/65NマイコンでTCP/IP通信を目指す一環としての⓪HW編です。
⓪HW設計 ＜－今回
①LED点滅 （https://meron33.hatenablog.com/entry/2026/05/07/150319）
②シリアル通信（https://meron33.hatenablog.com/entry/2026/05/10/114522）
③TCP/IP通信 (https://meron33.hatenablog.com/entry/2026/05/18/121143)
Rx66nは、2020年発売、Rxｖ3コア搭載のrenesasメインストリームマイコンです。
TSIP無(暗号化機能、LAN内ならあまり関係ない)の最低限機能100Pモデル、最安で1000円/個くらい。
最上位Rx72Nとの違いはCPU120MHｚ制限、Eth１ポートでROMが少ないくらい。
（RX66N ハンドブック記載）
存分ににRxv3をお楽しみいただけます。
ただ、出て数年たつのにtargetボードしか出ていない。NW開発ボードが欲しい。そこでRx66NをLANに接続すべく研究していきます。
目次
０ 概要
(1)目標
(2)CK-RX65Nのほうが速い。
(3)Rxマイコンの開発基板は使い回せる。
１ HW設計
(1)電源回路 ※VCC_USBは5Vじゃない。
(2)デバック回路
(3)発振回路
(4)IOポート
３ RXマイコンのEthernetの仕様（物理層）
（１）MIIとRMII
（２）MII or RMII対応の１００BASE-T物理PHY
（３）LAN8720ボード
４ AW
０ 概要
Rxマイコンはrenesasが作っているため日本製・日本語情報なのはよいのですが、あまりり整理されていないので、その情報に行きつくまでが苦難の道だったりします。
そのせいでWEB上の情報が少なくて、さらにユーザーが減っている気がします。
GWが終われば、後は土日と寝る前1時間とかでの開発なので、個人用にしっかり文書として残しておきます。
（１）目標
困難は分割せよです。適切な目標系列を定めましょう。
⓪HW設計 ＜－今回
①Rx66nでLED点滅
②シリアル通信
③TCP/IP通信
開発環境
・CS+CC評価版（128K制限状態）
（GCCは難しすぎて断念、E2stuidioが不安定すぎて断念）
・基板：デバック回路構成の他、基本全ポート引き出しただけ
（LAN8720とSCI0（シリアルポート）だけは引出）
・E2lite
シリアル書き込みで対応できますが、E2liteがあればCS+CCでF6を押すだけでビルド＋マイコンでの実行ができてしまいます。デバック機能は全然使いこなせてないのでこれからです。趣味用で私費購入したのですが、たまに仕事でも使う・・・
Rxマイコン自体、基本がBtoBで、開発キット（1万円～）を買って有料でコンパイラ・サポートが前提なので、基本的にWEBにまとった情報がありません。各種マニュアルと
renesasの「rx72n-envision-kit」向けのTCPマニュアル
https://github.com/renesas/rx72n-envision-kit/wiki/1-Ether-TCP-IP
を参考にあらゆる文献を参考にしています、違うところが多く苦戦したため複数段階を踏みます。
（２）CK-RX65Nのほうが速い。
資金力があり、RX65で良ければ、
CK-Rx65n＋FreeRTOS(with IoT Libraries)/E2studio/CC-RX製品版
が一番近道。すぐソフト確認に入れますが、懸念があります。
・E2studio がとにかく不安定、CC-RXとGCCを選べるもののGCCが不安定
（Eclipceの不具合を解決できる力が必要）
・CC-RXの試用制限にかかるとまともに運用できない可能性が高い。
まずは自力で構築できる力がなければ、活用できそうにないので。自力作成に臨みます。
（３）Rxマイコンの開発基板は使い回せる。
Rxマイコンは同じ100pinだと世代が違う製品でもピン配置が同じだったりします。
前世代のRx65nと今回のRx66nも同じ基板で評価できます。今後新マイコンが出ても同じ設計が使いまわせます。（やるかどうかは別としても、その気になればGRsakuraのRx62nをはがしてRx66nに換装できるはず。）
renesas自身もデバックボードを一から引き直すのが面倒なことに気づいたのか?ユーザーがマイコン置き換えを渋ってDisconしにくくなるからか？コアも新しいのでしばらくは廃版にならないと思われます（願望）
１ HW設計
Rx66N/65Nの回路は以下の通りです。Rx72じゃないのでHWは自力です。
PICとかだと電源と＃RSTだけでどうにかなるのですが、RXはそうはいきません。
Rxマイコンで本格的にイーサネットを使う場合100pinはわりかし最低ラインだったりします。100pinでもLAN（RMII）＋デバッグだけで残りIO56pin、
64pinだと残20pin。SDやLCDはなかなか厳しく・・・しかも数が出ないのか高価
デバック用なので回路は単純で、大きく4つに分類されます
・電源
・デバック端子回路
・発振回路
・端子引き出し+ Eth物理PHY用引き出し端子
（１）電源
注意１ 電源の罠
RXはVCC、AVCC、AVSS、VREF端子をすべて接続する必要があり、同電圧です
AVCCはAD変換関連と誤認して放置してはいけません。実はGPIO電源に繋がっておりピンに電圧が出なくなります。AVCC0とAVCC1がありポートによって分けられているので一部のポートが出力されず、はまります。これらの端子に電位差があるのは保証外なので、最悪ラッチアップの危険すらあります。ＥＭＣ対策か何かのピン分けです。必ずつなぐ。
注意２ VCC_USBは５Vじゃない
特にVCC3.3Vとは別にVCC_USBがあります。ここに5Vつなぐと壊れます。
VCC_USB＝3.3Vです。ﾃﾞｰﾀｼｰﾄに書いてあります。
あくまでRx内部のUSB回路の駆動電源が外部に引き出されているだけ。
安心してください。dp,dnは5Vトレラントです。と言った具合です。
VCCともAVCCとも分ける意味がどこにある！。どうせ5VのV_BUSじゃないならavcc2とかにすればいいのに。
（２）デバック端子回路
この手の高性能多ピンマイコンは、マイコンライターで書いてから基板にさす方式では開発できません。製品基板にデバッカ接続専用端子を設けて、マイコン・書込回路・JTAG(又はFINE）接続回路をすべて基板側に搭載して、あとはデバッカに接続するだけにします。つまりそれらを配線済みにする必要があります。
こちらは「E2エミュレータLite ユーザーズマニュアル別冊 (RX接続時の注意事項)」を参考に進めていきます。デバックが充実しているうえ、USBメモリからのファームアップもできる関係上RxはJTAGでもFINEでもシリアル書き込みでも処理するピンが多いんですよね
PULL_UP：MD、FINEC、（TxD、RxDJTAG/シリアル書込時）
PULL_DN： EMLE
M16ベースのR8の時にはFineだと接続用ポートが減って便利だったのですが、Rx65、66、71、72はどちらでもピン数は変わりません。そして、fine接続時のMDの抵抗値だけ4.7ｋなのに注意、10ｋでも実用上動きはしますが
（３）発振回路
Rx66nは内蔵発振器がついています。LAN8720を独立クロックで使う場合は問題ありませんが、USBや、50MCLOCKOUT時に外部回路が不安定になる現象が報告されているようです。（※１）また、メインとRTC用サブクロック搭載時にはピンの最短位置への搭載が必要なため、とりあえずはボード上にパターンを作成して未実装とします。また水晶振動子が推奨になってしまっているので、使用水晶とコンデンサのマッチングが必要で面倒です。こういうときは、水晶メーカにてマッチング検証済みの水晶を使うのがよいです。
https://www.sii.co.jp/jp/quartz/ic-matching-information-2-2/
（４）IOポート
基本的に全ポートを素直に引き出します。targetボードと同じです。
後で引き出すシリアルの４ピンXHコネクタと、LAN8720ボード用の引き出しをつけておきます。（本当はRMIIの配線はCPU直近で、かなり制約がありますが、ボード使う時点で無理なので引き回します）
３ RXマイコンのEthernetの仕様（物理層）
（１）MIIとRMII
ロジックレベルで動いているマイコンで、100BASE-Tや100BASE－FX等の信号を直接扱うのには無理があります。物理層とデータリンク層を別ICで担当し、MIIという共通規格でつなぐことで、MAC側の再設計不要（含マイコン）で対応できる構成となっております。
一般の１Gや10GのLANカードもツイストペアや光の規格変更のたびにMACを再設計しなくて済むよう、SGMII（１Gbps）、XGMII（10G）などで物理層とMACをつないでいます。
Rxマイコンも物理層は搭載せず、MIIとRMII（reduced：ピン数削減版）に対応し、MACのみ搭載しています。すると、物理PHYの選定が必要となります。
（２）MII or RMII対応の１００BASE-T物理PHY
①LAN8720：
GRkaedeやGRsakuraに搭載されておりRxマイコンとの相性は良い。他社マイコンでも搭載例は多い。IC単体だと驚異の100円、RMII対応で省ピンで接続できて便利、
waveshareのモジュールや、そのコピー品がamazonやアリエクで安く売っている
②ICS1894：
renesas謹製 CK-RX65Nにも使われ、smartconfigratorに出てきてMIIにも対応している。間違いなく動くはずだが、情報０、ボード無し、入手性悪くて高い。断念
※aruduinoのイーサネットシールドに使われるENC28J60は物理phyではなく、内部に全てを持っており、spiでコマンドやデータを送受信するものです。その分簡単ですが値段は張ります。
基本的にMII/RMIIどちらかに対応していればつながるが、実績や情報の出ないICは極めて厳しい。規格には後方互換があるのでSGMIIでも繋がりますが、MACが100Mなので１００Mしか出ない。RTL8211Cもつながるはずだが情報もないのでたぶん無理。
LAN8720で自分で線引いてもいいのですが、waveshareのLAN8720基板を衝動買いしたので採用します。一旦動く状態にしないとデバックできないしと言い訳します。
（３）LAN8720ボード
この基板は必要な配線が抜けていて、改造が必要な模様、ボードから出ている線をつなぎ切って満足したら、普通気が付かないので貴重な情報です。下記参照ください。
（http://www.rvf-rc45.net/wordpress/?p=3023）
・MDCのVCCへのプルアップが抜けてる
・RMMID_Rx_ERが出ていないので、あいてるNC端子にとばす
４ AW
C基板サイズにしましたので、上下にC基板をスタックできます。
B基板サイズに２枚面付けしてJLCPCBに発注して、届いたら切ってます。B基板5枚(C基板で10枚)で1000円以下なので１枚あたりは100円以下なのでC基板より安い。100LQFPの変換基板とかわざわざ名古屋〇ツまで出張って1000円とかなので、JLCPCBは地方在住の強い味方です。
後でいろいろな間違いに気づきましたが、その時はウキウキ気分で発注してました。
そういや昔、PCBEインストールしたときにこんなサンプル基板がありましたね・・・懐かしい。
変換基板は、はんだ付けしたらようやくスタートラインなんです。
LEDちかちか編に続く
以下余談
（１）Rx66nの入手性
一番安く買えそうなRx66N（R5F566NDDDFP 100pin）は
Chip1stopで1個1000円（10個単価）で買えましたが、arrow に移行なので今後の入手性は微妙です。mouserやdigikeyだと1700円もするのでちょっと手軽ではなさそうです。
（２）機種選定（RxかRL78かの葛藤）
RL78：超省電力・小型志向 RL78（それなりにいばらの道）
Rx ：汎用～高性能
Rxは、LAN,USB搭載品、３相モータのベクトル制御用、低消費電力小型品まであります。SH、H8、M32、78Kで別機種でカバーしていた部分を、1機種にまとめようというものです。マイコン、組み込みにもIoT化の波が押し寄せている関係でマイコンの要求能力が上がってきています。
自動車用のV850/RH850は崩せないものの、Rxの低消費電力版がじわじわと16/8bitマイコンを押しています。RL７８の高機能版は結構厳しいと思われます。
（３）開発環境の制限
E2studioは微妙だし、GCCは挫折（※開発環境のコンパイルがいる）
CubeSuiteを使う場合に重要なのはコンパイラの容量制限です
Rxはリンクサイズが128KB制限
RL78は64KB＋最適化に制限がかかります。
（V1.12以降（つまり新規ダウンロードでは制限版））
RL78はTFAT（FATファイルシステム9Kbyte）を搭載に9KB必要。上限が128Kか64Kかで大きな違いが出ます。Ethernetなど夢のまた夢です。
（４）Rxの製品ラインナップ
「RXグループ 製品比較ガイド」には以下のような大きなラインアップがあります
製品機能の差：RX700,600,200,100シリーズ
：T（モータ・インバータ向け）、N（ネットワーク強化）・M（EtherCAT）
末尾数字（付加機能無し、汎用・安価）
Rxコアver ：Rxv1, Rxv2, Rxv3
Rxv1コアとRxｖ２コアの一部はすでにDisContinueで新規入手が困難。一部のRxv2を残しRxv3コアへに移行していくのではと思われます。これから手を付けるならRxv3コアです。H8からの乗り換えと秋月で一時流行ったRx220はすでに廃版、Rx100シリーズにRxv2のRx140がでており、Rxv1は淘汰の予感です。
（５）Rx600シリーズの勧め
RX65/66シリーズはRx71/72から一部機能削除版で、内部は似ている模様。
特にRx66は「RX66N グループと RX72M/RX72N グループの相違点」によると、Eth×1、CPU120MHｚ以外ほぼ共通。rx65で一部型番は削られた機能が標準搭載になっており、Rx66最安品のほうがRx65の中間性能品よりも強くて安いです。
最低価格で言えばRx66nは1000円、Rx65nは700円くらいなので65のほうが安い。
Rxはマイコン乗り換え労力が高い気がします。機能が足らないから上位にと気軽に行けない。Rx600シリーズはrenesasがメインストリームと銘打つだけあり、高機能なうえ、廉価品は安価です。廃版以外での乗り換えがいらず、最小64pinからでポート不測の心配が遠いRx600シリーズは確かにおすすめです。
今回の調査の情報源のgithubにあるrenesasの中の人のパワポでも勧められております。
（５）E2の推奨接続回路が分かれている
Rxにも系統があるのか分かれています。Rx,66,72,26TあたりはRxv3コアでRx72M派生で、さすがに省電力小型系統のRx100/Rx200シリーズ等とは構成が違うのだと思います。FITの説明書なども「RX全般」と、これらが分かれているものもあります。
ベクトル制御用途など、モーター向け高機能版のRx23TがRxv3コアになったのでこの辺りは統合されるのかもしれません。
（６）Rxマイコンってそもそもどうなの？
組込みはIoTで盛り上がるのは間違いないですが、個別のマイコンが生き残れるかは別です。（こんなスレッドが立っていますが・・・https://community.renesas.com/cafe_rene/forums-groups/mcu-mpu/rx/f/forum5/53932/rx）
・小型の8～16bitならPIC、AVR、ESP32等があり、特にarudionoにすればWEBにコピペで動く情報がたくさんあります。Rxもarudiono互換ボードがありますが、同じaruduinoが走るなら、差別化なり、利便性なり、価格競争などに巻き込まれます。。
・32bitなら高性能から低消費電力までARM系のSOCが各社から出ておりかなりの激戦区です。組込Linuxが走るためTCPやGUIを手軽に動かせます。raspberypiには情報が多いです。
・本格的なNW・WEBサーバ機能を要求するならばルーター用LinuxのOpenWRTを使ったり、組込み用LinuxPCが選択肢に入ります。シリアル入出力やGPIOも備えておりでマイコンとも連携できます。
・最近のシーケンサはNW機能を充実させ、TCPベースのリモートIOや、DB等との連携もできるようになっています。
これらが、32bit高性能マイコンの範囲にじわじわ降りてきています。
ところで、最近Rxマイコンってルネサス製品採用企業で研修受けた社員しか触れないマイコンになりつつないですか？
がじぇっとルネサスが下火になって以降、一般ユーザー向けの情報とかがあまりに少ないです。日本語情報というだけでも他社に対する優位点なのに、情報があまりに少なくて手が出しにくく、あまり流行っているようには見えません。
一般ユーザとか学生相手では目先の金にならないのはわかりますが、学生時代にRxマイコンを触って育った技術者はRx製品を使う可能性があり潜在的なシェア拡大につながるわけです。私もGRsakuraやR8Cを触っていたからこそ、久々にRxに戻ってきたわけですし。
現に少子高齢化以上に、マイコンソフトを学ぶ技術者の絶対数は減っています。
Rxに新たな技術者がつかなければ、現役世代が定年するにつれて、製造も開発も既存製品の保守製造に縮小してしまい、最終的には保守困難になって外国製マイコンや組込みLinuxボードやPCへの置き換えで終了となってしまうのではないでしょうか？
国産マイコンが消えても、マイコン技術者が消えるわけではないですが、HWで得られていた利益と技術的利点は国内から失われます。
既にコンシューマ向けPCや携帯電話は、国産OS、CPUは完全にシェアを失い、日系のPCメーカーは他社との差別化が厳しくなり、すでにレノボ等の傘下だったりします。
そのうち組込み機器が国産で賄えなくなり、外国製CPUで外国技術者のプログラミングした製品を買うことしかできなくなってしまいませんかね？
サプライチェーンリスクが叫ばれている時代ですが、国内製造も開発もできない状態で、海外製のLinuxボードが巷に氾濫したら、ペネトレーションテストとがどうするの？
（それでもやるのがサイバーセキュリティの仕事ではある・・・）
マイコンもこのままでいのか？と思うこの頃です。
そのためのrenesasのARM系RZ/RAマイコンなのかもしれないですが・・・
※１ RFP(RenesasFlashProgrammer)-USB I/F で、RX65Nマイコン基板にFWを書き込む場合、外部から 20/24MHzクロックを入れる必要がある？
https://community.renesas.com/cafe_rene/forums-groups/mcu-mpu/rx/f/forum5/51559/rfp-renesasflashprogrammer--usb-i-f-rx65n-fw-20-24mhz
最近の高演色LEDには2種類ある。～LEDの演色性と色温度～
～高Ra低R9型LEDの演色性と色温度～
最近Ra90以上の高演色LEDとして売られているものには、
従来の紫外線LED+赤緑青蛍光体方式に加えて、青LED+赤緑蛍光体方式の演色性向上型が含まれています。
特に青LED+赤緑蛍光体方式には高Ra低R9型という演色性向上型があります。
高効率・高演色・安価なLEDが家庭で使えてしまう時代が来ましたが、特性は理解して使う必要があるという話です。
双方の特徴と活用について白色LEDの基礎から調べました。
０ 前書き
１ 白色ledの構造
（１）青LED＋黄色蛍光体方式
（２）青LED＋緑赤蛍光体方式
（３）紫外線LED+赤緑青蛍光体方式
２ CRI（演色評価数）とは
（1）光の三原色は錯覚。
（２）xy色度図
（3）反射光観察と、直視する場合の違い
３ 演色評価数の種類
４ 色温度は何がいいのか
５ 青LED＋GB蛍光体方式の特徴と選定の注意事項
０ 前書き～電子工作を支えるインフラ、作業灯～
照明にはCRI（演色評価数）というものがあります。
光源で照らした物体の反射光が、太陽光下にどれだけ近いかを表す指数です。
あまりにかけ離れた光源の場合、筆記や精密作業などの効率が落ち、塗装では色がおかしくなります。作業灯は電子工作を支える重要なインフラです。
LQFPの半田やチップ抵抗の印字の読み取り、ジャンク修理の時は視認困難なトランジスタやICの刻印を読んだり、クラックを発見する必要があるので高演色なLED作業灯が欲しかったのです。
そこで、Ra90以上の高演色のLEDを探していたところ、
OSLAMの高演色高効率LED「GW QSLMS1.KM」を発見しました。演色評価数92で高効率227lm/Wを実現し、digikeyで100個2500円、１個30lm程度で、4直列10.5V、120lm程度になるので１２V運用にちょうど良いです。
ただ、この演色評価がRa＝92、Ri(R9=50)とあります。
データシートのスペクトルを見ると青と赤の目立つ、太陽光とはずれたスペクトルです。紫外線LED+赤緑青蛍光体方式ではなく、青LED＋赤緑蛍光体方式の演色性向上型なのだと思われます。
高Ra、低R9型LEDというようです。（https://www.nhk.or.jp/strl/publica/rd/162/5.html）
Ra92だけど、Ri50それって結局何なのか
それを理解するには、単に「演色性高い＝良い」ではなく、演色性と何なのか、照明としてどう影響するのか、演色性の評価方法理解せずには進められません
自身の勉強も兼ねていますので、基本的な知識の調査事項も反映しています
１ 白色ledの構造
１チップで白色を出すLEDで最も主流な白色LED、青又は紫外線系＋蛍光体を活用して光らせるものです。光源のLEDと蛍光体の組み合わせて概ね３種類あります。
（１）青LED＋黄色蛍光体方式（発光効率重視）
最初に実用化された方式で、青色LEDと黄色蛍光体を使用して人間の目に白色と見えるような光を出します。構造が単純で変換効率を高めることができます。発光効率重視型LEDです。（XL-3528WWCはカタログスペック上は310lm/w化け物か？）
（スペクトルはexcellで適当に作ったポンチ絵です）
光源の青が強いピークを持ち、黄色のスペクトルを出すことで人間の目には白と錯覚させることができます。
1分でも長持ちさせたい懐中電灯、目で直接見る分電盤の運転表示灯やなどでは全く問題ないのですが（分電盤の通電ランプは最近白ランプが出始めているし）青と黄色の波長しか出ておらず、反射光を観察する照明として使用すると演色性が劣ります。
（２）青LED＋緑赤蛍光体方式（バランス型）
青＋黄色蛍光体の演色性を向上させるために、光源の青LEDをそのまま活用したうえでに緑と赤の蛍光体を追加し３原色を再現するようにしたLEDです。RGBのLEDを直接組み合わせる方式よりもスペクトル幅が出せることから、演色性は改善します。
蛍光体での変換が行われるのでその分発光効率は落ちます。
青＋黄色方式に比べれば、太陽に近いスペクトルが出せるものの、光源の青が強すぎる関係上演色性には劣り、コストもかかると言われて言われていました。
近年の技術向上で、高Ra低R9形LEDと言われる、赤の再現は苦手なものの、
発光効率。コスト・演色性をある程度両立できる潜在性の高い製品が出てきています。
（３）紫外線LED+赤緑青蛍光体方式（演色性重視）
太陽光にスペクトルを近づけるために、青LEDで直接青色を出すのをやめ、光源にUVLEDを使用しRGBすべての蛍光体を配合したものです。光源の紫がもれますが、蛍光体の配合次第で太陽光に近づきます。
光源のLED光を蛍光体で変換する関係上、発光効率は低下したうえ高コストです。過去は数十lm/W等で高価なため照明などには使えませんでしたが、LEDの発光効率が全体的に向上しているため100lm/w程度はある製品が出ています。
更に高演色タイプの白色LEDでは複数の蛍光体を組み合わせてスペクトルを近づけたり、スペクトルの異なるチップを集積することもありますが、スペクトルの調整が非常に困難になってきます。
根本的に人間の目に余り見えない波長の出力に電力を割くことになり発光効率は低下します。
２ CRI（演色評価数）とは
本題です。白色LEDはCRI（演色評価数）というものがあります。
ある光源で照らしたに物体の反射光がどれだけ太陽光下の時に近いかを表す指数です。人間の色覚と工学的な利用方法について理解する必要があります。
（1）光の三原色は錯覚。
赤と青の光を混ぜると、紫の光が見えます。これは物理現象ではありません。
冷静に考えれば波の独立性から赤(564nm)と青（420nm）の光を重ねると紫(400nm)が発生することはありません、目の錯覚です。
人間の目はRGB錐体＋明るさだけを感知する錐体を持っており、人間の目を３つの波長で刺激することにより任意の波長の光を見ているように錯覚させることができます。別の波長が発生しているわけではありません。（通信用の波長変換デバイスとかもありますが、ややこしいので割愛）
しかし、実は三原色ですべての色を完全に再現する（錯覚させる）ことができるわけではありません。
（２）xy色度図
色の混色を考える場合、R（X）+G（Y）+B（Z）＝100％となるのでZは考えずにXとYだけで考えるという座標系です。曲線の中は人間が見える色全てで、RGBを混ぜて作れる色の範囲です。この外は、三色の混色では再現できない部分があり３色の混色だけでは一致させることはできないようです。（RGBの三角の位置は適当です）
歴史は古くはCIE 1931 色空間（1931年）を発端に研究が進み、CIE XYZ色空間やCIE 1976とか2006とか出ているようですが、根本の考え方自体はここが発端です。
「https://ja.wikipedia.org/wiki/色度_(光学))」と秋月サイトより
黒体放射の軌跡を色度図にブロットするとどこかで見た曲線、ANSI C78.377の8種類の色度規定につながります。
今回使用のOSLAMのLEDはこちらにのっとってラインナップしています。
（3）反射光観察と、直視する場合は違う
RGB混色の6000Kと太陽光の6000Kは三角の範囲内だから再現できるではないか、
液晶画面であればその通りです。反射光になるとまた厄介です。
赤灯の下で、白い紙と赤い紙を見てもどちらも赤にしか見えません。
照らされたもの反射光を見る場合、物体に吸収されずに反射された光を見ますが、元の光源に無い波長の光は存在しないので見えません。
太陽光は赤外線から紫外線まで連続したスペクトルを持っています。三角の外の光を反射する物体の反射光は帰ってこないので、理想的な太陽光を当てた時と照明下での反射光は一致はしません。太陽光とLED下では色が違って見えるのです。塗装などではわりかし致命的です。
青LED＋黄色蛍光体方式は青と黄色で補色関係にあり、混ぜると中間にある白色の範囲に見せることができるため直視する場合は成立しますが、反射光観察では赤や緑が含まれず致命的な欠陥となります。
３ 演色評価数の種類
色の再現度を評価するためにはその指標が必要です。代表的なものはRaとかRiです。色覚の研究の進歩だけでなく、近年の照明は、人の目より感度の高いデジタルカメラ等の撮影に影響するのでCQS、TM30、CCD目線での演色性であるTLCIなど大量発生しています。単なる照明用途のLEDでは人間の目にどう見えるかの評価が中心なのでRaやRiが多いです。
（１）CRI（Ra）
人間の視覚に基づいて作成したサンプルを使って、その色の正確さを見るものです。1960年代ごろに作られたものです。
肌色の表現に赤が重要であることがわかってきた関係から、今となっては古い規格となっていますが。伝統的に使われる指標です。
印刷物や写真の判別寄りの指標と思われ、顔料の混色に近い彩度の低いCIE色空間から引用されたと思われ、淡い色が多いです。
弱点は大きく2点
・前述の赤の評価が不十分でLEDの評価に向かない
LEDは赤色の成分が少なく後述のRi(R9)の再現が苦手ですが、この評価ではあまり現れない
・平均値での評価
R1~R9の平均値で見ることから、たとえRa80でもR1~R9のばらつきの大きさが評価されないので、同じRaでも違った見え方がします。
Raが高い場合、例えば平均92とかだとばらつける範囲は少ないのですが平均値80とかだと、極端に悪い色（LEDの苦手な赤など）が混じる場合があります。
（２）CRI（Ri）
Raは淡い色が多く平均値を採用します。当時の理論上は正しかったのですが、映像業界などで赤色の再現性が人間の肌色での評価に重要で、Ra評価だけでは足りないという事が経験的に知られ、業界の独自企画などが作られていました。結果特殊演色評価が作り出されました。鮮やかな色が多いのが特徴です。また評価は個別に取ります。
下記はZlight社の高演色照明の製品紹介の引用ですが、LEDは赤の再現が極端に苦手で、R9一桁のLEDもあり、Ra評価には現れません。
そういった関係でRaにRi(R9)の評価を追加したLEDが売られていたりします。
４ 色温度は何がいいのか
机を白色LEDで明るく照らしたい。でも白の定義って実は難しいんです。
太陽の表面は5000〜6000K程度ですが、地球上では空の青色が混じるのでちょっと色温度が上がります。季節や時間によって違います。また、一方でxy色度図の中央の色味のない白色が6500KでPCモニターは6500Kで調整しますが、6500Kの照明は青白く見えます。当然個人差もあります。
6500Kは青白く寒色系、4000Kは黄色みがある白で暖色系となります。作業灯には、寒色のほうが物がくっきり見えるので最適ですが。行き過ぎると目が疲れます。寝室を寒色でぎらぎらにすると落ち着かなくなるので暖色系を選びますが、こちらも行き過ぎると色があまりに変に見えるので疲れます。
（１）クルイトフ曲線
また、作業灯として机の上をビカビカにするつもりなので気にしていませんが、
色温度と適切な照度には曲線があります。
同じ色温度でも暗くすると青白くて不快（調光を付けると顕著）
電球色LEDは明るくしすぎると色味が不自然となり不快となります。電球色LEDで机をビカビカにすると、筆記や読書が極端に疲れるようになります。
ただこれ、西洋人の視覚を使った実験結果であることや、当時の実験に不十分な部分があることが指摘されています（https://www2.panasonic.biz/jp/lighting/plam/manual/basic/light-color-rendering/）曲線の引き方に問題があるとしても、個人や人種の違いがあるにしても、
照明の快適さは、色温度と照度の両方で決まるということ自体は確からしいです。
(en.wikipedia Kruithof curve)
（２）LEDは青が強く反射する。
さて、ただでさえややこしい白に、青LED＋黄色蛍光体方式や、青LED＋緑赤蛍光体方式は青色が強く出ている関係上反射光がわずかに青白く見える場合があります。
CRIが悪く、Raのばらつきが大きいほどこの傾向が強いです。
その辺を加味した色温度が、各社の味付け次第なので、要確認です。
またLEDは電流を増やしすぎると色温度や演色性がずれる。（光源の青色が強く出すぎる）ので、標準電流以下で点灯させる必要があります。
（３）結局買ってみないとわからん
というわけで、買ってつけてみました。
やはり、6500Kはモニター等よりも青が強く見え、作業灯用途には５７００K あたりが自然な白っぽい色には見えます。そして、人間よりもはるかに高い感度を持つデジタルカメラとはまた違って映り、見る画面によっても変わる。難しい・・・
慣れていない人は、色味を見ずに100個買いとかすると危ないです。
５ 青LED＋GB蛍光体方式（高Ra低R9型）の特徴と選定の注意事項
（１）スペクトルの読み取り
一周回って、今回のLED W QSLMS1.KM-H7H9-XX32-1-65-R18のﾃﾞｰﾀｼｰﾄを見てみるとCRI（Ra）はTyp92ですが、Riに含まれるR9単体は50です。スペクトルで見ると一目瞭然です。
左W QSLMS1.KMのスペクトル、右：太陽光
太陽光と比較すると結構差があります。光源由来の青とか蛍光体の赤は非常に消しにくく突き抜けてしまっています。とはいえ、図中の人間の標準分光視感効率 V ( λ )で特に強く見える部分は、大体スペクトルが出しRa評価９２を出せるくらい作りこんだのでしょう
他の帯域のスペクトルも連続的にある程度出すためにはしかたがなかったのでしょうRiのR9赤やR12青は蛍光体を光らせるLEDである以上結構厳しいです。
（２）色温度選定には注意が必要
青が強い関係上、人によって微妙に青白く見えます。5800Kを作業灯として選んでみることにしました。照らす場所の照度も考える必要があります。
買ってみて思った色温度と違うとならないよう、少量購入しての点灯確認は必要と思われます。
ごく微妙な色の差が致命的な塗装（車庫での車の塗装）や、色温度を精密に合わせて使う撮影では注意が必要かもしれません。とはいえ、それくらい比べないと分からないレベルなのは確か。
（３）Riの測定すらしていないLED照明には注意
精密作業用や普通の基板撮影程度ならRa92もあれば演色性はよいはずです。部屋の照明はRa80で限界、な時代に比べれば、高い演色性を持つことは間違いなく、演色性の高いLEDをデスクライトや部屋の照明に高演色LEDが気軽に使える時代が来ているのは確かです。
ただし、一般家庭の蛍光灯やLED電灯ではRa85でRi未評価の照明があり、RIが一桁なものまであります。そのようなLEDは、Ra85とかでも反射光が不自然だったり、色温度が思ったより寒色に寄る場合があります。更にLEDをけちるためにオーバードライブ気味で点灯している照明は演色性が壊滅するので、精密作業の疲労の原因となったりします。
最後に
W QSLMS1.KMは演色性と発光効率を実用的な範囲でうまくまとめた良いLEDと言えます。点灯確認をしてLEDを選定したので、このLEDを使った照明を作成したいと思います。
