こんにちは。NoMaYです。ライセンスはMIT Licenseでした。TLSとしてmbed TLSが使用されていました。サポートされているボードの写真を見ていたら、どれにも有線LANコネクタが無いことに気付きました。時代の流れでしょうか、、、Getting Started with Amazon FreeRTOSaws.amazon.com/freertos/getting-started/Amazon FreeRTOSaws.amazon.com/freertos/Amazon FreeRTOS ソースコードgithub.com/aws/amazon-freertos[関連リンク]FreeRTOS - freertos.orgwww.freertos.org/FreeRTOS - sourceforge.netsourceforge.net/projects/freertos/files/FreeRTOS kernel自体はCC-RXにも対応github.com/aws/amazon-freertos/tree/master/lib/FreeRTOS/portable/RenesasAmazon FreeRTOSはTLSにmbed TLSを使用github.com/aws/amazon-freertos/tree/master/lib/third_party/mbedtls[ニュース]組み込み業界に大インパクト「Amazon FreeRTOS」の衝撃 - 大原雄介，MONOistmonoist.atmarkit.co.jp/mn/articles/1712/28/news011.htmlアマゾン「AWS IoT」は何が衝撃的なのか - 大原雄介，MONOistmonoist.atmarkit.co.jp/mn/articles/1510/21/news026.html(2018/01/01 : 記事を選び直しました。)[追記]もしかしたら、オープンソースライセンスのドライバライブラリが用意されていないから、ルネサスさんはアマゾンさんに相手にして貰えないのかも、、、ちなみに、FreeRTOS kernel自体のライセンスがV10からModified GPLからMIT Licenseに変わったようです。
シェルティさん、こんにちは。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-iotIoT におけるセキュリティ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ルールチェック
シェルティさん、こんにちは。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 namePlease 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になってました