こんにちは。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です。GR-SAKURA対応の作業中ですが、今までのボードのようなRAMの使い方では第一世代GR-SAKURAのRAM 128KBには収まらないことに気付きました。今までのボードではFreeRTOSConfig.hで、128KBのヒープ(たぶん各タスクのスタックなどもここから確保していると思われます←間違えたかも)を確保していましたが、これを56KBに減らしてもAWS接続デモは動作するでしょうか？(もっともこれでも128KBいっぱいいっぱいなので、第一世代GR-SAKURAでのユーザアプリケーションの為のRAMを空ける為には、いずれRAMの使い方を見直して削減しないといけませんが、、、RAM 128KBの第一世代GR-SAKURAとRAM 256KBの第二世代GR-SAKURAとの出荷台数比はどれくらいだろうか、、、)FreeRTOSConfig.h : 今まで
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 128U * 1024U ) )
FreeRTOSConfig.h : 第一世代GR-SAKURAのRAM 128KBに収めようとした場合
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 56U * 1024U ) )
[追記]RAMの使い方を見直す時にはR_BSPモジュールで確保しているヒープ/Iスタック/Uスタック=8KB/12KB/12KBも要調査な気がします。各タスクの必要スタックサイズはCC-RX ＋ Call Walkerで分析/確保する、ですかね。(その結果を(必要なら微調整して)GNURXへも適用する、といったところでしょうか。)
シェルティさん、こんにちは。NoMaYです。 RX63N GR-SAKURA対応の作業では、結局、どのように対処しようか悩んでいたFIT Configuratorとスマートコンフィグレータとではソースが生成される場所が違っていた件を、e2 studio(というかEclipse/CDT)の機能の、仮想フォルダ、リンクされたフォルダ、リソースフィルタ、を組み合わせることで、形だけ(IDE上の見え方だけ(以下の画面コピーを参照))ですが今までとプロジェクト構造を合わせるようにしました。なお、試行錯誤しているうちに、ファイル名文字列を利用して"Please exclude unnecessary r_xxx from build"というアドバイスをユーザに伝える小細工とか、r_configフォルダ/r_pincfgフォルダのソースはユーザが内容を書き換えたりチェックしたりすることがあるのでフォルダを分けた方が良さそうだとか、気付きましたので(以下の画面コピーの青枠部分を参照)、これら2つに関しては今までのプロジェクトへ逆輸入しようかと考えています。(現在、これまでに挙げた作業のうちで、まず3コンパイラ対応のBSPのフォルダ構成の変更から着手しようと考えていますが、その時にこの逆輸入作業を一緒にやってみようと考えています。(どちらも.projectファイル/.cprojectファイルをあれこれ変更しないといけないので。))以下、いつものように画面コピーです。CC-RX/e2 studio (FIT Configuratorが使える)GNURX/e2 studio (FIT Configuratorは使えない)CC-RX/CS+ (FIT Configuratorは使えない)r_configフォルダ/r_pincfgフォルダのファイルシステム上の場所以下、次作業の予定項目です。(たぶん、やっているうちに増えていくだろう、と思ってますが、、、)・前述の逆輸入の件・3コンパイラ対応のBSPのフォルダ構成の変更案の試行・3コンパイラ対応のBSPの取り込み作業中に気掛かりだった箇所の修正や思い浮かんだ改良案の試行・demos\renesas\XXX\common\config_file\*.hの#define等の順序をAmazon FreeRTOS本家の*.hに合わせる・コンパイル時のワーニングを減らす・GNURXのリンク時のワーニングを取る・ビルド前ステップのバッチファイルの見直し([追記] make.exeが見付かりません問題の緩和策も)・AFQPのドキュメントを読んで問題無さそうならプロジェクト名の"aws_demos"の後に色々足して複数同時にインポート可能にする