電装工芸日記
- 舞台照明機器の製作とか -
2025年6月14日の投稿［1件］
現地照明でしたが、シュートが終わったらバラシまで待機という名の休憩。直しとトラブルシュートに対応出来ればいいのでまとまった空き時間です。こんな時は設計という名の妄想が一番です。
課題は毎度おなじみ「ArtNetPatch」です。主にソフトウェアの構成が課題です。
受けたデータを一時保存、加工、出力しますので、機能は映像ストリーミングに近いかもしれませんが、自分のイメージはデータベースです。
その昔ファイルメーカーを母体に機材の稼働管理システムを作って今も使っていますが、データを動的に仕分けて加工する感覚が今回活用出来ています。
アルゴリズムと言えばそうなんですが、データを保管する構造体の設計が主な作業です。可能か不可能かを確認しながらになりますが、最終的にまとめる構造体が決まれば仕分けて加工するアルゴリズムはおのずと決まってくるので私にはこの感覚で進めるのが性に合っているようです。処理の全体像が見えてきました。
アセンブラではないので構想の段階で処理時間の見込みを付けることは難しいのですが、そもそもRaspberryPiのCPUにおけるマシンコードの動作速度はどうだと計算したら恐ろしい数字。ARMの2.4GHzですが、PICの感覚で単純計算したら１クロック当たりの時間は0.42nsec。PICに比べたら桁違いというか単位違い。OSを介するので単純には比べられないもののマシンコードのイメージで書けばかなり速くなりそう。例えば、積や商を求めるために四則演算をするかビットシフトをするかってことです。2倍や1/2などの2の乗数に関わる積や商ならビットシフトの方が速いハズです。この辺りが「C言語はアセンブラを汎用化したもの」ってイメージであり、Pythonとは違い、C言語はアセンブラの感覚で使うベシってのが私個人の感覚になりつつあります。出来るだけ単純な計算方法を目指してデータ構造を考えるのです。Ｃ言語の難解さがアセンブラ傾向のアプローチで軽くなった気分です。普通は逆なんでしょうけど。
Ｃ言語を作った神達はアセンブラをマクロ化して手間を減らすところから始まってますので、世代を経ても底辺はアセンブラなんでしょう。同時代のCOBOLやFORTRANは意味付けが違うようですけど。
勝手な妄想はともかく、どんなデータをどう変換・加工するかを明らかにすればおのずと見えてくるようです。
#[Art-Net] #器具の製作 #Ｃ言語
課題は毎度おなじみ「ArtNetPatch」です。主にソフトウェアの構成が課題です。
受けたデータを一時保存、加工、出力しますので、機能は映像ストリーミングに近いかもしれませんが、自分のイメージはデータベースです。
その昔ファイルメーカーを母体に機材の稼働管理システムを作って今も使っていますが、データを動的に仕分けて加工する感覚が今回活用出来ています。
アルゴリズムと言えばそうなんですが、データを保管する構造体の設計が主な作業です。可能か不可能かを確認しながらになりますが、最終的にまとめる構造体が決まれば仕分けて加工するアルゴリズムはおのずと決まってくるので私にはこの感覚で進めるのが性に合っているようです。処理の全体像が見えてきました。
アセンブラではないので構想の段階で処理時間の見込みを付けることは難しいのですが、そもそもRaspberryPiのCPUにおけるマシンコードの動作速度はどうだと計算したら恐ろしい数字。ARMの2.4GHzですが、PICの感覚で単純計算したら１クロック当たりの時間は0.42nsec。PICに比べたら桁違いというか単位違い。OSを介するので単純には比べられないもののマシンコードのイメージで書けばかなり速くなりそう。例えば、積や商を求めるために四則演算をするかビットシフトをするかってことです。2倍や1/2などの2の乗数に関わる積や商ならビットシフトの方が速いハズです。この辺りが「C言語はアセンブラを汎用化したもの」ってイメージであり、Pythonとは違い、C言語はアセンブラの感覚で使うベシってのが私個人の感覚になりつつあります。出来るだけ単純な計算方法を目指してデータ構造を考えるのです。Ｃ言語の難解さがアセンブラ傾向のアプローチで軽くなった気分です。普通は逆なんでしょうけど。
Ｃ言語を作った神達はアセンブラをマクロ化して手間を減らすところから始まってますので、世代を経ても底辺はアセンブラなんでしょう。同時代のCOBOLやFORTRANは意味付けが違うようですけど。
勝手な妄想はともかく、どんなデータをどう変換・加工するかを明らかにすればおのずと見えてくるようです。
#[Art-Net] #器具の製作 #Ｃ言語