Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page

Amazon FreeRTOSだそうです。ルネサスさんのRXは参加しないのかな?

こんにちは。NoMaYです。

ライセンスはMIT Licenseでした。TLSとしてmbed TLSが使用されていました。サポートされているボードの写真を見ていたら、どれにも有線LANコネクタが無いことに気付きました。時代の流れでしょうか、、、

Getting Started with Amazon FreeRTOS
aws.amazon.com/freertos/getting-started/

Amazon FreeRTOS
aws.amazon.com/freertos/

Amazon FreeRTOS ソースコード
github.com/aws/amazon-freertos

[関連リンク]

FreeRTOS - freertos.org
www.freertos.org/

FreeRTOS - sourceforge.net
sourceforge.net/projects/freertos/files/

FreeRTOS kernel自体はCC-RXにも対応
github.com/aws/amazon-freertos/tree/master/lib/FreeRTOS/portable/Renesas

Amazon FreeRTOSはTLSにmbed TLSを使用
github.com/aws/amazon-freertos/tree/master/lib/third_party/mbedtls

[ニュース]

組み込み業界に大インパクト「Amazon FreeRTOS」の衝撃 - 大原雄介,MONOist
monoist.atmarkit.co.jp/mn/articles/1712/28/news011.html

アマゾン「AWS IoT」は何が衝撃的なのか - 大原雄介,MONOist
monoist.atmarkit.co.jp/mn/articles/1510/21/news026.html

(2018/01/01 : 記事を選び直しました。)

[追記]

もしかしたら、オープンソースライセンスのドライバライブラリが用意されていないから、ルネサスさんはアマゾンさんに相手にして貰えないのかも、、、

