タグ「Ｃ言語」を含む投稿［86件］ - 電装工芸日記 - 舞台照明機器の製作とか -

　Nim はＣ言語でやれることを全て出来るのに凄くシンプルな…

Sun, 14 Jun 2026 20:36:32 +0900

　Nim はＣ言語でやれることを全て出来るのに凄くシンプルな記述です。Python と同じではないけど近い感覚で書けるのがいいですね。
　中間言語的にＣ言語に吐き出(トランパイル)してから gcc などでバイナリまで作る構成ですが、Ｃ++ や JavaScript にもトランスパイル出来るのだそうです。Ｃ++ も JavaScript も知らない自分にとってはＣ言語として保存出来るならそれでいいのですけどね。
　Ｃ言語を経由するのでＣ言語を知っていた方がいいみたいです。Ｃ言語で作れる低レイヤー(ハードウェアにより近い部分)の処理を Python みたいな記述で比較的簡単に書けることがメリットですが、途中でＣ言語になるのですからそれを知らずに使えるかと問われればどうなんでしょう。Ｃ言語の概念が刷り込まれてしまった私の脳ミソではそれを外した評価など出来ません。
　今日勉強していた内容ではポインタの概念が必要でした。Ｃ言語の要素の中で最も理解し難いと言われるポインタです。わかってしまえば大したことではなく、私の場合は長く書いてきた PIC16 のアセンブラに置き換えながら抽象化の意味を探ってみたら解決しましたが、アセンブラの概念が無い人にポインタをわかってもらう説明ってどうやったらいいんだろうって考えるとなーんにもイメージ出来ませんでした。
　他人に Nim を教えようなんて思ってもいませんが、Ｃ言語を全く知らずに低レイヤーのプログラミングをするのは無茶だと思った今日の休憩時間でした。
　Nim と共にＣ言語の勉強も継続した方が良さそうです。Rust の世界からは退場することにします。

#Nim #Ｃ言語 -- Posted by 電装工芸〔713文字〕

　Nim のことを少しかじってみましたがイイですね。

Wed, 10 Jun 2026 10:25:16 +0900

　Nim のことを少しかじってみましたがイイですね。
　普及率が低い言語なので情報が少ないですし、個人レベルのコミュニティで開発されているので配布やメンテが突然終わってしまうかもしれませんが、Ｃ言語に変換してから gcc でコンパイルするってのがいいですね。Nim で書けなくなってもＣ言語としては残るのです。今やＣ言語は古代語みたいな存在感ですが、私が生きている間に消え去ることは無いでしょう。扱える言語として残せるなら問題なかろうと思います。
　それにも増して、初めて眺めた Nim のコードが何となく読めることがイイです。自分が勉強したのは Python3、Ｃ言語(ANSI)、Rust ですが、Pythonに他の言語の方言が少しずつ混じったと思えば済んでしまいそうです。変数の型指定が必須の Python と思えばいいようです。
　コード書きで飯を食おうなんて思っていませんし、自分で組んだハードウェアを動かすことが目的ですので、Nim の普及率が低くても問題はありません。少ない学習コストで短期間で書けるならそちらの方にメリットがあります。もちろん、RaspberryPi でも使えます。
　AI/Geminiさんにお聞きしたところ、コンパイルには注意が必要っぽいです。コンパイルにはデバックレベルとリリースレベルがありますが、リリースレベルは最適化が強いので、デバックレベルでは動いたコードがリリースレベルでは動かないことがあるそうです。これはメモリキャッシュに代表される挙動の違いらしいので、この辺りをキチンと追い込む必要はありそうです。
　何にしても、Python 並みに書きやすく読みやすく、Ｃ言語で出来ることはほぼ100%実現可能で、Ｃ言語やＣ＋＋並みの速度で動くなら願ったり叶ったりです。

追記
　Nim の教科書をポチりました。明日入荷だそうです。
　まずは読んでみましょう。

#Nim #Ｃ言語 -- Posted by 電装工芸〔812文字〕

　「Nim(ニム)」と呼ばれるプログラム言語があるそうな。

Wed, 10 Jun 2026 07:57:03 +0900

　「Nim(ニム)」と呼ばれるプログラム言語があるそうな。
　Python に近い書き方でＣ言語並みの速度が出るそうな。
　Nim のコードをＣ言語に変換してから gcc でコンパイルする構成で、Python をＣ言語に変換する Cython が進化したような立ち位置らしい。
　Rust の勉強をしていますが自分の中に妙な違和感があります。嫌いって程じゃないのですがナンか違うなと。
　面白そうなので Nim の勉強もしてみます。

#Nim #Ｃ言語 -- Posted by 電装工芸〔227文字〕

　Rust の教科書は「所有権」や「ライフタイム」で大騒ぎし…

Thu, 07 May 2026 06:18:59 +0900

　Rust の教科書は「所有権」や「ライフタイム」で大騒ぎしないモノがいいようです。大騒ぎする教科書はその厄介さを語って力尽きるのか「とどのつまり？」の説明が薄い傾向にあります。両方とも重要なことですが、これらが Rust の全てではありません。「cargo」と呼ばれるプロジェクト管理ツールを説明しない教科書は論外です。
　間違っても初めてのプログラム言語に Rust を選ぶのはお勧めできません。最終的に作りたいモノによりますが、html や Python あたりで成功体験を積み重ねて神エンジニアたちが目指したことを体に取り入れるのが良いと思います。Rust はＣ言語同様に理解するための前提というか基礎の裾野が広すぎるのです。
　私は回路設計とプログラミングの境界が曖昧な PIC16 で右往左往してきましたので脳ミソが少しおかしいのですが、Ｃ言語もそうですが、Rust を受け入れるにはこのコードでハードウェアが何をするかをイメージ出来るといいようです。両言語ともハードウェアを制御する傾向が強いからでしょうか。

#器具の製作 #Ｃ言語 #Rust -- Posted by 電装工芸〔480文字〕

