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さん

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

    >>19日にRX65N RSKのEtherのケースだけ先行して動作確認してみます。

    動作確認OKでした。感謝感激です。
    今週末に他の環境もすべて動作確認してリリースビルドを作ります。

    以上です
  • シェルティさん、こんにちは。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へも適用する、といったところでしょうか。)

  • In reply to NoMaY:

    NoMaYさん

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

    調査ありがとうございます。確かにRAM容量懸念がありますね。
    第1世代と第2世代の比率は岡宮さんに聞かないと分からないですが、
    結構早い時期から第2世代になってたと思うので第2世代の方が多いような気がします。

    いずれにしても小さい方に合わせるとして普段の私の設計ポリシーからすると
    OS層までで使用するのは物理容量の半分まで、となるので64KB以内に収めたいところですね。

    ヒープを削っても多分動くと思いますが要検証です。
    ひとまず128KBに収まるように適当にコンフィグ値を触っていただき、コミットしてもらってよいでしょうか。
    GR-SAKURAでの実機実験はこちらで引き受けます。

    ちなみに、現状の設定値は完全に「適当」です。
    多めに盛っているだけで最終的に無駄なところを削って最小値にしようと考えています。
    Amazon FreeRTOSのハードウェア要件にRAM 64AKB以上とあるので、
    64KBあれば最低限動く設計になってるはずですね。
    aws.amazon.com/.../

    ちなみに、無線LANモジュール側にTLS機能、TCP/IP機能をオフロードできれば(無線LANモジュール側にこれら機能があれば)必要RAMは16KBになります。
    今はRX65NでTLSとTCP/IPをマイコン側に持たせる設計にしてあるので64KB必要ですが、
    構成を組み替えることでRX113やRX231でもAmazon FreeRTOSを使って
    マイコンをAmazon Web Serviceに繋ぐことができます。
    RX65Nがひと段落したら、この構成も試す予定です。

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

    NoMaYさん

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

    全環境無事に動作確認終わりました。ありがとうございました。
    リリースビルドを作っておきました。
    github.com/.../v0.1.5

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

    NoMaYさん

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

    RX63N GR-SAKURAの環境追加ありがとうございます。
    15分だけ時間があったでのハード環境組み立ててコンパイルOKまで確認しました。
    FITコンフィグレータの設定や端子設定が問題なさそうなことも確認しました。
    これ本当にありがたいです。たすかります。

    後ほどお昼休みに実機確認も進めてみます。

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

    シェルティさん、こんにちは。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"の後に色々足して複数同時にインポート可能にする

  • In reply to NoMaY:

    NoMaYさん

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

    ありがとうございます。現在の作り、今後の方針など分かりました。

    こちらではRX63N GR-SAKURAでの実機確認を進め、Amazon Web Serviceに繋がることを確認しました。
    現状コードから、r_bsp_config.hのユーザスタックをゼロ、割り込みスタックを4KB(0x1000)、ヒープを256バイト(0x100)に減らしました。
    あとFreeRTOSのヒープを56KBまで減らしていただきましたが、これだとmbed TLSでヒープ確保される
    段階でヒープが足りなくなりエラーを吐いたので、68KBまで増やしました。
    (Amazon FreeRTOSのミニマム要件に64KBと書いてあったので、64KB設定を試しましたがNGでした)

    結果、現在のRAM使用量112KBです。マップファイルを眺めてますが、
    削れそうなところはもうない感じですね。実質これがAmazon FreeRTOSを機能フルで動かすのに必要な
    RAM総量かなと思います。性能フルにすると通信バッファを多段にする必要がありもう少しRAM要ります。
    とすると、やはりGR-SAKURA II(RAM256KB)が最小ハードウェアの推奨マシンとなりますね。

    もうすこしRAMについてはダイエットしてみます。

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

    NoMaYさん

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

    日々改善を進めていただき、感謝申し上げます。
    Amazon関連は若手に託して、シェルティは最近新しいマイコン、新しい無線の仕込みを開始しております。
    新しいマイコン、新しい無線ではAmazon FreeRTOS対応を引き続き前面に出して
    使うよう検討を進めております。

    Amazonに関しては以下を重点的に開発を進めていきたいと思っています。
    ・セキュリティハードウェア(TSIP)とmbed TLS連携(2018年中に技術目処を立てる予定)
    ・OTA関連(TIの環境を勉強中)
    ・Tracelyzer関連(資産購入手配の段取り中)

    NoMaYさんの活動成果は今後RXマイコンの公式のBSPおよび他FITモジュールに取り込みさせていただきます。
    GitHubにあるBSPを中心にFIT関連開発メンバーに見てもらっていますが、特に問題になるところは無さそう、
    との見解を得ています。
    引き続き議論を続けながら開発を続けさせていただけますと幸いです。

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

    私の今の進捗です。

    済み
    ●AFQPのドキュメントを読んで問題無さそうならプロジェクト名の"aws_demos"の後に色々足して複数同時にインポート可能にする
    ⇒ CS+でも小細工して可能にしましたが小細工の都合上プロジェクトの保存は避けた方が良いです(連続ビルドは出来る)
    ⇒ 画面コピー参照
    ●3コンパイラ対応のBSPのフォルダ構成の変更案の試行
    ⇒ 画面コピー参照
    ●前述の逆輸入の件

    着手
    ●コンパイル時のワーニングを減らす
    ⇒ 形式的にワーニングを減らそうとするだけというのもどうかと思い始めたのでワーニングレベルを上げてやり始めました
    ⇒ 今のCC-RXとGNURXのワーニング設定は画面コピーの通りです
    ●3コンパイラ対応のBSPの取り込み作業中に気掛かりだった箇所の修正や思い浮かんだ改良案の試行
    ⇒ ワーニグレベルを上げたことで気付いた点も修正していきます

    未着手
    ●GNURXのリンク時のワーニングを取る
    ●demos\renesas\XXX\common\config_file\*.hの#define等の順序をAmazon FreeRTOS本家の*.hに合わせる
    ●ビルド前ステップのバッチファイルの見直し(make.exeが見付かりません問題の緩和策も)

    新たに気になり始めたこと(&思い出したこと) (RX71M-RSK, RX64M-RSK, RX63N-RSKの作業の前に対処したい分)

    ・R_FLASH_RXでCC-RXの__sectop()演算子が使われていることへの対処
    ・ICCRX向けのiodefine.hの__sfrはvolatileの方がうれしい人もいるような気がする
    ・ボード依存のSCIのチャンネル番号の指定方法の見直し(現状はボード種別番号で切り替え)
    ・ボード依存のETHERの初期化関数名の指定方法の見直し(同上)
    ・SCIのチャンネルは1つで済む筈?(複数チャンネル有効化されているのは今では単に歴史的経緯のみ?)
    ・GR-SAKURAのIスタック/Uスタック(今回未使用)/R_BSPヒープのサイズは他ボードへ展開した方が良い?
    ・GNURXプロジェクトでのIスタック/Uスタック(今回未使用)のサイズ指定方法の見直し(r_bsp_config.hで指定したい)
    ・GNURXプロジェクトでもCC-RXプロジェクト同様にRAMの先頭256バイトを空けるようにする

    新たに気になり始めたこと(&思い出したこと) (もう少し先で対処したい分)

    ・3コンパイラ対応のFITモジュールが正式リリースされた後のプロジェクト構造をどうする?
    ・各プロジェクトのマイコン型番をユーザのターゲットボードのマイコン型番に変更する簡単な方法は?
    ・試作基板のGR-ROSEはR5F565NEDxLJでしたね(でも量産基板で変わるかも? それから"_DUAL"は有りか無しか?)
    ・GR-CITRUS(RX631)+WA-MIKAN(ESP8266) 対応
    ・FreeRTOS+POSIX 対応

    以下、いつものように画面コピーです。

    プロジェクト名の"aws_demos"の後に色々足して複数同時にインポート可能になった



    3コンパイラ対応のBSPのフォルダ構成の変更案の試行




    今のCC-RXとGNURXのワーニング設定




    [余談]

    今日、このスレッドを開いた時のビューカウント値が 21212 になっていて面白かったので採取した画面コピーです。

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

    私の今の進捗です。なお、確認したい事項が2つあります。

    確認事項
    ●以下の新規追加されたbsp_ram_initialize()を_INITSCT()や__iar_data_init2()の後に実行する意図が分かりません。operating_frequency_set()の前なら(今は必要無いが)将来operating_frequency_set()でg_bsp_Locksを使うことになった場合に備えてやることにした、という予想は立つのですが、_INITSCT()や__iar_data_init2()で所謂bssセクションの0クリアが行われた後にg_bsp_Locks[i].lockを0クリアする必要は無いと思うのです。何か設計ミスしていないでしょうか?

    resetprg.c

    #if defined(__CCRX__) || defined(__GNUC__)
    void PowerON_Reset_PC(void)
    #elif defined(__ICCRX__)
    int __low_level_init ( void )
    #endif /* defined(__CCRX__), defined(__GNUC__), defined(__ICCRX__) */
    {

        /* Switch to high-speed operation */
        operating_frequency_set();

        /* If the warm start Pre C runtime callback is enabled, then call it. */
    #if BSP_CFG_USER_WARM_START_CALLBACK_PRE_INITC_ENABLED == 1
         BSP_CFG_USER_WARM_START_PRE_C_FUNCTION();
    #endif

        /* Initialize C runtime environment */
    #if defined(__CCRX__) || defined(__GNUC__)
        _INITSCT();
    #elif defined(__ICCRX__)
        __iar_data_init2();
    #endif /* defined(__CCRX__), defined(__GNUC__), defined(__ICCRX__) */

        /* Initialize RAM */
        bsp_ram_initialize();

        /* If the warm start Post C runtime callback is enabled, then call it. */
    #if BSP_CFG_USER_WARM_START_CALLBACK_POST_INITC_ENABLED == 1
         BSP_CFG_USER_WARM_START_POST_C_FUNCTION();
    #endif

    cpu.c

    void bsp_ram_initialize (void)
    {
        uint32_t i;

        /* Initialize g_bsp_Locks to 0. */
        for (i = 0; i < BSP_NUM_LOCKS; i++)
        {
            g_bsp_Locks[i].lock = 0;
        }
    }

    mcu_locks.c

    BSP_CFG_USER_LOCKING_TYPE g_bsp_Locks[BSP_NUM_LOCKS];

    ●以下のR_NOP()の意図が分かりません。(ただ、これは元々はFITでは無い場合のCC-RXのスタートアップルーチンに由来するものなので、シェルティさんにお聞きするのは少々担当違いかなとは思っています。) 削除して構わないものでしょうか?(少なくとも謎のNOPに設計意図についてのコメントを付けたいです。)

    resetprg.c(FITのr_bspのもの)

        /* Configure the MCU and board hardware */
        hardware_setup();

        /* Change the MCU's user mode from supervisor to user */
    #if defined(__CCRX__) || defined(__GNUC__)
        R_NOP();
        R_SET_PSW((R_SET_PSW_CAST_ARGS1)PSW_init);
    #elif defined(__ICCRX__)
        asm("POP R15");
        R_SET_PSW((R_SET_PSW_CAST_ARGS1)PSW_init);
        asm("PUSH.L R15");
    #endif /* defined(__CCRX__), defined(__GNUC__), defined(__ICCRX__) */

    resetprg.c(FITではない通常のCC-RXのスタートアップルーチンのもの)

    //  HardwareSetup();                // Use Hardware Setup
        nop();

    //  _CALL_INIT();                   // Remove the comment when you use global class object

        set_psw(PSW_init);              // Set Ubit & Ibit for PSW

    以下、進捗です。

    特記事項
    ●GR-SAKURAのGNURXプロジェクトで割り込み/例外/リセットのベクタ関連の致命的ミスに気付いたので一緒に修正中
     GitHub上のソースはリセットベクタすら正しくセットされていないので動作しないです、、、
    ●GNURXプロジェクト及びICCRXプロジェクトでC++のコンストラクタが実行されないと思われる不具合を修正中
     Amazon FreeRTOSとしては重要事項では無いと思っていますがFITのBSPとしては望ましくないように思ったからです
     ICCRXプロジェクト用にアセンブラソースを追加しますが現状はビルド環境未構築なのでエラーが出るかも知れません
    ●以前に報告したGNURXプロジェクト及びICCRXプロジェクトでユーザモードへ遷移出来ないと思われる不具合を修正中
     Amazon FreeRTOSとしては重要事項では無いと思っていますがFITのBSPとしては望ましくないように思ったからです
     処理を同じにしたいのでCC-RXでもchg_pmusr()は使用せずに以下の追加関数(デバッグ中)を使用します

    /***********************************************************************************************************************
    * Function name: R_BSP_Change_PSW_PM_to_UserMode
    * Description  : Switches to user mode.
    *                The CC-RX's inline asm function generates no code for prologue and epilogue.(★要確認★) On the other hand,
    *                the GNURX and the ICCRX may generate such kind of code for prologue and epilogue. So, in case of
    *                the CC-RX, this tricky function is defined here in C source file. On the other hand, in case of
    *                the GNURX and the ICCRX, the function is defined in other Assembler source files.
    * Arguments    : none
    * Return value : none
    ***********************************************************************************************************************/
    #if BSP_CFG_RUN_IN_USER_MODE==1
    #if defined(__CCRX__)
    R_PRAGMA_INLINE_ASM(R_BSP_Change_PSW_PM_to_UserMode)
    void R_BSP_Change_PSW_PM_to_UserMode(void)
    {
    ;_R_BSP_Change_PSW_PM_to_UserMode:
        mvfc    psw, r1     ; get the current PSW value
        btst    #20, r1     ; check PSW.PM
        bne.b   1f
    ;_psw_pm_is_supervisor_mode:
        pop     r2          ; pop the return address value of caller
        bset    #20, r1     ; change PM = 0(Supervisor Mode) --> 1(User Mode)
        push.l  r1          ; push new PSW value which will be changed
        push.l  r2          ; push return address value
        rte
    ;_psw_pm_is_user_mode:
    1:
        ;rts
    }
    #endif /* defined(__CCRX__) */
    #endif /* BSP_CFG_RUN_IN_USER_MODE==1 */

    作業中(進行中)
    ●3コンパイラ対応のBSPの取り込み作業中に気掛かりだった箇所の修正や思い浮かんだ改良案の試行
    ●GNURXプロジェクトでのIスタック/Uスタック(今回未使用)のサイズ指定方法の見直し(r_bsp_config.hで指定したい)
    ●GNURXプロジェクトでもCC-RXプロジェクト同様にRAMの先頭256バイトを空けるようにする

    作業中(少し後回し)
    ●コンパイル時のワーニングを減らす

    [追記]

    あぁ、FITのR_BSPはCC-RXの場合でもC++のコンストラクタが実行されない(以下が無い)のか、、、 どう直そう、、、

    resetprg.c(FITではない通常のCC-RXのスタートアップルーチンのもの)

    //  _CALL_INIT();                   // Remove the comment when you use global class object

    以上です。

  • In reply to NoMaY:

    NoMaYさん

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

    ありがとうございます。以下のように進めたいと考えています。
    情報が出てきましたら、適宜ここで報告いたします。

    ・bsp_ram_initialize()を_INITSCT()や__iar_data_init2()の後に実行する意図
    ・R_NOP()の意図
    ⇒開発元に確認します

    ・GR-SAKURAのGNURXプロジェクトで割り込み/例外/リセットのベクタ関連の致命的ミスに気付いたので一緒に修正中
    ・GNURXプロジェクト及びICCRXプロジェクトでC++のコンストラクタが実行されないと思われる不具合を修正中
    ・以前に報告したGNURXプロジェクト及びICCRXプロジェクトでユーザモードへ遷移出来ないと思われる不具合を修正中
    ⇒了解しました。
     C++に関しては確かに現時点でCC-RX用のリファレンスコードでもコメントアウトですね。
     意図、方針等を確認してみます。

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

    Amazon FreeRTOSとはターゲットユーザが異なりますが、Arm社がMbed Linux OSなるものを発表したようです。まだ詳細は公開されていないようで、ベータテスト参加者を募集中のようです。IntelのGalileoやEdisonのArduinoのようにLinux上にMbed OSのAPIを実装したものなのか、TOPPERS SafeGのようなハイパーバイザー(SafeGはハイパーバイザーより簡素なのでデュアルOSモニタと呼ぶようですが)にMbed OSとLinux OSの2つを載せたものなのか、それとも、もっと違った実装なのかな???

    Introducing Arm Mbed Linux OS
    os.mbed.com/blog/entry/Introducing-Arm-Mbed-Linux-OS/

    Mbed Linux OS
    A free Linux distribution re-imagined for IoT
    os.mbed.com/linux-os/

    [追記]

    ベータテスト参加者募集のところのHardware platformを見ると以下の機種がラインナップされていました。

    Raspberry Pi
    Raspberry Pi 3
    WaRP7

    [参考]

    Intel Galileo Arduino
    www.arduino.cc/en/ArduinoCertified/IntelGalileo

    TOPPERS SafeG
    www.toppers.jp/safeg.html

    [余談]

    TOPPERS開発者会議2018というところで「アマゾンウェブサービスジャパン株式会社 園田 修平」という方の「AWSとFreeRTOS(仮題)」」(もしくは「AWSとIoT(仮題)」)というタイトルのゲストトークがあるようです。(会議への参加募集は締め切られています。) 将来、TOPPERSもAWSに繋げるライブラリを作ったりとか???

    TOPPERS開発者会議2018 開催概要
    www.toppers.jp/devconf2018.html
     

  • In reply to NoMaY:

    NoMaYさん

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

    新鮮な情報ありがとうございます。
    Cortex-A向けの技術ですね。RZ/A2Mなどで動作させるのが良いと感じます。
    私は主にはRXマイコンの活動をしているので、本件にはアンテナ張ってませんでした。
    RZ/A2Mチームと会話をしてみたいと思います。

    Introducing Arm Mbed Linux OS
    os.mbed.com/blog/entry/Introducing-Arm-Mbed-Linux-OS/

    ブログ記事イントロ部分をざっとまとめました。

    ---
    mbed ファミリの新しいソフト、Mbed Linux OSをリリース。(2018/10/17)

    我々は組み込み機器開発において以下のような課題に直面している。
    1. 多くの装置は無人操作が必要。リモート操作や暗所などに設置された装置を優れた費用対効果の運用でカバーしなければならない。
    2. 多くの製品はセンシティブなデータを扱うためセキュア(データ保護と実行状態の完全性)である必要がある。
    3. 多くの開発はタイトなスケジュールで行われる。このため「中核事業」の本質ではないプラットフォーム部分の調達が必要であり、そこに多くのコストと妥協が含まれていた。(中核事業に関わる開発を阻害していた)

    これら課題を解決するため、多くの時間を以下のようなプラットフォーム開発に割く必要があった。
    1. 3-5年は維持されるであろうプラットフォーム(商用ソフトまたはOSS)を探す
    2. 作りたい製品に合わせてフットプリントを最適化する
    3. ソフトウェアアップデートのメカニズムを作り込む

    これらプラットフォームは製品仕様からは見えないが、継続的なメンテナンスが必要であり、新しい製品開発時にはプラットフォーム自体を新しいものに置き換えていくことも必要であった。
    これらは不可欠な活動だが新製品開発のためのリソースを一定割合で削り取ってしまっており、各チームはいつもこの活動を強いられ、商業的にも良くない状況を生んでいた。
    様々なアンケートでもこれらは「現実のIoT開発者が抱える課題」として表れている。

    Mbed Linux OSこれら課題を解消することができる。(以下技術紹介)
    ---

    TOPPERSもTCP/IPスタックを作っているので、AWS連携を考えるのも当然の流れかもしれませんね。
    いよいよ組み込み用OSもTCP/IPを抱える世の中になってきたのだと実感します。

    以上です

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