最近の記事

M5StickC Plus + FreeRTOSでLチカ

そろそろリアルなハードウェア上でFreeRTOSを動かしてみたくなったので、M5StickC Plusをポチった。M5StickC PlusにはXtensa LX6コアベースでWiFiやBLEがワンチップ化されたESP32マイコン(Espressif ESP32-PICO-D4)が搭載されている。標準の開発環境はArduinoかUIFlowだけど、FreeRTOS上に実装されているので、ArduinoのプログラムからFreeRTOS APIを直接叩くことができるのだ。もう少し

    • FreeRTOS: セマフォとミューテックス

      マルチタスクにおいて避けられない、タスク間の同期・排他制御プリミティブAPIであるセマフォ(Semaphore)とミューテックス(Mutex)について調べる。 セマフォ(Semaphore)と遅延割込み処理セマフォとは「手旗信号」のことであり、旗を上げる(up)と通ってよし、降ろす(down)と止まれという、タスクの流れを制御する仕組みのことである。これを使うことで複数タスクが同時に動作するとまずいクリティカルセクションの排他制御や、限りある資源へのアクセス制御(条件同期。

      • FreeRTOSの動作をLLDBで追っかける

        プログラムの動作を追うにはデバッガを使うのが手っ取り早い。ということでgdbを使おうと思ったら、コード署名しろというエラーが。おそらくこのgdbはbrewでインストールしたもののはず。ウェブを探すとコード署名する方法は見つかるが、いい機会なのでLLDBを使ってFreeRTOSの動作を追っかけてみる。正確にはPOSIXシミュレータなので、リアルなものとの違いはある。 (gdb) runStarting program: /Users/ryousei/Devel/FreeRTO

        • Efficient Scheduling Library for FreeRTOS

          前回、FreeRTOSのスケジューリングポリシは優先度付きラウンドロビンと書いたけど、これは意外だった。UNIXと変わらないじゃないかと。リアルタイムOSと言っているから、EDFとかRMとか実装しているのかと思ったけどそうでもない。スケジュール可能性とかどこへ行ったんだ? 単にフットプリントの小さな組込みOSということでみんな使っているのかな。 Rate Monotonic (RM)スケジューリング、つまり周期が短いタスクほど優先度を高くする、を実装するには、固定優先度のプ

        M5StickC Plus + FreeRTOSでLチカ

          FreeRTOS: スケジューリング

          前回に続きFreeRTOSネタで、タスクスケジューリングについて眺めてみよう。FreeRTOSはシングルプロセッサコアが対象なので、一度に一つのタスクしか動かない。タスクはUNIXで言うところのスレッドに近く独自のコンテキスト(要はレジスタセットに格納された値)とスタックを持つ。UNIXプロセスのように独自のアドレス空間は持たない。というか、そもそもカーネルもタスクもすべてが特権モード&単一アドレス空間で動作する。 次に実行すべきタスクを選択するのがスケジューラ。実際にタス

          FreeRTOS: スケジューリング

          FreeRTOSなるもの

          最近若い人の間でFreeRTOSが流行っていると聞いたので、少し調べてみた。FreeRTOSはAWSが買収したことでも注目を集めたが(もう3年も前か)、実装が簡単で扱いやすいと言うことで商用でも広く使われているようだ。ちなみにMicrosoftはThreadXを買収してAzure RTOSとしているし、GoogleやFacebookはLinux FoundationのZephyrを支援している(GoogleのFuchsiaはどうなった?)。クラウド事業者のIoT戦略の一つとし

          FreeRTOSなるもの

          macOSでもBCCで遊んでみたい

          eBPFプログラムを開発する一般的な方法はBCC (BPF compiler collection)を使うことである。Linux環境だとDockerで簡単に環境も構築できるが、今回はmacOS上に環境構築してみる。 macOSローカルでもBCCを動かして遊んでみるために、Vagrantスクリプトを公開している人がいたので、Ubuntuのバージョンを18.04から20.04にしてみた(vagrant-bcctools)。バックエンドはVirtualboxを使っている。BCC自

          macOSでもBCCで遊んでみたい

          データセンター向けTCPとeBPF実装

          最近のLinuxではeBPFで輻輳制御アルゴリズムを実装し、カーネル内で実行できる。今日はDCTCP実装を眺めてみたいと思う。その前にオリジナルのDCTCPについて確認する。マージされたのはバージョン3.17の頃。 commit e3118e8359bb7c59555aca60c725106e6d78c5ceAuthor: Daniel Borkmann <daniel@iogearbox.net>Date: Fri Sep 26 22:37:36 2014 +0200

          データセンター向けTCPとeBPF実装

          TCP-BPF: Linuxはマイクロカーネルの夢を見るか

          eBPFでcommit logを調べてみるといろいろと面白そうなものが出てくるな。例えば、TCP-BPF [netdev 2.2]。TCPコネクションのパラメータをBPFで操作できる。さらに最近(バージョン5.5以降)では、輻輳制御もeBPFで実装できるようになっているようだ。eBPFによりカーネルからどんどん機能を追い出してLinuxはマイクロカーネル化するのだという鼻息荒い発表も見かけるが(「eBPF - Rethinking the Linux Kernel」[QCon

          TCP-BPF: Linuxはマイクロカーネルの夢を見るか

          eBPFって何だろう

          eBPFには前々から興味があったので、ちょっと調べてみた。資料はいろいろある。日本語だと(会員登録が必要なので最後まで読めないが)「Berkeley Packet Filter入門」が詳しい。英語でよければ「BPF: Linux kernel code execution engine」とか。 eBPF以前オリジナルのBPF (Berkeley Packet Filter)が登場したのは90年代初頭で、tcpdumpに組み込まれているので知らずにお世話になっている人も多いか

          eBPFって何だろう

          Linux stack or BSD stack

          LinuxのTCP/IPスタックと*BSDのTCP/IPスタックどっちが優れているのかというのはよく出てくる質問で、探せばベンチマーク結果もいろいろ出てくるが、当然TCP/IPスタック以外のカーネル構造の違いも大きいので、apple-to-appleの比較は難しい。 ユーザベースではLinuxが圧倒的なのだろうけど、NetflixのCDNではFreeBSDが使われているのは有名(「Netflix and FreeBSD: Using Open Source to Deliv

          Linux stack or BSD stack

          RTT(Round Trip Time)推定

          RTTはその名の通り、送信元から送信先へ行って帰っての往復時間(ラウンドトリップ時間)のことで、TCPでは非常に重要なパラメータである。インターネット環境では他のトラフィックの影響を受けたり、経路が変わったりとRTTがばらつくのは当たり前であり、再送タイムアウトなどの計算にはRTTを平滑化したSmoothed RTT (SRTT)が使われる。​TCPの標準仕様であるRFC793によるとSRTTは以下の式から計算される。 R←αR + (1 - α)M Mは直近のRTTの計

          RTT(Round Trip Time)推定

          Time Sensitive Networkとか

          フィールドネットワークというかIoTの世界では、ここ数年Time Sensitive Network (TSN)が盛り上がっている。TSNの狙いは、端的に言うと、ITとOTのネットワークを融合することで、技術的にはEthernetベースで時間同期を保証できるネットワークを実現しようというものである。この辺でERTと交わりそうな話があるんだなという話を書きたいと思う。 commit 80b14dee2bea128928537d61c333f24cb8cbb62fAuthor:

          Time Sensitive Networkとか

          Earliest Departure Timeモデル

          バージョン4.20から導入されたEDTモデルについて。EDTの考えは前述したVan Jacobsonの「Evolving from AFAP: Teaching NICs about time」を見てもらうのが手っ取り早い。今まではNICに対して「何」を送るかしか指定しなかったが、「何」に加えて「いつ」送るかも指定すべきと言うのが基本的なアイデアだろうか。EDTの実装として、SIGCOMM17で発表されたCarousel(日本語で言うとメリーゴーランド)が例示されているけど、

          Earliest Departure Timeモデル

          TCPペーシング

          OSカーネルのコードを読むときに意識しておくべきことは、どのコンテキストで動作しているか。特にネットワークスタックやファイルシステムなど、IOに関係するときには重要で、初学者は見落としがちである。コンテキストには、システムコールの延長線上で実行されるプロセスコンテキストと、割り込みの延長で実行される(ハードウェア or ソフトウェア)割り込みコンテキストの2種類が存在する。 Linuxのネットワークスタックだと、ユーザコンテキストと割り込みコンテキストをつなぐデータ構造がQ

          TCPペーシング

          ソケットバッファとタイムスタンプ

          sk_buff構造体BSDのネットワークスタックで導入されたmbufが好きだ。ソースコードを読む醍醐味の一つが、実問題に対してどんなアルゴリズムやデータ構造を使って解こうとしているかにあるかと思っている。mbufを最初に知ったのは悪魔本だったかどうか記憶は曖昧だが、悪魔本とかStevensの詳解TCP/IP等を読んでなるほどよくできていると感心した。パケットはスタックの階層を行ったり来たりするときに、ヘッダを足したり引いたりする必要があるが、その際に無駄なメモリコピーを無くす

          ソケットバッファとタイムスタンプ