　Art-Net 関連品の開発では「Rust」を使うことにし…

Tue, 05 May 2026 18:53:06 +0900

　Art-Net 関連品の開発では「Rust」を使うことにしました。
　Rust が持つ標準機能が Art-Net 関連品を作るのに絶大に有益なことがわかったからです。コレクションと呼ばれる機能です。
　新たな言語を勉強するのは大変ですが、Ｃ言語の方言と思えばゼロベースではありません。Ｃ言語を学んだことで Rust がすんなり自分の中に入ってくる実感があります。Rust を学ぶためにＣ言語を勉強するベキ！？ってことでもありますが、案外そんなもんかなと感じています。Ｃ言語でも Rust でもコードの裏側にあることは同じってことですかね。ハードウェアを動かすのがソフトウェアですから。
　あまりに便利なので Python みたいに遅くねーの？って疑問はありますが、コンパイルされたバイナリはＣ言語やＣ＋＋に匹敵するらしいのでその評価を信じましょう。
　言葉は優しいですが、AI/Geminiさんのお言葉を要約するなら基板を作ってPIC16アセンブラを書いて RaspberryPi と協調動作する装置を作る素人(アマチュア)は斜め上過ぎる存在らしいです。私にとっては日常感覚ですケド、その延長かプログラム言語に対するアプローチも少し変みたいです。私からしたらパチンコやスロットで確率数値を操って常に勝ち続けてる人の方がどうかしてますケド。

#器具の製作 #Ｃ言語 #Rust -- Posted by 電装工芸〔589文字〕

　DMX-Timer は終わりが見えてきました。次の課題はA…

Tue, 05 May 2026 15:34:40 +0900

　DMX-Timer は終わりが見えてきました。次の課題はArt-Net 関連機器と行きたいところです。
　これらは RaspberryPi 上でのプログラミングが主となりますが言語どうするか。Ｃ言語か Rust の二択ですけど、未だに迷っております。この２種はハードウェアを扱うのに適した言語ですから Art-Net 関連機器を組むにはよいと思われます。両方を使いこなせればいいのですが、年齢的に一つでも辛いのに二つは無理。。。少し前までＣ言語でいくつもりで勉強していましたが、 Rust の教科書を斜め読みしたところ自分がやりたいことには Rust が向いているような気がして困っているワケです。
　Rust の情報に接しますと「所有権がぁ、所有権がぁ」と脅しの様に書かれております。これはＣ言語での「ポインタがぁ、ポインタがぁ」や、Ｃ＋＋での「オブジェクト指向がぁ、がぁ」と同じです。身に着けないと使えないし身に着ければよりよいコードが書けるのですから身に着ければいい。簡単でないことは確かですが、言語をデザインした神エンジニアたちは苦労や混乱をさせたかったワケではありません。たぶん。
　開発には心の余裕とまとまった時間が必要です。なかなかそんな時間は取れませんので、引き続き妄想しながら勉強をしましょう。

#Ｃ言語 #Rust -- Posted by 電装工芸〔569文字〕

　AI/Geminiさんに聞いたところ、RaspberryP…

Thu, 12 Mar 2026 19:15:58 +0900

　AI/Geminiさんに聞いたところ、RaspberryPiでは4byte単位、4kB単位でキリ良く考えるとストレスが少ないのだそうな。1byte単位のデータでも4byteで扱った方が良いってことです。
　パディング対策して詰め々々がイイって話を振ってきたのもGeminiさんですが、知識のある年寄りに時間を開けて話を聞いた時のような困惑を感じたりしたり。。。

追記
　4byte、64byte、4096byte区切りでメモリを扱う様に構造体などを定義すると良いのだそうです。更に、構造体のメモリ上のアドレスをアトリビュートで64の倍数値にするのもお勧めとのこと。
　4byteはCPUのレジスタの長さ、64byteはキャッシュの転送単位、4096byteはメモリページの扱い単位です。
　気にしなくても動きますが、CPUやOSの挙動において無駄を省くことに繋がるらしいです。

#Ｃ言語 -- Posted by 電装工芸〔397文字〕

　Ｃ言語の共用体(union)ですが、教科書やら動画を見ます…

Thu, 05 Mar 2026 06:26:33 +0900

　Ｃ言語の共用体(union)ですが、教科書やら動画を見ますと「あまり使い道が無い」的な解説が多いような気がします。
　されど、今回のArt-Net系の装置では便利です。Art-Net のポート番号 0x1936(6454) の受信値をとりあえず突っ込むだけで要素毎に取り出すことも出来るからです。例えば ArtDMX は530バイトのパケットですが、受信値を uint8_t[530] (または unsigned char[530]) の配列として保存するだけで ArtDMX の構造体としても扱えます。パディングに注意は必要ですが、便利に使えると思うのです。ID、OpCode、ProVer をまとめて評価するのに先頭12バイトを uint8_t[12] としておいて memcmp で判別することも出来ます。AertDMX と別種の Art-Net パケットもシームレスに扱えそうです。
　天才を超越した神たちが何故 union を作ったのかを考えるとワクワクします。

　とまぁ、最近Ｃ言語の理解が進んで一人笑いが止まらないアホの戯言でした。

　オレメモです。
　gccで構造体のパディングを回避する書き方。struct に続いて「__attribute__((__packed__))」を入れるそうな。gcc独特の書式らしいので、コンパイラに合わせた書式を使ってください。

typedef struct __attribute__((__packed__)) {
　uint8_t ID[8];
　uint8_t OpCode[2];
　uint8_t ProVerHi;
　uint8_t ProVerLow;
　uint8_t Sequence;
　uint8_t Physical;
　uint8_t SubUni;
　uint8_t Net;
　uint8_t LengthHi;
　uint8_t Length;
　uint8_t Data[512];
} ad_t;

ad_t ad_data;

