🗐 電装工芸日記 - 舞台照明機器の製作とか -

今年は開発案件を進めたい

or 管理画面へ

タグ「C言語」を含む投稿[75件]

Icon of admin
 ちょっと忙しい1月です。
 仕事があるのは喜ばしいことですが、妄想は出来ても工作の実作業は出来ません。基本設計という名の妄想をしませんといけませんのである意味いいのですけどね。
 最近の妄想はGoogle検索よりもAIさんたちに聞くことで進めることが多くなりました。AIさんから結論をもらうというより代わりに検索してもらってレポートを頂戴する感じです。
 そんなやりとりの中で「C言語は高級アセンブリ言語である」という言葉がありました。ハードウェアを隠蔽してサービスに特化するいわゆる高級言語ではなく、ハードウェアに依存しないアセンブラ言語を示すってことらしいです。自分はハードウェアを動かすことに趣向が向いています。自分のベースはPIC16のアセンブラですが、書いているウチに「C言語はCPUにごとに違うアセンブラを汎用化して書きやすくしたモノだと思えば自分にとって自然だな」と感じていたので妙に納得した言葉です。
 何をしたいかによるので「C言語が絶対正義」とは思いませんが、昨今流行りのプログラム言語の大半はC言語を基礎としてして作られていますので原典とも言える存在です。高級言語を書いているとC言語が見え隠れしますので、C言語を知っていた方が理解し易いように思います。今どきの高級言語はC言語の方言と言ってもいいのかもしれません。自分はPIC16アセンブラの後にPython3に行ったのですが、むしろPythonだけを見て煮詰まったことがC言語を習得することで解決したように思います。高級言語とはC言語を楽に使うためのマクロ言語と捉えることが自然な気すらします。FORTRAN・COBOL・BASICなどのC言語と同時期に研究・開発された高級言語は少し違う感じがしますが、今主流の開発言語の大半はC言語の方言なのでしょう。
 私のように「物理的な物を作ること」に趣向を持つ方は少ないと思いますが、コンピュータはマシンコードで動くのですから、マシンコードを汎用的に表現するC言語はハードウェアを直接動かす存在なのでしょう。名前が似通ったC++やC#(C++++)はそれとは違った感じがしますけど。

#C言語
Icon of admin
 珍しく年末年始休みですが、いざとなると暇すぎ。
 ならばとAIのGeminiさんと会話。Art-Net機器の開発に関してです。ぶっちゃけChatGPTより頼もしい回答。色々解決しました。

#[Art-Net] #C言語
Icon of admin
 最近、現場の合間に「POSIX(ポジックス)」の勉強をしています。UNIX互換OSの標準仕様を定義したもので、OSや言語の仕様の基です。それぞれについて学ぶことも大切ですが、そもそもを知ることに意味はあります。たぶん最初からPOSIXを学んでも迷宮を彷徨うだけですが、ある程度わかってから読むと「なるほどぉ〜」が沢山です。

#C言語
Icon of admin
 Art-Net切替器の構成メモ
・マザーボード:EtherNet-Portを2つ、Wi-fiを1つ持つ RaspberryPi (CM4 + Dual Ether Boardなど)
・Ether Hub:ごく普通の EtherNet-Hub × 2
・NICの設定:OEMコードとMACアドレスからIPv4アドレスを定義しこれを基本アドレスとする
・ネットワークの構成:ネットワークはArt-Net切替器を挟んで卓側とノード側の2ゾーン構築する。この2ゾーンは全く同じ構成とする。Wi-fiは操作用のスマホやタブレットなどを接続するアクセスポイントとする。
・IPアドレスの工夫:手打ちやArtPollを用いてネットワーク上のArt-NetデバイスのIPアドレスを取得し、卓側ゾーンのArt-NetデバイスのIPアドレスをノード側ゾーンのエイリアスとして設定し、ノード側ゾーンのArt-NetデバイスのIPアドレスを卓側ゾーンのエイリアスとして設定する。

追記
 必要になりそうなコードをChatGPTに聞いたところそれらしいモノが出てきました。これで動いたらこの上なく便利ですね。雛形であってもChatGPTと10分もやりとりするだけで得られるのは生産性が無茶苦茶いい。IPアドレスのエイリアスを一覧の状態にするコードを尋ねたのですが自分ですべて書いたら何日かかったでしょう。
 こういった手段でC言語の関数ライブラリを増やしていけばいいのかもしれません。
 ただ、概要を理解して質問しないと求める答えに近づくには時間が掛かるようです。

