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

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

    GitHubのアカウントを教えて頂ければ、リポジトリの設定を変更して、シェルティさんからもリポジトリを直接変更出来るようにしたいと思います。

    また、解凍したフォルダのパスが(あまり深いとは言えないけれども)深くなるとコンパイルエラーが発生する件、問い合わせて頂けるとのことで有難う御座います。私の方でも、CS+とe2 studioで違いがあることが気になってしまい、もっと調べてみました。CS+では、コンパイルエラーが発生するかしないかの境目は以下の深さでした。それに対して、e2 studioでは、境目が以下の深さでした。

    CS+

    OK:
    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-1234567890123456789

    NG:
    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-12345678901234567890
    以下のエラーが発生
    src\realtime_OS_pkg\r_cmt_rtos_rx\src\../../r_bsp_rtos/./board/rskrx65n_2mb/r_bsp.h(52):F0520005:Could not open source file "../../../r_bsp_rtos/mcu/rx65n/mcu_mapped_interrupts_private.h"
    (参) この時のソースツリー上の最も深いパス名 = 207文字
    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-12345678901234567890\demos\renesas\rx65n-envision-kit\ccrx-csplus\src\realtime_OS_pkg\r_bsp_rtos\board\rskrx65n_2mb\r_bsp_interrupt_config_reference.h

    e2 studio

    OK:
    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318

    NG:
    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-
    以下のエラーが発生
    ../src/realtime_OS_pkg/r_cmt_rtos_rx/src/../../r_bsp_rtos/./board/rskrx65n_2mb/r_bsp.h(52):E0520005:Could not open source file "../../../r_bsp_rtos/mcu/rx65n/mcu_mapped_interrupts_private.h"
    (参) この時のソースツリー上の最も深いパス名 = 187文字
    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-\demos\renesas\rx65n-envision-kit\ccrx-csplus\src\realtime_OS_pkg\r_bsp_rtos\board\rskrx65n_2mb\r_bsp_interrupt_config_reference.h

    推測ですが、<カレントフォルダのパス>¥<Cソースフォルダの相対パス>¥<ヘッダファイルの相対パス>というようにパスを連結しようとしている処理があって、連結後のパスの長さが260文字(Windows SDKのMAX_PATH)を超える場合には連結するのではなく何かエラーを返すようになっていて、それがコンパイルエラーに繋がっているのではないか、という予感がします。なぜなら、エラーメッセージに含まれているパスから連結後のパスを作ってみると以下の通りになって、それが261文字だったからです。

    CS+

    Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-12345678901234567890\demos\renesas\rx65n-envision-kit\ccrx-csplus\src\realtime_OS_pkg\r_bsp_rtos\mcu\all\../../../r_bsp_rtos/./board/rskrx65n_2mb/../../../r_bsp_rtos/mcu/rx65n/mcu_mapped_interrupts_private.h

    e2 studio

    Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-\demos\renesas\rx65n-envision-kit\ccrx-e2studio6\HardwareDebug\..\src\realtime_OS_pkg\r_bsp_rtos\mcu\all\../../../r_bsp_rtos/./board/rskrx65n_2mb/../../../r_bsp_rtos/mcu/rx65n/mcu_mapped_interrupts_private.h

    そして、e2 studioがCS+より浅いフォルダに解凍した場合でもコンパイルエラーが発生するのは、e2 studioではCS+よりも1階層深いフォルダがカレントフォルダですので、それによる差異でマージンが大きく削られてしまっているのだと推測されます(上のパスの赤字部分)。また、寄与としては小さいのですが、フォルダ名に含まれている"e2studio6"が"csplus"より長い文字列であるということもあります(上のパスの青字部分)。

    なお、ファイルシステム、レジストリ、プロセス、スレッドの活動をリアルタイムで表示する、Process MonitorというMicrosoft社のツールを使い、CC-RXのファイルアクセスを調べてみた印象では、Windows API内部の処理で起きているのでは無さそうで、CC-RXに実装された処理で起きているのだろうと推測されます。なぜなら、以下の画面コピーの通り、OKの場合にはrealtime_OS_pkg\r_bsp_rtos\mcu\rx65n\mcu_mapped_interrupts_private.hへ問題無くファイルアクセス出来ていますが、NGの場合にはmcu_mapped_interrupts_private.hを探そうと幾つものパスの組み合わせを試していますがrealtime_OS_pkg\r_bsp_rtos\mcu\rx65n\mcu_mapped_interrupts_private.hへファイルアクセスは見当たらず、CC-RXに実装された処理で事前に除外されてしまっているのだと推測されます。

    OKの場合はrealtime_OS_pkg\r_bsp_rtos\mcu\rx65n\mcu_mapped_interrupts_private.hへ問題無くアクセス出来ている


    NGの場合はrealtime_OS_pkg\r_bsp_rtos\mcu\rx65n\mcu_mapped_interrupts_private.hへのアクセスが見当たらない

  • In reply to NoMaY:

    NoMaYさん

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

    種々調査ありがとうございます。

    私のGitHubのアカウントは SheltyDog です。よろしくお願いします。
    コードが出来てきたので、NoMaYさんのフォークをベースに整理していきたいと思っています。
    github.com/.../amazon-freertos

    GitHubにある最新版はビルドが通らないと思いますが、何かビルドを通すまでの
    ステップがありましたら、教えていただけますと幸いです。
    #スマートコンフィグレータでコード出力して、インクルードパスを整えていけばよいかとは思っています。

    また、アプリ層に近いコードに関しては、ルネサスアメリカの開発チームと共同活動することにしました。テストはほぼ通ったそうです。

    --------------------------------------------------------------------------
    ■進捗
    --------------------------------------------------------------------------
    RX65N Envision Kit、RX65N RSK(2MB版/暗号器あり品)をターゲットにコードメンテを維持します。
    下記 Amazon FreeRTOS 1.2.x は適宜最新コードに更新していきます。
    2018/03/17時点での適用コードは 1.2.2 です。

    ①ルネサスTCP/IPをターゲットで動作させる(Etherの動作確認)
    ②SDIO無線LANを動作確認した時期のFreeRTOS 8.2.2をターゲットで動作させる
    ③ルネサスのFreeRTOSパッケージ、9.0.0をターゲットで動作させる
    ④Amazon FreeRTOS 1.2.xのFreeRTOS部分をターゲットで動作させる
    ⑤Amazon FreeRTOS 1.2.xのFreeRTOS+TCP部分をターゲットで動作させる
    ⑥Amazon FreeRTOS 1.2.xのmbed TLS部分をターゲットで動作させる
    ⑦Amazon FreeRTOS 1.2.xのMQTT部分をターゲットで動作させる(AWSへの接続実験)
    ⑧Amazon FreeRTOS 1.2.xのFreeRTOS+TCP部分のネットワーク層の結合部分を工夫して、
     (1)Ether、(2)SPI接続無線LANモジュール、(3)SDIO無線LANモジュールの3種類を
     切り替えられるようにする ★(1)は完成。アメリカの開発チームに(2)を依頼。(3)はスキップ
    ⑨Amazon FreeRTOS 1.2.xのmbed TLS部分の暗号処理プリミティブの
     ソフトウェア実装(AESとかRSAとか)をRX65N内蔵暗号器を使った
     ハードウェア実装に置き換える ★一旦スキップしてソフトウェア実装のみでゴールを目指す。
    ⑩Ether層のゼロコピーに対応する ★アメリカの開発チームに依頼。うまくいかない場合はスキップ
    ⑪Amazon FreeRTOS本家環境にマージし、Amazon FreeRTOS本家コードへの追従を簡単にできるようにする ★アメリカの開発チームで調整済み
    ⑫Amazon FreeRTOS のGitのforkに登録する ★アメリカの開発チームの成果を受け調整結果登録する予定
    ⑬Amazon FreeRTOS のCertificationを受験し合格しGitの本家に登録する  ★アメリカの開発チームで調整中(ほぼ完成)
     aws.amazon.com/.../
    ⑭GCC対応  ★協力会社に依頼予定(一旦スキップしてCC-RXのみでゴールを目指す)
    ⑮Amazon FreeRTOSの最低ハードウェア要件であるRAM64KBを満たさないRXマイコンでは
     SSLおよびTCP/IP機能をWIFIモジュール側にオフロードした版を用意する  ★アメリカの開発チームに依頼。うまくいかない場合はスキップ
    ⑯再度Amazon FreeRTOS のCertificationを受験し合格しGitの本家に登録する ★アメリカの開発チームに依頼。

    --------------------------------------------------------------------------
    ■その他課題
    --------------------------------------------------------------------------
    ・e2 studio, CS+ともに長いファイルパスの場合コンパイルエラーが発生
    ・スマートコンフィグレータで出力したコードの取り扱い (出力後の状態でGitHubに掲載できるのか?)

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

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

    驚きました。ルネサスアメリカの開発チームも加わることになったのですね。(むしろ、ルネサスアメリカ主体になったとか?) ちなみに、ルネサスアメリカがやろうとしているSPI接続無線LANモジュール/ターゲットボードは、以下のものだったりしますか?

    RX65N Wi-Fi Cloud Connectivity Kit (以前調べた時は日本からは購入出来ないようでした。技適の関係かも知れません。)
    www.renesas.com/en-us/solutions/key-technology/connectivity/wi-fi/rx65n-wi-fi-kit.html

    そして、GitHubのリポジトリに関しては、すみません、遅くなりましたが、invitationを送りました。GitHubから以下のようなメールが届いているかと思います。メール内の[View invitation]のボタンのリンク先でacceptして頂けますか。

    メールのタイトル:
    NoMaY-jp invited you to NoMaY-jp/amazon-freertos

    メールの内容:
    @NoMaY-jp has invited you to collaborate on the NoMaY-jp/amazon-freertos repository

    You can accept or decline this invitation. You can also head over to
    https://github.com/NoMaY-jp/amazon-freertos to check out the repository or
    visit @NoMaY-jp to learn a bit more about them.

    [View invitation] ← ボタン

    それから、ソースをビルドするには以下のテキストの手順に従ってソースを入手および生成して頂けませんか。以下の2つのテキストはrx65n-rsk/ccrx-e2studio6のものですが、他のものも同様のフォルダにテキストを置いています。この2つの手順だけでビルド出来るようになります。

    ああっ、そうか、e2 studioでビルドする場合、どのソースが不足しているのか全く分からない(e2 studio/CDTはソースの有無に関しては一切関知しないので、CS+のようにソースが欠落しているというエラーは出ない)ので、このテキストの存在に気付きようがないですね。すみません。配慮が足りませんでした。どうするのが良いのか考えてみたところ、1つ案が思い浮かびました。幾つか前の投稿でも書いたビルド前ステップで、何かファイルの有無をチェックして見付からない場合は、以下のテキストを読むよう促すメッセージをコンソールウィンドウに表示させてみる、ということをやってみようかと思います。併せて、このGitHubのリポジトリのトップページのREADME.mdに注意書きを加えようと思います。もちろん、これらの手順が不要なようにGitHubに登録出来るようになれば、それが一番良いと思います。

    (1) RX65N Group Application Note RX65N Real-time OS Package V1.0.00のソースの入手

    テキストの場所:
    demos/renesas/rx65n-rsk/ccrx-e2studio6/src/realtime_OS_pkg/get!.txt

    内容:
    github.com/NoMaY-jp/amazon-freertos/blob/renesas-rx-experiment/demos/renesas/rx65n-rsk/ccrx-e2studio6/src/realtime_OS_pkg/get!.txt

    (2) スマートコンフィグレータのコード生成機能でソースを生成

    テキストの場所:
    demos/renesas/rx65n-rsk/ccrx-e2studio6/src/smc_gen/generate!.txt

    内容:
    github.com/NoMaY-jp/amazon-freertos/blob/renesas-rx-experiment/demos/renesas/rx65n-rsk/ccrx-e2studio6/src/smc_gen/generate!.txt

    [追記]

    おお、Hardware PartnersにESPRESSIFが、Ecosystem & Technology PartnersにSEGGERとMIPSが、新たに加わっていますね。このHardware PartnersにやがてRENESASも加わるのですね。(あれっ、armって全部小文字でしたっけ。ARM→Armになったのだったような。)

    Amazon FreeRTOS Partners
    aws.amazon.com/jp/freertos/partners/
     

  • In reply to シェルティ:

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

    >e2 studio, CS+ともに長いファイルパスの場合コンパイルエラーが発生
    これは回避策が見付かりそうです。

  • In reply to NoMaY:

    NoMaYさん

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

    Invitationありがとうございます。
    間違えてプライベートのメールアドレスをPrimary設定にしていたので、
    会社のメールアドレスにInvitationが届いてませんでした。
    帰宅したらInvitationの処理をします。

    ボードは「RX65N Wi-Fi Cloud Connectivity Kit」ではなくて、
    RX65N TargetBoardの拡張ボードで、と考えています。
    www.renesas.com/.../rx-family-target-board.html

    RX65N Wi-Fi Cloud Connectivity Kit は日本国内技適が取れておらず、日本国内販売ができないからです。
    拡張ボードはEtherと代表的センサと無線LAN拡張コネクタをと考えており、
    可能な限り廉価でW/W販売しようとしています。
    使用する無線LANモジュールをどれにしようか悩んでいるところです。
    W/Wで技適取得済みとなると限られてしまいますね。

    ルネサスアメリカの経緯ですが、私たちのかふぇルネでの活動を会社内で報告していたところ
    彼らもRX65N Wi-Fi Cloud Connectivity Kit でAmazonと付き合いがあり、協力できそうとのことで
    話に乗ってきてくれました。NoMaYさんの行動が大きな起点になっていると思っております。
    新しいことを始めるときは工数見積もりが難しく、積極的に挑戦する人が少ないのですが、
    最初のとっかかりが出来てしまえば、わりとあっさり進んだりもするものですね。
    恐れず挑戦する姿勢が大事なのだと思います。(一定確率で失敗してしまったりもしますけれど必要経費と思っています)
    本件、NoMaYさんにとっかかりを作って頂けたものと思っています。
    ありがとうございます。なんとかゴールに導きたいと思います。

    get!.txt, generate!.txtについては、申し訳ありません。
    ファイルの存在は過去投稿を覚えているので知っていたのですが
    他になにか落とし穴的なものがないか確認したく、質問させていただきました。
    このファイルを見ながら、今週末にコード調整したいと思います。

    >>Hardware PartnersにやがてRENESASも加わるのですね。

    はい、そうしたいと思っています。
    FreeRTOSがAmazonに買収される前は、RenesasもパートナーとしてFreeRTOSのページに
    ロゴが置いてあったはずなのですが、買収後は、Amazonに協力しているパートナーのみ
    表示されるようになりましたね。


    >>>>e2 studio, CS+ともに長いファイルパスの場合コンパイルエラーが発生
    >>これは回避策が見付かりそうです。

    助かります。また、ご連絡いただけますと幸いです。

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

    長いファイルパスの場合にコンパイルエラーが発生する件で、昨日、回避策によって長さの制限を緩和したものをGitHubに登録しました。この件も含めて、他にも、以下の変更を行いました。

    (1) 長いファイルパスの場合にコンパイルエラーが発生する件でソースを展開するフォルダの深さの制限を緩和
      諸事情で"..\"を多用していたRX65N Real-time OS Packageのplatform.hとr_bsp.hを自前のplatform.hr_bsp.hで代替
      ビルド前ステップが複雑になりすぎたのでバッチファイル化しました
    (2) (1)の回避処置の1つで併せてhwsetup.c問題にも対処(hwsetup.cの場所がhwsetupフォルダ→alternativeフォルダに変更)
    (3) (1)の回避処置の1つで併せてiodefine.h問題にも対処(小細工に使っていた特殊なiodefine.hを削除)
    (4) (1)の回避処置の1つで併せてRX65N Real-time OS Packageを利用する為に追加した中身が空のcroutine.hを削除
    (5) (1)のバッチファイルにおいてソースツリーに不都合が検出されたらエラーメッセージを表示するようにしました
      ファイルパスが長すぎる
      RX65N Real-time OS Packageのソースのコピーが行われていない
      Smart Configuratorによるコード生成が行われていない
      (1)の回避処置の1つとしてバッチファイルでフォルダやファイルをリネームするが何故か同名のものが既にある(念の為)
    (6) 幾つかのソースでコメントに含まれているAmazon FreeRTOSやFreeRTOS+TCPのバージョン文字列を変更
      対象ソース:  aws_application_version.h, pack_struct_end.h, pack_struct_start.h

    今回登録したものでは、以下のようなパスのフォルダに展開した場合でもビルド出来るようになりました。(以下はrx65n-envision-kit(18文字)をビルドする場合です。rx65n-rsk(9文字)だけをビルドするのであれば、あと9文字(=18文字-9文字)まで深くすることが出来ます。) なお、以下の青字部分が今回緩和された長さの分です。

    e2 studio

    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-1234567890123456789012345678901234567890123456789012345

    CS+

    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-12345678901234567890123456789012345678901234567890123456789012345678

    上のそれぞれに1文字を追加したパスに展開した場合、実際にソースツリー上で最長パス名となるソースは以下のファイルになりますが、今回は、統合開発環境がCC-RXへ引き渡しているパス名が"..\"や".\"を含んでいることによってCC-RXの内部で以下のパス文字列が使用された結果、コンパイルエラー/リンクエラーになってしまうのだと推測されます。(これまでは、コンパイルされるソースに記述された#include文でのパス名が"..\"や".\"を含んでいたことに起因していたのだと推測されますが、それとは異なるものです。)

    e2 studio

    ソースツリー上の最長パス名:
    (243文字)
    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-12345678901234567890123456789012345678901234567890123456\demos\renesas\rx65n-envision-kit\ccrx-csplus\src\realtime_OS_pkg\r_bsp_rtos\board\rskrx65n_2mb\r_bsp_interrupt_config_reference.h

    エラーの原因になったと考えられるパス文字列:
    (e2 studioでは以前はコンパイルエラーでしたが回避策の影響で今回はリンクエラーです)
    (260文字)
    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-12345678901234567890123456789012345678901234567890123456\demos\renesas\rx65n-envision-kit\ccrx-e2studio6\HardwareDebug\.\lib\aws\FreeRTOS-Plus-TCP\source\portable\NetworkInterface\RX\NetworkInterface.obj

    発生するエラー:
    F0563300:Cannot open file : ".\lib\aws\FreeRTOS-Plus-TCP\source\portable\NetworkInterface\RX\NetworkInterface.obj"

    CS+

    ソースツリー上の最長パス名:
    (256文字)
    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-123456789012345678901234567890123456789012345678901234567890123456789\demos\renesas\rx65n-envision-kit\ccrx-csplus\src\realtime_OS_pkg\r_bsp_rtos\board\rskrx65n_2mb\r_bsp_interrupt_config_reference.h

    エラーの原因になったと考えられるパス文字列:
    (CS+ではコンパイルエラーです)
    (260文字)
    C:\Renesas\AmazonFreeRTOS\renesas-rx-experiment-20180318-123456789012345678901234567890123456789012345678901234567890123456789\demos\renesas\rx65n-envision-kit\ccrx-csplus\..\..\..\..\lib\FreeRTOS-Plus-TCP\source\portable\NetworkInterface\RX\NetworkInterface.c

    発生するエラー:
    E0511134:Input file "..\..\..\..\lib\FreeRTOS-Plus-TCP\source\portable\NetworkInterface\RX\NetworkInterface.c" is not found.

    以下は、長いファイルパスの場合に発生するエラーの画面コピーです。なお、今回追加したビルド前ステップのバッチファイルによる事前検出のエラーも含まれています。(ただ、事前検出してもビルドが続いてしまうのが、ちょっと残念ですが、、、)





    また、以下は、RX65N Real-time OS Packageのソースのコピーが行われていなかったり、Smart Configuratorによるコード生成が行われていなかったり、という場合に事前検出されるエラーの画面コピーです。)





    なお、ソースツリーに不都合が検出されなければ、フォルダやファイルのリネームを行うメッセージやファイルのコピーを行うメッセージを表示したり、それらが行われた後であればそれに気付くようなメッセージを表示したり、といったことをするようにしています。(これは今までと同様ですが、以下の画面コピーのように少しメッセージを変更しました。







    [追記] 2018/04/09 09:00

    以前の投稿の時と同様にProcess MonitorでCC-RXのファイルアクセスを調べてみた印象では、Windows API内部の処理でエラーになっているのでは無さそうで、CC-RXに実装された処理でエラーになっているのだろうと推測されます。なぜなら、以下の画面コピーの通り、OKの場合にはHardwareDebug\lib\aws\FreeRTOS-Plus-TCP\source\portable\NetworkInterface\RX\NetworkInterface.objやlib\FreeRTOS-Plus-TCP\source\portable\NetworkInterface\RX\NetworkInterface.cへファイルアクセスしていますが、NGの場合にはファイルアクセスしていませんので、CC-RXに実装された処理で事前に除外されてしまっているのだと推測されます。

    e2 studio

    OKの場合にはHardwareDebug\lib\aws\FreeRTOS-Plus-TCP\source\portable\NetworkInterface\RX\NetworkInterface.objへアクセスしている


    NGの場合にはHardwareDebug\lib\aws\FreeRTOS-Plus-TCP\source\portable\NetworkInterface\RX\NetworkInterface.objへアクセスしていない


    CS+

    OKの場合にはlib\FreeRTOS-Plus-TCP\source\portable\NetworkInterface\RX\NetworkInterface.cへアクセスしている


    NGの場合にはlib\FreeRTOS-Plus-TCP\source\portable\NetworkInterface\RX\NetworkInterface.cへアクセスしていない


  • In reply to NoMaY:

    NoMaYさん

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

    種々調査いただきありがとうございます。
    いただいたコードを使ってこちらもコード調整を進めてまいります。

    こちらでは、以下を進めておりました。

    ・RX65N Target Board用の拡張ボードの設計・製造(ルネサスヨーロッパに依頼)
    ・RX65N Target Board用の拡張ボードのPMODに差し込める
     UART接続のSilex SX-ULPGN搭載(技適対応:北米、欧州、日本)無線LANボードの
     設計・製造(ルネサスヨーロッパに依頼)
    ・アジア地域向けの無線LANモジュールの検討/ESP32活用
     store.digilentinc.com/.../
    ・Amazon FreeRTOSのコード調整とQualification Program検討(ルネサスアメリカに依頼)
    ・Amazon FreeRTOSのRX-GCC対応(協力会社に依頼)
    ・FITモジュールやコード生成出力コードの再配布について権利関係の確認

    ひとまずAmazon FreeRTOSのRXファミリ版の公開にあたり大きな問題は
    クリアできてきたという感触です。
    まだ明確な計画が立っていませんが、夏から秋にかけてボード発売開始と
    ソフト公開ができれば、というようなイメージでいます。
    NoMaYさんのコードとルネサスアメリカの調整したコードとをうまく組み合わせれば
    きれいになるのではないかと思っています。ゴールデンウィーク中の宿題になりそうです。

    また進捗報告します。

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

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

    とうとう、ルネサスヨーロッパの開発チームも加わることになったのですね。ところで、すみませんが、もし宜しければ4つほど、教えて下さい。

    (1)ちょっと先走り過ぎて、シェルティさんのGitHubへのユーザー登録を急がせてしまったかも、とも感じているのですが、今しばらく(ボード発売の時まで?)シェルティさん側でのソースの更新や追加は無さそうでしょうか?その場合でも、コンフィグレーション系のヘッダファイルで新しくなっているものがあれば、随時、頂けないでしょうか? GitHubの私のForkのソースツリーとルネサスアメリカのコードをマージした時にトラブルを起こすとしたら、コンフィグレーション系のヘッダファイルの入れ替え忘れが一番の原因になりそうな気がするからです。

    (2)GitHubの私のForkのページに「ルネサスエレクトロニクス社(日本、米国、欧州)にて開発作業が始まったとの情報を頂きました」みたいなト ピックス(英文)を載せても大丈夫そうでしょうか? (かふぇルネで日本語で話が出るのと、あちら(GitHub)で英語でトピックスを載せるのとでは、ちょっと重みが違うかも知れない、と気掛かりだからで す。)

    (3)スマートコンフィグレータが生成したFITモジュールやコード生成出力コードの再配布について、今回のAmazon FreeRTOSの件では、どのようになる方向でしょうか?

    (4)同じくスマートコンフィグレータが生成したコードの再配布について、一般の場合(今回のAmazon FreeRTOSの件以外)に関して、ルネサスさんの方針など決まっているようでしょうか? (今のところ、明文化されたものが見付からないので。) 決まっているようであれば、かふぇルネで、ルネサスさんの中の人(この件なら鈴木さんかな?)に質問してみようかと思ったからです。

  • In reply to NoMaY:

    NoMaYさん

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

    (1)についてはGitHubのコード整備前にルネサスアメリカが調整したコードをNoMaYさんに見ていただくことで
     どのようにGitHubに入れていくのがよいかご意見いただければ、と考えています。
     私がGitHubに何かコードを入れるとしたらそのあとからと思います。
    (2)~(4)については現状だと何らかの見解をだすのは時期尚早でして、もう少しお時間いただければと思います。

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

    NoMaYさん

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

    正式に仕事として動き出したのでなかなか公開できる情報が少ないですね。
    最近は専らボード仕様についてW/Wメンバー間で議論を重ねています。
    良い方向に進んではいますので何らか報告も良いものが出せると思っています。

    そうそう、ずいぶん前に購入したSTM32のAWS IoTキットが届いたので試してみました。
    プリインストールのデモを動かして説明書読みながらあれこれ設定したら
    30分でAWS接続できましたね。とてもよくできています。

    最近の週末はRX65N内蔵のセキュリティIP用のドライバのコードを書いていることが多く
    Amazon FreeRTOSはあまり触ってなかったですが、
    ドライバのほうがだいたい落ち着いてきたので
    Amazon FreeRTOSのコードの整理も再開しようと考えています。

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

    NoMaYさん

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

    NoMaYさんの環境ベースで動作確認できました。
    shelty1.servegame.com/.../experiment.zip

    今回の整備にあたりNoMaYさんに作っていただいたビルド前のチェッカのおかげで
    作業中の間違いにすぐ気づくことができとても助かりました。
    NoMaYさんのご配慮に感謝しつくせません。

    以下についてご意見いただけますか?
    このあたり整理ができたら、コード生成のコードとFreeRTOS用のBSPを抜いた形で
    GitHubに登録したいと思います。

     ・e2 studioの環境のフォルダ構成が実物とまだ合ってない。修正する。(CS+はできた)
     ・以下はボード依存が無いコード(全く同じになった)なので1階層UPしてマージする。
       \lib\ota\portable\renesas\rx65n-envision-kit\aws_ota_pal.c
       \lib\ota\portable\renesas\rx65n-rsk\aws_ota_pal.c
       \lib\pkcs11\portable\renesas\rx65n-envision-kit\pkcs11.c
       \lib\pkcs11\portable\renesas\rx65n-rsk\pkcs11.c
       \lib\secure_sockets\portable\renesas\rx65n-envision-kit\aws_secure_sockets.c
       \lib\secure_sockets\portable\renesas\rx65n-rsk\aws_secure_sockets.c
     ・BSPやドライバは、以下フォルダに入れるのがお作法のようだ。そのうち引っ越しする。
       \lib\third_party\mcu_vendor\renesas\
        ⇒DriverLibNameとあるので、ベンダが好きな名前を付けられるようだ。
         何にしようかな?
         ⇒素直に、「rx_driver_package」にしよう。

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

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

    >以下についてご意見いただけますか?
    すみません。体調不良でダウンしていました。明日、ソースを見ながら考えてみます。

  • In reply to シェルティ:

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

    すみません。リプライが遅くなりました。

    >以下はボード依存が無いコード(全く同じになった)なので1階層UPしてマージする。

    aws_ota_pal.cではコードフラッシュ書き換えを行うことになると思いますが、RX65NとRX231/RX130ではフラッシュメモリがMONOSとSuperFlashというように異なっています。そして、フラッシュ書き換え処理そのものはr_flash_rxモジュールが差異を吸収してくれるのですが、ブロックの仕様が混合か一律か(RX65Nは8KB/32KB混合、RX231/RX130は一律2K/一律1K)の違いが将来ソースコード上に現れてくるような予感がします。ですので、私は1階層UPしない方が良いと思います。(ところで、5月1日のシェルティさんのソースのaws_ota_pal.cは未実装なソースですよね、、、)

    pkcs11.cはデータフラッシュ書き換えを行っているように思えますので、ブロックサイズの違いこそあれ、ブロックサイズが一律であることは同じですので、RX65NでもRX231/RX130でも同じソースコードで済みそうですので、これは1階層UPして良さそうに思います。

    他方、aws_secure_sockets.cではAmazon FreeRTOS v1.2.4でソース一本化の方向に向かい始めたのではないかという気がします。aws_secure_sockets.cに関してはAmazon FreeRTOS v1.2.4により再検討になるのではないかという気がします。(なお、pkcs11.cも以下の変更に合わせて修正が必要になるのではないかと思われます。
    github.com/aws/amazon-freertos/blob/v1.2.4/change_log.txt
    Change Log for Amazon FreeRTOS V1.2.4 05/01/2018
    抜粋

    OTA PAL for Curiosity PIC32MZEF V0.9.1
        - Updated for PKCS#11 PAL layer API changes.

    OTA PAL for Windows Simulator V0.9.2
        - Minor restructuring of file locations.Minor restructuring of file locations.

    OTA PAL for CC3220SF-LAUNCHXL V0.9.3
        - Minor changes to enable test integration.

    OTA Agent V0.9.4
        - Minor restructuring of file locations.

    mbedTLS-based PKCS#11 V1.0.2
        - Combined the mbedTLS based PKCS#11 implementation from Curiosity PIC32MZEF, LPC54018 IoT Module, Windows Simulator, and STM32L4 Discovery kit IoT node into a single file.
        - Add support for public key verification of signatures.
        - Fix to free context structures on session failure.
        - Update C_OpenSession to use CKF_SERIAL_SESSION flag.

    PKCS#11 for Curiosity PIC32MZEF V1.0.2
        - Create port specific functions for certificate and key access:
          PKCS11_PAL_SaveFile(), PKCS11_PAL_ReadFile(), PKCS11_PAL_ReleaseFileData().

    PKCS#11 for LPC54018 IoT Module V1.0.1
        - Create port specific functions for certificate and key access:
          PKCS11_PAL_SaveFile(), PKCS11_PAL_ReadFile(), PKCS11_PAL_ReleaseFileData().

    PKCS#11 PAL for Windows Simulator V1.0.2
        - Create port specific functions for certificate and key access:
          PKCS11_PAL_SaveFile(), PKCS11_PAL_ReadFile(), PKCS11_PAL_ReleaseFileData().

    PKCS#11 for STM32L4 Discovery kit IoT node V1.0.1
        - Create port specific functions for certificate and key access:
          PKCS11_PAL_SaveFile(), PKCS11_PAL_ReadFile(), PKCS11_PAL_ReleaseFileData().

    PKCS#11 for CC3220SF-LAUNCHXL V1.0.2
        - PKCS#11 implementation for TI based on mbedTLS moved into this file.

    Secure Socket for FreeRTOS+TCP V1.1.2
        - Combined Secure Sockets implementation for Curiosity PIC32MZEF and Windows Simulator into a single file.
        - Fixed return value of SOCKETS_Socket on error.
        - Attempting to create an unsupported UDP socket now triggers an assert.
        - Added cryptographic random number generator function for TCP sequence numbers.
        - Updated the Socket structure to keep track of a connection attempt and added support of the ECONN error.

    Secure Sockets for LPC54018 IoT Module V1.0.0 Beta 3
        - Fixed minor bug in SOCKETS_Recv().

    Secure Sockets for STM32L4 Discovery kit IoT node V1.0.0 Beta 2
        - Fixed return value of SOCKETS_Close on error.

    Secure Sockets for CC3220SF-LAUNCHXL V1.0.3
        - Secure sockets printing is now controlled independently using the SOCKETS_PRINT macro. SOCKETS_PRINT prints TI driver error codes.

    >BSPやドライバは、以下フォルダに入れるのがお作法のようだ。そのうち引っ越しする。

    Amazon FreeRTOSのソースツリーでは、どれもそちらのフォルダに置かれていますが、スマートコンフィグレータの仕様と合わず、使い勝手が悪くなってしまうので、今の{プロジェクトフォルダ}/src/smc_gen/等を前提にするのが良いと思います。(かふぇルネでも時々目にする意見として「コード生成機能やFITに関して何も考慮されておらず、このサンプルプログラムを作った人はルネサスのツールのことを理解していない人なのだと思われます。」というのがありますが、ここをAmazon FreeRTOSの作法に合わせてしまうと、これもその仲間入りをしてしまうような気がします。自分らのやろうとしていることをゴールとして捉えると、確かにそちらのフォルダに置きたくなりますが、実際には、そこは他の人達にはスタート地点ですので、その人達にとっての利便性を損なうのは避けたいですね。)

    GitHubのAmazon FreeRTOSのページを見ていたら、この件とIssue #25は同様なことではないかと思い始めました、、、
    github.com/aws/amazon-freertos/issues/25
    Update request pic32mzef MHC #25
    抜粋

    dcgaws commented 11 days ago

    Ah, sorry, I only looked at the diff of the file and didn't recognize the actual issue.
    The MHC files in our repo are from the initial ports from Harmony over to Amazon FreeRTOS.
    However, the Microchip Harmony Configurator doesn't recognize the Amazon FreeRTOS directory structure,
    and the MHC files in our repo are not being maintained.

    I regret the inconvenience that this is causing to customers that are accustomed to MHC.
    We're discussing potential longer-term solutions.

    ところで、細かい話ですが、5月1日のシェルティさんのソースのpkcs11.cで以下の赤文字の部分の処理が腑に落ちないです。64はRX65Nのデータフラッシュのブロックサイズかなと思うのですが、意図が分からない部分が多くて、、、

    /* Renesas */
    // XXX
    int FLASH_update(uint32_t dst_addr, const void *data, uint32_t size)
    {
        uint32_t    i;
        flash_err_t err;
        volatile uint32_t addr;←volatile?
        uint32_t    size_blk;
        uint32_t * src_addr = (uint32_t *) data;

        /* Open driver */
        err = R_FLASH_Open();
        if (err != FLASH_SUCCESS) return -1;

        /* Erase code flash block */←code flash?
        addr = dst_addr;
        if ((size%64) == 0)
        {
            size_blk = (int)(size/64);
        }
        else
        {
            size_blk = (int)(size/64) + 1;
        }

        err = R_FLASH_Erase(dst_addr, (size_blk/64));←size/64のsize_blkを更にsize_blk/64しているのは?
        if (err != FLASH_SUCCESS) return -1;

        while (addr < (dst_addr + size_blk))←size_blkではなくてsizeでは?
        {
            err = R_FLASH_Write((uint32_t)src_addr, addr, size_blk);←size_blkではなくて64または端数では?
            if(err != FLASH_SUCCESS) return -1;

            /* Verify code flash write */←code flash?
            for (i = 0; i < size_blk; i++)←size_blkではなくて64または端数では?
            {
                if (*((uint8_t *)(src_addr + i)) != *((uint8_t *)(addr + i)))←src_addrはuint32_t *だがaddrはuint32_tなので場所が全然違う筈
                {
                    return -1;
                }
            }

            addr += size_blk;←size_blkではなくて64または端数では?src_addrの更新が無いのでは?
        }

        return size_blk;←size_blkではなくてsizeでは?
    }

     

  • In reply to NoMaY:

    NoMaYさん

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

    貴重なご意見ありがとうございます。考えがまとまってきました。

    >以下はボード依存が無いコード(全く同じになった)なので1階層UPしてマージする。
    ⇒分かりました。ご指摘通りと思います。現状維持にしたいです。

    >BSPやドライバは、以下フォルダに入れるのがお作法のようだ。そのうち引っ越しする。
    ⇒分かりました。ご指摘通りと思います。現状維持にしたいです。

    >pkcs11.cで以下の赤文字の部分の処理が腑に落ちないです。
    ⇒ご指摘感謝です。PKCS11のアップデート及びOTAについてはまだ動作確認しておらず作りかけの状態ですね。

    現状とV1.2.4との差分を確認して、フラッシュ関連のコードを一旦スタブ化し、
    一度GitHubに登録してみようと思います。作業は次の週末の予定です。

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

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

    Amazon FreeRTOS v1.2.3→v1.2.4の差分を確認するとmbedTLS v2.6→v2.8へ変わったことによる差分が結構出ます。一旦、Amazon FreeRTOS v1.2.3ベースで動作確認出来たものをGitHubに登録し、その後、v1.2.4に追従させるようにした方が、気持ち的に楽ではないかと思います。私的にも、変更箇所を確認し易くなりますので、むしろ、その方が良いように思うのです。どうでしょうか?(以下、差分のあったファイル一覧の画面コピーです。)

    Amazon FreeRTOS v1.2.3→v1.2.4:トータルの差分が286ファイル、その内のmbedTLSでの差分は123ファイル

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