幾つかの品種だけRX MCUs internal USB peripheral registersのbitfieldがunavailableなiodefine.hがありますが作成ミスではないでしょうか?

こんにちは。NoMaYです。

最近、以下のスレッドに関わったのですが、どうもiodefine.hの作成ミスがあったのではないかなぁと思われましたので、スレッドを立ててみることにしました。

iodefine.h で、IODEFINE_H_HISTORY キーワードについて
japan.renesasrulz.com/cafe_rene/f/forum5/8446/iodefine-h-iodefine_h_history

続く。

(すみません、上記スレッドの投稿主さんのhirakuni45さんにおかれましては、当方の投稿が終了するまで暫くお待ち頂ければ、と思います。あわてない、あわてない、との、一休さんの心持も良いかと思うのです。)

Parents
  • こんにちは。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に対応しました。

Reply
  • NoMay さんこんにちは。

    膨大な調査とレポートありがとう御座います。

    ※貴重な時間を使ってこれだけの調査、感謝しかありません。

    レポートを読んでいて、何故なのか、大体理解出来ました。

    r_usb だけで考えるなら、問題になる箇所のビットフィールドを使ったアクセスをしないように実装していると思うので、レジスターのワードアクセスさえ出来れば関係無いのでしょうね・・

    ただ、tinyusb など、サードパーティーの USB フレームワークを使うには、ドライバーが、iodefine に頼った実装なので問題が起こるという事のようです。

    ---

    自分は、USB 関係レジスターの定義を C++ で独自に行っており、tinyusb の RX マイコン用ドライバー(C ベースのiodefine を使った実装)を割と簡単に C++ へ書き換える事(sedを使った簡単なトランスレーターで変換)が出来たので、とりあえず、そのようにして、RX72Tに対応しました。

Children
No Data