　ArtDMXを保存する構造体はこんな感じに書けばよいのでしょう。たぶん。
　この型を sizeof で見て530バイトならヨシです。

　ついでに共用体の定義(案)です。

// Art-Netの受信値を収める構造体
typedef struct __attribute__((__packed__)) {
　uint8_t resv[530];
} an_t;

// ArtDMXを取り出す構造体
typedef struct __attribute__((__packed__)) {
　uint8_t ID[8];
　uint8_t OpCode[2];
　uint8_t ProVerHi;
　uint8_t ProVerLow;
　uint8_t Sequence;
　uint8_t Physical;
　uint8_t SubUni;
　uint8_t Net;
　uint8_t LengthHi;
　uint8_t Length;
　uint8_t Data[512];
} ad_t;

// Art-Netの受信値を保存する共用体ループバッファ
union {
　an_t an_resv;
　ad_t ad_data;
} an_stack[8192];

　こういうことでいいのかな？
　共用体の書き方はまだよくわかってないのですけど。

　共用体の配列を作って Art-Net のポートで受信したパケットを延々と保存します。8191番まで記録したら0に折り返すループバッファです。
　8192個あれば44fps、８センダー、各16ユニバースで最短でも1.45秒分の保存が出来るハズです。十進数で8192なのは２進数(16進数)でキリの良い数値のため折り返し評価が少ない処理で出来るからです。十進数8192は16進数0x2000でキリがよく処理しやすいのです。このあたりはアセンブリ言語だけでPICマイコンと会話をしてきた者にとって自然な着想です。10進数は人が日常的に使い慣れているだけで特筆するほど合理的な数体系ではありませんし、今どきのコンピュータ(論理回路)に合わせた方が便利です。

　ヘッダーチェックは当該の配列要素(例えば an_stack[1024] )を示すポインタからmemcmpで12バイトをチェックすれば済みますので共用体には定義しません。
　ArtDMX以外のパケットにも使えるチェック方法です。

#Ｃ言語 -- Posted by 電装工芸〔1896文字〕

　先日の現場はヒマな時間が長かったのでＣ言語の教科書を読みま…

Mon, 02 Mar 2026 15:51:50 +0900

　先日の現場はヒマな時間が長かったのでＣ言語の教科書を読みまくってみましたがかなり整理出来ました。
　昨今の教科書はポインタの説明が丁寧です。ハードウェアとしてのメモリの動作がアタマに入っていないと分かり難いことですが、私はPICのアセンブラで普通に扱ってきたことなので改めてではありますが素直に理解出来ました。わかってしまえばむしろ便利だなと。変数の読み書き方法が何種類もあることになるので混乱すると思いますが、どれもメモリへのアクセス手段だと捉え直せばいいだけでした。このあたりが整理できるとmmapも自然に理解出来ます。
　ヘッダーファイルはコピペでテキトウに書いていましたが、意味と書き方が整理できました。後はmakefileが整理出来れば良さそうです。

#Ｃ言語 -- Posted by 電装工芸〔338文字〕

　Art-Net 切替＆パッチマシンを作るためにＣ言語を勉強…

Wed, 18 Feb 2026 15:59:50 +0900

　Art-Net 切替＆パッチマシンを作るためにＣ言語を勉強しなおしています。AI/Geminiさんから学んだことですが、Ｃ言語はいわゆる高級言語(PythonやJAVAなど)ではなくアセンブリ言語の一つと捉えて教科書を読み直したところわかるわかる、すっげーわかる。なんだ簡単じゃねーかってくらいです。高級言語ほど抽象化されていないけれど、「機械としてのコンピュータ」を操っている感じが強いのにマシンコード(PIC16アセンブリしか知りませんが)を直にさわる時ほどレジスタやメモリに気を配らなくてもいい。途方もなく膨大で広大なライブラリの世界を網羅するのは不可能ですが、基本的なライブラリを使ったＣ言語として定義された基本書式はPIC16アセンブリのちょっと上くらいです。もちろん、CPUは何をやっているのか、メモリとは何のためにあるのか、I/Oっちゃ何よって基本機構をわかっている必要はありますけど。
　教科書は買い直しました。所有しているのは2008年執筆が一番新しいのですが、20年近く経って書式が変わってきているようです。例えば1バイトを表すcharはint8_tとも書けるようです。コンパイルが通るならば古くても新しくてもいいのですが、どうせならこれからの書式に慣れた方がいいかなと思うのです。
　アセンブリ言語は愚直にベタに書くモノだと思っています。10年後の自分が楽しんで読める内容にしたいですね。

#Ｃ言語 -- Posted by 電装工芸〔612文字〕

　猛烈に忙しかった一か月でしたが、落ち着いてきたのでＣ言語の…

Tue, 17 Feb 2026 07:07:53 +0900

　猛烈に忙しかった一か月でしたが、落ち着いてきたのでＣ言語の勉強を再開しています。
　データ蓄積の話です。変数と呼ばれる入れ子に数値を代入して一時保存するのが普通のやり方です。ですが、その実体はメモリに保存するに他なりません。
　Ｃ言語は「高級アセンブリ言語」と呼ばれることもあり、派生の歴史はマシンコードが違うハードウェア間でソフトウェアの移植性を高めることにあったとか。AI/Geminiさんとやりとりをしてわかってきたことですが、Ｃ言語はソフトウェアを書きやすくするのとは少し違った方向性のようです。Pythonの様な言語に慣れてしまうと「どうしてこうなのか？」「不便だな」と思うことが多々ありますが、アセンブリ言語として捉えると「こりゃ便利だ」と思えます。この感覚はアセンブリ言語を書いたことがないとピンと来ないことかもれませんが、ハードウェアは何をしているのか、ＯＳは何をしているのか、コンパイラは何をしているか、この辺りをイメージ出来るとＣ言語の書式の意味が見えてくるように思います。
　変数はメモリ領域を確保しインデックス(ステータス・メタ情報)を関連付けることで成立します。確保しただけのメモリ領域を「Raw」とも呼ぶそうですが、「Raw」のアドレスを示すのがポインタです。変数という作法(インデックス)を使って読み書きしてもいいのですが、ポインタというメモリアドレスで直接読み書きすることも出来るようです。私が知るアセンブリ言語はPIC16のそれしかありませんが、変数とはどういう機構なのか？を理解出来るとポインタのイメージをすんなり受け止められました。typedefも「オレ専用の型」作っておくClassみたいな作法だと思えば自然と理解。
　ここまできたところ、構造体(Structure)と共用体(Union)の違いや使い方もすんなり理解。どちらもメモリ領域を確保してインデックスを関連付けることは同じですが、共用体は複数のインデックスを関連付けることが出来ることが違う。Art-NetでDMXのデータを扱うArtDMXパケットは受信した際は530バイトのバイナリですが、その何バイト目がどんな意味のデータかとなるので、同じデータ群であっても530バイトのバイト配列であったり構造体であったりするので、共用体として保存するが適当ぢゃないかと思ってきたところです。
　mmapも意味や作法がイマイチわからなかったのですが、Ｃ言語の深堀り出来てきた気がしています。

