こんにちは。NoMaYです。最近、以下のスレッドに関わったのですが、どうもiodefine.hの作成ミスがあったのではないかなぁと思われましたので、スレッドを立ててみることにしました。iodefine.h で、IODEFINE_H_HISTORY キーワードについてjapan.renesasrulz.com/cafe_rene/f/forum5/8446/iodefine-h-iodefine_h_history続く。(すみません、上記スレッドの投稿主さんのhirakuni45さんにおかれましては、当方の投稿が終了するまで暫くお待ち頂ければ、と思います。あわてない、あわてない、との、一休さんの心持も良いかと思うのです。)
こんにちは。NoMaYです。前の2つの投稿で「もちろん、なぜ今もそのままなのだろうか？というのは、それはそれで別途あります」とは書きましたけれども、疑問形にするまでも無く、ルネサスさん社内での他のもろもろの業務との優先順位の問題(工数の事情や外注費予算の事情)が主であろうなぁ、ということは想像に難くありません。(優先順位の結末に未来永劫そのままにする可能性も含みます。)続く。
こんにちは。NoMaYです。幾つか前の投稿でRX65Nのiodefine.hは以下の(2)の形でリリースされて→(1)→(3)とルネサスさんが変更してきたことが分かったのですが、そのように変更してきたということは、ルネサスさん社内に今回の件の事情が分かっている人がいるだろう、ということだと思います。(1) ビットフィールド定義が使えないもの - その1 - #ifdef IODEFINE_H_HISTORY～#endifの条件コンパイルで除かれている(2) ビットフィールド定義が使えないもの - その2 - //にてビットフィールド定義がコメントアウトされている(3) ビットフィールド定義が使えるもの後は、RX231(やRX230)のiodefine.hは上の(2)の形でリリースされて(RX231の頃はRX65Nのiodefine.hが上の(2)の形としてリリースされる前だった)今もそのままだったり、RX66TやRX72Tのiodefine.hは上の(1)の形でリリースされて(その頃のRX65Nのiodefine.hは上の(1)の頃だった)今もそのままだったり、とか、これらに関しては、ルネサスさん社内での他のもろもろの業務との優先順位の問題(工数の事情や外注費予算の事情)が主であろうなぁ、と思われることは、事情が解消すれば(もしもナイスなタイミングになるとすれば来月のツールアップデートにて)素朴にそうあるべきであるような(3)の形でリリースされるのであろう、と思われるのです。他方、ルネサスさんが決めた優先順位の結末には、未来永劫そのままにする、という可能性もありますが、そうでは無いものであって欲しいところかと思います。ということで、すみません、ここで 第一部 完 としたいと思います。続いて、第二部というか番外編を続けます。それは、発端となったスレッドの投稿主さんが書かれていますけれども、「iodefine.h内で#ifdef IODEFINE_H_HISTORY～#endifで括られている部分が正しくGCC対応になっていない(endian対応になっていない)」という件についてです。番外編へ続く。
こんにちは。NoMaYです。内容の話の前に番外編の「iodefine.h内で#ifdef IODEFINE_H_HISTORY～#endifで括られている部分が正しくGCC対応になっていない(endian対応になっていない)」件についての行き先として考えている話を書きますと、いっそ自分自身でスクリプトを書いて、e2 studioのGCC向けのプロジェクトジェネレータの原本のフォルダのiodefine.hのすべてを自動変換して、それとスクリプトを一緒にzipファイルに固めて、かふぇルネのサンプルプログラム置き場に投稿しておく、というのはどうだろうか、と考えているところです。かふぇルネのサンプルプログラム置き場の現在のURL(といっても以前とURLの初めが変わっているだけですけれども)community-ja.renesas.com/cafe_rene/m/sample_programもっとも、今やったところで、来月のツールアップデートで原本のiodefine.hが修正されたら無駄骨ですので、少なくともそれまでは様子見なのですけれども。(スクリプト言語を何にするか考えてみるとか、ちょっと試作してみるとか、そのぐらいですけれども。) 一番危惧されるのは、言ったっきり忘れてしまう、という悪いクセが出ないかどうかですけれども。(いったい何度やらかしたのだろうか、自分は。)番外編が続く。[追記]もちろん、ルネサスさんに修正をお願いすることはしますけれども。
こんにちは。NoMaYです。番外編の続きですが、幾つか前の投稿時に過去のCS+のRX向け(CC-RX向け)のiodefine.hを調べていて気付いたのですが、ある時点まで、iodefine.hには#ifdef IODEFINE_H_HISTORY～#endifで括られている部分はありませんでした。ですが、今では、発端となったスレッドに投稿されているように、くだんのUSB回りと、その他にも以下のようなUSB回り以外の部分にも、#ifdef IODEFINE_H_HISTORY～#endifで括られている部分があります。例えば、e2 studio 2022-07のCC-RX向けとGNURX向けのiodefine.hにはそれぞれ以下の部分があります。(もちろん他にもあります。)そして、同じく発端となったスレッドに既に投稿されているように、GNURX向けのiodefine.hにおいてそれらの部分がGCC対応になっていません。GNURX向けとしては、以下のソースの3つ目のソースのように#ifdef __RX_LITTLE_ENDIAN__～#else～#endifによって2種類のendian向けの定義が記述されていなければなりません。たぶん、各コンパイラ向けiodefine.hの生成には、ルネサスさん社内で何かしらのツールが作成されていて、以下のどちらかの方法で生成されているのであろうと思われます。(A) CC-RX向けiodefine.hから変換スクリプトなどによりGNURX向けiodefine.hとICCRX向けiodefine.hを生成する(B) 大元に例えばエクセルファイルなどがありエクセルのマクロなどによりCC-RX向けiodefine.hとGNURX向けiodefine.hとICCRX向けiodefine.hを生成するそして、たぶん、そのツールにおいて、#ifdef IODEFINE_H_HISTORY～#endif括られている部分を正しくGNURX向けに生成する処理が実装されていないのだろうと思われるのです。(もちろん、ここにも優先順位の問題はあって、くだんの括られている部分が正しくGCC対応になっていないことにはルネサスさんも気付いているけれども、その部分は今後は使えないようにした部分なのだから、ぶっちゃけ、諦めて欲しい、という判断がされている可能性もあります。いっそGNURX向けiodefine.hではその部分を削除します、という計画が立てられている可能性もあります。推測/仮説というより妄想ですけれども。)話がややこしくなるのは、幾つかの品種において、USB回りのビットフィールドを(使える筈なのに)使えないようにすることにも使われていている、ということであるからなのですね。番外編が続く。CC-RX向け(ここだけではありません):SupportFiles￥.eclipse￥com.renesas.platform_275843822￥internal￥projectgen￥Renesas_rxc￥Rx_1_1_0￥Generate￥iodefine￥rx65n.h
…略… union { unsigned char BYTE;#ifdef IODEFINE_H_HISTORY struct { unsigned char WI:1; unsigned char WE:1; unsigned char :5; unsigned char SEG:1; } BIT;#endif } ELSEGR;…略…
GNURX向け(ただし括られている部分は不完全です)(ここだけではありません):SupportFiles￥.eclipse￥com.renesas.platform_275843822￥internal￥projectgen￥rx￥Generate￥iodefine￥rx65n.h
GNURX向け(括られている部分は本来はこうなっていて欲しい)(ここだけではありません):
…略… union { unsigned char BYTE;#ifdef IODEFINE_H_HISTORY struct {#ifdef __RX_LITTLE_ENDIAN__ unsigned char SEG:1; unsigned char :5; unsigned char WE:1; unsigned char WI:1;#else unsigned char WI:1; unsigned char WE:1; unsigned char :5; unsigned char SEG:1;#endif } BIT;#endif } ELSEGR;…略…
こんにちは。NoMaYです。e2 studio 2022-10がリリースされましたのでGNURX向けiodefine.hを比較してみました。RX66Tに関しては以下の画面コピーの修正が入っていました。USB回りだけでなく他の箇所にも修正が入っていました。また、RX66T以外にも以下の画面コピーの修正など幾つかの修正が入っていました。ですが、意外なことに、RX72Tは修正が入ってなかったです。(これは、すみません、漠然とですが、工数不足では無く、修正漏れ(或いは協力会社さんへの発注漏れ)なのでは無いのかなぁ、とか思ったりとか思わなかったりとか、、、)以前に書いた以下の残りに関しては、あとは「時が来る」のを待つばかりなのかなぁ、というように思ったのでした。「(1) ビットフィールド定義が使えないもの - その1 - #ifdef IODEFINE_H_HISTORY～#endifの条件コンパイルで除かれている品種: RX66T(下記内容)、RX72T(2) ビットフィールド定義が使えないもの - その2 - //にてビットフィールド定義がコメントアウトされている品種: RX64M(下記内容)、RX71M、RX230、RX231、RX2Z4(謎の品種)(3) ビットフィールド定義が使えるもの」「幾つか前の投稿でRX65Nのiodefine.hは以下の(2)の形でリリースされて→(1)→(3)とルネサスさんが変更してきたことが分かったのですが、そのように変更してきたということは、ルネサスさん社内に今回の件の事情が分かっている人がいるだろう、ということだと思います。(1) ビットフィールド定義が使えないもの - その1 - #ifdef IODEFINE_H_HISTORY～#endifの条件コンパイルで除かれている(2) ビットフィールド定義が使えないもの - その2 - //にてビットフィールド定義がコメントアウトされている(3) ビットフィールド定義が使えるもの後は、RX231(やRX230)のiodefine.hは上の(2)の形でリリースされて(RX231の頃はRX65Nのiodefine.hが上の(2)の形としてリリースされる前だった)今もそのままだったり、RX66TやRX72Tのiodefine.hは上の(1)の形でリリースされて(その頃のRX65Nのiodefine.hは上の(1)の頃だった)今もそのままだったり、とか、これらに関しては、ルネサスさん社内での他のもろもろの業務との優先順位の問題(工数の事情や外注費予算の事情)が主であろうなぁ、と思われることは、事情が解消すれば(もしもナイスなタイミングになるとすれば来月のツールアップデートにて)素朴にそうあるべきであるような(3)の形でリリースされるのであろう、と思われるのです。他方、ルネサスさんが決めた優先順位の結末には、未来永劫そのままにする、という可能性もありますが、そうでは無いものであって欲しいところかと思います。」了以下、ファイル比較ツールの画面コピーです。[追記]RX72Tはアルファベット順のファイルリストの最後のファイルですね。以下、ファイル比較ツールの画面コピーです。
NoMay さんこんにちは。
膨大な調査とレポートありがとう御座います。
※貴重な時間を使ってこれだけの調査、感謝しかありません。
レポートを読んでいて、何故なのか、大体理解出来ました。
r_usb だけで考えるなら、問題になる箇所のビットフィールドを使ったアクセスをしないように実装していると思うので、レジスターのワードアクセスさえ出来れば関係無いのでしょうね・・
ただ、tinyusb など、サードパーティーの USB フレームワークを使うには、ドライバーが、iodefine に頼った実装なので問題が起こるという事のようです。
---
自分は、USB 関係レジスターの定義を C++ で独自に行っており、tinyusb の RX マイコン用ドライバー（C ベースのiodefine を使った実装）を割と簡単に C++ へ書き換える事（sedを使った簡単なトランスレーターで変換）が出来たので、とりあえず、そのようにして、RX72Tに対応しました。
こんにちは。NoMaYです。e2 studio 2023-01がリリースされましたけれども以下の件のRX72TのGNURX向けiodefine.hには依然として修正が入ってなかったです。以下、ファイル比較ツールの画面コピーです。