電装工芸日記
- 舞台照明機器の製作とか -
No.1063
と、なると、って書き出しは私のアタマの中の言葉のままですが、プロセスかスレッドかはともかく、処理のスジを次の様に分けようかと。
１）アプリの起動部で、共有物を設定して以下のモジュールを呼ぶ「ap_main」
２）画面表示やユーザー操作を司る「ap_console」
３）Art-Netを受信する「ap_receiver」
４）受信値や設定値から出力値まとめ、Art-Net を出力する「ap_transmitter」
５）データのタイムアウト管理をする「ap_timeout」
大きなデータは共有メモリ「mmap」と「semaphore」でやりとりし、指示や返答は「queue」で繋げます。自分ナリに得手不得手を検討した結果です。
タイムアウトを別枠で勝手にやらせる発想が出たら役割分担が楽になりました。
これが出来るのも共有メモリとセマフォのオカゲです。
まだまだ決定ではありませんが、タイミングがラフなところはOS に任せてしまえ！って思えたら気が楽になったかも。
メモリ管理も処理タイミングの管理も OS に頼った方が間違いないのです。
この役割分担をしたら RaspberryPi でも処理しきれそうな気になってきたかも。
追記
成り行き任せで後回しにしても構わない処理はプロセスやスレッドを別にして区切りのいいところに短い「sleep」を入れればいい。こうすると OS のジャッジで急ぎと思われるプロセスやスレッドを優先的に処理をしてくれるようです。
厳密なタイミング管理が必要なら「RTOS」ベースのカーネルを使ってガチガチに管理するのが良いと思いますが、そこまででない処理のため導入の敷居が高い RTOS を使うのはどうかと。
#[Art-Net] #器具の製作
１）アプリの起動部で、共有物を設定して以下のモジュールを呼ぶ「ap_main」
２）画面表示やユーザー操作を司る「ap_console」
３）Art-Netを受信する「ap_receiver」
４）受信値や設定値から出力値まとめ、Art-Net を出力する「ap_transmitter」
５）データのタイムアウト管理をする「ap_timeout」
大きなデータは共有メモリ「mmap」と「semaphore」でやりとりし、指示や返答は「queue」で繋げます。自分ナリに得手不得手を検討した結果です。
タイムアウトを別枠で勝手にやらせる発想が出たら役割分担が楽になりました。
これが出来るのも共有メモリとセマフォのオカゲです。
まだまだ決定ではありませんが、タイミングがラフなところはOS に任せてしまえ！って思えたら気が楽になったかも。
メモリ管理も処理タイミングの管理も OS に頼った方が間違いないのです。
この役割分担をしたら RaspberryPi でも処理しきれそうな気になってきたかも。
追記
成り行き任せで後回しにしても構わない処理はプロセスやスレッドを別にして区切りのいいところに短い「sleep」を入れればいい。こうすると OS のジャッジで急ぎと思われるプロセスやスレッドを優先的に処理をしてくれるようです。
厳密なタイミング管理が必要なら「RTOS」ベースのカーネルを使ってガチガチに管理するのが良いと思いますが、そこまででない処理のため導入の敷居が高い RTOS を使うのはどうかと。
#[Art-Net] #器具の製作