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

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

or 管理画面へ

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

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

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

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

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

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

#C言語
Icon of admin
 C言語の共用体(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 を作ったのかを考えるとワクワクします。

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

 オレメモです。
 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、8センダー、各16ユニバースで最短でも1.45秒分の保存が出来るハズです。十進数で8192なのは2進数(16進数)でキリの良い数値のため折り返し評価が少ない処理で出来るからです。十進数8192は16進数0x2000でキリがよく処理しやすいのです。このあたりはアセンブリ言語だけでPICマイコンと会話をしてきた者にとって自然な着想です。10進数は人が日常的に使い慣れているだけで特筆するほど合理的な数体系ではありませんし、今どきのコンピュータ(論理回路)に合わせた方が便利です。

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

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

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

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

#C言語
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言語

■思ってみた

陽が伸びて暑さを感じるようになってきました。

編集

■全文検索:

複合検索窓に切り替える

■複合検索:

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

■日付検索:

■カレンダー:

2026年5月
12
3456789
10111213141516
17181920212223
24252627282930
31

■カテゴリ:

■最近の投稿:

最終更新日時:
2026年6月3日(水) 15時33分11秒