#Ｃ言語 -- Posted by 電装工芸〔1047文字〕

　ちょっと忙しい１月です。

Mon, 19 Jan 2026 08:34:13 +0900

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

#Ｃ言語 -- Posted by 電装工芸〔911文字〕

　珍しく年末年始休みですが、いざとなると暇すぎ。

Thu, 01 Jan 2026 16:02:09 +0900

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

#[Art-Net] #Ｃ言語 -- Posted by 電装工芸〔112文字〕

　最近、現場の合間に「POSIX(ポジックス)」の勉強をして…

Sun, 14 Dec 2025 10:57:54 +0900

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

#Ｃ言語 -- Posted by 電装工芸〔169文字〕

　Art-Net切替器の構成メモ

Sat, 27 Sep 2025 09:50:42 +0900

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

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

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

#器具の製作 #[Art-Net] #Ｃ言語 -- Posted by 電装工芸〔1407文字〕

　ChatGPT に Art-Net を受信するC言語のコー…

Tue, 24 Jun 2025 06:48:40 +0900

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

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

#Ｃ言語 #AI -- Posted by 電装工芸〔504文字〕

　現地照明でしたが、シュートが終わったらバラシまで待機という…

Sat, 14 Jun 2025 22:44:01 +0900

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

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

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

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

#[Art-Net] #器具の製作 #Ｃ言語 -- Posted by 電装工芸〔1034文字〕

　Ｃ言語のポインタには面白い機能(使い方？)がありました。

Tue, 10 Jun 2025 22:39:25 +0900

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

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

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

#Ｃ言語 #雑記 -- Posted by 電装工芸〔1257文字〕

　現場ですが、簡単なひな壇を組むだけの現地道具なので終演まで…

Tue, 10 Jun 2025 17:53:28 +0900

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

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

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

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

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

#[Art-Net] #器具の製作 #Ｃ言語 -- Posted by 電装工芸〔959文字〕

　子プロセスを使う場合は親プロセスが落ちたらこれらも落とさな…

Tue, 10 Jun 2025 07:22:53 +0900

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

#Ｃ言語 -- Posted by 電装工芸〔190文字〕

　Art-Netの扱いにアイデアを一つ。

Sat, 07 Jun 2025 06:21:33 +0900

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

#[Art-Net] #Ｃ言語 -- Posted by 電装工芸〔999文字〕

　しばらく前に書いた Art-Net を扱うコードです。

Fri, 06 Jun 2025 12:59:08 +0900

　しばらく前に書いた Art-Net を扱うコードです。
　今だったらこうするのにってところは多いですが、これをたたき台にしようかなと。
　表示の都合で一部の文字を全角にしています。コピペしてお使いになる際はご注意ください。オレオレライブラリーやオレオレヘッダーが必要なのでこのソースだけでは動きませんけど、要点の参考になれば幸いかと。

/*　--------------
　　Art-Net Engine
　　ae_main.c
　　-------------- */

// 汎用ライブラリをインクルード
#include
#include
#include
#include
#include
#include
#include
#include
#include
//#include
//#include

// 自作ライブラリをインクルード
#include "ae_main.h"
#include "std_inkey.h"
#include "std_dump.h"