追記の2
 「IPv4アドレスの配列から「0.0.0.0」と重複を削除する」とか
 「4バイトのchar配列からIPv4アドレスの文字列配列を作る」とか
 「IPv4アドレスの文字列配列から4バイトのchar配列を作る」などの一見地味だけど絶対必要になる処理は chatGPT で一発解決。先人が作った関数ライブラリがあれば簡単ですが、自作するには案外時間がかかったりする代物かもしれません。得られたコードを整理して関数ライブラリ化しヘッダーファイルまで作っておけば便利に使えそうです。この他にも使いそうなローレベルの関数を chatGPT に質問してコレクションしています。IPv4アドレスの一覧からIPアドレスのエイリアスをNICに定義する処理も得ましたが、Google検索だけで自作するには数週間かかったかもしれません。これは本当に凄い。Google検索で先人たちの成果を参考に書いていた時とやっていることは同じですが、より答えに近いところに短時間で到達出来るので生産性は良さそうです。別にC言語を身に着けたいのではなく、C言語でないと処理速度を確保出来ないから仕方なくC言語で書いているだけですからね。
 ただ、やってて思ったのですが、全体のアルゴリズムを chatGPT にまとめてもらうにはプロの設計さん並みの知識と説明力が必要かもしれません。求める結果と状況を適切な言葉で簡潔に表さないといけないからです。AIはこちらの求めていることを推測しようとしてくれますが、説明が足りなければ、AIからの提案を理解出来なければ、その先に進むことは出来ません。いや、無料で得られる範囲では限度があると思うべきでしょう。

#器具の製作 #[Art-Net] #C言語
Icon of admin
 ChatGPT に Art-Net を受信するC言語のコードを聞いたところ、これまでに勉強したことが簡潔にまとまったコードが出てきました。
 欲しいすべてが出て来るワケではありませんが、これはスゲー。
 出てきたコードを理解・評価するにはある程度の基礎が必要ですが、細かい質問にも丁寧に答えてくれますし、何よりもヘッダーファイルを読んだり検索しないと理解出来なかったライブラリ関数の使い方も詳しく解りやすく教えてます。Google 検索で先達の成果から学ぶのも大事だと思いますが、AIエージェントを検索と同じ感覚で使うのは効率的だと思った次第。
 アプリの製作代行まで求めるには質問の仕方を工夫して課金しなければならないでしょうけど、イメージとしては教科書から求める情報を抜き出してくれる補助ツールとして有効だなって感じ。

追記
 他にも重要となる処理を ChatGPT に聞きましたが簡潔でわかりやすいお答え。
 先達の書き込みはありがたいものの奇妙な応用を含めた物が多く知りたいことが読み取りにくいことがあります。
 シンプルな質問を心がければ AI はとても便利に使えそうです。

#C言語 #AI
Icon of admin
 現地照明でしたが、シュートが終わったらバラシまで待機という名の休憩。直しとトラブルシュートに対応出来ればいいのでまとまった空き時間です。こんな時は設計という名の妄想が一番です。

 課題は毎度おなじみ「ArtNetPatch」です。主にソフトウェアの構成が課題です。
 受けたデータを一時保存、加工、出力しますので、機能は映像ストリーミングに近いかもしれませんが、自分のイメージはデータベースです。
 その昔ファイルメーカーを母体に機材の稼働管理システムを作って今も使っていますが、データを動的に仕分けて加工する感覚が今回活用出来ています。
 アルゴリズムと言えばそうなんですが、データを保管する構造体の設計が主な作業です。可能か不可能かを確認しながらになりますが、最終的にまとめる構造体が決まれば仕分けて加工するアルゴリズムはおのずと決まってくるので私にはこの感覚で進めるのが性に合っているようです。処理の全体像が見えてきました。

 アセンブラではないので構想の段階で処理時間の見込みを付けることは難しいのですが、そもそもRaspberryPiのCPUにおけるマシンコードの動作速度はどうだと計算したら恐ろしい数字。ARMの2.4GHzですが、PICの感覚で単純計算したら1クロック当たりの時間は0.42nsec。PICに比べたら桁違いというか単位違い。OSを介するので単純には比べられないもののマシンコードのイメージで書けばかなり速くなりそう。例えば、積や商を求めるために四則演算をするかビットシフトをするかってことです。2倍や1/2などの2の乗数に関わる積や商ならビットシフトの方が速いハズです。この辺りが「C言語はアセンブラを汎用化したもの」ってイメージであり、Pythonとは違い、C言語はアセンブラの感覚で使うベシってのが私個人の感覚になりつつあります。出来るだけ単純な計算方法を目指してデータ構造を考えるのです。C言語の難解さがアセンブラ傾向のアプローチで軽くなった気分です。普通は逆なんでしょうけど。
 C言語を作った神達はアセンブラをマクロ化して手間を減らすところから始まってますので、世代を経ても底辺はアセンブラなんでしょう。同時代のCOBOLやFORTRANは意味付けが違うようですけど。

 勝手な妄想はともかく、どんなデータをどう変換・加工するかを明らかにすればおのずと見えてくるようです。

