Top Page [◀◀] 2 3 4 5 6 7 8 9 ... [▶▶] Last Page
こんにちは。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です。私の今の進捗です。その前に、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 OverviewAliOS 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 linkkitappAll 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/corekernelの概要github.com/alibaba/AliOS-Things/wiki/AliOS-Things-Technical-Overview#kernel-descriptionサポートハードウェアgithub.com/alibaba/AliOS-Things/wiki/AliOS-Things-HardwareRL78対応github.com/alibaba/AliOS-Things/tree/master/platform/arch/rl78RX65N対応github.com/alibaba/AliOS-Things/tree/master/platform/arch/rx600/rx65n/e2sFreeRTOSからのポーティングガイド(現状は中文のみの模様)github.com/alibaba/AliOS-Things/wiki/AliOS-Things-FreeRTOS-Porting-Guide.zhGoogle検索: AliOS Thingswww.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赤枠は私によるもの[余談]以前、このスレッドを開いた時のビューカウント値が ２１２１２ になっていて面白かったので採取したことがありましたが、今度は、ビューカウント値が ２３４３２ になっていたことがあったので採取した画面コピーです。
In reply to NoMaY:
シェルティさん、こんにちは。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 FreeRTOSgithub.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_checkHungarian Notationチェックツールgithub.com/aws/amazon-freertos/tree/86a1c8a/tools/checks/style/hn_checkGit-Hooksgithub.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-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ルールチェック
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 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になってました
シェルティさん、こんにちは。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;
シェルティさん、こんにちは。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
シェルティさん、こんにちは。NoMaYです。＞＞いえ、どんどんコミットをお願いします。＞了解しました。それから、このコメントアウトされた部分は後で私の方で元に戻しておきます。よくよく考えたら、私がtestプロジェクトのことをケアしていないのが不味かったですね。すみませんでした。それで、testプロジェクトを見ていて思ったのですが、出来ることなら以下の2点が望ましいですよね。(AFQPで何も縛りが無ければ。)(1) testプロジェクトと通常プロジェクトでソースファイルの2重持ちは避けたい(2) .projectや.cprojectのtestプロジェクトと通常プロジェクトの差分は少ない方が良いこれをWindowsのシンボリックリンク(MKLINKコマンドで作成)を使って実現出来ないものかと思い始めました。来週、試しに、シンボリックリンクを作成するバッチファイルを作ってみて、必要ならば何か小細工も考えて、ということをしてみようかと思います。ただし、コミットはせず、まずは本スレッドにバッチファイルを投稿するだけにします。(もっとも、思惑通りのものが作れるかは、やってみないと分かりませんが、、、)
シェルティさん、こんにちは。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に保存されていない情報)も含まれていて、丸ごと除外するのは危ないと思います。シェルティさんと相談してみて頂けないでしょうか。