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です。

    私の今の進捗です。その前に、AliOS Thingsですが、ライセンスはApache 2.0で、GitHubリポジトリは以下ですね。TCP/IPスタックはLwIP、TLSはmbed TLSのようです。また、VSCode pluginによるAliOS Studio IDEというものがあるようです。

    AliOS Things released by Alibaba is an open-source implementation of operating system (OS) for Internet of Things (IoT).
    github.com/alibaba/AliOS-Things

    Architecture Overview
    AliOS Things supports multiple architectures, including ARM, C-Sky, MIPS, rl78, rx600 and xtensa, AliOS Things also supports a large number of boards.
    From an architectural point of view, AliOS Things adapts Layered Architecture and Component Architecture. From bottom to top, AliOS Things includes:
        BSP: Board Support Package mainly developed and maintained by SoC Vendor
        HAL: Hardware Abstraction Layer, like WiFi, UART
        Kernel: Rhino RTOS Kernel, Yloop, VFS, KV Storage included
        Protocol Stack: LwIP TCPIP Stack, uMesh mesh networking stack included
        Security: TLS, TFS(Trusted Framework Service), TEE(Trusted Exexcution Environment)
        AOS API: AliOS Things exposed APIs for Application and Middleware
        Middleware: Alibaba's value-added and commonly seen IoT components included
        Examples: hands-on sample codes, and well tested applications such as linkkitapp
    All modules have been organized as Components, and each component has its own .mk file to describe its dependency with other Components, which enables applications to choose components needed easily.


    kernelのソース(この辺りかな)
    github.com/alibaba/AliOS-Things/tree/master/kernel/rhino/core

    kernelの概要
    github.com/alibaba/AliOS-Things/wiki/AliOS-Things-Technical-Overview#kernel-description

    サポートハードウェア
    github.com/alibaba/AliOS-Things/wiki/AliOS-Things-Hardware

    RL78対応
    github.com/alibaba/AliOS-Things/tree/master/platform/arch/rl78

    RX65N対応
    github.com/alibaba/AliOS-Things/tree/master/platform/arch/rx600/rx65n/e2s

    FreeRTOSからのポーティングガイド(現状は中文のみの模様)
    github.com/alibaba/AliOS-Things/wiki/AliOS-Things-FreeRTOS-Porting-Guide.zh

    Google検索: AliOS Things
    www.google.com/search?q=AliOS+Things

    以下、進捗です。(◆は新規項目です。)

    済み
    ●Amazon本家のv1.4.1→v1.4.2の差分の取り込み

    コミット済みだがデバッグ未着手
    ●スタートアップ処理でC++のコンストラクタを呼び出し可能にした(GNURXで使われていた#ifdef CPPAPP~#endifで括った)
    ◆R_BSPのsbrk()はCC-RXとGNURXで有効になっているけれどもGNURXで呼び出されることがあるかどうか確認する

    作業中
    ●コンパイル時のワーニングを減らす(FITモジュールのソースの修正もあります)
    ⇒たまたまMISRA-Cについて検索していて気付いたウェブページにあった文言「付加価値のない活動に労力を費やす」(この投稿の終わりの方の画面コピーを参照)にギクっとしているところですが、もう少し続けます。

    未着手
    ●GNURXのリンク時のワーニングを取る
    ◆GR-SAKURAのe2 studioプロジェクトでインクルードファイルに関してINDEXERエラーが出ているのを何とかしたい
    ●demos\renesas\XXX\common\config_file\*.hの#define等の順序をAmazon FreeRTOS本家の*.hに合わせる
    ●ビルド前ステップのバッチファイルの見直し(make.exeが見付かりません問題の緩和策も)

    最近気になり始めたこと(&思い出したこと) : RX71M-RSK, RX64M-RSK, RX63N-RSKの作業の前に対処したい分

    ◆ICCRX向けのiodefine.hの#pragma bitfields=reversedはreversed_disjoint_typesの方が良いのでは?
    ◆ICCRX向けのiodefine.hで#pragma pack()に切り替えたものを最後に元に戻すことを忘れているのでは?
    ●ICCRX向けのiodefine.hの__sfrはvolatileの方がうれしい人もいるような気がする
    ◆ICCRX対応の試作時の暫定コードが(FITモジュール以外のソースで)そのままになっていることを忘れないように
    ◆プロジェクト(ボード)でlib\wifi\portable\renesas\XXXX\aws_wifi.cが使われていない場合はプロジェクトから削除
    ●ボード依存のSCIのチャンネル番号の指定方法の見直し(現状はボード種別番号で切り替え)
    ●ボード依存のETHERの初期化関数名の指定方法の見直し(同上)
    ●SCIのチャンネルは1つで済む筈?(複数チャンネル有効化されているのは今では単に歴史的経緯のみ?)
    ●GR-SAKURAのIスタック/Uスタック(今回未使用)/R_BSPヒープのサイズは他ボードへ展開した方が良い?

    最近気になり始めたこと(&思い出したこと) : もう少し先で対処したい分

    ◆MOTファイルとMAPファイル(CC-RXでは出力を詳細に変更)をGitHubに登録してはどうだろうか?
    ●3コンパイラ対応のFITモジュールが正式リリースされた後のプロジェクト構造をどうする?
    ⇒将来e2 studio上でAmazon FreeRTOSとRX Driver Package込のプロジェクトを生成出来るようになるので任せる?
    ●各プロジェクトのマイコン型番をユーザのターゲットボードのマイコン型番に変更する簡単な方法は?
    ⇒e2 studio v7.1.0(後日インストール予定)でプロジェクトのマイコン型番変更が簡単になったようだが活用出来るか?
    ◆各プロジェクトのボード名をユーザのターゲットボードのボード名に変更する簡単な方法は?
    ●試作基板のGR-ROSEはR5F565NEDxLJでしたね(でも量産基板で変わるかも? それから"_DUAL"は有りか無しか?)
    ●GR-CITRUS(RX631)+WA-MIKAN(ESP8266) 対応
    ●FreeRTOS+POSIX 対応

    最近気になり始めたこと : ツールで対処して貰わないと駄目そうな分
    ◆ワーニングレベルを上げるとvoid R_CGC_Create_UserInit();のような引数void無し関数宣言/関数本体で警告が出る(CG)
    ◆ワーニングレベルを上げるとvoid R_SCI_PinSet_SCI0();のような引数void無し関数宣言/関数本体で警告が出る(FIT)

    将来の探求テーマ
    ◆Amazon FreeRTOSのスタック使用量の調査/考察/適正化
    ◆Amazon FreeRTOSのヒープ使用量の調査/考察/適正化
    ◆Amazon FreeRTOSのRAM使用量の調査/考察
    ◆Amazon FreeRTOSのROMコードサイズのRXコアと他CPUコア(Cortex-M4/MIPS microAptiv/Xtensa LX6)とでの比較
    ◆Amazon FreeRTOSでRXマイコンのMPU(メモリプロテクションユニット)を有効にするには?
    ◆Amazon FreeRTOSのソースのCC-RXによるMISRA-C 2012ルールチェック

    以下、Amazon本家のv1.4.1→v1.4.2の差分の取り込みに関して、いつものように画面コピーです。

    Amazon本家のv1.4.1→v1.4.2では素朴に比較すると1000ファイル近い差異が出るが、、、


    現状のRenesas RXのプロジェクトに直接(および間接的に)関係のある差異は50ファイルほど


    ただし今回は空白類文字の差異を無視するソースファイル比較で検出されない差異でMOTファイルが変化する差異あり


    なおソースファイル中で__DATE__が使われていて(今回に限らず)ビルド日付が異なるとMOTファイルは数バイト変わる


    [参考]

    レガシーコードをMISRA C 2012準拠にするための実践的ガイド
    Published 2018年4月27日
    parasoft.techmatrix.jp/practical-guide-to-make-your-legacy-codebase-misra-c-2012-compliant
    赤枠は私によるもの


    [余談]

    以前、このスレッドを開いた時のビューカウント値が 21212 になっていて面白かったので採取したことがありましたが、今度は、ビューカウント値が 23432 になっていたことがあったので採取した画面コピーです。

  • In reply to NoMaY:

    NoMaYさん

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

    AliOSの情報まとめ、ありがとうございます。
    とにかくもってクラウドサービスに接続させることに
    AlibabaもAmazonも熱心であるようですね。

    以下、こちらの進捗です。

    (1)nop()の件についてはコンパイラチームに確認中です。
    (2)Amazon FreeRTOSが動作するRX65N WIFI対応ボードは当初計画通りの内容、お値段で調整中です。
     前段としてRX65N RSK(Ether)版でAmazon FreeRTOS Qualification Programに臨んでいます。
     (RXマイコンとしては無線LANより有線LANのユーザが多いので有線LANが本命)
    (3)SilexのWIFIモジュールはSSLクライアント認証機能が使えないのでAmazon FreeRTOS内部のmbed TLSの力を
     借りたソフトウェア実装となりRAMが64KB必要です。
     この壁を超えるため、ESP32の検討を進めています。これが実現できれば、RAMは16KBで済み、
     RX130、RX231などの小型マイコンでもAmazon Web Serviceに繋ぐことができます。
     繋ぐことができればこれもまたGitHubにプロジェクトを追加するつもりです。
     (2)に同梱のWIFIモジュールはSilexのものですが、PMOD接続なので、ESP32の以下モジュールを代わりに
     差し込めば動くようにGitHub上のプロジェクトを調整するつもりです。
     store.digilentinc.com/.../
    (4)RX65N GR-ROSE用に、ESP8266のドライバを作ってAmazon FreeRTOSに繋ぐ実験に成功しました。
     近々、GitHubのGR-ROSE用のプロジェクト(WIFI対応版)を追加します
    (5)RX65N 内蔵の暗号ハードウェアTrusted Secure IPを使ってmbed TLSを加速させるための
     mbed TLS改造方法の検討を進めています
    (6)Amazon FreeRTOSのOTA機能について引き続き調査を進めています

    [余談]
    20000もカウンタ回ったのですね。このスレッドがはじまったのが2017年12月2日、そろそろ1年であります。
    非常に多くの議論ができ、実際の商売にもつながるような成果が出せました。
    何よりコミュニティベースで開発を進めることができたのは非常に良かったです。
    これからもこのスレッドでNoMaYさんと会話しながらAmazon FreeRTOSの開発を続けていきたいです。
    今後ともよろしくお願いします。

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

    私の今の進捗です。なお、Amazon本家がv1.4.2→v1.4.3になっていましたので、これから差分の取り込みを行います。今回のリリースのメインはXilinx Zynq-7000 based MicroZed Industrial IoT Bundleというボードが追加されたことですかね。あと、mbed TLSライブラリが2.8.0→2.13.1になったことと、PKCS #11ライブラリ(まだルネサスボードへの移植済みソースは無い)の抜本的変更があったことも、大きなところのようです。(といっても、私には以下の変更履歴の内容はチンプンカンプンだったりしますが、、、)

    Change Log for Amazon FreeRTOS
    github.com/aws/amazon-freertos/blob/86a1c8a/CHANGELOG.md

    ちなみに、v1.4.3のフォルダツリーをチラ見していて気付いたのですが、.projectファイルや.cprojectファイルのAFQP適合チェックツール、ソースコードのスタイル(Hungarian Notation)チェックツール、gitのhooksなどもありました。そして、AFQP適合チェックでは"aws_demos"以外のプロジェクト名は不可にしていました。(以前、AFQPのドキュメントを読んだ時には不可だとは読み取れませんでしたが、、、) 認証を受けるプロジェクトに関しては(その時までには)"aws_demos"に戻しておく必要がありそうです。

    AFQP適合チェックツール
    github.com/aws/amazon-freertos/tree/86a1c8a/tools/checks/afqp/afqp_check

    Hungarian Notationチェックツール
    github.com/aws/amazon-freertos/tree/86a1c8a/tools/checks/style/hn_check

    Git-Hooks
    github.com/aws/amazon-freertos/tree/86a1c8a/tools/git/hooks

    以下、進捗です。(は新規項目もしくは状況変化項目です。)

    作業中
    コンパイル時のワーニングを減らす(FITモジュールのソースの修正もあります)
    ⇒来週の中頃までには作業を終了させます(区切りを付けます)
    Amazon本家のv1.4.2→v1.4.3の差分の取り込み
    ⇒チラ見中です

    来週中頃~再来週初めの作業
    ●GNURXのリンク時のワーニングを取る
    ●GR-SAKURAのe2 studioプロジェクトでインクルードファイルに関してINDEXERエラーが出ているのを何とかしたい
    ●demos\renesas\XXX\common\config_file\*.hの#define等の順序をAmazon FreeRTOS本家の*.hに合わせる
    ●ビルド前ステップのバッチファイルの見直し(make.exeが見付かりません問題の緩和策も)

    コミット済みだがデバッグ未着手だった件の作業(来週中頃~再来週初め)
    ●スタートアップ処理でC++のコンストラクタを呼び出し可能にした(GNURXで使われていた#ifdef CPPAPP~#endifで括った)
    ●R_BSPのsbrk()はCC-RXとGNURXで有効になっているけれどもGNURXで呼び出されることがあるかどうか確認する

    最近気になり始めたこと : ツールで対処して貰わないと駄目そうな分
    ●ワーニングレベルを上げるとvoid R_CGC_Create_UserInit();のような引数void無し関数宣言/関数本体で警告が出る(CG)
    ●ワーニングレベルを上げるとvoid R_SCI_PinSet_SCI0();のような引数void無し関数宣言/関数本体で警告が出る(FIT)

    最近気になり始めたこと(&思い出したこと) : RX71M-RSK, RX64M-RSK, RX63N-RSKの作業の前に対処したい分

    有線LAN版のsecure socketsのポーティングソースをAmazon FreeRTOSが事前準備しているフォルダ下のソースに変更
    entropy_hardware_poll.cのmbedtls_hardware_poll()が取り敢えず版のような印象なので直してみる
    ●ICCRX向けのiodefine.hの#pragma bitfields=reversedはreversed_disjoint_typesの方が良いのでは?
    ●ICCRX向けのiodefine.hで#pragma pack()に切り替えたものを最後に元に戻すことを忘れているのでは?
    ●ICCRX向けのiodefine.hの__sfrはvolatileの方がうれしい人もいるような気がする
    ●ICCRX対応の試作時の暫定コードが(FITモジュール以外のソースで)そのままになっていることを忘れないように
    ●プロジェクト(ボード)でlib\wifi\portable\renesas\XXXX\aws_wifi.cが使われていない場合はプロジェクトから削除
    ●ボード依存のSCIのチャンネル番号の指定方法の見直し(現状はボード種別番号で切り替え)
    ●ボード依存のETHERの初期化関数名の指定方法の見直し(同上)
    ●SCIのチャンネルは1つで済む筈?(複数チャンネル有効化されているのは今では単に歴史的経緯のみ?)
    ●GR-SAKURAのIスタック/Uスタック(今回未使用)/R_BSPヒープのサイズは他ボードへ展開した方が良い?

    最近気になり始めたこと(&思い出したこと) : もう少し先で対処したい分

    ●MOTファイルとMAPファイル(CC-RXでは出力を詳細に変更)をGitHubに登録してはどうだろうか?
    ●3コンパイラ対応のFITモジュールが正式リリースされた後のプロジェクト構造をどうする?
    ⇒将来e2 studio上でAmazon FreeRTOSとRX Driver Package込のプロジェクトを生成出来るようになるので任せる?
    ●各プロジェクトのマイコン型番をユーザのターゲットボードのマイコン型番に変更する簡単な方法は?
    ⇒e2 studio v7.1.0(後日インストール予定)でプロジェクトのマイコン型番変更が簡単になったようだが活用出来るか?
    ●各プロジェクトのボード名をユーザのターゲットボードのボード名に変更する簡単な方法は?
    ●試作基板のGR-ROSEはR5F565NEDxLJでしたね(でも量産基板で変わるかも? それから"_DUAL"は有りか無しか?)
    ●GR-CITRUS(RX631)+WA-MIKAN(ESP8266)対応⇒シェルティさんのGR-ROSE用ESP8266ドライバを自力移植しては?
    ●FreeRTOS+POSIX対応

    将来の探求テーマ
    ●Amazon FreeRTOSのスタック使用量の調査/考察/適正化
    ●Amazon FreeRTOSのヒープ使用量の調査/考察/適正化
    ●Amazon FreeRTOSのRAM使用量の調査/考察
    ●Amazon FreeRTOSのROMコードサイズのRXコアと他CPUコア(Cortex-M4/MIPS microAptiv/Xtensa LX6)とでの比較
    Amazon FreeRTOSの各プロジェクトでのコンパイラ最適化レベルでRXコアと他CPUコアのCoreMark/MHzを比較すると?
    更にプリエンプションを禁止した状態と許可した状態でそれぞれRXコアと他CPUコアのCoreMark/MHzを比較すると?
    ●Amazon FreeRTOSでRXマイコンのMPU(メモリプロテクションユニット)を有効にするには?
    ●Amazon FreeRTOSのソースのCC-RXによるMISRA-C 2012ルールチェック

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

    私の今の進捗です。その前に、Amazon FreeRTOSにDevice Defenderサポート機能がありますが、何をするものなのか良く分からなかったので少し調べてみました。結局、まだ良く分かっていませんが、見てみたページのURLを書いておきます。(せっかく少し調べたので、、、)

    Amazon FreeRTOS の特徴
    aws.amazon.com/jp/freertos/features/

    AWS IoT の Device Defender のサポート

    Amazon FreeRTOS は AWS IoT Device Defender ライブラリを提供します。AWS IoT Device Defender との統合により、デバイス側のメトリクスについて簡単にレポートでき、それらのメトリクスが予想動作から逸脱すると異常を検出します。また、AWS IoT Device Defender は Amazon FreeRTOS デバイスに関連する IoT 設定を継続的に監査し、それらがセキュリティのベストプラクティスを順守するようにします。


    AWS IoT Device Defenderの特徴
    aws.amazon.com/jp/iot-device-defender/features/

    監査

    AWS IoT Device Defender では、所有するデバイスに関連付けられたリソース (X.509 証明書、IoT ポリシー、クライアント ID など) が、AWS IoT セキュリティのベストプラクティス (最小限の特権の原則、デバイスごとの ID の付与など) に従っているかどうかを監査できます。・・・以後省略・・・

    検出

    AWS IoT Device Defender では、デバイスおよび AWS IoT Core から送信される重要なセキュリティメトリクス (デバイスのリッスン状態の TCP ポートの数や、認証に失敗した回数など) を継続的にモニタリングすることで、セキュリティ侵害の兆候を示す、通常と異なるデバイスの動作を検出できます。・・・以後省略・・・


    AWS IoT Device Defender による IoT デバイスのセキュリティ管理
    www.slideshare.net/AmazonWebServicesJapan/aws-iot-device-defender-iot

    IoT におけるセキュリティ
    www.slideshare.net/AmazonWebServicesJapan/iot-122553904

    以下、進捗です。(は新規項目もしくは作業順序変更項目もしくは状況変化項目です。)

    済み
    Amazon本家のv1.4.2→v1.4.3の差分の取り込み
    ⇒なおAmazon本家のGitHubの運用方針が変わったのか(?)今までと異なり新規コミットが随時追加されています
    コンパイル時のワーニングを減らす(FITモジュールのソースの修正もあります)
    ⇒今週の中頃までに作業を終了させたかった(区切りを付けたかった)のですが金曜まで掛かってしまいました

    本日~来週中頃の作業
    プロジェクト(ボード)でlib\wifi\portable\renesas\XXXX\aws_wifi.cが使われていない場合はプロジェクトから削除
    ⇒未使用引数のワーニングが多数出るので先に行う(AFQP適合チェックツールでは削除されていてもワーニングのようです)
    ⇒なおaws_ota_pal.cとaws_pkcs11_pal.cも未実装なので未使用引数のワーニングが多数出ますが実装後は無くなる筈
    ●GNURXのリンク時のワーニングを取る
    ●GR-SAKURAのe2 studioプロジェクトでインクルードファイルに関してINDEXERエラーが出ているのを何とかしたい
    ●demos\renesas\XXX\common\config_file\*.hの#define等の順序をAmazon FreeRTOS本家の*.hに合わせる
    ●ビルド前ステップのバッチファイルの見直し(make.exeが見付かりません問題の緩和策も)

    コミット済みだがデバッグ未着手だった件の作業(本日~来週中頃の作業)
    ●スタートアップ処理でC++のコンストラクタを呼び出し可能にした(GNURXで使われていた#ifdef CPPAPP~#endifで括った)
    ●R_BSPのsbrk()はCC-RXとGNURXで有効になっているけれどもGNURXで呼び出されることがあるかどうか確認する

    最近気になり始めたこと : ツールで対処して貰わないと駄目そうな分
    ●ワーニングレベルを上げるとvoid R_CGC_Create_UserInit();のような引数void無し関数宣言/関数本体で警告が出る(CG)
    ●ワーニングレベルを上げるとvoid R_SCI_PinSet_SCI0();のような引数void無し関数宣言/関数本体で警告が出る(FIT)

    最近気になり始めたこと(&思い出したこと) : RX71M-RSK, RX64M-RSK, RX63N-RSKの作業の前に対処したい分

    ROMキャッシュが存在するものはROMキャッシュを有効にする?(r_bsp_config.hで指定) (10%速くなる可能性もある?)
    GNURXプロジェクトのコンパイラ最適化レベルを -O2 → -O3 に上げる(CC-RXに関してはもう少し先で考える?)
    ●有線LAN版のsecure socketsのポーティングソースをAmazon FreeRTOSが事前準備しているフォルダ下のソースに変更
    無線LAN版のsecure socketsのポーティングソースと有線LAN版のズレが大きくなっているのを何とかした方が良いか?
    ●entropy_hardware_poll.cのmbedtls_hardware_poll()が取り敢えず版のような印象なので直してみる
    ●ICCRX向けのiodefine.hの#pragma bitfields=reversedはreversed_disjoint_typesの方が良いのでは?
    ●ICCRX向けのiodefine.hで#pragma pack()に切り替えたものを最後に元に戻すことを忘れているのでは?
    ●ICCRX向けのiodefine.hの__sfrはvolatileの方がうれしい人もいるような気がする
    ●ICCRX対応の試作時の暫定コードが(FITモジュール以外のソースで)そのままになっていることを忘れないように
    ●ボード依存のSCIのチャンネル番号の指定方法の見直し(現状はボード種別番号で切り替え)
    ●ボード依存のETHERの初期化関数名の指定方法の見直し(同上)
    ●SCIのチャンネルは1つで済む筈?(複数チャンネル有効化されているのは今では単に歴史的経緯のみ?)
    ●GR-SAKURAのIスタック/Uスタック(今回未使用)/R_BSPヒープのサイズは他ボードへ展開した方が良い?

    最近気になり始めたこと(&思い出したこと) : もう少し先で対処したい分

    ●MOTファイルとMAPファイル(CC-RXでは出力を詳細に変更)をGitHubに登録してはどうだろうか?
    ●3コンパイラ対応のFITモジュールが正式リリースされた後のプロジェクト構造をどうする?
    ⇒将来e2 studio上でAmazon FreeRTOSとRX Driver Package込のプロジェクトを生成出来るようになるので任せる?
    ●各プロジェクトのマイコン型番をユーザのターゲットボードのマイコン型番に変更する簡単な方法は?
    ⇒e2 studio v7.1.0(後日インストール予定)でプロジェクトのマイコン型番変更が簡単になったようだが活用出来るか?
    ●各プロジェクトのボード名をユーザのターゲットボードのボード名に変更する簡単な方法は?
    ●試作基板のGR-ROSEはR5F565NEDxLJでしたね(でも量産基板で変わるかも? それから"_DUAL"は有りか無しか?)
    ●GR-CITRUS(RX631)+WA-MIKAN(ESP8266)対応⇒シェルティさんのGR-ROSE用ESP8266ドライバを自力移植しては?
    ●FreeRTOS+POSIX対応

    将来の探求テーマ
    ●Amazon FreeRTOSのスタック使用量の調査/考察/適正化
    ●Amazon FreeRTOSのヒープ使用量の調査/考察/適正化
    ●Amazon FreeRTOSのRAM使用量の調査/考察
    ●Amazon FreeRTOSのROMコードサイズのRXコアと他CPUコア(Cortex-M4/MIPS microAptiv/Xtensa LX6)とでの比較
    ●Amazon FreeRTOSの各プロジェクトでのコンパイラ最適化レベルでRXコアと他CPUコアのCoreMark/MHzを比較すると?
    ●更にプリエンプションを禁止した状態と許可した状態でそれぞれRXコアと他CPUコアのCoreMark/MHzを比較すると?
    ●Amazon FreeRTOSでRXマイコンのMPU(メモリプロテクションユニット)を有効にするには?(RTOS未使用での事例 ,)
    ⇒脆弱性(Volnability)の簡易的な予防対策に活用することって出来ないものだろうか?
    ●Amazon FreeRTOSのソースのCC-RXによるMISRA-C 2012ルールチェック

  • In reply to NoMaY:

    NoMaYさん

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

    いつも開発にご協力いただき、ありがとうございます。
    こちらではテスト合格に向けてAmazon本社と会話を開始しております。

    PKCS #11周りの実装はとりあえずで作っておきました。
    github.com/.../aws_pkcs11_pal.c

    これまでヘッダファイルに存在していたAWS接続用のRSA秘密鍵とクライアント証明書が、
    不揮発性メモリ経由で読み出せるようなインタフェースが規定されてそこから取りだすようになりました。
    上記実装はひとまずRAM上にデータを展開してそれを取り出すように実装しました。
    もう少し整理してマイコン内蔵のデータフラッシュに保持するように改良する予定です。

    これで従来通りAmazon FreeRTOS最新版のV143でAWS接続ができるところまで確認できました。
    FreeRTOSのヒープとスタックは足りなくなっていたので増やしておきました。
    RX63NのGR-SAKURAが厳しいですね。128KBカツカツになってしまいました。
    とりあえず動くようにはしましたが、256KB RAMがあるGR-SAKURA II限定にした方が良いような気がします。

    テスト環境をV143に合わせて登録しました。
    github.com/.../ccrx-e2studio

    ひとまず初期化がひととおり通るところまで確認しました。
    古いバージョンのAmazon FreeRTOSではだいたいテストOKになっているので、
    調整していけば最新版のAmazon FreeRTOSでもテストOKにできそうです。

    こちらでは引き続きテスト環境を中心に開発を進めてまいります。

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

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

    GitHubに登録されたソースで3点気付きました。今週の作業のソース修正の折に、一緒に私の方で直しておこうと思います。

    (1) GR-SAKURAでRAMが厳しい件はGR-SAKURA II限定にします(CC-RXは足りたようですがGNURXは既にRAMが足りません)

    ・リンカスクリプトをGR-SAKURA II用に変更しておきます
    ・フォルダ名を rx63n-gr-sakura → rx63n-gr-sakura2 に変更しておきます

    (2) FreeRTOSConfig.hでconfigPLATFORM_NAMEが軒並みRenesasRX63Nになっていたのは私のミスですね。(RenesasRX64MやRenesasRX65Nも定義したような記憶があるのですが、記憶違いか、変更しなければと思ったものの結局忘れてしまったか、だと思います。すみません。) それで、このconfigPLATFORM_NAMEですが、どうもマイコン名を定義するようです。他社製品はそうなっています。

    #define configPLATFORM_NAME    "EspressifESP32"
    #define configPLATFORM_NAME    "XMC4800"
    #define configPLATFORM_NAME    "MicrochipPIC32MZEF"
    #define configPLATFORM_NAME    "NXPLPC54018"
    #define configPLATFORM_NAME    "WinSim"
    #define configPLATFORM_NAME    "STM32L475"
    #define configPLATFORM_NAME    "TICC3220"
    #define configPLATFORM_NAME    "XilinxZynq7000"

    なお、AFQPドキュメント(V1.1.2)の18頁には以下の記載があって紛らわしいですが、この定義は使われていないです。(上のは configPLATFORM_NAME、下のは mqttconfigMETRIC_PLATFORM、です。)

    (B3.3) Configure your board name
    Please put your board name in: $AFR_HOME/demos/[vendor]/[board]/common/config_files/FreeRTOSConfig.h
    #define mqttconfigMETRIC_PLATFORM "Platform=Unknown"
    Replace “Unknown” with your own board name.

    (3) RX65N RSKのCC-RX/e2 studioプロジェクトのコンパイラ最適化レベルの設定が0になってました

  • In reply to NoMaY:

    NoMaYさん

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

    (1)ご提案ありがとうございます、よろしくお願いします。
    (2)こちらも承知しました。マイコン名でお願いします。
    (3)ご指摘感謝です。私はどうも実機デバッグするときは最適化切るクセがありますね。
     Gitに登録するときは元に戻すことも意識を強めておきます。

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

     私の今の進捗です。(は新規項目もしくは作業順序変更項目もしくは状況変化項目です。) 文字ばかりで見辛いですが。

    済み
    ●プロジェクト(ボード)でlib\wifi\portable\renesas\XXXX\aws_wifi.cが使われていない場合はプロジェクトから削除
    ⇒未使用引数のワーニングが多数出るので先に行う(AFQP適合チェックツールでは削除されていてもワーニングのようです)
    ⇒なおaws_ota_pal.cとaws_pkcs11_pal.cも未実装なので未使用引数のワーニングが多数出ますが実装後は無くなる筈
    スタートアップ処理でC++のコンストラクタを呼び出し可能にした(GNURXで使われていた#ifdef CPPAPP~#endifで括った)
    ⇒お試しでGR-ROSEのGNURX/e2 studio(SmartConfigurator可)のC++(gnu++11)プロジェクトを作成してコミットしました
    ⇒GNURX/e2 studioでC99のCソースとC++11のC++ソースを混在させる方法についてはGR-ROSE SDKからヒントを得ました
    GR-ROSE SDKはAmazon FreeRTOS(FIT込み)のC(C99)とArduinoのC++とROS2(micro-RTPS-client)のCが混在してますね
    R_BSPのsbrk()はCC-RXとGNURXで有効になっているけれどもGNURXで呼び出されることがあるかどうか確認する
    ⇒NEWLIBとOPTLIBで実装が異なっておりNEWLIBではsbrk()が呼び出されましたがOPTLIBでは呼び出されませんでした
    ⇒この際ですのでsbrk.cをOPTLIB対応にしBSP_CFG_HEAP_BYTESをCC-RXとGNURXの両対応にしました(現状ICCRXは除外)
    ⇒なおNEWLIBもOPTLIBもmalloc/free系関数(及びC++のnew/deleteも)はスレッドセーフでは無いのでRTOSでは要注意です
    GNURXのリンク時のワーニングを取る
    ⇒調べたらassert()マクロ(内部でfprintf()関数やkill()関数等を使用)とfprintf()関数とsscanf()関数が原因でした
     (これらの関数の奥底で未実装のgetpid(),kill(),isatty(),fstat(),lseek(),read(),write(),close()を呼んでいる)
     またNEWLIBではsscanf()がfscanf()と奥底で共通になっていて共通ルーチン内で未実装関数が必要になっていました
    ⇒GNURXはfprintf()やkill()等は使用不可なので上位側(mbed TLSとTINYCBORの2つのOSSコンポーネント)を修正しました
     sscanf()を使用禁止には出来ないので最低限のlseek(),read(),write(),close()のダミー関数を作成して対処しました
    ⇒なおGNURXのインストールパッケージではNEWLIBのソースはrx-elf\rx-elf\bin\newlibフォルダにあります
    ⇒ちなみにシェルティさんのreadme.txtの課題のGNURXでE1の仮想コンソールを使う方法はNEWLIBとOPTLIBで異なります
     NEWLIBではprintf()やscanf()は主に上記のread()やwrite()を呼び出してくる筈です(なお他の関数も呼ばれます)
     ⇒read()やwrite()の中でE1と通信するようにします
     ⇒なお頑張ればセミホスティング機能まで実装することが可能な筈です(たぶんですが)
     OPTLIBではprintf()やscanf()は途中でputchar()やgetchar()を経由して_read()や_write()を呼び出してくる筈です
     ⇒_read()や_write()の中でE1と通信しても良いですがputchar()やgetchar()の中でE1と通信するのが簡単です
     ⇒なおfprintf()やfscanf()が無いのでFILE *fpでのセミホスティング機能は無理です(int fdであれば可能かも)
    RX65N RSKのCC-RX/e2 studioプロジェクトのコンパイラ最適化レベルの設定が0でコミットされていたのを戻しました
    Amazon本家のv1.4.3→v1.4.4の差分の取り込み

    本日~再来週初め目標の作業
    以下の3項目が未着手なので着手して完了を目指す
    ●GR-SAKURAのe2 studioプロジェクトでインクルードファイルに関してINDEXERエラーが出ているのを何とかしたい
    ⇒RX63Nではスマートコンフィグレータが使えずFITコンフィグレータを使ったが相違点を吸収する小細工が原因の筈
    ●demos\renesas\XXX\common\config_file\*.hの#define等の順序をAmazon FreeRTOS本家の*.hに合わせる
    ⇒FreeRTOSConfig.hにvLoggingPrint関数のプロトタイプ宣言の追加も(なおvLoggingPrintf関数の方はある)
    ●ビルド前ステップのバッチファイルの見直し(make.exeが見付かりません問題の緩和策も)
    ⇒e2 studioの問題ウィンドウに表示されるインクルードパスが見つかりませんエラーも何とかしたい(欲が出た)
    GR-SAKURAのプロジェクトのフォルダ名を rx63n-gr-sakura → rx63n-gr-sakura2 に変更する
    GR-SAKURAでも試しにGNURX/e2 studioのC++(gnu++11)プロジェクトを作成してGitHubに登録する
    ⇒但しFITConfigurator使用不可(そもそもコンパイラがGNURXである時点でFITConfiguratorが使えなくなってしまう)
    reset_program.asmの拡張子をマクロプリプロッセッサ対応の.Sに変更する(自アセンブラソース追加時にメリット)
    freertos_commonフォルダのIDE見えの位置をlibフォルダの奥底からsrcフォルダの直下に移す(IDE側のリンクのみ変更)
    ●ボード依存のSCIのチャンネル番号の指定方法の見直し(現状はボード種別番号で切り替え)
    ●ボード依存のETHERの初期化関数名の指定方法の見直し(同上)
    ●SCIのチャンネルは1つで済む筈?(複数チャンネル有効化されているのは今では単に歴史的経緯のみ?)
    main.cのpcApplicationHostnameHook()に"RX65N_FREERTOS_TCP_TEST"の文字列があるがRX65N→RenesasRXへ変更
    NetworkInterface.cのxApplicationDNSQueryHook()には"RX65N"の文字列があるがmain.cへ移して"RenesasRX"へ変更
    GitHubに登録済みFITソースで存在を忘れていたR_CMT_RX/R_IIC_RX/R_SCI_IIC_RXのワーニング削減のやり忘れを行う
    ●GNURXプロジェクトのコンパイラ最適化レベルを -O2 → -O3 に上げる(CC-RXに関してはもう少し先で考える?)

    最近気になり始めたこと : ツールで対処して貰わないと駄目そうな分
    ●ワーニングレベルを上げるとvoid R_CGC_Create_UserInit();のような引数void無し関数宣言/関数本体で警告が出る(CG)
    ⇒引数void無し関数宣言/関数本体の記述はC++のコンストラクタやデストラクタの記述スタイルの影響なのだろうか?
    ●ワーニングレベルを上げるとvoid R_SCI_PinSet_SCI0();のような引数void無し関数宣言/関数本体で警告が出る(FIT)
    ⇒各FITコンポーネントのテンプレートファイルを書き換えることで(書き換えるだけで)対応出来るかも知れません
    CC-RXでワーニングレベルを上げるとコンパイラ標準インクルードファイルに起因する警告が出るが対処をどうするか

    最近気になり始めたこと(&思い出したこと) : RX71M-RSK, RX64M-RSK, RX63N-RSKの作業の前に対処したい分

    ●ROMキャッシュが存在するものはROMキャッシュを有効にする?(r_bsp_config.hで指定) (10%速くなる可能性もある?)
    ●有線LAN版のsecure socketsのポーティングソースをAmazon FreeRTOSが事前準備しているフォルダ下のソースに変更
    ⇒今はAmazon FreeRTOSが事前準備しているulRand()→PKCS#11共通部→mbedTLS→mbedtls_hardware_poll()の流れ?
    ●無線LAN版のsecure socketsのポーティングソースと有線LAN版のズレが大きくなっているのを何とかした方が良いか?
    ⇒FreeRTOSIPConfig.h内でマクロ定義でFreeRTOS_XXXX()とsx_ulpgn_tcp_XXXX()の付け替えをして何とか出来ないか?
    ●entropy_hardware_poll.cのmbedtls_hardware_poll()が取り敢えず版のような印象なので直してみる
    ⇒元々はハードウェア乱数生成器用の関数であるがmbedTLSにソフトウェア版(config.hで切り替え?)が存在しないか?
    GR-SAKURAのIスタック/Uスタック(今回未使用)/R_BSPヒープのサイズは他ボードへ展開した方が良い?

    最近気になり始めたこと(&思い出したこと) : もう少し先で対処したい分

    以下の4項目は此方のカテゴリに移した
    ●ICCRX向けのiodefine.hの#pragma bitfields=reversedはreversed_disjoint_typesの方が良いのでは?
    ●ICCRX向けのiodefine.hで#pragma pack()に切り替えたものを最後に元に戻すことを忘れているのでは?
    ●ICCRX向けのiodefine.hの__sfrはvolatileの方がうれしい人もいる気がする(ビッグエンディアンを使わなければ)
    ●ICCRX対応の試作時の暫定コードが(FITモジュール以外のソースで)そのままになっていることを忘れないように
    Amazon FreeRTOSでアサートのOn/OffやデバッグメッセージのOn/Off/レベル変更は何種類あるか?設定する位置は?
    Renesas Driver Packageの新バージョンにGitHubに登録済みFITソースを追従させる
    ●MOTファイルとMAPファイル(CC-RXでは出力を詳細に変更)をGitHubに登録してはどうだろうか?
    ●3コンパイラ対応のFITモジュールが正式リリースされた後のプロジェクト構造をどうする?
    ⇒将来e2 studio上でAmazon FreeRTOSとRX Driver Package込のプロジェクトを生成出来るようになるので任せる?
    ●各プロジェクトのマイコン型番をユーザのターゲットボードのマイコン型番に変更する簡単な方法は?
    ⇒e2 studio v7.1.0(後日インストール予定)でプロジェクトのマイコン型番変更が簡単になったようだが活用出来るか?
    ●各プロジェクトのボード名をユーザのターゲットボードのボード名に変更する簡単な方法は?
    ●試作基板のGR-ROSEはR5F565NEDxLJでしたね(でも量産基板で変わるかも? それから"_DUAL"は有りか無しか?)
    ●GR-CITRUS(RX631)+WA-MIKAN(ESP8266)対応⇒シェルティさんのGR-ROSE用ESP8266ドライバを自力移植しては?
    ●FreeRTOS+POSIX対応

    将来の探求テーマ
    ●Amazon FreeRTOSのスタック使用量の調査/考察/適正化
    ●Amazon FreeRTOSのヒープ使用量の調査/考察/適正化
    ●Amazon FreeRTOSのRAM使用量の調査/考察
    ●Amazon FreeRTOSのROMコードサイズのRXコアと他CPUコア(Cortex-M4/MIPS microAptiv/Xtensa LX6)とでの比較
    ●Amazon FreeRTOSの各プロジェクトでのコンパイラ最適化レベルでRXコアと他CPUコアのCoreMark/MHzを比較すると?
    ●更にプリエンプションを禁止した状態と許可した状態でそれぞれRXコアと他CPUコアのCoreMark/MHzを比較すると?
    ●Amazon FreeRTOSでRXマイコンのMPU(メモリプロテクションユニット)を有効にするには?(RTOS未使用での事例 , )
    ⇒脆弱性(Volnability)の簡易的な予防対策に活用することって出来ないものだろうか?
    ●Amazon FreeRTOSのソースのCC-RXによるMISRA-C 2012ルールチェック

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

    シェルティさんがGitHubに登録されたソースで少し確認したいのですが、以下をコメントアウトされたのは、私の変更が少しやり過ぎてしまった、ということになりますか? あるいは、テスト作業優先の一時的なものですか?(そうであれば金曜夕方~土曜/日曜のシェルティさんの作業終了のreadme.txtのコメントがあるまで私のコミットは控えた方が良いですか?)

    lib\third_party\mbedtls\include\mbedtls\config.h

    /*
     * Allow user to override any previous default.
     *
     * Use two macro names for that, as:
     * - with yotta the prefix YOTTA_CFG_ is forced
     * - without yotta is looks weird to have a YOTTA prefix.
     */
    #if defined(YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE)
    #include YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE
    #elif defined(MBEDTLS_USER_CONFIG_FILE)
    #include MBEDTLS_USER_CONFIG_FILE
    #elif defined(__RX) || defined(__RX__)
    //FIXME: Is a command line option better?
    //#include "mbedtls_user_config.h"
    #endif

    あと、09foxさんの修正で気になっていることがあって、どのタイミングで話を出そうか思っていたことがあるのですが、この機会に話をさせて下さい。以下の修正ですが、r_sci_rx_platform.hはR_SCI_RXモジュールのモジュール内ローカルヘッダファイルですので、モジュール外のソースからインクルードするのは避けた方が良いと思ったのですが、しかしインクルードしないとコンパイルエラーになってしまいますので、ひょっとしてr_sci_rx_if.h内でr_sci_rx_platform.hをインクルードしないといけないものなのではないでしょうか?(又は、実装の詳細を隠蔽しようとしていた訳ですので、キューへのポインタ(というかハンドル)を返す関数を新設するのが一番だと思います。)

    lib\third_party\mcu_vendor\renesas\amazon_freertos_common\serial_term_uart.c

    修正前

    #include <string.h>              // For strlen
    #include "FreeRTOS.h"
    #include "serial_term_uart.h"   // Serial Transfer Demo interface file.
    #include "platform.h"           // Located in the FIT BSP module
    #include "r_sci_rx_if.h"        // The SCI module API interface file.
    #include "r_byteq_if.h"         // The BYTEQ module API interface file.
    #include "r_sci_rx_config.h"    // User configurable options for the SCI module
    #include "r_pinset.h"

    修正後

    #include <string.h>              // For strlen
    #include "FreeRTOS.h"
    #include "serial_term_uart.h"   // Serial Transfer Demo interface file.
    #include "platform.h"           // Located in the FIT BSP module
    #include "r_sci_rx_platform.h"  // The SCI module API interface file.
    #include "r_byteq_if.h"         // The BYTEQ module API interface file.
    #include "r_bsp_config.h"       // User configurable options for the BSP module
    #include "r_pinset.h"

    コンパイルエラーになる記述

    189行目     R_BYTEQ_Unused(my_sci_handle->u_tx_data.que, &transmit_length);

    コンパイルエラーの内容

    serial_term_uart.c(189):E0520393:Pointer to incomplete class type is not allowed

    おそらく、r_sci_rx_if.hにあるのは型が構造体へのポインタ型であるという宣言だけで、実際の構造体の定義はr_sci_rx_platform.hからインクルードされているr_sci_rx65n_private.hにしか無いので、R_BYTEQ_Unused()の第一引数の"->"がエラーになっているのだと思います。

    lib\third_party\mcu_vendor\renesas\FIT\RDP_v1.15_modified\r_sci_rx\r_sci_rx_if.h

    /* CHANNEL CONTROL BLOCK HANDLE */

    typedef struct st_sci_ch_ctrl * sci_hdl_t;

    lib\third_party\mcu_vendor\renesas\FIT\RDP_v1.15_modified\r_sci_rx\src\targets\rx65n\r_sci_rx65n_private.h

    /* CHANNEL CONTROL BLOCK */

    typedef struct st_sci_ch_ctrl       /* SCI channel control (for handle) */
    {
        sci_ch_rom_t const *rom;        /* pointer to rom info */
        sci_mode_t      mode;           /* operational mode */
        uint32_t        baud_rate;      /* baud rate */
        void          (*callback)(void *p_args); /* function ptr for rcvr errs */
        union
        {
    #if (SCI_CFG_ASYNC_INCLUDED)
            byteq_hdl_t     que;        /* async transmit queue handle */
    #endif
            uint8_t         *buf;       /* sspi/sync tx buffer ptr */
        } u_tx_data;
        union
        {
    #if (SCI_CFG_ASYNC_INCLUDED)
            byteq_hdl_t     que;        /* async receive queue handle */
    #endif
            uint8_t         *buf;       /* sspi/sync rx buffer ptr */
        } u_rx_data;
        bool            tx_idle;        /* TDR is empty (async); TSR is empty (sync/sspi) */
    #if (SCI_CFG_SSPI_INCLUDED || SCI_CFG_SYNC_INCLUDED)
        bool            save_rx_data;   /* save the data that is clocked in */
        uint16_t        tx_cnt;         /* number of bytes to transmit */
        uint16_t        rx_cnt;         /* number of bytes to receive */
        bool            tx_dummy;       /* transmit dummy byte, not buffer */
    #endif
        uint32_t        pclk_speed;     /* saved peripheral clock speed for break generation */
    #if SCI_CFG_FIFO_INCLUDED
        uint8_t         fifo_ctrl;      /* fifo ctrl (enable/disable) flag */
        uint8_t         rx_dflt_thresh; /* RX FIFO threshold(default) */
        uint8_t         rx_curr_thresh; /* RX FIFO threshold(current) */
        uint8_t         tx_dflt_thresh; /* TX FIFO threshold(default) */
        uint8_t         tx_curr_thresh; /* TX FIFO threshold(current) */
    #endif
    } sci_ch_ctrl_t;

     

  • In reply to NoMaY:

    NoMaYさん

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

    >>私の変更が少しやり過ぎてしまった、ということになりますか?

    いえ、違います。

    >>あるいは、テスト作業優先の一時的なものですか?

    はい、そうです。とりあえずでビルドが通るようにしております。

    >>(そうであれば金曜夕方~土曜/日曜のシェルティさんの作業終了のreadme.txtのコメントがあるまで私のコミットは控えた方が良いですか?)

    いえ、どんどんコミットをお願いします。
    今週末の作業は先ほど終了しました。明日12月2日はひたすらメールに返信する予定になっています。

    >>09foxさんの修正

    先週ほとんど私が事務所におらず、09foxさんと直接コードベースで会話する機会がありませんでした。
    NoMaYさんの認識がただしく、FITモジュールのインタフェースは"r_XXX_rx_if.h"で完結する仕様になっています。
    09foxさんに確認してみます。09foxさんは最近ルネサスに来られたのでFITモジュールの
    細かいところは触りながら覚えている段階です。
    従ってコミットが完全な状態とは限りませんので、おかしそうな場合は気にせずに
    コミットを重ねていっていただければ、と思います。
    不安を感じる際などは今回のように掲示板に書いていただき、方針を定めていきたいと思います。

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

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

    >いえ、どんどんコミットをお願いします。
    了解しました。それから、このコメントアウトされた部分は後で私の方で元に戻しておきます。

    >09foxさんに確認してみます。09foxさんは最近ルネサスに来られたのでFITモジュールの
    >細かいところは触りながら覚えている段階です。
    今回の09foxさんの件は、09foxさんも「やむを得ず」というところで、根はFITの設計の問題(?)のような気がします。09foxさんに限らず、R_SCI_RXモジュールでR_BYTEQモジュールを使おうとした人は皆さん「あれっ?」っと感じているのではないかという気がします。

    それから、シェルティさんのコミット内容を見ていて思ったのですが、現状vAssertCalled()内は以下のようになっています。これを、このように修正してはどうでしょうか?そして、test用の.cprojectだけでAFQPTESTを-Dオプションで定義するようにすれば、通常のプロジェクトには影響無いように出来ると思います。そういう修正をコミットしてみようかと思ったのですが、どうでしょうか?

    lib\third_party\mcu_vendor\renesas\amazon_freertos_common\freertos_start.c

    現状

    void vAssertCalled(void)
    {
    #if(0)
        TEST_ABORT(); // XXX unity testing
        volatile unsigned long ul = 0;

        taskENTER_CRITICAL();
        {
            /* Use the debugger to set ul to a non-zero value in order to step out
            of this function to determine why it was called. */
            while( 0 == ul )
            {
                portNOP();
            }
        }
        taskEXIT_CRITICAL();
    #endif
    } /* End of function vAssertCalled() */

    #if defined(AFQPTEST)
    #include "unity_internals.h"
    #endif



    void vAssertCalled(void)
    {
    #if (0)
        // debugging with E1/E2/E2L emulator
        volatile unsigned long ul = 0;

        taskENTER_CRITICAL();
        {
            /* Use the debugger to set ul to a non-zero value in order to step out
            of this function to determine why it was called. */
            while( 0 == ul )
            {
                portNOP();
            }
        }
        taskEXIT_CRITICAL();
    #elif defined(AFQPTEST)
        // unity testing
        TEST_ABORT();
    #endif
    } /* End of function vAssertCalled() */

    unity_internals.hの中を見るとsetjump()とlongjump()でしたので、vAssertCalled()の中でTEST_ABORT()しても問題なさそうに思います。

    lib\third_party\unity\src\unity_internals.h

    /*-------------------------------------------------------
     * Test Running Macros
     *-------------------------------------------------------*/

    #ifndef UNITY_EXCLUDE_SETJMP_H
    #define TEST_PROTECT() (setjmp(Unity.AbortFrame) == 0)
    #define TEST_ABORT() longjmp(Unity.AbortFrame, 1)
    #else
    #define TEST_PROTECT() 1
    #define TEST_ABORT() return
    #endif

     

  • In reply to シェルティ:

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

    >>いえ、どんどんコミットをお願いします。
    >了解しました。それから、このコメントアウトされた部分は後で私の方で元に戻しておきます。

    よくよく考えたら、私がtestプロジェクトのことをケアしていないのが不味かったですね。すみませんでした。それで、testプロジェクトを見ていて思ったのですが、出来ることなら以下の2点が望ましいですよね。(AFQPで何も縛りが無ければ。)

    (1) testプロジェクトと通常プロジェクトでソースファイルの2重持ちは避けたい
    (2) .projectや.cprojectのtestプロジェクトと通常プロジェクトの差分は少ない方が良い

    これをWindowsのシンボリックリンク(MKLINKコマンドで作成)を使って実現出来ないものかと思い始めました。来週、試しに、シンボリックリンクを作成するバッチファイルを作ってみて、必要ならば何か小細工も考えて、ということをしてみようかと思います。ただし、コミットはせず、まずは本スレッドにバッチファイルを投稿するだけにします。(もっとも、思惑通りのものが作れるかは、やってみないと分かりませんが、、、)

  • In reply to NoMaY:

    NoMaYさん

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

    >>根はFITの設計の問題(?)のような気がします。
    はい、私もそんな気がしています。内部で議論してみてSCIやBYTEQのFITモジュール側にも
    必要に応じてフィードバックします。

    >>そういう修正をコミットしてみようかと思ったのですが、どうでしょうか?
    ありがとうございます。お願いします。

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

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

    ・BSP_CFG_HEAP_BYTESを0に出来そうなのでr_bsp_config.hで0にしてみる

     (a) Amazon FreeRTOS側ではmalloc()やcalloc()を実質的に使っていなかったことが分かった
     (a') また特に意味無くリンクされていた部分があったが取り除く方法も分かった
     (b) FITモジュール+CC-RXではlowsrc.cの_INIT_IOLIB()内のfreopen()のせいでmalloc()がリンクされるが多分CC-RXのライブラリソースでfreopen()と何かmalloc()を使用する関数が同一のソースに記述されているせいでfreopen()を使うと一緒にmalloc()までもがリンクされ(そしてsbrk()もリンクされ)ただけで_INIT_IOLIB()内のfreopen()自体はmalloc()は呼んでいない(malloc()が呼ばれればsbrk()も呼ばれる筈であるが呼ばれなかった)
     (c) Amazon FreeRTOSデモプログラム+CC-RXでは同様のカラクリ(だと思う)のせいで以下を使おうとするとmalloc()がリンクされ(そしてsbrk()もリンクされ)るがmalloc()は呼ばれないようだ(malloc()が呼ばれればsbrk()も呼ばれる筈であるが呼ばれなかった)
       sprintf()
       snprintf()
       vsnprintf() <-- これは確かめるのを略した
       sscanf()

    09foxさん、こんにちは。NoMaYです。

    先程のコミットで/.setting/を.gitignoreに追加されましたが、.settingフォルダはe2 studioのプロジェクト情報(.projectや.cprojectに保存されていない情報)も含まれていて、丸ごと除外するのは危ないと思います。シェルティさんと相談してみて頂けないでしょうか。

  • In reply to NoMaY:

    NoMaYさん

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

    ご協力感謝です。ヒープの件承知しました。ありがとうございます。
    実はすでにAmazonの検定を進めておりまして、フィードバックがあった内容を適宜09foxさんに
    GitHubにコミットいただいています。.gitignoreもフィードバックがあった項目ですね。
    中間フォルダ・ファイルは.gitignoreに登録せよ、といった類のフィードバックでした。
    .settingは残した方が良いと私も思うので他のメンバーにも確認しつつ、元に戻すかどうか決めます。

    例によって私が出張で出歩いていて事務所にいないので、09foxさんは迷いながらもGitHubに
    コミットしている状態と思います。
    #変になったらあとでシェルティが直すから、どんどんコミットしておいてほしい、と09foxさんにはお願いしてあります。

    NoMaYさん視点のコメントを書いておいていただけますと、
    あとで内部で集まってレビューする際に非常に助かりますので、他にも気になるところがあれば書いて
    頂けますと幸いです。

    次回内部で集まってレビューするのは12月7日朝の予定です。

    RXマイコン用のAmazon FreeRTOSは一度検定が通ったあとも、おそらく年単位で継続してメンテしていきます。
    相応の開発予算も継続割り当てが要るであろう、といった議論も内部で進めています。
    引き続きコードを磨いてまいりましょう。

    以上です

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