#[Art-Net] #器具の製作 #C言語
Icon of admin
 C言語のポインタには面白い機能(使い方?)がありました。
 関数の呼び出しをポインタ化するのです。なんのこっちゃ?って話ですねぇ~。
 ソースコードの大半はそのままに、条件分岐で関数を差し替えるイメージです。オブジェクト指向の一歩手前?
 もちろん、構造体を含む変数もポインタを介して差し替えられます。
 DMXの場合、受信中のスタックから読み出すことは避けなければなりません。パケットの中身に不整合が起こるからです。例えばアドレス100までは最新の受信内容、101以降は1フレーム前の受信内容や全てゼロになるのです。2スロット構成のアトリビュートがアドレス100と101にまたがったらよろしくないことが起こります。リトルエンディアンだったら目も当てられません。
 この対策は2つのスタックを交代しながら使います。片方は受信に、1フレーム前のデータを持ったもう片方を出力処理に使い、条件が整えば役割を交代するのです。この場合どちらをどちらに使うかをポインタで指定出来れば全体の処理はスマートになります。ピンと来る方が少ないのはわかっていますが、ソースコードを書く上ではとても合理的な方法です。今の常識からしたら万分の一の処理能力のハードウェアしかなかった時代にC言語をデザインした人は本当の天才だと思います。勉強すればするほど「天才」って言葉が身に沁みます。自分はその成果に甘えるだけで感謝々々です。

 C言語を学ぶ上でポインタは難解な要素の筆頭ですが、自分の様にアタマの半分がPICマイコンのアセンブラで占められている者には案外すんなりと理解出来ました。メモリのアドレスを直接扱う方法だからです。当初は高級言語でメモリのアドレスを直接扱うなんてイメージはありませんでしたので躓きましたが、C言語が値渡ししか出来ない(参照渡しが出来ない)ことも含めるとポインタは合理的であり、C言語は高級言語ではなく汎用化を目指したアセンブラ言語と思えばイイらしいと思った次第。正しくはなくても私にはこの理解が自然でした。

 自分は PC8001(PC6001)-BASIC → Z80アセンブラ(当時小学生、挫折しました) → (20年空いて) → PICアセンブラ → Python → C言語(今) と進んできました。小学生の時分に論理演算、16進数、2進数を本能に焼き付け、成果は出せずともZ80アセンブラに挑んだことが今に活きているようです。小学生当時、戦前産まれの父母は数百円の漫画本は買ってくれませんでしたが高価な技術書やその筋の雑誌(月刊マイコンやBASICマガジンなど)は買ってくれました。100歳まであと数年のカウントダウンなのに林業を生業とし登山やスキーを楽しむ父と米寿間近で父の3倍は元気な母に絶大な感謝をする今日この頃。
 自分の今の最大の不安は三途の川の向こう岸で父母をお迎えすることです。あと100年くらいは部下や後輩に迷惑をかけずに現役をやってやろうと思っていますけど(笑

#C言語 #雑記
Icon of admin
 現場ですが、簡単なひな壇を組むだけの現地道具なので終演までヒマです。
 ArtNetPatch の ap_transmitter の構造を構造体配列を元に整理したのですが、割り切って構成したら案外軽い処理になりました。メモリの節約など考えず、条件分岐や計算を出来るだけ減らし繰り返しをヒトまとめにする方針だからでしょうか。
 実際に組んで実行時間を計測しなければなりませんが、パッチ処理の後にもディレイやプロファイルカーブの処理を入れられそうな予感がします。

 receive(受信)、bind(入力ユニバースを内部Bus(ユニバース)にパッチ、ここで数値をマージしてHTPミキサーとします)、pre-delay、pre-profile-curve、patch、post-delay、post-profile-curve、transmit といった流れで考えています。

 ついてはモジュール構成を少し変えます。
 ap_transmitter の中の数値操作と Art-net の出力を分割します。
 fps はともかく、すべてのユニバースを連続して送るのは避けた方がいいかなと思うので、ユニバース毎にインターバルを持たせるためです。

1)アプリの起動部とし、共有物を設定して以下のモジュールを呼ぶ「ap_main」
2)画面表示やユーザー操作を司る「ap_console」
3)Art-Netを受信する「ap_receiver」
4)受信値や設定値から出力値をまとめる「ap_effect」
5)Art-Net を出力する「ap_transmitter」
6)データのタイムアウト管理をする「ap_timeout」

 今後はタイムラグを減らす工夫を考えてみましょう。
 出力の目標は 30fps 以上、出来れば 36fps ですが、1/36秒以内に処理を一巡出来るなら遅れても1フレームとなります。無理ならスレッド的なアプローチで考えて出来るだけ遅れを少なくしましょう。
 何にしても、試作をして処理時間と処理負荷の計測が必要です。
 こんな複雑なシステムは10回くらい書き直すつもりで試すしかありません。素人の私が結果を完全に予測するなんで無理ですもん。

