日時：2018年6月16日(土) 10:00 〜 17:00
場所：東京都中央区日本橋大伝馬町
講師：名古屋大学 高田 広章 氏、李 奕驍 氏、TECS WG 小南 靖雄 氏
ETロボコンには参加していないのですが、今年もTOPPERSセミナーに参加させていただきました。名古屋からいらしている先生方は前日のTOPPERSカンファレンス2018からの連投ですね。 😀
2011年、2015年と同様のTOPPERSセミナーに参加させていただいているので今年で３回目ですね。TOPPERSやRTOSの最新動向の情報収拾を兼ねて今回も参加させていただきました。また mruby on EV3RT + TECS のセッションも勉強させていただきました。深くて難しい組み込みの世界。処理が間に合う、間に合わないは悩まし問題ですね。 🙁
いつものように会場でつらつらとTwitterにつぶやいていた内容を掲載させていただきます。私の感想や聞き間違いも混じっていますのでお許しください。 😉
TOPPERS ETロボコン向けセミナー 会場はこちらです。 #etrobo pic.twitter.com/CEvloJ6PEd
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
製品分野、産業分野ごとに応用ドメインが異なる。ネットワーク通信一つとっても、直接インターネットに繋がるのかLoWPANで繋がるのか、繋がり方は様々。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
たとえば自動車向けのプラットフォーム "AUTOSAR" はプラットフォームだけでなく開発環境のバックエンドなどより広い範囲で共通化を試みている。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
時間の『予測可能性』 ： システムを動かさなくても実行時間がわかる。モダンなMPUはキャッシュ機能などがあるため予測可能性は難しい。しかしながら動かしてみるまでわからない、間に合わない、では（システムによっては）困る。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
TOPPERSにmrubyを実装した当初はGC(ガベージコレクション)で時々、時間制約が守れなくて困った。時間制約が守れないと倒立制御が間に合わずに倒れてしまう… ? #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
ストレージ（HDDやSSDなど）がないシステムでファイルシスエムをサポートするOSを使うのは冗長。汎用コンピュータと（一般的な）組み込みシステムの違うところ。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
組み込みシステムは単目的であることが多い。目的が限定されていて、ファームウェアの書き換えもメーカーがバージョンアップすることが多いため『保護のための機能』は必ずしも必須ではない。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
(組み込み)Linuxではデバイスドライバーなどを取り外した最小構成でも１メガバイト程度のフットプリントになってしまう。しかしRTOSでは数十キロバイト程度に収めることも可能である。サイズに随分と違いがある。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
OS(汎用OSとRTOS)のAPIの境界線。システムの発展の歴史の影響？ コンピュータメーカとユーザの責任分担がそのままOSとユーザアプリの境界になっている。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
『OS』という呼び方は汎用OSとの誤解から避ける傾向。『カーネル』、『リアルタイムカーネル』という呼び方をする場合が多いです。TOPPERSでも『カーネル』と読んでいます。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
日常生活におけるスケジュールは「いつ」、「なに」をするか。マイコンの世界においては「いつ」、「どの」タスクを実行するか決めること。ちなみに(一般的な)RTOSでは未来の計画は立てていない。刻一刻と次に何を実行するかを決めているのが「スケジューリング」機能 #toppers #etrobo
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
TOPPERSでは『スケジューリング』と『ディスパッチ（タスク切り替え）』が同時（一続き）に実行されるわけではない。スケジューリングだけ先に実行して（割り込み処理が終わってから）ディスパッチが実行される、などの振る舞いがあります。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
『プリエンティブ』 先取り機能。実行中の処理を保留して別の処理が割り込んで（先取りして）実行される。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
プリエンプティブな処理は日常生活では『鳴っている電話をとる』に例えられるのでは？ それまでやっていた仕事を脇に置いて、電話を取る、こんな振る舞いがRTOSにおける『プリエンプティブ』です。 #toppers #etrobo
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
パソコンの場合はどちらの処理を急ぐか？必ずしも明確ではない。どっちを先にやるなんてユーザーにもOSにも決められないことが多い。一方で組み込みシステムでは優先して先に実行するべきことが決まっている（ことが多い） #toppers #etrobo
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
RTOS。時間制約を解決するためにスケジューリングやプリエンプトという仕組みを使って解決する。 #toppers #etrobo
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
『実行状態(RUNNING)』や『実行可能状態(REDY)』 ITRON(TOPPERS)では、こういう呼び方をしますがOSによって呼び方がまちまち（不統一）です。用語よりも内容を理解してください。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
RTOSではループ（繰り返し、ポーリング）で待つのは好ましくない。ループを実行している間、そのタスクが走り続けて、別のタスクを実行することができない。だから『待ち状態(waiting)』をつかうべき。 #toppers #etrobo
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
（グローバルな共有データ）整数１個を複数のタスクから読み書きする程度なら排他制御は不要。しかしながら複雑なデータ構造を読み書きするのであれば排他制御は必須。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
『処理Aはxx秒』、『処理Bはyy秒』と各々の処理の制約時間を決めて処理が一巡する時間をきっちり決めて（設計して）作る方法もあります。ただ、柔軟性に劣るためRTOSのタスクに分割して作る方が多い（設計が簡単）でしょうね。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
RTOSをつかったシステム開発 => 時間制約を持った多重処理システムの開発が容易になる！ #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
『RTOS』はプロセッサの多様性・依存性を隠蔽してくれる『プロセッサのデバドラ（デバイスドライバ）』と捉えることもできます。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
RTOSのデメリット。タスクのスタックエリアのメモリ消費。カーネル本体のワークエリアよりもタスクをいくつも作った時に各々のタスクごとに必要となるスタックエリアがメモリサイズを押し上げる。 #toppers #etrobo
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
RTOSのタスクを細かく分割すると「きれいな」設計になってように見えたりしますが、あまり分割を進めすぎるとオーバヘッドが大きくなって期待通りに動かなかったりしますから気をつけましょう！ #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
「プリエンプトされても実行順序は後回しにならない」同一優先度であればプリエンプトされても後回しにされない。一方で待ち状態から実行可能状態になったタスクはFCFSのルールに従い同一優先度のタスクの中で一番最後に実行される。うーん、仕様書の記述は厳密だけで面倒ですね。? #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
ITRONのシステムコールは（もっぱら）前３文字と後３文字の連結で命名しています。「いま仕様をつくるならフルスペルで書きますが…」 by 高田先生。関数名などの長さに制約があった時代の名残ですね。 ? #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
TOPPERSでは可変長メモリ管理(malloc)を必要とするときはライブラリを使ってください。というスタンスです。メモリフラグメンテーションの課題があるためOSには可変長メモリ管理機能を含めませんでした。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
ustreamが使えなくなったので今回のセミナーはYouTubeで配信されているのですが、私のアカウントからYouTubeを開くと「フロントメモリー」と「小松奈菜」で溢れる事態発生。 ?
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
TOPPERS ETロボコン活用セミナーは休憩中です。次は小南さんによる『mruby on EV3RT+TECSを使ったアプリ開発環境』です。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
mrubyのスクリプトはmrubyのバイトコードに変換されて、さらにC言語（の配列）に変換されてEV3RTに読み込まれる。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
1ミリ秒でほぼ処理が完了している。しかし稀（数十秒の処理の中で）に４ミリ秒を超えて６ミリ秒程度、処理にかかっていることがある。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
2018年度版 デカタイヤ にあわせて mruby on EV3RT+TECS ではバックラッシュキャンセル処理を追加しています。バックラッシュキャンセル処理の強度はデフォルトで４。ロボットの個体差に合わせて調整してください。０はバックラッシュキャンセル無効。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
Bluetoothを介したプログラム（mrubyのバイトコード）転送では稀に失敗することがあるので注意しましょう。PC側はデータを送り切ったと判定し（多分送り切っている？）、一方でEV3側が全てのデータを最後まで受信できずにデッドロックに陥るケースがあります。 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
会場からの質問「応答が遅れる原因はわかっていますか？」 小南さん「いろいろな原因を探っていますが、まだわかっていません」 #etrobo #toppers
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日
newlib.cのメモリアロケータはメモリをたくさん消費する（メモリが豊富なシステムが前提） TLSFメモリアロケータはリアルタイム性があり小さなメモリでも効率的にメモリをアロケートできるので今回EV3/RTに採用した。 #toppers #etrobo
— Takehiko YOSHIDA (@chihayafuru) 2018年6月16日