ちなみに、FreeRTOS kernel自体のライセンスがV10からModified GPLからMIT Licenseに変わったようです。

  • シェルティさん、こんにちは。NoMaYです。

    案件その1

    今の作業で以下を追加しようと思います。(夜ぐらい)

    ・GR-SAKURAのr_bsp_config.hでのIスタック=4KB/Uスタック=未使用の設定を他のボードへも展開する

     (a) R_PRAGMA_USTACK_SIZE()マクロとR_PRAGMA_ISTACK_SIZ()の改良案が思い浮かんだのがきっかけです。現状、CC-RXの#pragma stacksize si又はsu=sizeでsizeが'(0x3000)'のようなカッコ付きですとエラーになる都合から、以下のr_bsp_config.hの記述が不自然になる部分がありましたが、マクロ改良案に気付きました。

    現状(以下はGR-SAKURAでの例、他のものはR_PRAGMA_USTACK_SIZEもR_PRAGMA_ISTACK_SIZEも共に0x3000です)

    r_bsp_config.h

    /* The 'BSP_DECLARE_STACK' macro is checked so that the stack is only declared in one place (resetprg.c). Every time a 
       '#pragma stacksize' is encountered, the stack size is increased. This prevents multiplication of stack size. */
    #if defined(BSP_DECLARE_STACK)
        /* If only 1 stack is chosen using BSP_CFG_USER_STACK_ENABLE then no RAM will be allocated for the user stack. */
        #if (BSP_CFG_USER_STACK_ENABLE == 1)
        /* User Stack size in bytes. The Renesas RX toolchain sets the stack size using the #pragma stacksize directive. */
        R_PRAGMA_USTACK_SIZE                (0)
        #endif

    /* Interrupt Stack size in bytes. The Renesas RX toolchain sets the stack size using the #pragma stacksize directive.
     * If the interrupt stack is the only stack being used then the user will likely want to increase the default size
     * below.
     */
    R_PRAGMA_ISTACK_SIZE                    (0x1000)
    #endif

    マクロ改良後(マクロ呼び出し部に関してはresetprg.cへ移しました)(マクロ名もちょっと変えました)

    r_bsp_config.h

    /* If only 1 stack is chosen using BSP_CFG_USER_STACK_ENABLE then no RAM will be allocated for the user stack. */
    #if (BSP_CFG_USER_STACK_ENABLE == 1)
    /* User Stack size in bytes. The Renesas RX toolchain sets the stack size using the #pragma stacksize directive. */
    #define BSP_CFG_USTACK_BYTES            (0)
    #endif

    /* Interrupt Stack size in bytes. The Renesas RX toolchain sets the stack size using the #pragma stacksize directive.
     * If the interrupt stack is the only stack being used then the user will likely want to increase the default size
     * below.
     */
    #define BSP_CFG_ISTACK_BYTES            (0x1000)

    resetprg.c

    /* Declaration of stack size. */
    #if (BSP_CFG_USER_STACK_ENABLE == 1)
    R_PRAGMA_STACKSIZE_SU(BSP_CFG_USTACK_BYTES)
    #endif
    R_PRAGMA_STACKSIZE_SI(BSP_CFG_ISTACK_BYTES)


     (b) そして、GR-SAKURA→GR-SAKURA IIの話の件でスタック設定も他のと同じに戻ったと思っていたところ、よくよくr_bsp_config.hを見るとそのままになっていて、どうも、AFQPテストもRX65N RSKと同程度は通るらしいことにも気付きました。(シェルティさんの週末作業の機材の都合からGR-SAKURAでもテストされていたので。)

     (c) それなら、今回のマクロを改良しようと思った機会に、そこを触るのだからスタック設定もGR-SAKURA以外でもGR-SAKURAに合わせておこう、と思い至りました。

    案件その2

    >実はすでにAmazonの検定を進めておりまして、

    GitHubのrenesas-rx/amazon-freertosにAmazonさんから指摘が入るようにもなったのですね。

    github.com/renesas-rx/amazon-freertos/issues/1

    それで、特に気掛かりなのは、ファイルシステム上のフォルダ構成やe2 studio見えでのフォルダ構成として、スマートコンフィグレータのツールの制約と使い勝手の兼ね合いで今の構成に至っている部分ですが、このまま行けそうでしょうか? それとも、雲行きが怪しそうでしょうか?

    なお、作業項目の以下を日曜夜半ぐらいにやるつもりです。見合わせた方が良ければそうします。(GR-SAKURAの方に関してはAmazonさんには影響無いと思いますが。)

    ・freertos_commonフォルダのIDE見えの位置をlibフォルダの奥底からsrcフォルダの直下に移す(IDE側のリンクのみ変更)
    ・GR-SAKURAのプロジェクトのフォルダ名を rx63n-gr-sakura → rx63n-gr-sakura2 に変更する

    [追記]

    案件その3

    Amazonさんからの指摘ですが、masterブランチの最新版に関してですね。Git/GitHubに関して詳しくないですが、developブランチなどを作成して、そちらで日々のコミット(私の手元に環境が無く、シェルティさんのCONFORMED頼りだったのですが、そうも行かなくなりそう?)をするようなのが良いのだろうか?

  • シェルティさん、こんにちは。NoMaYです。

    案件その4

    Amazonさんからの指摘の以下なのですが、どうしたものかと食事をしていて思ったのは、私の手元に環境が無く、今まで出来る限り気を付けながらコミットしていたのですが、この指摘に対してはどうするのが良いでしょうか?このまま無視して今夜コミットするのもどうしたものかな、と気掛かりな次第です。(今の、renesas-rx/amazon-freertosリポジトリのmasterブランチはいわゆる開発ブランチであって品質保証するリリースブランチでは無いと思っていたのですが、Amazonさんは違う認識なのかな?と気になったのです。)(もちろん開発ブランチだからといって、滅茶苦茶にコミットするつもりは無いですが、人間ですので気の緩みというのはどうしてもありまして、、、)

    github.com/renesas-rx/amazon-freertos/issues/1


    Please test all of the new changes.


    案件その5

    シェルティさんのreadme.txtにあった以下の案件ですが、私のgitの設定を変えた方が良いですか?(といっても、どう設定すべきか分からずにいます。gitをインストールし直して初期設定に戻せば良いのだろうか?、、、) 先程、shinya083さんのコミットに気付いた時に、人が増えてきたので、私だけ違う設定になっていたら拙いな、と思ったからです。


     2018/11/25
      改行コードをLFにした方が良いのではないか。本家はLF、ルネサスはCRLFと
      なっている。

  • In reply to NoMaY:

    NoMaYさん

    シェルティです、こんにちは。

    案件その1:承知しました。問題ないです。
    案件その2:おっと。Amazon本家からIssue届いてますね。
          これはローカルで受けた指摘でもあります。こちらで修正します。
          あのAmazonのエンジニアとGitHub上で絡むことになるとは、Amazonの日本サービス開始時からの
          生粋のAmazonジャンキーとして嬉しい限りです。
          ちなみに、今のプロジェクトの作りで、合格まで辿り着けそうです。
          (細かくはAmazonの規定に従い移動、リネームなどが必要です)
          「スマートコンフィグレータの出力先を調整」「FITモジュールのRTOS、GCC、IAR対応」が
          出揃ってこれば、そのときまた調整すればよいかと思います。
    案件その3:うちの開発チーム内でも「ブランチ作ったほうがよいのでは」と声が上がっていますが、
          今のところはマスターのみで進めたいです。
          ブランチの運用方法が定まっていないためです。
          しばらくはシェルティが踏ん張ってリリースビルドを作ります。
          今週末に一度全環境の動作確認をしてみてリリースビルドを作ってみようかと思っています。
          現状の通り、気にせずマスターにコミットしてください。
    案件その4:案件その3と同じで、気にせずマスターにコミットしてください。
          Amazonの検定に合格したら、Amazon Web Service側にプラットフォーム毎に検定済みの
          プロジェクトが掲載されます。GitHubは検定されてない状態の最新ソースコードの束ですね。
    案件その5:コミット時になるべく前のファイルの改行コードを踏襲するようにしましょう。
          追って方針(Gitの改行コード設定、FITのコーディングルールに
          改行コードのルールを追加、など)を考えたいと思います。

          社内で本件活動報告書を回していたら、有志が何人か本プロジェクト参加表明してくれたので、
          またもう少しコミットする人が増えるかもしれないです。

    以上です
  • In reply to シェルティ:

    NoMaYさん

    シェルティです。こんにちは。

    いつぞやのNOP()ですが、削除して問題ないことが確認できました。
    BSPのresetprg.c にあったNOP()ですね。
    なぜNOP()があったかまでは確認できませんでした。
    公式のBSP側で直すので、我々のGitHubは特に手を入れなくても大丈夫です。
    そのうち公式のBSP(とRX Driver Package全般)がGCC対応とIAR対応を盛り込みますので
    それを適用すれば自然に治ります。

    以上です
  • In reply to シェルティ:

    シェルティさん、こんにちは。NoMaYです。

    すみません。寝落ちしてしまいました。今夜(こそ)やります。(日中、他の事に気を取られていて準備を後回しにしていたら、やらかしてしまいました、、、)

    >・freertos_commonフォルダのIDE見えの位置をlibフォルダの奥底からsrcフォルダの直下に移す(IDE側のリンクのみ変更)

    なお、以下は終わりました。

    >・GR-SAKURAのプロジェクトのフォルダ名を rx63n-gr-sakura → rx63n-gr-sakura2 に変更する

    それで、気付いたのですが、先日の/.setting/の件に関しては、意図されたものは/.settings/ではないですか?(意図した本来のものの最後の's'が抜けているのではないですか?)

    >いつぞやのNOP()ですが、削除して問題ないことが確認できました。
    。。。
    >公式のBSP側で直すので、我々のGitHubは特に手を入れなくても大丈夫です。
    >そのうち公式のBSP(とRX Driver Package全般)がGCC対応とIAR対応を盛り込みますので
    >それを適用すれば自然に治ります。

    確認ありがとうございます。こちらは、1行削除で済むので手間ではありませんので、取っておこうと思います。

  • In reply to NoMaY:

    NoMaYさん

    こんにちは。シェルティです。

    コンフィグファイルをtest/demoでマージいただいているコミットですが
    少し様子見してあとで戻そうと思います。
    Amazonのメンバーから「なぜマージしているのか?」とコメントがありました。

    github.com/.../39a34fa41799ada514b5fb3e921d8c9afba9f0f9

    以上です
  • In reply to シェルティ:

    シェルティさん、こんにちは。NoMaYです。                                                            

    >コンフィグファイルをtest/demoでマージいただいているコミットですが
    >少し様子見してあとで戻そうと思います。
    >Amazonのメンバーから「なぜマージしているのか?」とコメントがありました
    了解しました。ただ、えっ、test/demo双方のFreeRTOSConfig.hをマージしたら何か拙いことでもあるのかな?という感もありますね。最大タスク名長とか最大ログ文字列長とかヒープサイズ等も同じにしてしまって、同じファイルにしてしまった方が扱い易いのではないか、と昨夜から思い始めていたところでした。そうしておけば、demoからtestへコピペすれば済むだけになるよね、と、、、

    それで、少し話が変わりますが、testプロジェクトではCC-RXのコード生成オプションに-branch=32が無いですね。実は少し前からdemoプロジェクトに-branch=32が付いているのはコード効率が悪くなるだけで無駄ではないかと思い始めていたところでした。今の作業で、GNURXで-O2を-O3にするつもりでいますが、CC-RXでは-branch=32を削除するようにしてはどうかと考え始めました。(なお、RX65N RSK testプロジェクトは、先ほど書いた通り、-branch=32は付いていませんので、そのまま変更無しです。他方、機材の都合によるバックアップ環境であるRX63N GR-SAKURA testプロジェクトの方は、-branch=32が付いていましたので、こちらは削除しておこうと思っています。)

    あと、demoプロジェクトの共通部(libの下のフォルダのソース)に手を入れている箇所ですが、Resesas固有部に移す方法が思い浮かんだ場合にはResesas固有部に移していくようにするつもりです。今、幾つか思い浮かびましたので、今後移していく(共通部のソースを元に戻していく)つもりです。

    [追記]

    ああっ、「なぜマージしているのか?」に関しては、差分が少ししかないファイルを見るとマージしたくなるのが私の性分というかクセというか、そういう面が大きいですね、、、(あと、幾つもの派生品種を同時に同列に扱いたがる、とかも、、、)

  • In reply to NoMaY:

    NoMaYさん

    こんにちは、シェルティです。

    いつもご協力感謝いたします。
    出張ラッシュが終わりようやく事務所に戻ってきました。

    ただいまAmazonから貰っているフィードバックを整理しています。
    いくつか、Amazonの検定を通すために必要な変更がありそうです。
    のちほど相談させていただければ、と思います。
    クリティカルな指摘は特にはなくて、ファイル構成やコピーライトに関する指摘などです。

    あとtests/demosのコンフィグのマージは様子見していたら以下コメントが追加で来てました。
    github.com/.../39a34fa41799ada514b5fb3e921d8c9afba9f0f9

    Thinking some more about this, I conclude this is fine if it is in your preference for them to be the same. I would recommend not leaving dead code (#if 0 ... #endif). You are free to define your configASSERT as best for the applications for your board and customers in demos/. Thank you for responding! :)

    #if0-#endifは消すのを推奨で、tests/demosを共通にしておくのはOKとのことです。
    個人的にはtests用のコンフィグ、demos用のコンフィグということで、似て非なるファイルが
    存在していても特に気にはなりませんでした。少し私もあとでコードを見てみてどうするか判断してみます。

    あと、-branch=32は残しておいていただけると幸いです。
    これは24ビット長を超えるメモリ空間にプログラムコードを転送して実行するプロジェクトを
    ビルドする際に必要です。具体的にはフラッシュメモリのセルフプログラミング時に
    コードを拡張RAM(RX65Nだと0x00800000以降)に転送しようとしてリンカ設定すると、
    リンクエラーになります。
    確かに多少効率は悪くなりますが、目に見えて悪くなるというわけではないので、
    ひとまずは-branch=32を維持しておきたいです。

    以上です
  • In reply to シェルティ:

    シェルティさん、こんにちは。NoMaYです。

    >ひとまずは-branch=32を維持しておきたいです。
    なるほど、セルフプログラミング時に必要になるのでしたか。了解しました。

    >#if0-#endifは消すのを推奨で、tests/demosを共通にしておくのはOKとのことです。
    たぶん、この#if0-#endifは、私が自分自身のTODOの気合を入れる目的、兼、作業の参考資料としてコメント的にFreeRTOSConfig.hに入れた以下の部分のことでしょうね。リリース前には何とかTODOを済ませて、これは削除してしまうつもりでいました。アサートは色んなやり方があって、面白いですね、、、

    /* TODO: Improve configASSERT() implementation. */
    #if 0 // For example, ESP32's FreeRTOSConfig.h has following code. */
     * FreeRTOS Kernel V10.0.1
     * Copyright (C) 2018 Amazon.com, Inc. or its affiliates.  All Rights Reserved.
    /* configASSERT behaviour */
    #if defined(CONFIG_FREERTOS_ASSERT_DISABLE)
        #define configASSERT(a) /* assertions disabled */
    #elif defined(CONFIG_FREERTOS_ASSERT_FAIL_PRINT_CONTINUE)
        #define configASSERT(a) if (!(a)) {                                     \
                ets_printf("%s:%d (%s)- assert failed!\n", __FILE__, __LINE__,  \
                        __FUNCTION__);                                       \
                }
    #else /* CONFIG_FREERTOS_ASSERT_FAIL_ABORT */
        #define configASSERT(a) if (!(a)) {                                         \
                    ets_printf("%s:%d (%s)- assert failed!\n", __FILE__, __LINE__,  \
                            __FUNCTION__);                                          \
                    abort();                                                        \
                }
    #endif
    #endif /* #if 0 */
    #if 0 // For example, XMC4800's FreeRTOSConfig.h has following code. */
     * FreeRTOS Kernel V10.0.1
     * Copyright (C) 2018 Amazon.com, Inc. or its affiliates.  All Rights Reserved.
    /* Define configASSERT() to disable interrupts and sit in a loop. */
    #define configASSERT( x )     if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }
    #endif /* #if 0 */
    #if 0 // Or to be orthodox? For example, Zynq7000's FreeRTOSConfig.h has following code. */
     * FreeRTOS Kernel V10.0.1
     * Copyright (C) 2018 Amazon.com, Inc. or its affiliates.  All Rights Reserved.
    #define configASSERT( x )    if( ( x ) == 0 )  vAssertCalled(__FILE__, __LINE__)
    #endif /* #if 0 */
    #if 0 // Or to be ANSI standard? For example, newlib has following code. */
    #ifdef NDEBUG           /* required by ANSI standard */
    # define assert(__e) ((void)0)
    #else
    # define assert(__e) ((__e) ? (void)0 : __assert_func (__FILE__, __LINE__, \
                                                           __ASSERT_FUNC, #__e))
    # ifndef __ASSERT_FUNC
      /* Use g++'s demangled names in C++.  */
    #  if defined __cplusplus && defined __GNUC__
    #   define __ASSERT_FUNC __PRETTY_FUNCTION__
      /* C99 requires the use of __func__.  */
    #  elif __STDC_VERSION__ >= 199901L
    #   define __ASSERT_FUNC __func__
      /* Older versions of gcc don't have __func__ but can use __FUNCTION__.  */
    #  elif __GNUC__ >= 2
    #   define __ASSERT_FUNC __FUNCTION__
      /* failed to detect __func__ support.  */
    #  else
    #   define __ASSERT_FUNC ((char *) 0)
    #  endif
    # endif /* !__ASSERT_FUNC */
    #endif /* !NDEBUG */
    #endif /* #if 0 */

    [余談]

    実は、Amazonさんからのコメントを見た時に驚いたのが、私が以下を書いたことに呼応するかのように来ていたことで、もしかしたら、AmazonさんであればAI自動翻訳で日本語スレッドをチェックするぐらい朝飯前かもなぁ、とか思ってしまいました、、、

    >最大タスク名長とか最大ログ文字列長とかヒープサイズ等も同じにしてしまって、同じファイルに
    >してしまった方が扱い易いのではないか、と昨夜から思い始めていたところでした。

  • In reply to NoMaY:

    NoMaYさん

    こんにちは、シェルティです。

    ご見解ありがとうございます。
    こちらはさきほど、AmazonのテストがすべてOKになることを確認しました。
    これからコードを整理した後、リリースビルドを作ってそれでもってAmazon側での検定に進みます。

    あと、相談前に実行してしまいましたが、AmazonからのフィードバックによりStdafx.hを一旦削除しました。
    このファイルの役割と指摘についてまだ私は理解できていませんので情報を整理してみるつもりです。
    すみません、過去情報をいただいていたかもしれませんが、Stdafx.hはどのような役割のものでしょう?

    他にも細かいところを追々相談させていただきたいと考えています。

    [余談]
    Amazonの人と話をしていると本当に話が進んでいくのが早く感じますね。
    ついていくのに必死になっています。

    以上です
  • In reply to シェルティ:

    シェルティさん、こんにちは。NoMaYです。

    >こちらはさきほど、AmazonのテストがすべてOKになることを確認しました。
    >これからコードを整理した後、リリースビルドを作ってそれでもってAmazon側での検定に進みます。
    それは良かったですね。それで、こちらからはスケジュール(ソフトの検定だけでなくボードの日程も)が見えないので確認したいことがあります。

    (1) ひょっとしてAmazonの検定もRX65N RSK+ETHERで行うのですか? つまり、テストの試行をRX65N RSK+ETHERで行っていた訳ではなく、まず今回、RX65N RSK+ETHERで正式に参加し、日程的に更にその先にて、次のステップでWiFiボードについても正式に参加する、という流れでしょうか?

    (2) 現在GitHubに登録されている他のボード及び今後登録予定のボード(RX71M/RX64M/RX63N RSK)もAmazonの検定をゆくゆくは受ける計画ですか? それとも、これらに関しては、ここ暫くは関心のある方がGitHubから取得出来れば良くて、将来はe2 studio上でAmazon FreeRTOSとRX Driver Package込のプロジェクトを生成出来るようになるので、それで事が足りそうであり、検定までは受けない計画ですか? あと、GNURXのプロジェクトに関してはどうですか?CS+のプロジェクトに関してはどうですか?(私なりに優先順位を考える時の参考にしたいです。といっても、今は、課題を3つ減らして2つ増やす、という進行状態ですが、、、)

    >他にも細かいところを追々相談させていただきたいと考えています。
    了解しました。早めに大枠的なところを知りたいです。(細かいところの、大枠的なところ、というのは日本語的に変な表現な気もしますが、、、) 今日/明日、またAmazon FreeRTOSの共通部に手を入れた箇所の1つをRenesas固有部に移すつもりでいますが、mbed TLSのコンフィグレーションが若干他と変わることになりそうであり、でも、そういうのは自己責任で(と重々釘をさされていたり)という話になっていれば、別の手を考えるか、そもそも手を入れた大元の動機自体から見合わせるとかします。

    あと、C++のプロジェクトは削除した方が良さそうですか? (先程、このスレッドの初期の頃に使用していた今まで休眠状態だったGitHubの私のAmazon FreeRTOS Renesas RXのリポジトリを運用可能状態にしましたので、そちらでポツリポツリとやっていくことが出来ます。) 検定前の今だけの事なのかも知れませんが、AmazonさんはRenesasさんの公式リポジトリを、リリース候補版の入手元として運用したがっているのかな?とか考えたりしています。(逆に考えると、ソースの受け渡し用リポジトリを用意しなかったのが拙かったかも?とか考えたりしています。)

    それから、今、RenesasさんのリポジトリのソースはRX65N RSK以外はビルド出来ないですが、修正しておきます。(あと、GNURXプロジェクトの-O2 → -O3も変えておこうと思います。) ああっ、そして更に本家Amazonがv1.4.5になってましたので、来週の平日のどこかで追従するようにします。今度は、MediaTek MT7697Hx Development Kit だそうです。あと、このボードでlwIPがサポートされたようです。

    >AmazonからのフィードバックによりStdafx.hを一旦削除しました。 このファイルの役割と指摘について
    >まだ私は理解できていませんので情報を整理してみるつもりです。
    このファイルの名前の由来は、私が若かりし頃にWindowsでプログラミングの勉強に使用していたMicrosoftの開発環境で使用されていたものからです。いったい何度 #include "StdAfx.h" と書いたことか、、、目的は以下の2点です。(なお、Microsoftの元々の導入理由は、Windowsヘッダファイル/MFCヘッダファイルが巨大であることによるコンパイル時間の増大(大昔のPCは非力でした)を解消する為にプリコンパイル済みヘッダという仕組みを実現する為でしたが、それは今回の目的ではありません。ちなみに、Windowsではこのような感じです。昔はもう少し複雑だった気がしますが、MFCが過去のものになったせいでしょうか、、、)

    (A) Amazon FreeRTOSのヘッダファイルが何十種類もあるので、主要なものを予めStdAfx.h内でインクルードして私&ユーザさんが細かいことを気にしなくても良いようにしたかったからです。(StdAfx.hはRenesas固有部に配置しました。) デメリットはコンパイル時間の増大ですが、Windowsヘッダファイル/MFCヘッダファイルに比べればAmazon FreeRTOSのヘッダファイルは小さいですし、今のPCは昔に比べれば格段に馬力がありますので、気にならないレベルだろうと考えました。

    (B) Amazon FreeRTOSのAWSコンポーネントのヘッダファイルにはC++からC関数を使えるようにするextern C { }が無かった(FreeRTOSカーネルのヘッダファイルには有る)のですが、それをAmazon FreeRTOSの共通部の個々のヘッダファイルに追加していくのは気が引けましたので、Renesas固有部に(A)の理由で配置してみたStdAfx.hでまとめてextern C { }することにしました。

    (B') なお、スマートコンフィグレータで自動生成されるCGのソースにもextern C { }がなく、ユーザコーディング箇所をうまくやりくりして出来ないものかと考えてみても出来ませんでしたので、StdAfx.hの親戚的なファイルとしてRenesasRX.hというのも作成しました。

    StdAfx.hとRenesasRX.hは以下の内容です。(以下のStdAfx.hはETHER用のものです。WiFi用のものはインクルードするファイルを若干変えてあります。)

    StdAfx.h

    7838.StdAfx_h_20181214.txt
    /* stdafx.h : include file for standard system include files,
     * or project specific include files that are used frequently, but
     * are changed infrequently (this is true not only in case of PCH
     * but also in general case of MAKE or build systems like MAKE)
     */
    
    #ifndef _STDAFX_H_
    #define _STDAFX_H_
    
    /* FreeRTOS includes. */
    #include "FreeRTOS.h"
    #include "task.h"
    #include "semphr.h"
    #include "queue.h"
    //#include "croutine.h" // Amazon FreeRTOS does not have this header
    #include "timers.h"
    #include "event_groups.h"
    #include "message_buffer.h"
    
    #ifdef __cplusplus
    extern "C" {
    #endif
    
    /* FreeRTOS headers seem to lack following declaration */
    #if( configUSE_DAEMON_TASK_STARTUP_HOOK == 1 )
    extern void vApplicationDaemonTaskStartupHook( void );
    #endif /* configUSE_DAEMON_TASK_STARTUP_HOOK */
    
    /* Version includes. */
    #include "aws_application_version.h"
    
    /* System init includes. */
    #include "aws_system_init.h"
    
    /* PKCS#11 includes. */
    #include "aws_pkcs11.h"
    #include "aws_pkcs11_config.h"
    
    /* Client credential includes. */
    #include "aws_clientcredential.h"
    
    /* mbedTLS includes. */
    #include "mbedtls/base64.h"
    
    /* Defender includes. */
    #include "aws_defender.h"
    
    /* Key provisioning includes. */
    #include "aws_dev_mode_key_provisioning.h"
    
    /* Greengrass includes. */
    #include "aws_ggd_config.h"
    #include "aws_ggd_config_defaults.h"
    #include "aws_greengrass_discovery.h"
    
    /* Logging includes. */
    #include "aws_logging_task.h"
    
    /* MQTT includes. */
    #include "aws_mqtt_agent.h"
    
    /* Amazon FreeRTOS OTA agent includes. */
    #include "aws_ota_agent.h"
    
    /* Required for shadow APIs. */
    #include "aws_shadow.h"
    
    /* FreeRTOS+TCP includes. */
    #include "FreeRTOS_IP.h" // Comment out when unnecessary
    ////#include "FreeRTOS_Sockets.h" // Using aws_secure_sockets.h is better
    
    /* TCP/IP abstraction includes. */
    #include "aws_secure_sockets.h"
    
    /* WiFi interface includes. */
    //#include "aws_wifi.h" // Remove '//' when necessary
    
    /* Standard includes. */
    #include <stdio.h>
    #include <string.h>
    #include <stdarg.h>
    #include <stdint.h>
    
    /* Project specific includes. (You can replace headers for your needs.) */
    #include "aws_demo_runner.h"
    
    #ifdef __cplusplus
    }
    #endif
    
    #endif /* _STDAFX_H_ */
    


    RenesasRX.h

    0005.RenesasRX_h_20181214.txt
    #ifndef _RENESASRX_H_
    #define _RENESASRX_H_
    
    #include "platform.h"
    
    #include "r_ether_rx_if.h"
    #include "r_flash_rx_if.h"
    #include "r_byteq_if.h"
    #include "r_sci_rx_if.h"
    //#include "r_cmt_rx_if.h"
    //#include "r_riic_rx_if.h"
    //#include "r_sci_iic_rx_if.h"
    
    #ifdef __cplusplus
    extern "C" {
    #endif
    
    #include "r_smc_entry.h"
    
    #ifdef __cplusplus
    }
    #endif
    
    #endif /* _RENESASRX_H_ */
    

     

  • In reply to NoMaY:

    NoMaYさん

    こんにちは、シェルティです。

    種々ありがとうございます。そして情報伝達不足について申し訳ありません。
    明日1件ずつしっかり読み込み回答いたします。

    実際にAmazonと調整を進めてみた結果、
    ものすごく柔軟に対応いただけることが分かりましたし、
    私自身も何がOKで何がNGか勘所が分かってきましたし、
    NoMaYさんにはほとんどいつも正解のコードをコミットいただいていますので、
    NoMaYさんには思う通りにコミットいただきたいです。
    NGに触れそうなときは都度相談致します。

    今週末、ある程度区切りの良いところでリリースビルドを作り、それを検定に回します。
    12月16日までに一回はリリースビルドを作り検定に回し、12月21日に検定完了が目標です。
    本家にルネサスのコードが登録されるのは年明けなるべく早く・・・でしょうかね。
    Mediatekにも先を越されましたね。これでAmazonのマイコンパートナーは8社目ですか。
    なんとかうちが9社目になって、順位一桁になりたいです。

    そしてご推察の通りEtherが第1候補で、Wifiが第2候補です。
    私としては暗号機能とネットワーク機能の連携が主目的ですので、
    TCP/IPとSSL/TLSがWifi内部に抱えられている構成は二の次です。
    本音を言うとWifiはPHY層だけの無線モジュールを使ってTCP/IPとSSL/TLSをマイコン側に
    持ってくる構成を第2候補にしたかったのですが、「とにかくWIFIをマイコンで制御したい」という
    要求の方が勝っているだろうと考えて順番を入れ替えました。
    第3候補以降、どのような順序で検定を通していくかは、現在計画中です。

    そのほかのご質問については、明日回答いたします。

    以上です
  • シェルティさん、こんにちは。NoMaYです。

    すみません。GNURXプロジェクトの -O2 → -O3 の変更は取り止めます。プログラム実行速度を気にしてのことでしたが、サイズのことも気になって、GR-SAKURAのプロジェクトで変更して確認したところ、大幅に増大してしまいました。

    -O2 指定時

    .text           0xfff00000    0x2f5f8 ⇒ 194040 バイト

    -O3 指定時

    .text           0xfff00000    0x3e430 ⇒ 255024 バイト

    生成されたアセンブラコードを見てみると、どうもstatic関数が積極的にインライン展開されるようで、その結果、サイズが肥大化してしまうようでした。GCCのオンラインドキュメントを見直してみると、-O2 と -O3 の違いは、プログラムサイズの増大を容認してプログラム実行速度の向上を優先させるかどうか、ということがポイントのようでした。

    3.10 Options That Control Optimization
    gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options

    -O2

        Optimize even more. GCC performs nearly all supported optimizations 
        that do not involve a space-speed tradeoff. As compared to -O,
        this option increases both compilation time and the performance of the generated code.

        -O2 turns on all optimization flags specified by -O.
        It also turns on the following optimization flags:
        以下省略

    -O3

        Optimize yet more. -O3 turns on all optimizations specified by -O2 
        and also turns on the following optimization flags:
        以下省略

    ちなみに、-O/-O1、-O0、-Os、-Og などは以下のようになってました。

    -O
    -O1 ⇒ コンパイル時間やコンパイルに必要なパソコンのメモリを大幅に増大させることの無い、そういう最適化

        Optimize. Optimizing compilation takes somewhat more time, 
        and a lot more memory for a large function.

        With -O, the compiler tries to reduce code size and execution time,
        without performing any optimizations that take a great deal of compilation time.

        -O turns on the following optimization flags:
        以下省略

    -O0 ⇒ コンパイル時間短縮最優先、デバッグ作業効率優先

        Reduce compilation time and make debugging produce the expected results. 
        This is the default.

    -Os ⇒ -O2に対してプログラムサイズを増大させる可能性のある最適化をしないようになっている

        Optimize for size. -Os enables all -O2 optimizations except those 
        that often increase code size:
        途中省略
        It also enables -finline-functions, causes the compiler to tune for code size rather than
        execution speed, and performs further optimizations designed to reduce code size.

    -Og ⇒ デバッグ作業効率最優先

        Optimize debugging experience. -Og should be the optimization level of choice 
        for the standard edit-compile-debug cycle, offering a reasonable level of optimization
        while maintaining fast compilation and a good debugging experience.
        It is a better choice than -O0 for producing debuggable code because some compiler passes
        that collect debug information are disabled at -O0.

        Like -O0, -Og completely disables a number of optimization passes
        so that individual options controlling them have no effect.
        Otherwise -Og enables all -O1 optimization flags except for those
        that may interfere with debugging:
        以下省略

     

  • In reply to NoMaY:

    シェルティさん、こんにちは。NoMaYです。

    >AmazonからのフィードバックによりStdafx.hを一旦削除しました。 このファイルの役割と指摘について
    >まだ私は理解できていませんので情報を整理してみるつもりです。
    今思えば、以下のようなファイルを作成してAfxBase.hというような名前にして、それをmain.cからインクルードすれば事足りたのかなぁ、という気がしてきています。(Amazonさんから09foxさんのコミットにコメントが入っていたので、オーソドックスな修正方法で、こちらで修正しました。AfxBase.hの手法は検定後に考察してみます。)

    それで、そもそも何が問題だったかというと、AmazonさんのCloudからAmazon FreeRTOSをダウンロードする時に使用するコンポーネントをカスタマイズするコンフィグレーションウィザードがあったと思いますが、Amazon FreeRTOSのコンポーネントのヘッダファイルを何でもかんでも軒並みインクルードしてしまうと、ウィザードで除外されたヘッダファイルはダウンロードに含まれていませんので、main.cでインクルードファイルが見つからないというエラーが発生してコンパイル出来なくなる、という点です。ですので、つまり、demosのmain.cでは必要最小限のコンポーネントのヘッダファイルのみインクルードしなければならない、という点です。

    以下は思い浮かんだAfxBase.hです。(以下はETHER用のものです、WiFi用のものはインクルードするファイルを若干変える必要があります。)

    AfxBase.h

    2630.AfxBase_h_20181215.txt
    #ifndef _AFXBASE_H_
    #define _AFXBASE_H_
    
    /* FreeRTOS includes. */
    #include "FreeRTOS.h"
    #include "task.h"
    #include "semphr.h"
    #include "queue.h"
    //#include "croutine.h" // Amazon FreeRTOS does not have this header
    #include "timers.h"
    #include "event_groups.h"
    #include "message_buffer.h"
    
    #ifdef __cplusplus
    extern "C" {
    #endif
    
    /* FreeRTOS headers seem to lack following declaration */
    #if( configUSE_DAEMON_TASK_STARTUP_HOOK == 1 )
    extern void vApplicationDaemonTaskStartupHook( void );
    #endif /* configUSE_DAEMON_TASK_STARTUP_HOOK */
    
    /* Version includes. */
    #include "aws_application_version.h"
    
    /* System init includes. */
    #include "aws_system_init.h"
    
    /* Logging includes. */
    #include "aws_logging_task.h"
    
    /* Key provisioning includes. */
    #include "aws_dev_mode_key_provisioning.h"
    
    /* FreeRTOS+TCP includes. */
    #include "FreeRTOS_IP.h"
    
    #ifdef __cplusplus
    }
    #endif
    
    #endif /* _AFXBASE_H_ */
    

     

  • In reply to シェルティ:

    シェルティさん、こんにちは。NoMaYです。

    以下の件ですが、私がRX63NのFITコンフィグレータで遭遇して気付いた対処法が使えるかも知れません。出来ているところまでの.project/.cproject/バッチファイルを頂けませんか?

    >この状態だと、スマートコンフィグレータでコード生成するとコンパイルが通らなくなる。
    >原因を解析したところ、スマートコンフィグレータがインクルードパスを1行ずつチェックし、
    >smc_genが含まれる行を全削除し、かならずプロジェクト配下のsmc_genにインクルードパスを
    >通しなおす動きをしていることが原因と判明。

Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page