// Main
int main( int argc, char *argv〔〕 ) {
　　// 汎用変数
　　// int i ;
　　// int ret = 0 ;
　　// 共有メモリ変数
　　ae_sharemem_t *ae_sharemem ;
　　int ae_sharememsize = sizeof( ae_sharemem_t ) ;
　　int ae_sharememID ;
　　//【開発用】共有メモリ領域の確保上位モジュールが出来たらそちらで作る
　　ae_sharememID = shmget( IPC_PRIVATE, ae_sharememsize, SHM_R|SHM_W ) ;
　　// 共有メモリ定義
　　ae_sharemem = shmat( ae_sharememID, 0, SHM_R|SHM_W ) ;
　　// nsec時変数
　　struct timespec now ;　　　　　　　　　　　 // 現在POSIX時を得る構造体
　　unsigned long long int start_nsec ;　　　　 // 処理開始nsec時を保存
　　//【開発用】処理時間変数
　　unsigned long long int lap_nsec ;　　　　　 // 処理終了nsec時
　　static unsigned long long int max_nsec = 0 ; // 経過したnsecの最大値
　　// Art-Net 受信変数
　　int an_rx ;　　　　　　　　　　　　　　　　 // 受信socket番号
　　struct sockaddr_in an_rx_addr ;　　　　　　 // 受信先指定構造体
　　int an_rx_length ;　　　　　　　　　　　　　// recvfromで得たデータ長
　　char an_rx_nic〔〕 = { "eth0" } ;　　　　　　 // 受信NICの名称
　　char an_rx_buf〔 ADMX_BUF_SIZE 〕 ;　　　　　 // 受信バッファ ArtDMXの最大バイト長で設定
　　socklen_t an_rx_sin_size = ADMX_BUF_SIZE ;　// recvfromに渡す受信バッファサイズ
　　struct sockaddr_in an_rx_from_addr ;　　　　// 送信元情報の構造体
　　artdmx_t artdmx_rx ;　　　　　　　　　　　　// 受信したArtDMXを保存する構造体
　　// Art-Net 送信変数
　　int an_tx ;　　　　　　　　　　　　　　　　 // 送信socket番号
　　struct sockaddr_in an_tx_addr ;　　　　　　 // 送信先指定構造体
　　char an_tx_nic〔〕 = { "eth1" } ;　　　　　　 // 受信NICの名称
　　int yes = 1 ;　　　　　　　　　　　　　　　 // 送信をブロードキャストに設定する際のフラグ変数
　　artdmx_t artdmx_tx〔 ADMX_TX_UNIVRESES 〕 ;　 // 送信するArtDMXを保存する構造体配列
　　char an_tx_buf〔 ADMX_BUF_SIZE 〕 ;　　　　　 // 送信バッファ Art-DMXの最大バイト長で設定
　　int an_tx_count = 0 ;　　　　　　　　　　　 // 送信ユニバースカウンタ
　　unsigned long long int an_tx_nsec = 0 ;　　 // 送信nsec時を保存
　　float an_tx_fps = 29.97 ;　　　　　　　　　 // 送信フレームレート
　　unsigned int an_tx_interval =
　　　　　　( unsigned int )( 1e9 / ADMX_TX_UNIVRESES / an_tx_fps ) ;

　　// Art-Netの受信ソケットを作成
　　an_rx = socket( AF_INET, SOCK_DGRAM, 0 ) ;　　　　　　　　　　　　　// 受信ソケットのインスタンスを作成
　　setsockopt( an_rx, SOL_SOCKET, SO_BINDTODEVICE,　　　　　　　　　　 // 受信NICを指定する
　　　　　　　　&an_rx_nic, sizeof( an_rx_nic ) );
　　an_rx_addr.sin_family = AF_INET ;　　　　　　　　　　　　　　　　　 // 受信をUDPに設定
　　an_rx_addr.sin_port = htons( AN_PORT ) ;　　　　　　　　　　　　　　// 受信ポート番号を設定
　　an_rx_addr.sin_addr.s_addr = INADDR_ANY ;　　　　　　　　　　　　　 // 送信元アドレスを無指定にする
　　bind( an_rx, ( struct sockaddr * ) &an_rx_addr,　　　　　　　　　　 // 上記をインスタンスに設定する
　　　　　　　　　　sizeof( an_rx_addr ) ) ;
　　// Art-Netの送信ソケットを作成
　　an_tx = socket( AF_INET, SOCK_DGRAM, 0 ) ;　　　　　　　　　　　　　// 送信ソケットのインスタンスを作成
　　an_tx_addr.sin_family = AF_INET ;　　　　　　　　　　　　　　　　　 // 送信をUDPに設定
　　an_tx_addr.sin_port = htons( AN_PORT ) ;　　　　　　　　　　　　　　// 送信ポート番号を設定
　　an_tx_addr.sin_addr.s_addr = inet_addr( "255.255.255.255" ) ;　　　 // 送信先アドレスを無指定にする
　　setsockopt( an_tx, SOL_SOCKET, SO_BINDTODEVICE,　　　　　　　　　　 // 送信NICを指定する
　　　　　　　　&an_tx_nic, sizeof( an_tx_nic ) ) ;
　　setsockopt( an_tx, SOL_SOCKET, SO_BROADCAST,　　　　　　　　　　　　// 送信をブロードキャストに設定
　　　　　　　　( char * )&yes, sizeof( yes ) ) ;
　　// std_inkey 用変数
　　int key_code_length = 0 ;
　　int key_code_length_st = 0 ;
　　char key_code〔 32 〕 = { 0x00 } ;
　　char key_code_st〔 32 〕 = { 0x00 } ;
　　// std_inkey を開始
　　set_inkey( SET ) ;

　　// ***** Art-Netの受送信と表示 *****
　　printf( "\e〔2J\e〔?25l" ) ;　　　　　　　　 // 画面を消去カーソル非表示　\e〔?25l カーソル非表示
　　while( strcmp( key_code, _KEY_F12 ) != 0 ) {
　　　　// ------ 開始nsec時を取得 ------
　　　　clock_gettime( CLOCK_REALTIME, &now ) ;　　　　　　　　　　 // 現在POSIX時間値取得
　　　　start_nsec = ( unsigned long long int )now.tv_sec * 1e9　　 // unsigned long long int型(8バイト長int)変数に
　　　　　　　　　　 + now.tv_nsec ;　　　　　　　　　　　　　　　　// 取得値をひとまとめにする(nsec)

　　　　// --------- キー入力 ----------
　　　　key_code_length = get_inkey( key_code ) ;　　　　　　　　　 // キー入力を取得
　　　　if( strcmp( key_code, "\x20" ) == 0 ) max_nsec = 0 ;　　　　//【開発用】キー入力が〔SP〕なら実行時間計測の最大値をクリア
　　　　if( key_code_length > 0 ) {　　　　　　　　　　　　　　　　 // キー入力を別関数に渡すためのスタック
　　　　　　key_code_length_st = key_code_length ;
　　　　　　memcpy( key_code_st, key_code, sizeof( key_code ) ) ;
　　　　}

　　　　// --------- 受信 -----------
　　　　memset( an_rx_buf, 0, ADMX_BUF_SIZE ) ;　　　　　　　　　　　　　　　　　　　　 // 受信バッファのクリア
　　　　an_rx_length = recvfrom( an_rx, an_rx_buf, ADMX_BUF_SIZE, MSG_DONTWAIT,　　　　 // an_rx_from_addrには送信元情報が入る
　　　　　　　　( struct sockaddr * )&an_rx_from_addr, &an_rx_sin_size ) ;
　　　　// 受信がある場合
　　　　if( an_rx_length > 0 ) {　　　　　　　　　　　　　　　　　　　　　　　　　　　　// an_rx_lengthは受信値のバイト長
　　　　　　// 送信元IPアドレスとポートを抽出し、構造体artdmx_rxに保存
　　　　　　inet_ntop( AF_INET, &an_rx_from_addr.sin_addr,　　　　　　　　　　　　　　　// 受信データから送信元IPアドレスを抽出保存
　　　　　　　　　　　　artdmx_rx.senderip, sizeof( artdmx_rx.senderip ) ) ;
　　　　　　strcpy( artdmx_rx.senderip, inet_ntoa( an_rx_from_addr.sin_addr ) ) ;
　　　　　　artdmx_rx.senderport = ntohs( an_rx_from_addr.sin_port ) ;　　　　　　　　　// 受信データから送信元ポートを抽出保存
　　　　　　artdmx_rx.recv_nsec = start_nsec ;　　　　　　　　　　　　　　　　　　　　　// 受信日時を保存
　　　　　　// 受信したArtDMXをデコード
　　　　　　if( artdmx_decode( an_rx_buf, &artdmx_rx ) >= 0 )　　　　　　　　　　　　　 // ArtDMXなら送信スタックに保存
　　　　　　　　memcpy( &artdmx_tx〔 artdmx_rx.universe 〕,　　　　　　　　　　　　　　　 // ArtDMX以外なら読み飛ばし
　　　　　　　　　　　　&artdmx_rx, sizeof( artdmx_t ) ) ;

　　　　　　//【開発用】終了nsec時を取得
　　　　　　clock_gettime( CLOCK_REALTIME, &now ) ;　　　　　　　　　　　　　　 // 現在POSIX時間値取得
　　　　　　lap_nsec = ( unsigned long long int )now.tv_sec * 1e9　　　　　　　 // unsigned long long int型(8バイト長int)変数に
　　　　　　　　　　　　+ now.tv_nsec - start_nsec ;　　　　　　　　　　　　　　// 取得値をひとまとめにする(nsec)
　　　　　　if( max_nsec < lap_nsec ) max_nsec = lap_nsec ;　　　　　　　　　　 // ここまでの最大処理時間を得る

　　　　}

　　　　// --------- 送信 -----------
　　　　else if( start_nsec - an_tx_nsec > ( unsigned int )( an_tx_interval ) ) {
　　　　　　artdmx_encode( an_tx_buf, &artdmx_tx〔 an_tx_count 〕 ) ;　　　　　　 // 送信データをエンコード
　　　　　　sendto( an_tx, an_tx_buf, ADMX_BUF_SIZE, MSG_DONTWAIT,　　　　　　　// 送信実行
　　　　　　　　　　( struct sockaddr * )&an_tx_addr, sizeof( an_tx_addr ) ) ;
/*
　　　　　　//【開発用】終了nsec時を取得
　　　　　　clock_gettime( CLOCK_REALTIME, &now ) ;　　　　　　　　　　　　　　 // 現在POSIX時間値取得
　　　　　　lap_nsec = ( unsigned long long int )now.tv_sec * 1e9　　　　　　　 // unsigned long long int型(8バイト長int)変数に
　　　　　　　　　　　　+ now.tv_nsec - start_nsec ;　　　　　　　　　　　　　　// 取得値をひとまとめにする(nsec)
　　　　　　if( max_nsec < lap_nsec ) max_nsec = lap_nsec ;　　　　　　　　　　 // ここまでの最大処理時間を得る
*/
　　　　　　//【開発用】受信データの表示
　　　　　　artdmx_check_disp( &artdmx_tx〔 an_tx_count 〕,　　　　　　　　　　　 // 送信データの仮表示
　　　　　　　　　　key_code_st, &key_code_length_st, &lap_nsec, &max_nsec ) ;
　　　　　　// 送信事後処理
　　　　　　an_tx_nsec = start_nsec ;　　　　　　　　　　　　　　　　　　　　　 // 送信インターバル・次回用のnsec取得
　　　　　　if( ++an_tx_count > 7 ) an_tx_count = 0 ;　　　　　　　　　　　　　 // 送信ルートカウンタインクリメント
　　　　}
　　　　// 待ち時間無駄にループしても処理負荷が増えるだけなので少しお休み
　　　　usleep( 1 ) ;
　　}
　　// --------- 終了 ----------
　　set_inkey( RESET ) ;　　　　　　// std_inkeyを終了
　　close( an_rx ) ;　　　　　　　　// 受信ソケットをクローズ
　　close( an_tx ) ;　　　　　　　　// 送信ソケットをクローズ
　　printf( "\e〔?25h\e〔0m\n" ) ;　　// コンソール画面を戻す \e〔?25h カーソルの表示
　　shmdt( ae_sharemem ) ;　　　　　// 共有メモリの切り離し
　　//【開発用】上位モジュールが出来たらそちらで処理する
　　shmctl( ae_sharememID, IPC_RMID, 0) ; // 共有メモリ領域開放
　　return 0 ;
}