#[Art-Net] #器具の製作 #C言語
Icon of admin
 子プロセスを使う場合は親プロセスが落ちたらこれらも落とさないといけません。ゾンビとして残ってしまうからです。
 一般的にはメインから「終わりにしなさい」って指示を受けて落としますが、開発途中ではそうもいかないことがあります。
 ならば、「続けなさい」って指令が無ければタイムアウトすることにしましょう。親の存在確認をする方法もありますが、この方法なら管理が楽かも。

#C言語
Icon of admin
 Art-Netの扱いにアイデアを一つ。
 送信元を識別するにはIPv4アドレスがキーになると思います。運が悪くなければ送信元毎にユニークなハズです。これの扱い。

 IPv4アドレスは4バイト長(32bit)で構成され、文字列で表しても7~15文字です。
 これを一つの整数にまとめてしまうアイデアです。一般的にint型は4バイト長ですから、丸めてしまえばint型にしても情報は欠落しません。
 こうすれば、4つの数字や7~15文字のテキストよりも扱いが簡単で軽くなると思うのです。IPアドレスとしての情報は別途残すとして、識別IDにこれを使うのです。
 ユニバースも同じ考え方でいいでしょう。15bit長ですからshort型でも収まりますが、噂に聞くところではint型の方が処理が軽いらしいのでこの型にしておこうかなと。
 この両者を合わせた8バイトのlong型もしくはLongLong型を併記しておいてもいいかもしれません。なぜこの様なことを考えるかと言いますと、複数のユニバースを保管する配列から特定のものを探し出す処理を軽くしたいからです。処理の方針にもよりますが、受信したものを一旦スタックして一定の時間間隔で取り出そうというのが今の考え方ですので、クエリに相当するインデックスを作るのは当然としてもキーワードが簡素なことは重要だと思うのです。一定の時間間隔で作れらたLoop配列ならばその並びが時間情報となりますので、Delay を求めても受信日時と現在日時を比較する必要がありません。

 Art-Netのモニターも兼ねたいので、使う使わないはともかく、受信したデータを全て一時保管するつもりです。
 かといってモニターのための保管とパッチのための保管を別々にするのは気に入らないので、受信をすべて保管してそこから必要なモノを取り出したいのです。
 仮に、送信元8、それぞれ8ユニバースとするなら、最大44fpsとして1秒間に2,816件のスタックをしなければなりません。1パケット当たりのデータ長は540バイトくらいですから1.5MB/秒くらいです。2秒分のスタックをしても3MBです。動画の1フレーム当たりのデータ長は640x480の16bitカラーで1.8MBくらいですので55MB/秒です。動画に比べたらArt-Netの情報量は余裕っしょ。

#[Art-Net] #C言語

■思ってみた

新年あけましておめでとうございます
本年もよろしくお願いいたします

編集

■全文検索:

複合検索窓に切り替える

■複合検索:

  • 投稿者名:
  • 投稿年月:
  • #タグ:
  • カテゴリ:
  • 出力順序:

■日付検索:

■カレンダー:

2026年1月
123
45678910
11121314151617
18192021222324
25262728293031

■カテゴリ:

■最近の投稿:

最終更新日時:
2026年1月19日(月) 08時34分13秒