hirakuni45 です。
最近（既に数か月経過してるけど・・）、RXマイコン用、TinyUSB/Host ドライバーがコミットされたので、機能を試しています。
RX65N Envision Kit、RX72N Envision Kit での動作を確認しました。
そこで、USB の構成がほぼ同じ RX72T も試そうと思い、e2Studio/gcc でプロジェクトを作成し、出力された iodefine.h を利用しようとしましたが・・
iodefine.h が中途半端でgccのコンパイルに失敗します。
RX72N、RX65N では、ビットフィールドは、リトルエンディアンとビッグエンディアンで分かれていて、全ての定義があるので、gcc でも適切にコンパイル可能です。
ところが、RX72T 用の iodefine.h では、USB 関係のレジスタ定義が中途半端で、コンパイル出来ません・・
具体的には、表題の通り「IODEFINE_H_HISTORY」で囲まれていて、「ビッグエンディアン」の定義しか無い場合があります。
※レジスターによっては、RX72N と同じようにちゃんと定義されている場合もある。
何故、このような中途な状態になっているのか？、回避策などご存じの方がいれば教えて下さい。
※もちろん、RX72N 用のUSB部分を切り貼りすれば出来るでしょうが、iodefine.hを触りたくありません。
又、「IODEFINE_H_HISTORY」キーワードは、どのような意味があるのでしょうか？
RX72N iodefine.h USB 関係：
typedef struct st_usb0 { union { unsigned short WORD; struct { #ifdef __RX_LITTLE_ENDIAN__ unsigned short USBE : 1; unsigned short : 3; unsigned short DPRPU : 1; unsigned short DRPD : 1; unsigned short DCFM : 1; unsigned short : 3; unsigned short SCKE : 1; unsigned short : 5; #else unsigned short : 5; unsigned short SCKE : 1; unsigned short : 3; unsigned short DCFM : 1; unsigned short DRPD : 1; unsigned short DPRPU : 1; unsigned short : 3; unsigned short USBE : 1; #endif } BIT; } SYSCFG;
RX72T iodefine.h USB 関係：
typedef struct st_usb { union { unsigned short WORD; #ifdef IODEFINE_H_HISTORY struct { unsigned short :5; unsigned short SCKE:1; unsigned short :3; unsigned short DCFM:1; unsigned short DRPD:1; unsigned short DPRPU:1; unsigned short :3; unsigned short USBE:1; } BIT; #endif } SYSCFG;
hirakuni45さん、こんにちは。NoMaYです。以下の何れか(2つ目はアレですが)の理由により、リードモデファイライトが不可となっているのではないでしょうか。・仕様書の改版(エンドユーザ見えではユーザーズマニュアルの改版もしくはエラッタの発行)・手違いその為、わざわざ不可となっている部分をBIG/LITTLEで分けるようなこともしていないのだと思います。不可となっていることが妥当であるかは、すみません、私には分からないです。ただ、以下の事例には気付きました。RX72Tグループ ユーザーズマニュアル ハードウェア編R01UH0803JJ0100 Rev.1.00 Pages 2307 2019.05.161406頁
・PIPEnCTR (n = 6 ～ 9)b7 SQSET シーケンストグルビットセット ビット（注2） 0：無効 R/W （注1） 1：DATA1指定b8 SQCLR シーケンストグルビットクリア ビット（注2） 0：無効 R/W（注1） 1：DATA0指定注1. 読むと“0”が読めます。“1”のみ書けます。
union { unsigned short WORD;#ifdef IODEFINE_H_HISTORY struct { unsigned short BSTS:1; unsigned short :5; unsigned short ACLRM:1; unsigned short SQCLR:1; unsigned short SQSET:1; unsigned short SQMON:1; unsigned short PBUSY:1; unsigned short :3; unsigned short PID:2; } BIT;#endif } PIPE6CTR;
NoMaY さんこんにちは。
RX72N のハードウェアーマニュアルにも同様の説明が書いてありますので、RX72Tが特別だとは思えません。
RX72Nに搭載のUSBと、RX72Tに搭載のUSBで、違いは、以下の二つだけで、他は同じと思います。
(1) ディープスタンバイ USB トランシーバ制御 / 端子モニタレジスタ (DPUSR0R)
(2) ディープスタンバイ USB サスペンド / レジューム割り込みレジスタ (DPUSR1R)
RX72Nの同じレジスタ (PIPE6CTR) では、ちゃんと、リトル、ビッグで場合別けで定義がしてあります。
NoMaY said:その為、わざわざ不可となっている部分をBIG/LITTLEで分けるようなこともしていないのだと思います。
レジスタにアクセスする事が出来なくなるので、これは当てはまらないと思えます。
又、「手違い」にしても、こんなに大掛かりにするのも変ですし・・・
hirakuni45さん、こんにちは。NoMaYです。＞ レジスタにアクセスする事が出来なくなるので、これは当てはまらないと思えます。あえてそうした(手違いだとしても)可能性を考えていました。例えば、超大手ユーザさんで「読むと“0”が読めます。“1”のみ書けます。」的なビットのあるレジスタにうっかり(というかiodefine.hで出来てしまったので)他のビットを操作する時にリードモデファイライトして動かなくなり大変な手間を取らせてしまったけれども、原因がそういうことであることが分かって激怒してしまって、今後ルネサスさんとは取引しないとも言い始めてしまって、事態を収束させる為にこうした、とかあったかも、と考えてしました。当然、全マイコンの全レジスタの再チェックをすることになりますが、何人、何十人と、手分けして作業するのでバラツキが出たとか、その後何年かして作業者が変わった時に経緯を知らないので余計なレジスタにまで適用してしまったとか、単に作業者の注意力の違いで私みたいに想像力のあり過ぎる人が余計なレジスタにまで適用してしまったとか、あるかも知れません。その、何というか、ルネサスさんは大きな会社なので、ひとりの人がすべてのiodefine.hを管理しているわけではない、のでしょうから、そのあたりの可能性が気になりました。現実として、このあたりのレジスタを触るのはFITモジュールの開発者さんぐらいですが、たまたまコンパイルエラーが発生しないコードになっていたら、もう誰も気付けない、とも思うのです。他にも、作業者さんが入社まもない人とかで気付いたけれども言い出せなくてコードを修正して回避した、とかもあるかも知れません。あとは、すみません、他の人からのリプライを待って頂けませんか。
hirakuni45さん、こんにちは。NoMaYです。この情報を伝えた方が良いかも、というのがありました。・CC-RX向けiodefine.hでもIODEFINE_H_HISTORYは使われています
hirakuni45さん、こんにちは。NoMaYです。本件、他の人からのリプライはありませんでしたが、私の推測(妄想)でも合点が行きましたでしょうか？(思うに、次の課題として、なぜ RX72NやRX65N 対 RX72T で定義が異なるのか？というスレッドを私の方で立てた方が良いのかな、という気がしたのです(来週月曜ぐらいにでも)(CC-RX向けに関して)。)
こんにちは。NoMaYです。新しいスレッドを立てようと下調べをしていて、たぶん元凶(と書くとIP開発者さんが悲しむと思いますけど)が分かった気がしました。RX64MとRX71MにはUSBAとUSBAaというBattery Charging Specification Revision 1.2に対応したUSB IPが搭載されているのですが、基本的には従来のUSB IPのレジスタ割り付けを継承しているものの、読むと不定値が読めます、書く場合“0”としてください、と記載されている未使用ビットを含んでいるレジスタがゴロゴロしています。つまり、そのようなレジスタに対してはビットフィールドによる書き換えは不可ですので、あえて出来ないようにしてあります。それとバランスを取ろうとしたのだと思いますが、一緒に搭載されている従来のUSB IPの方に対しても、あえて出来ないようにしてありました。そして、そのようにした従来のUSB IPの方のレジスタ定義を別の品種で流用してしまったのだと思います。他方、RX64MとRX71Mとは無縁のまま、それ以前のレジスタ定義が流用され続けている品種も存在しているのだと思います。その結果、現在、従来のUSB IPの方のレジスタ定義が2種類存在するようになってしまったのだろうと思います。例えば、その一方がRX72T(RX64MとRX71Mの余波あり)であり、もう一方がRX72N(RX64MとRX71Mとは無縁)だった、のだと思うのです。なお、そのあたりの別スレッドは立てるつもりでいます。
こんにちは、NoMay さん。
USB IP を調べてみましたが、以下のようになっています。
※USBb には、「読むと不定値が読めます、書く場合“0”としてください」というのはありません。
RX621、RX62N ---> USB
RX631、RX63N ---> USBa
RX64M、RX71M ---> USBb
RX66T、RX72T ---> USBb
RX65N ---> USBb
RX72N、RX72M ---> USBb
少なくとも、USBb IPを搭載するマイコンは全て同等に扱えるので、RX65N、RX72N、RX66T、RX72T は同じに扱えると思えます。
※割り込みが、RX66T、RX72T は通常割り込みで、RX65N、RX72N は選択型割り込みの違いはあります。
USB、USBa を搭載するマイコンは確かに微妙（USBa は LowSpeed に対応していないなど）ですが、USBb は同じと思います、それで、RX66T、RX72T の USB 関係の扱いが奇妙（余波）なのは、「e2Sudio の不具合」なのだろうと思っています。
hirakuni45さん、こんにちは。NoMaYです。私の文章では通じませんでしたか。元凶はRX64MとRX71MのUSBAとUSBAaなのだと思うのです。それとも、そこは通じているのかな、、、RX64MとRX71MのUSBAとUSBAaに、読むと不定値が読めます、書く場合“0”としてください、と記載されているのは気付きましたでしょうか？これらには、USBbの他にBattery Charging Specification Revision 1.2に対応した新しいタイプの、もう1種類のUSB IPが搭載されているのですけれども。つまり、USB IPが2種類搭載されているのですけれども。[追記]ひょっとして、USBAとUSBAaを共にUSBaのタイプミスと解釈してしまったのでしょうか、、、そして、USBaというのも私の勘違い(正しくはUSBbなのでは？)なのだと解釈してしまったのでしょうか、、、
NoMay さんこんにちは。
「USBA」は、フルスピード（480Mbps）に対応した IP で、一般的な USB2.0（1.5Mbps、12Mbps）に対応したコア（USBb）とは別物だと思います。
このフルスピードに対応したIPは、現状では、RX64M、RX71Mにしか無いと思いますし、構成は、USBb とはかなり異なります、比べるなら、USBb の IP で比較する必要があると思います。
USBb の IP は、前の投稿のようにほぼ違いがありませんので、RX72N の iodefine.h と、RX72T の iodefine.h で異なる理由が判らないと言っています。
USBb の IP には、「読むと不定値が読めます、書く場合“0”としてください」と言うのは無いので、RX72T の USBb 関係の定義だけ、ビットフィールドが無効になっている理由が判りません。
USBA は、フルスピード対応の全く異なる IP ですし、RX72T にある USBb の IP とは関連が無いと思いますので、「元凶」の意図もイマイチ判りません・・
hirakuni45さん、こんにちは。NoMaYです。＞ フルスピード（480Mbps）＞ RX72N の iodefine.h と、RX72T の iodefine.h で異なる理由が判らないと言っています。 ＞ 「元凶」の意図もイマイチ判りません・・480Mbpsは、フルスピードでは無くて、ハイスピードですよ。今日、もうひとつスレッドを立て、そちらで考察してみようと思います。(もっとも、私がくだんのiodefine.hを作成した張本人ではありませんので、推測だらけであることにはなりますけれども。)