// ArtDMXのデコード関数
int artdmx_decode( char *an_rx_buf, artdmx_t *artdmx_rx ) {
　　int i ;
　　char int_st〔 sizeof( int ) 〕 ;
　　// IDを抽出
　　for( i = 0; i < 8; i++ ) {　　　　　　　　　　　　　// bufの先頭から８バイト
　　　　artdmx_rx->id〔 i 〕 = an_rx_buf〔 i 〕 ;　　
　　}
　　// OpCodeを抽出
　　int_st〔 0 〕 = an_rx_buf〔 8 〕 ;
　　int_st〔 1 〕 = an_rx_buf〔 9 〕 ;
　　int_st〔 2 〕 = 0x00 ;
　　int_st〔 3 〕 = 0x00 ;
　　artdmx_rx->opcode = *( ( int * )&int_st〔 0 〕) ;
　　if( ! (strcmp( artdmx_rx->id, "Art-Net" ) == 0　　　　　// ArtDMXかチェックし、そうでなければエラーを返して終了
　　　　　　　　&& artdmx_rx->opcode == 0x5000 ) ) {
　　　　return -1 ;
　　}
　　// ProVerを抽出
　　int_st〔 0 〕 = an_rx_buf〔 11 〕 ;
　　int_st〔 1 〕 = an_rx_buf〔 10 〕 ;
　　int_st〔 2 〕 = 0x00 ;
　　int_st〔 3 〕 = 0x00 ;
　　artdmx_rx->prover = *( ( int * )&int_st〔 0 〕) ;
　　// Sequenceを抽出
　　artdmx_rx->sequence = an_rx_buf〔 12 〕 ;
　　// Physicalを抽出
　　artdmx_rx->physical = an_rx_buf〔 13 〕 ;
　　// Universeを抽出
　　artdmx_rx->subnet = an_rx_buf〔 14 〕 / 0x10 ;
　　artdmx_rx->universe = an_rx_buf〔 14 〕 % 0x10 ;
　　artdmx_rx->net = an_rx_buf〔 15 〕 ;
　　// Lengthを抽出
　　int_st〔 0 〕 = an_rx_buf〔 17 〕 ;
　　int_st〔 1 〕 = an_rx_buf〔 16 〕 ;
　　int_st〔 2 〕 = 0x00 ;
　　int_st〔 3 〕 = 0x00 ;
　　artdmx_rx->length = *( ( int * )&int_st〔0〕) ;
　　// Dataを抽出
　　for( i = 0; i < artdmx_rx->length; i++ ) {
　　　　artdmx_rx->data〔 i 〕 = an_rx_buf〔 i + 18 〕 ;
　　}
　　if( artdmx_rx->length < 512 ) {
　　　　for( i = artdmx_rx->length; i < 512; i++ ) {
　　　　　　artdmx_rx->data〔 i 〕 = 0x00 ;
　　　　}
　　}
　　return 0 ;
}

