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に変わったようです。

  • In reply to NoMaY:

    NoMaYさん

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

    ありがとうございます。v1.2.3でまず登録してみたいと思います。

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

    GNURXでビルド出来るようにする作業を始めました。厄介な点はGNURXプロジェクトではスマートコンフィグレータがFITモジュールのコンポーネントを生成してくれない点だと気付いたのですが、ひとまず以下のやり方を前提にして、作業を進めてみます。(アプリケーションノートが更新されていました。ドキュメントは各サンプルプログラム毎にあと3冊あるようです。)

    ● GNURXプロジェクトではr_bsp_rtosとr_cmt_rtos_rxの他にもコンポーネントをアプリケーションノートからコピペして貰う

    対象コンポーネント:
    r_bsp_rtos, r_cmt_rtos_rx, r_ether_rx, r_flash_rx, r_sci_rx, r_byteq

    対象アプリケーションノート:
    RX65N Group Application Note RX65N Real-time OS Package V1.1.00 ドキュメント(英文)
    www.renesas.com/en-eu/doc/products/mpumcu/apn/rx/002/r01an4033es0110-rx65n.pdf
    RX65N Group Application Note RX65N Real-time OS Package V1.1.00 サンプルプログラム
    www.renesas.com/en-eu/software/D6002273.html
     

  • In reply to NoMaY:

    NoMaYさん

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

    GitHub上のコードメンテが完了しました。実機動作確認もOKです。
    readme.txt を更新したので確認いただいてもよいでしょうか。
    github.com/.../renesas

    GCCの件、おっしゃる通りですね。
    スマートコンフィグレータで出力したコードに対してさらに#pragma interruptの記述を
    変更していくなどの手作業も必要と思われます。

    こちらではこれも社内で課題に挙げ、公式のデバイスドライバのコードに
    コンパイラの仕様差を吸収するようなifdefを盛り込むことを提案し改善活動を進めています。
    同時にIARコンパイラの対応も進めたいと思っております。
    マルチコンパイラ対応はいつになるか分からないので、
    RX65N Amazon FreeRTOSの活動においては、ひとまずはreadmeによる手作業ガイドになると思います。


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

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

    IAR社のFITサポートですが、以下のウェブページに情報がありました。(IAR社?が手作業でFITソースコードを移植していて、その移植したFITソースコードがEWRXに組み込まれているのだろうか?)

    IAR Embedded Workbench and Renesas FIT
    www.iar.com/iar-embedded-workbench/partners/renesas/renesas-fit-support/

    他方、コード生成機能は、AP4 for RXがIARコンパイラに対応しているようですね。(スマートコンフィグレータは、将来的にはIARコンパイラ対応になるのでしょうが、作業は、まだこれから、というところでしょうか。)

    AP4, Applilet
    www.renesas.com/products/software-tools/tools/code-generator/ap4-application-leading-tool-applilet.html

    すみません、リプライが遅くなりましたが、readme.txtを確認しました。そうだったのですね、以下の修正が必要になるのですね。これに関しては、ビルド前ステップで自動的にやれないか考えてみようと思います。


    And modefy the ./realtime_OS_pkg/r_bsp_rtos/mcu/rx65n/mcu_interrupts.c Line851 from #if 0 to #if 1.


    それで、以下の部分なのですが、ブロックサイズが違うだけであれば私もそう考えているのですが、現状のMONOSではひとつのマイコンのフラッシュメモリの中でブロックサイズの異なるブロックが混在することが気掛かりなのです。(実際、RX631ですが、がじぇるねの別スレッドで32Kのブロックと16Kのブロックが混在することによる不具合に遭遇しているのです。) これがもし、RX130やRX231のSuperFlashのようにブロックサイズがマイコンのフラッシュメモリ内で一律で1Kであったり2Kであったりといったものであれば、マクロ定義されたブロックサイズを使えば同一ソースになるとは思っています。(あと、先日のリプライでは書きませんでしたが、実は、そもそもAmazon FreeRTOSのソースが他社マイコンでも現状の階層になっている、ということがあります。ただ、先日のリプライでは、Amazon FreeRTOSのソースの階層よりも使い勝手を優先させる意見を別の方で自分が述べていたので、ポリシーがダブルスタンダードになってしまいそうだった為、先日のリプライでは書きませんでしたが。)


    ・以下ボード依存が無いコード(全く同じになった)なので1階層UPしてマージする。
     ⇒現状維持。
      NoMaY氏:フラッシュのブロックサイズが機種毎に異なるため分けておいたほうが後々楽。
       ⇒シェルティ:YES。ただ、ブロックサイズはフラッシュモジュールの共通マクロ名で判別できるので
        将来的にはやはりマージできる可能性もありそう。


    それから、以下の部分は、やはりスマートコンフィグレータが改良されてソース生成先フォルダを指定出来るようになれば良いな、と思います。ただ、果たして解になるかどうか見極めがついていませんが、Eclipseのリンクされたフォルダという機能(既にAmazon FreeRTOSのEclipseプロジェクトで多用されている)で、Eclipseのプロジェクトエクスプローラー上での見掛けの位置を合わせることは可能だとは思います。(まだ実際に試してはいませんが。) (解になるかどうか見極めがつかないのは、結局、その場所にコード生成されても、あまりに通常とは違う場所に生成されるのだから、使う人に使い難いと思われてしまうことに変わりはないような気がするからです。と、ここまで書いて気づいたのですが、FITを主として考えているシェルティさんと、コード生成機能を主として考えている私とでは、意見は合わないような気がしてきました。なぜなら、FITでは生成されたコードはr_configフォルダのヘッダファイル以外は変更しないのでCソースはどこにあってもユーザは気にしないのに対し、コード生成機能では生成されたCソースをガシガシ変更するので普段慣れ親しんだ場所にないとユーザは戸惑うと思われるのですが、そもそもそういう違いがFITとコード生成機能の違いとしてあるような気がし始めたからです。逆に考えると、FITのソースはAmazon FreeRTOSの作法の場所へ、コード生成機能のソースは普段慣れ親しんだ場所へ、というのが良いのかも知れません。)


    ・BSPやドライバは、以下フォルダに入れるのがお作法のようだ。そのうち引っ越しする。
     ⇒現状維持。
      NoMaY氏:スマートコンフィグレータの仕様と合わせられない。
       ⇒シェルティ:把握。現状維持としたい。
        他ベンダと似た構成にすべく、継続議論は必要。
        (スマートコンフィグレータで対応できる方法を考えるなど)


    あと、プロジェクトの話が出たところで、シェルティさんが変更されたプロジェクトで以下の点が気になりました。これらは後で私が対処しておきます。(この機会に、いっそCS+プロジェクトのプロジェクトツリーの構造をEclipseプロジェクトに似せるように変更しようと思います。)

    e2 studioプロジェクト
    ・コンパイル時の最適化レベルがレベル0に変わってしまっていました

    CS+プロジェクト
    ・プロジェクトツリーの構造が変わってしまっていました(大きな単位で削除をして大きな単位で追加をした?)
    ・一括ビルドが解除されていました(実は別スレッドで投稿したことがある件です)

    また、プロジェクトを修正する時に、Amazon FreeRTOS v1.2.3→v1.2.4(というかmbedTLS v2.6→v2.8)でファイルの追加/削除があれば、それを反映させておこうと思います。(もし、コンパイルエラーが発生して、それが簡単に取れるようなものであれば、その時に対処しておいた方が良いかも、とも思います。)

    もうひとつあるのが、RX Driver Packageが更新されたことへの追従ですね。(これも実は別スレッドで投稿したことがある件です。) 何か簡単な手はないものかと、、、

  • In reply to NoMaY:

    NoMaYさん

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

    本当にありがとうございます。
    まとめていただいた情報を開発にフィードバックしたいと思います。
    この活動をNoMaYさんと進められて本当に良かったと思います。

    以下回答、コメントです。
    >>IAR社?が手作業でFITソースコードを移植していて、その移植したFITソースコードがEWRXに組み込まれているのだろうか?

    はい、IAR社の厚意でFIT対応いただいています。
    今は#pragma interrupt等のCC-RX特有コードがIAR向けに独自変換が成されています。

    >> スマートコンフィグレータは、将来的にはIARコンパイラ対応になるのでしょうが、作業は、まだこれから、というところでしょうか。)

    そうですね、コード生成もFITも向かう先はスマートコンフィグレータです。
    Amazon FreeRTOS関連の設定も文字通りスマートコンフィグレータで出来るようなのを目指しています。

    >>フラッシュメモリの中でブロックサイズの異なるブロックが混在することが気掛かりなのです。

    RX65Nも「FLASH_CF_MEDIUM_BLOCK_SIZE」= 32KBと「FLASH_CF_SMALL_BLOCK_SIZE」= 8KBが分かれていますね。
    www.renesas.com/.../rx65n-envision-kit.html
    ⇒デモファームウェア(ソースコード)
     ⇒\rx65n_envision_kit_demo\src\smc_gen\r_flash_rx\src\targets\rx65n\r_flash_rx65n.h

    実はRX65N Envision Kitのコードを書いたのは私なのですが、
    (フラッシュモジュールのコードはアメリカの開発チーム)
    「FLASH_CF_SMALL_BLOCK_SIZE」はブート用のコード専用にしようと用途を割り切って
    「FLASH_CF_MEDIUM_BLOCK_SIZE」のブロックだけをファームアップデート対象領域としましたね。
    同様の割り切りを前提とすれば、コード共通化も容易と思います。
    少し検討を進めてたいと思います。

    >>そもそもAmazon FreeRTOSのソースが他社マイコンでも現状の階層になっている、ということがあります。

    そうですね、私もこれは気付きました。
    そのうち整流されてくるでしょうから今すぐ対策するのは得策ではない、
    というのも「現状維持」とした理由です。

    >>以下の部分は、やはりスマートコンフィグレータが改良されてソース生成先フォルダを指定出来るようになれば良いな、と思います。

    そうですね、今回のAmazon FreeRTOSは最先端のオープンソースとして
    ケーススタディの素材としても非常に良いと思っています。
    スマートコンフィグレータやIDEの開発チームも見てもらおうと思ってます。

    >>FITのソースはAmazon FreeRTOSの作法の場所へ、コード生成機能のソースは普段慣れ親しんだ場所へ、というのが良いのかも知れません。

    これは最終的には考えをマージして1個のはっきりとしたポリシーを持ってコード構造を決めていきます。
    仰る通り私はFITの考えをベースにコード生成でどうするか、という順序で考えていますがこれは私がずっとFITを育ててきたから、というのが理由ですね。
    コード生成と考えをうまく合わせてトータルで使いやすいツール=スマートコンフィグレータにしていきたいという思いが今は一番です。

    >>(この機会に、いっそCS+プロジェクトのプロジェクトツリーの構造をEclipseプロジェクトに似せるように変更しようと思います。)

    ありがとうございます。
    どのような変更でもこちらで追って実機動作確認しますので
    出来たコードをGitHubに置いてもらえれば、と思います。

    > e2 studioプロジェクト
    > ・コンパイル時の最適化レベルがレベル0に変わってしまっていました

    すみません、戻し忘れです。
    初期デバッグ時は最初に最適化OFFにしてしまいますね。
    お手数ですが対処をお願いします。(こちらでも次コードを見る時に確認します)

    > CS+プロジェクト
    > ・プロジェクトツリーの構造が変わってしまっていました(大きな単位で削除をして大きな単位で追加をした?)

    プロジェクトツリーと、実際のフォルダ構成が1対1になるようにプロジェクトツリー側を構成しなおしました。リンクしているファイルは特に変更してないです。
    e2 studio側が逆にまだ1対1になっていないのですが、この構造の意図は何かありますか?
    明確な理由があれば実際のフォルダ構成と1対1になっていないのも良いかと思いますが、個人的にはファイルの在処を見失いやすいのでプロジェクトツリーと実際のフォルダ構成を合わせておきたいです。

    > ・一括ビルドが解除されていました(実は別スレッドで投稿したことがある件です)

    すみません、色々触っていて変えてしまったかもしれません。
    対処をお願いします。
    お手数ですが対処をお願いします。(こちらでも次コードを見る時に確認します)

    > RX Driver Packageが更新されたことへの追従ですね。(これも実は別スレッドで投稿したことがある件です。) 何か簡単な手はないものかと、、、

    この投稿の後すぐに、ツール開発部門にこの情報インプットしました。
    ・・・したつもりで、できてませんでした。
    私の希望としてはNoMaYさんと同じで「更新ボタン」ですね。


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

    NoMaYさん

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

    1個書き忘れました。以下不要になりそうです。

    > すみません、リプライが遅くなりましたが、readme.txtを確認しました。そうだったのですね、以下の修正が必要になるのですね。これに関しては、ビルド前ステップで自動的にやれないか考えてみようと思います。
    >
    > 「
    > And modefy the ./realtime_OS_pkg/r_bsp_rtos/mcu/rx65n/mcu_interrupts.c Line851 from #if 0 to #if 1.
    > 」

    リアルタイムOSのカーネル系の調整はシンガポールの開発チームに依頼しています。
    このifdefの真意を聞いてみたところ、#if 1に相当するコード(グループAL1の割り込み関数群)は
    「ユーザ定義側のコードに引っ越した」とのことでした。
    私がそのコードをAmazon FreeRTOS側に入れてないのでグループAL1に属するEther割り込みが入ったら
    割り込み関数未定義となり未定義命令割り込みが発生してました。
    これはBSP内部のコードの外側で対処が出来ると思います。
    #何で引っ越したかはその真意を確かめないと、ですが。

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

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

    >e2 studio側が逆にまだ1対1になっていないのですが、この構造の意図は何かありますか?
    >明確な理由があれば実際のフォルダ構成と1対1になっていないのも良いかと思いますが、個人的にはファイルの在処を見失いやすいのでプロジェクトツリーと実際のフォルダ構成を合わせておきたいです。

    これは、このスレッドの初め頃の話題でしたが、もともとのAmazon FreeRTOSのEclipseベースの他社統合開発環境のプロジェクトツリーが、Eclipseのリンクされたフォルダや仮想フォルダの機能を使用して、わざわざそう作られていたので、それを踏襲したものです。(実は、sourceforge.netで配布されているFreeRTOSカーネルのプロジェクトツリーも、同様に、実際のフォルダ構成とプロジェクトエクスプローラ見えのフォルダ構成が異なっていますので、ひょっとするとFreeRTOSで非常に数多くの品種に対応させようとした時に開発者のRichard Barry氏が何か多大なメリットを感じてそのような手法を採用して、以後ずっとRichard Barry氏がこのような手法を愛用しているのかも知れない、と思っています。) また、スマートコンフィグレータのようなコード生成先フォルダが固定されているといったようなe2 studioの制約のせいでそのような構造に出来ないという事情もありませんでした。

  • In reply to NoMaY:

    NoMaYさん

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

    なるほど、理解しました。
    Richard Barry氏の構造体を使いたいと思います。
    コメント感謝いたします。

    以上です
  • こんにちは。NoMaYです。

    ウェブで調べ物をしていて知ったのですが、イーソル社がAmazon FreeRTOSに対応するようです。(とは言っても、FreeRTOSの部分をイーソル社のeMCOSに差し替えるとのことなので、AWS IoT Coreに対応、という表現が合っているような気もしますが。)

    車載RTOSのイーソル、Amazon FreeRTOSにはこう対応 - 日経 xTECH (2018年5月17日14時まで無料公開)
    (なお、2ページ目以降にAmazon FreeRTOSの話題は無いです。)
    tech.nikkeibp.co.jp/atcl/nxt/event/18/00010/00007/

    [追記]

    ちなみに、eMCOSがサポートしているプロセッサには、ルネサスさんのものでは、RH850やR-Car H3がありました。

    eMCOS - イーソル株式会社
    www.esol.co.jp/embedded/emcos.html#processor

    ヘテロジニアスマルチコアプロセッサを1つのRTOSでサポート - イーソル株式会社 / Renesas DevCon Japan 2017
    www.renesas.com/ja-jp/promotions/solutions/event/devcon2017/sp-14.html
     

  • こんにちは。NoMaYです。

    Amazon FreeRTOSにESP32のサポートが追加されていました。ソースのzipファイルが14MB→33MBになっていました。

    github.com/aws/amazon-freertos/blob/v1.2.5/change_log.txt

    Change Log for Amazon FreeRTOS V1.2.5 05/14/2018

        - Added support for Espressif's ESP32-DevKitC and ESP-WROVER-KIT.

    FreeRTOS+TCP V2.0.4
        - Added Espressif ESP32 network interface support.

    mbedTLS-based PKCS#11 V1.0.3
        - Implement C_DigestInit, C_DigestUpdate, and C_DigestFinal for SHA-256.
        - Implement C_GenerateKeyPair for non-persistent ECDSA P256.

    PKCS#11 for for ESP32-DevKitC ESP-WROVER-KIT V1.0.0
        - Added support for Espressif's ESP32-DevKitC and ESP-WROVER-KIT.

    Wi-Fi STM32L4 Discovery kit IoT node V1.0.2
        - Bug fix to ensure that WIFI_ConnectAP() switches to the network parameters input, even when already connected to a different set.

    Wi-Fi for ESP32-DevKitC ESP-WROVER-KIT V1.0.0
        - Added support for Espressif's ESP32-DevKitC and ESP-WROVER-KIT.


  • In reply to NoMaY:

    NoMaYさん

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

    情報ありがとうございます。週末に我々のリポジトリも1.2.5に更新試みてみます。
    たしかにESP32が正式に仲間に加わっていますね。私もはやく仲間になりたいです。

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

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

    月曜にリプライした以下の件、一緒にv1.2.5もマージしてリンクでThe total section size exceeded the limitになってしまうところまでは出来ましたので、明日の夕方までにGitHubに登録しようと思います。(RX Driver Package Ver.1.14の件は、まだですが、後で少しやってみようと思います。)


    また、プロジェクトを修正する時に、Amazon FreeRTOS v1.2.3→v1.2.4(というかmbedTLS v2.6→v2.8)でファイルの追加/削除があれば、それを反映させておこうと思います。(もし、コンパイルエラーが発生して、それが簡単に取れるようなものであれば、その時に対処しておいた方が良いかも、とも思います。)


    それで、セクション配置なのですが、e2 studio & rx65n-rskで「W0561100:Cannot find "B_FRAME2_1" specified in option "start"」のワーニングが出ていたので調べたところ、以下の3パターンがありました。

    昔の版では皆同じだったのですが、前回の版でB_FRAME2_1が不要になって修正した時に3パターン出来てしまった(その内の1パターンは修正忘れ?)のだと思います。たぶん、以下の2つの赤文字のセクション配置のどちらか1つで良いのではないかと思いますが、どうするのが(どちらにするのが)良いでしょうか?

    e2 studio & rx65n-envision-kitでのセクション配置(昔の版では下のe2 studio : rx65n-rskでのセクション配置と同じだった)
    昔:
    B_1,B_2,B/0,B_FRAME2_1/0800000,B_ETHERNET_BUFFERS_1,B_RX_DESC_1,B_TX_DESC_1,SU,SI,R_1,R_2,R/0840000,C_1,C_2,C,C$*,D*,W*,L,P*/0FFF00000,EXCEPTVECT/0FFFFFF80,RESETVECT/0FFFFFFFC
    前回:
    B_1,B_2,B,SI,SU/0800000,B_ETHERNET_BUFFERS_1,B_RX_DESC_1,B_TX_DESC_1,R_1,R_2,R/0840000,C_1,C_2,C,C$*,D*,W*,L,P*/0FFF00000,EXCEPTVECT/0FFFFFF80,RESETVECT/0FFFFFFFC

    e2 studio & rx65n-rskでのセクション配置
    昔:
    B_1,B_2,B/0,B_FRAME2_1/0800000,B_ETHERNET_BUFFERS_1,B_RX_DESC_1,B_TX_DESC_1,SU,SI,R_1,R_2,R/0840000,C_1,C_2,C,C$*,D*,W*,L,P*/0FFF00000,EXCEPTVECT/0FFFFFF80,RESETVECT/0FFFFFFFC
    前回:(昔と同じ)
    B_1,B_2,B/0,B_FRAME2_1/0800000,B_ETHERNET_BUFFERS_1,B_RX_DESC_1,B_TX_DESC_1,SU,SI,R_1,R_2,R/0840000,C_1,C_2,C,C$*,D*,W*,L,P*/0FFF00000,EXCEPTVECT/0FFFFFF80,RESETVECT/0FFFFFFFC
    ワーニングあり W0561100:Cannot find "B_FRAME2_1" specified in option "start"

    CS+ & rx65n-envision-kit / rx65n-rsk でのセクション配置(両ボードで同じ)
    昔:
    B_1,B_2,B/0,B_FRAME2_1/0800000,B_ETHERNET_BUFFERS_1,B_RX_DESC_1,B_TX_DESC_1,SU,SI,R_1,R_2,R/0840000,C_1,C_2,C,C$*,D*,W*,L,P*/0FFF00000,EXCEPTVECT/0FFFFFF80,RESETVECT/0FFFFFFFC
    前回:
    B_1,R_1,B_2,R_2,B,R/00800000,B_ETHERNET_BUFFERS_1,B_TX_DESC_1,B_RX_DESC_1,SU,SI/00840000,C_1,C_2,C,C$*,D*,W*,L,P*/FFE00000,EXCEPTVECT/FFFFFF80,RESETVECT/FFFFFFFC

  • In reply to NoMaY:

    NoMaYさん

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

    種々調整いただき、ありがとうございます。とても助かります。
    更新いただくコードの実機確認はお任せください。

    B_FRAME2_1に関しては、最初液晶にprintf()表示してたのをUART出力に変更したので
    不要になりましたね。セクション定義から消していただいてOKです。
    私も次メンテするときセクション確認してみます。

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

    GitHubに登録しました。今回、まだタグを付けていません。そちらで確認されてOKならタグを付けて頂けませんか?(他にも変更がありましたら、その変更の後でタグを付けて頂いても構わないです。)

    RX Driver Package Ver.1.14の件は、今回、見送りました。理由は、新しいr_ether_rxモジュールの依存モジュールにr_bsp 3.70が含まれているのですが、以前に別スレッド「スマートコンフィグレータが生成したコンポーネントをアップデートする方法が分かりません」に投稿したように、スマートコンフィグレータでは今のところr_bsp 3.70を使用することが出来ないので、結局、新しいr_ether_rxモジュールを使用するのは危ないと感じて、見送りました。(追記: 最初、うっかりr_bsp 3.71としていましたが、正しくはr_bsp 3.70でした。すみません。)

    それから、セクション配置ですが、e2 studioの方を前回の版のCS+のセクション配置に合わせるようにしてみました。

    Amazon FreeRTOS v1.2.3 → v1.2.5の変更で気がかりなのは、以前に書いたように、以下の点です。

    ●mbedTLS v2.6 → v2.8 : マージ済み

    ●FreeRTOS plus TCPを使う場合にはsecure_socketでAmazon提供の実装が使えるらしい : 私の方では置き換えませんでした

    Amazon FreeRTOS v1.2.5のソースツリーでは以下のようになっていて、FreeRTOS plus TCPを使用しているMicrochipとEspressifのフォルダが無く、代わりにfreertos_plus_tcpのフォルダが追加されていたからです。(同じくpcのWindowsシミュレータのフォルダも無いです。)

    lib\secure_sockets\portable\freertos_plus_tcp\aws_secure_sockets.c
    lib\secure_sockets\portable\nxp\lpc54018_iot_module\aws_secure_sockets.c
    lib\secure_sockets\portable\st\stm32l475_discovery\aws_secure_sockets.c
    lib\secure_sockets\portable\ti\cc3220_launchpad\aws_secure_sockets.c

    ●mbed TLSを前提とした大きな処理のまとまりが切り出されてpkcs11でのボード依存部が小さくなりました : 試しに置き換えてみました

    今回、以下のソースに大きな処理のまとまりが切り出されていました。

    lib\pkcs11\mbedtls\aws_pkcs11_mbedtls.c

    結果、ボード依存部が以下のように小さくなりました。

    lib\pkcs11\portable\renesas\rx65n-envision-kit\aws_pkcs11_pal.c

    以前は以下のように大きなものでした。

    lib\pkcs11\portable\renesas\rx65n-envision-kit\pkcs11.c

    なお、試しに置き換えてみた理由は、先日のやりとりにあったように、まだ動いてはいない部分ですので、先走ってもよいかな、と思ったからです。(それに対して、secure_socketを動作確認出来ない私が弄るのは、ためらわれました。)

    ●少し首をひねっていることとして、STM32L4 DiscoveryのOTAのソースが消えていたことです。(そのせいで、最初にe2 studioでの.projectファイルを手直しする作業を間違えて、やり直していました、、、)

    Amazon FreeRTOS v.1.2.3には以下のソースがあったが、Amazon FreeRTOS v.1.2.4で無くなり、v.1.2.5でも無いまま、です。

    lib\ota\portable\st\stm32l475_discovery\aws_ota_pal.c

    それから、GitHubに登録したソースに、今回、作業手順の覚え書きのテキストを追加してみました。(過去の作業メモも残っていますので、追々、過去の分も追記していきます。)

    amazon-freertos/demos/renesas/upstream_merge_log_jp.txt
     

  • In reply to NoMaY:

    NoMaYさん

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

    無事V125で動作確認できました。
    タグ付けてコミットしましたのでご確認ください。
    github.com/.../amazon-freertos

    以上です

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