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

シェルティさん、こんにちは。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です。

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

済み
●プロジェクト(ボード)で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ルールチェック