• Replies 17 replies
  • Subscribers 379 subscribers
  • Views 2794 views
  • Users 0 members are here
Options
Related

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

NoMaY

こんにちは。NoMaYです。

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

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

続く。

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

Parents

  • こんにちは。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

    …略…
        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向け(括られている部分は本来はこうなっていて欲しい)(ここだけではありません):

    …略…
        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;
    …略…

    　

Reply

  • こんにちは。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

    …略…
        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向け(括られている部分は本来はこうなっていて欲しい)(ここだけではありません):

    …略…
        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;
    …略…

    　

Children
No Data