// ArtDMXのエンコード関数
int artdmx_encode( char *an_tx_buf, artdmx_t *artdmx_tx ) {
　　int i ;
　　// IDを設定
　　for( i = 0; i < 8; i++ ) {
　　　　an_tx_buf〔 i 〕 = artdmx_tx->id〔 i 〕 ;
　　}
　　// OpCodeを設定
　　an_tx_buf〔 8 〕 = (char)( artdmx_tx->opcode % 0x100 ) ;
　　an_tx_buf〔 9 〕 = (char)( artdmx_tx->opcode / 0x100 ) ;
　　// ProVerを設定
　　an_tx_buf〔 10 〕 = (char)( artdmx_tx->prover / 0x100 ) ;
　　an_tx_buf〔 11 〕 = (char)( artdmx_tx->prover % 0x100 ) ;
　　// Sequenceを設定
　　an_tx_buf〔 12 〕 = (char) artdmx_tx->sequence ;
　　// Physicalを設定
　　an_tx_buf〔 13 〕 = (char) artdmx_tx->physical ;
　　// SubUniを設定
　　an_tx_buf〔 14 〕 = (char)( artdmx_tx->subnet * 0x100 + artdmx_tx->universe ) ;
　　// Netを設定
　　an_tx_buf〔 15 〕 = (char)artdmx_tx->net ;
　　// Lengthを設定
　　an_tx_buf〔 16 〕 = (char)( artdmx_tx->length / 0x100 ) ;
　　an_tx_buf〔 17 〕 = (char)( artdmx_tx->length % 0x100 ) ;
　　// Dataを設定
　　memcpy( an_tx_buf + 18, artdmx_tx->data, 512 ) ;
　　return 0 ;
}

