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は使われています