// ArtDMXのチェック用画面表示
int artdmx_check_disp( artdmx_t *artdmx, char *key_code_st, int *key_code_length_st,
　　　　　　　　　　unsigned long long int *val1, unsigned long long int *val2 ) {
　　// 汎用変数
　　//int i ;
　　// タイムカウント変数
　　struct timespec now ;　　　　　　　　　　　　　 // 現在POSIX時を得る構造体
　　unsigned long long int now_nsec ;　　　　　　　 // 現在nsecを保存
　　static unsigned long long int prev_nsec = 0 ;　 // 過去nsecを保存
　　// データ管理用
　　static artdmx_t artdmx_disp ;
　　// std_dump 用変数
　　static int first_line = 0 ;　　　　　　　　　　 // 表示開始行数
　　// 表示制御変数
　　struct winsize ws ;
　　static int col = 20 ;
　　static int row = 100 ;
　　static int net = 0 ;
　　static int subnet = 0 ;
　　static int universe = 0 ;

　　// カーソルキー入力
　　if( *key_code_length_st > 0 ) {
　　　　if( strcmp( key_code_st, _KEY_RIGHT ) == 0 ) {
　　　　　　if( ++universe > 7 ) universe = 7 ;
　　　　}
　　　　if( strcmp( key_code_st, _KEY_LEFT ) == 0 ) {
　　　　　　if( --universe < 0 ) universe = 0 ;
　　　　}
　　　　if( strcmp( key_code_st, _KEY_UP ) == 0 ) {
　　　　　　first_line-- ;
　　　　}
　　　　if( strcmp( key_code_st, _KEY_DOWN ) == 0 ) {
　　　　　　first_line++ ;
　　　　}
　　　　*key_code_length_st = 0 ;
　　}
　　// 対象ユニバースのデータをスタック
　　if( ( artdmx->net == net ) && ( artdmx->subnet == subnet ) && ( artdmx->universe == universe ) ) {
　　　　memcpy( &artdmx_disp, artdmx, sizeof( artdmx_t ) ) ;
　　}

　　// タイムカウント
　　clock_gettime( CLOCK_REALTIME, &now ) ;　　　　　　　　　　　　 // 現在POSIX時間値取得
　　now_nsec = ( unsigned long long int )now.tv_sec * 1e9　　　　　 // unsigned long long int型(8バイト長int)変数に
　　　　　　　　+ now.tv_nsec ;　　　　　　　　　　　　　　　　　　 // 取得値をひとまとめにする(nsec)
　　if( now_nsec - prev_nsec < 5e7) return -1 ;　　　　　　　　　　 // 経過時間が不足なら何もせずリターン
　　prev_nsec = now_nsec ;　　　　　　　　　　　　　　　　　　　　　// 過去nsecを現在値としておく
　　// 画面のテキスト表示サイズを取得
　　ioctl(STDOUT_FILENO, TIOCGWINSZ, &ws) ;　　　　　　　　　　　　 // 画面サイズを取得幅=ws.ws_col 高=ws.ws_row
　　if( row + 4 > ws.ws_row ) row = ws.ws_row - 4 ;　　　　　　　　 // dumpの行数制限
　　// artdmxを表示
　　printf( "\e〔0;0H" ) ;　　　　　　　　　　　　　　　　　　　　　　　　　 // カーソルを左上に　
　　printf( "Sender: %s:%d", artdmx_disp.senderip, artdmx_disp.senderport ) ;
　　printf( "\e〔28GID: %s", artdmx_disp.id ) ;
　　printf( "\e〔41GOpCode: 0x%04X", artdmx_disp.opcode ) ;
　　printf( "\e〔57GProVer: 0x%04X", artdmx_disp.prover ) ;
　　printf( "\e〔0K\nSequence: 0x%04X", artdmx_disp.sequence ) ;
　　printf( "\e〔19GPhysical: 0x%04X", artdmx_disp.physical ) ;
　　printf( "\e〔37GLength: %d", artdmx_disp.length ) ;
　　printf( "\e〔50G< Net:%d SubNet:%d Universe:%d >\e〔0K\n", artdmx_disp.net, artdmx_disp.subnet, artdmx_disp.universe ) ;
　　dump_print( artdmx_disp.data, artdmx_disp.length, col, row, &first_line, 0 ) ;
　　printf( "%8lld /%8lld nsec", *val1, *val2 ) ;
　　//fflush( stdout ) ;
　　// 終了
　　return 0 ;
}

#[Art-Net] #Ｃ言語 -- Posted by 電装工芸〔12336文字〕

　今年も師走です。

Sat, 28 Dec 2024 15:55:20 +0900

　今年も師走です。
　現場は現地照明をもう１件やれば終わり。今期の年末年始は人並みにユックリ出来そうです。
　そんな時は机上の勉強を進めたいものです。物理的な加工や開発・設計ではなくお勉強。特にＣ言語の勉強です。
　一応書けるのですが、ポインタや構造体についてボンヤリしているところを整理したい。Art-Net関連には特に重要な基礎ですから抑えないといけません。

#Ｃ言語 -- Posted by 電装工芸〔187文字〕

　セマフォの使い方が見えたので構造の重要な要素は獲得出来まし…

Wed, 20 Nov 2024 19:25:06 +0900

　セマフォの使い方が見えたので構造の重要な要素は獲得出来ました。
　構成ですが、起動し mmap や pipe を定義し子プロセスの状態を監視する親プロセス「ArtNetPatch」、ユーザーの操作の相手やデータを画面表示をする子プロセス「ArtNetConsole」、Art-Netを送受信しパッチ処理やプロファイルカーブ処理を行う子プロセス「ArtNetEngine」の３本柱にしようと思います。
　子プロセスの生成は fork を使います。fork ならば mmap、pipe、semaqhoe を子プロセスに渡すのが楽です。メモリの消費は多くなるようですが、実体の複製ですからポインタ祭りにならずに済みます。メモリの消費が多いと言っても、私が作るソフトウェアの規模などたかが知れていますので RaspberryPiCM4 の８GBモデルなら楽勝でしょう。
　こういった構造は面倒な気もしますが、プロセス構造をシッカリ作っておけば開発が楽になると思いますし、何よりも「ArtNetEngine」の処理にリソースを集中したいのです。状態監視やユーザー相手は100msec毎で十分ですが、Art-Net の処理は5msec毎が欲しいのです。分散処理というより、求めるラップが違う処理を明確に分けたいのです。
　処理時間を意識してしまうのは PIC マイコンからのクセですが、RaspberryPiCM4 で８ユニバースのパッチ処理をするならダイエットが大事かと。

#[Art-net] #Ｃ言語 -- Posted by 電装工芸〔649文字〕

　ArtNet-Patch で共有メモリの mmap を使う…

Wed, 20 Nov 2024 18:00:29 +0900

　ArtNet-Patch で共有メモリの mmap を使うためにセマフォを勉強しています。mmap へのアクセスを排他的にするためです。
　ただ、プロセス間のセマフォを使うような人は上級者が多いのか解説ページを見てもわかりにくい。
　POSIX系のセマフォは物凄くシンプルな感じがしますが、とどのつまりがわからない。
　man もわかっている人向けなのか引数の記述があるだけ。
　もっと勉強です。

追記
　なんて愚痴っていたらよい記事がありました。
　開始が sem_init だったり sem_open だったりするけど、同じことみたいですからヘッダファイルのプロトタイプ記述を読めば良さそう。
「sem_overview - POSIX セマフォの概要」
「man-pages-ja sem_init(3)」
　次の記事は、パーミッションにおける umask のことが主題ですが、セマフォの使い方がよくわかる。シンプルな記述を示してくれるこんな記事が嬉しい。
「sem_openで、Permission denied になる」
　わかった気になった。

#[Art-net] #Ｃ言語 -- Posted by 電装工芸〔501文字〕