電装工芸日記
- 舞台照明機器の製作とか -
タグ「Ｃ言語」を含む投稿［87件］
(AxB)+(AxB＞＞8)+1/256
追記
変なメモを書いてしまいました。
AをDMXの値、Bをマスタの値として出力値を得ます。
IFなどの条件分岐を使わないのはGPUでも計算出来るからです。GPUは条件分岐処理は出来ませんがCPUで１計算する時間で同時に複数の計算が可能です。
256で割るってことは8ビット右シフトすることと同じですので、
((AxB)+(AxB＞＞8)+1)＞＞8
とした方がいいかもしれません。
「>>」は右へビットシフトする計算記号です。
追記の２
一番上の計算はAI/Geminiさんに聞いてのものですが、考えていたのとちょっと違う。AxBは8bitx8bitで16bitの積となりますが、下位8bitが0でなければ上位8bitをインクリメントして8bitの値にしたいのです。
( AxB ＞＞ 8 ) + int((( AxB ) and 0x00FF ) ＞ 0 )
bool値を数値化(0または1)して加算するのが肝です。アセンブラっぽい風味です。
追記の３
上記の式をAI/Geminiさんに評価してもらったのですが、アホかってくらいテンション上げて喜んでくれました。
AIさんはユーザーを過剰にヨイショする傾向にありますが、間違ってはいないようですし、GPUに与える公式としても使えるようです。
今考えているArt-Net系の装置にはマスタ値による出力値の計算はありませんが、GPUでこの計算が出来るなら調光卓が作れるってことになります。
一般照明用の小ぶりな卓が欲しいなぁ～って思うことがあるので、いずれ考えてみたいですね。ムービングライトを扱える卓には優秀な物が沢山ありますから、あくまで一般照明向けです。見たまんまで使える機能を削りまくったSmartFadeってイメージかな？
#RaspberryPi #Ｃ言語 #Nim
追記
変なメモを書いてしまいました。
AをDMXの値、Bをマスタの値として出力値を得ます。
IFなどの条件分岐を使わないのはGPUでも計算出来るからです。GPUは条件分岐処理は出来ませんがCPUで１計算する時間で同時に複数の計算が可能です。
256で割るってことは8ビット右シフトすることと同じですので、
((AxB)+(AxB＞＞8)+1)＞＞8
とした方がいいかもしれません。
「>>」は右へビットシフトする計算記号です。
追記の２
一番上の計算はAI/Geminiさんに聞いてのものですが、考えていたのとちょっと違う。AxBは8bitx8bitで16bitの積となりますが、下位8bitが0でなければ上位8bitをインクリメントして8bitの値にしたいのです。
( AxB ＞＞ 8 ) + int((( AxB ) and 0x00FF ) ＞ 0 )
bool値を数値化(0または1)して加算するのが肝です。アセンブラっぽい風味です。
追記の３
上記の式をAI/Geminiさんに評価してもらったのですが、アホかってくらいテンション上げて喜んでくれました。
AIさんはユーザーを過剰にヨイショする傾向にありますが、間違ってはいないようですし、GPUに与える公式としても使えるようです。
今考えているArt-Net系の装置にはマスタ値による出力値の計算はありませんが、GPUでこの計算が出来るなら調光卓が作れるってことになります。
一般照明用の小ぶりな卓が欲しいなぁ～って思うことがあるので、いずれ考えてみたいですね。ムービングライトを扱える卓には優秀な物が沢山ありますから、あくまで一般照明向けです。見たまんまで使える機能を削りまくったSmartFadeってイメージかな？
#RaspberryPi #Ｃ言語 #Nim
Nim はＣ言語でやれることを全て出来るのに凄くシンプルな記述です。Python と同じではないけど近い感覚で書けるのがいいですね。
中間言語的にＣ言語に吐き出(トランパイル)してから gcc などでバイナリまで作る構成ですが、Ｃ++ や JavaScript にもトランスパイル出来るのだそうです。Ｃ++ も JavaScript も知らない自分にとってはＣ言語として保存出来るならそれでいいのですけどね。
Ｃ言語を経由するのでＣ言語を知っていた方がいいみたいです。Ｃ言語で作れる低レイヤー(ハードウェアにより近い部分)の処理を Python みたいな記述で比較的簡単に書けることがメリットですが、途中でＣ言語になるのですからそれを知らずに使えるかと問われればどうなんでしょう。Ｃ言語の概念が刷り込まれてしまった私の脳ミソではそれを外した評価など出来ません。
今日勉強していた内容ではポインタの概念が必要でした。Ｃ言語の要素の中で最も理解し難いと言われるポインタです。わかってしまえば大したことではなく、私の場合は長く書いてきた PIC16 のアセンブラに置き換えながら抽象化の意味を探ってみたら解決しましたが、アセンブラの概念が無い人にポインタをわかってもらう説明ってどうやったらいいんだろうって考えるとなーんにもイメージ出来ませんでした。
他人に Nim を教えようなんて思ってもいませんが、Ｃ言語を全く知らずに低レイヤーのプログラミングをするのは無茶だと思った今日の休憩時間でした。
Nim と共にＣ言語の勉強も継続した方が良さそうです。Rust の世界からは退場することにします。
#Nim #Ｃ言語
中間言語的にＣ言語に吐き出(トランパイル)してから gcc などでバイナリまで作る構成ですが、Ｃ++ や JavaScript にもトランスパイル出来るのだそうです。Ｃ++ も JavaScript も知らない自分にとってはＣ言語として保存出来るならそれでいいのですけどね。
Ｃ言語を経由するのでＣ言語を知っていた方がいいみたいです。Ｃ言語で作れる低レイヤー(ハードウェアにより近い部分)の処理を Python みたいな記述で比較的簡単に書けることがメリットですが、途中でＣ言語になるのですからそれを知らずに使えるかと問われればどうなんでしょう。Ｃ言語の概念が刷り込まれてしまった私の脳ミソではそれを外した評価など出来ません。
今日勉強していた内容ではポインタの概念が必要でした。Ｃ言語の要素の中で最も理解し難いと言われるポインタです。わかってしまえば大したことではなく、私の場合は長く書いてきた PIC16 のアセンブラに置き換えながら抽象化の意味を探ってみたら解決しましたが、アセンブラの概念が無い人にポインタをわかってもらう説明ってどうやったらいいんだろうって考えるとなーんにもイメージ出来ませんでした。
他人に Nim を教えようなんて思ってもいませんが、Ｃ言語を全く知らずに低レイヤーのプログラミングをするのは無茶だと思った今日の休憩時間でした。
Nim と共にＣ言語の勉強も継続した方が良さそうです。Rust の世界からは退場することにします。
#Nim #Ｃ言語
Nim のことを少しかじってみましたがイイですね。
普及率が低い言語なので情報が少ないですし、個人レベルのコミュニティで開発されているので配布やメンテが突然終わってしまうかもしれませんが、Ｃ言語に変換してから gcc でコンパイルするってのがいいですね。Nim で書けなくなってもＣ言語としては残るのです。今やＣ言語は古代語みたいな存在感ですが、私が生きている間に消え去ることは無いでしょう。扱える言語として残せるなら問題なかろうと思います。
それにも増して、初めて眺めた Nim のコードが何となく読めることがイイです。自分が勉強したのは Python3、Ｃ言語(ANSI)、Rust ですが、Pythonに他の言語の方言が少しずつ混じったと思えば済んでしまいそうです。変数の型指定が必須の Python と思えばいいようです。
コード書きで飯を食おうなんて思っていませんし、自分で組んだハードウェアを動かすことが目的ですので、Nim の普及率が低くても問題はありません。少ない学習コストで短期間で書けるならそちらの方にメリットがあります。もちろん、RaspberryPi でも使えます。
AI/Geminiさんにお聞きしたところ、コンパイルには注意が必要っぽいです。コンパイルにはデバックレベルとリリースレベルがありますが、リリースレベルは最適化が強いので、デバックレベルでは動いたコードがリリースレベルでは動かないことがあるそうです。これはメモリキャッシュに代表される挙動の違いらしいので、この辺りをキチンと追い込む必要はありそうです。
何にしても、Python 並みに書きやすく読みやすく、Ｃ言語で出来ることはほぼ100%実現可能で、Ｃ言語やＣ＋＋並みの速度で動くなら願ったり叶ったりです。
追記
Nim の教科書をポチりました。明日入荷だそうです。
まずは読んでみましょう。
#Nim #Ｃ言語
普及率が低い言語なので情報が少ないですし、個人レベルのコミュニティで開発されているので配布やメンテが突然終わってしまうかもしれませんが、Ｃ言語に変換してから gcc でコンパイルするってのがいいですね。Nim で書けなくなってもＣ言語としては残るのです。今やＣ言語は古代語みたいな存在感ですが、私が生きている間に消え去ることは無いでしょう。扱える言語として残せるなら問題なかろうと思います。
それにも増して、初めて眺めた Nim のコードが何となく読めることがイイです。自分が勉強したのは Python3、Ｃ言語(ANSI)、Rust ですが、Pythonに他の言語の方言が少しずつ混じったと思えば済んでしまいそうです。変数の型指定が必須の Python と思えばいいようです。
コード書きで飯を食おうなんて思っていませんし、自分で組んだハードウェアを動かすことが目的ですので、Nim の普及率が低くても問題はありません。少ない学習コストで短期間で書けるならそちらの方にメリットがあります。もちろん、RaspberryPi でも使えます。
AI/Geminiさんにお聞きしたところ、コンパイルには注意が必要っぽいです。コンパイルにはデバックレベルとリリースレベルがありますが、リリースレベルは最適化が強いので、デバックレベルでは動いたコードがリリースレベルでは動かないことがあるそうです。これはメモリキャッシュに代表される挙動の違いらしいので、この辺りをキチンと追い込む必要はありそうです。
何にしても、Python 並みに書きやすく読みやすく、Ｃ言語で出来ることはほぼ100%実現可能で、Ｃ言語やＣ＋＋並みの速度で動くなら願ったり叶ったりです。
追記
Nim の教科書をポチりました。明日入荷だそうです。
まずは読んでみましょう。
#Nim #Ｃ言語
Rust の教科書は「所有権」や「ライフタイム」で大騒ぎしないモノがいいようです。大騒ぎする教科書はその厄介さを語って力尽きるのか「とどのつまり？」の説明が薄い傾向にあります。両方とも重要なことですが、これらが Rust の全てではありません。「cargo」と呼ばれるプロジェクト管理ツールを説明しない教科書は論外です。
間違っても初めてのプログラム言語に Rust を選ぶのはお勧めできません。最終的に作りたいモノによりますが、html や Python あたりで成功体験を積み重ねて神エンジニアたちが目指したことを体に取り入れるのが良いと思います。Rust はＣ言語同様に理解するための前提というか基礎の裾野が広すぎるのです。
私は回路設計とプログラミングの境界が曖昧な PIC16 で右往左往してきましたので脳ミソが少しおかしいのですが、Ｃ言語もそうですが、Rust を受け入れるにはこのコードでハードウェアが何をするかをイメージ出来るといいようです。両言語ともハードウェアを制御する傾向が強いからでしょうか。
#器具の製作 #Ｃ言語 #Rust
間違っても初めてのプログラム言語に Rust を選ぶのはお勧めできません。最終的に作りたいモノによりますが、html や Python あたりで成功体験を積み重ねて神エンジニアたちが目指したことを体に取り入れるのが良いと思います。Rust はＣ言語同様に理解するための前提というか基礎の裾野が広すぎるのです。
私は回路設計とプログラミングの境界が曖昧な PIC16 で右往左往してきましたので脳ミソが少しおかしいのですが、Ｃ言語もそうですが、Rust を受け入れるにはこのコードでハードウェアが何をするかをイメージ出来るといいようです。両言語ともハードウェアを制御する傾向が強いからでしょうか。
#器具の製作 #Ｃ言語 #Rust
Art-Net 関連品の開発では「Rust」を使うことにしました。
Rust が持つ標準機能が Art-Net 関連品を作るのに絶大に有益なことがわかったからです。コレクションと呼ばれる機能です。
新たな言語を勉強するのは大変ですが、Ｃ言語の方言と思えばゼロベースではありません。Ｃ言語を学んだことで Rust がすんなり自分の中に入ってくる実感があります。Rust を学ぶためにＣ言語を勉強するベキ！？ってことでもありますが、案外そんなもんかなと感じています。Ｃ言語でも Rust でもコードの裏側にあることは同じってことですかね。ハードウェアを動かすのがソフトウェアですから。
あまりに便利なので Python みたいに遅くねーの？って疑問はありますが、コンパイルされたバイナリはＣ言語やＣ＋＋に匹敵するらしいのでその評価を信じましょう。
言葉は優しいですが、AI/Geminiさんのお言葉を要約するなら基板を作ってPIC16アセンブラを書いて RaspberryPi と協調動作する装置を作る素人(アマチュア)は斜め上過ぎる存在らしいです。私にとっては日常感覚ですケド、その延長かプログラム言語に対するアプローチも少し変みたいです。私からしたらパチンコやスロットで確率数値を操って常に勝ち続けてる人の方がどうかしてますケド。
#器具の製作 #Ｃ言語 #Rust
Rust が持つ標準機能が Art-Net 関連品を作るのに絶大に有益なことがわかったからです。コレクションと呼ばれる機能です。
新たな言語を勉強するのは大変ですが、Ｃ言語の方言と思えばゼロベースではありません。Ｃ言語を学んだことで Rust がすんなり自分の中に入ってくる実感があります。Rust を学ぶためにＣ言語を勉強するベキ！？ってことでもありますが、案外そんなもんかなと感じています。Ｃ言語でも Rust でもコードの裏側にあることは同じってことですかね。ハードウェアを動かすのがソフトウェアですから。
あまりに便利なので Python みたいに遅くねーの？って疑問はありますが、コンパイルされたバイナリはＣ言語やＣ＋＋に匹敵するらしいのでその評価を信じましょう。
言葉は優しいですが、AI/Geminiさんのお言葉を要約するなら基板を作ってPIC16アセンブラを書いて RaspberryPi と協調動作する装置を作る素人(アマチュア)は斜め上過ぎる存在らしいです。私にとっては日常感覚ですケド、その延長かプログラム言語に対するアプローチも少し変みたいです。私からしたらパチンコやスロットで確率数値を操って常に勝ち続けてる人の方がどうかしてますケド。
#器具の製作 #Ｃ言語 #Rust
DMX-Timer は終わりが見えてきました。次の課題はArt-Net 関連機器と行きたいところです。
これらは RaspberryPi 上でのプログラミングが主となりますが言語どうするか。Ｃ言語か Rust の二択ですけど、未だに迷っております。この２種はハードウェアを扱うのに適した言語ですから Art-Net 関連機器を組むにはよいと思われます。両方を使いこなせればいいのですが、年齢的に一つでも辛いのに二つは無理。。。少し前までＣ言語でいくつもりで勉強していましたが、 Rust の教科書を斜め読みしたところ自分がやりたいことには Rust が向いているような気がして困っているワケです。
Rust の情報に接しますと「所有権がぁ、所有権がぁ」と脅しの様に書かれております。これはＣ言語での「ポインタがぁ、ポインタがぁ」や、Ｃ＋＋での「オブジェクト指向がぁ、がぁ」と同じです。身に着けないと使えないし身に着ければよりよいコードが書けるのですから身に着ければいい。簡単でないことは確かですが、言語をデザインした神エンジニアたちは苦労や混乱をさせたかったワケではありません。たぶん。
開発には心の余裕とまとまった時間が必要です。なかなかそんな時間は取れませんので、引き続き妄想しながら勉強をしましょう。
#Ｃ言語 #Rust
これらは RaspberryPi 上でのプログラミングが主となりますが言語どうするか。Ｃ言語か Rust の二択ですけど、未だに迷っております。この２種はハードウェアを扱うのに適した言語ですから Art-Net 関連機器を組むにはよいと思われます。両方を使いこなせればいいのですが、年齢的に一つでも辛いのに二つは無理。。。少し前までＣ言語でいくつもりで勉強していましたが、 Rust の教科書を斜め読みしたところ自分がやりたいことには Rust が向いているような気がして困っているワケです。
Rust の情報に接しますと「所有権がぁ、所有権がぁ」と脅しの様に書かれております。これはＣ言語での「ポインタがぁ、ポインタがぁ」や、Ｃ＋＋での「オブジェクト指向がぁ、がぁ」と同じです。身に着けないと使えないし身に着ければよりよいコードが書けるのですから身に着ければいい。簡単でないことは確かですが、言語をデザインした神エンジニアたちは苦労や混乱をさせたかったワケではありません。たぶん。
開発には心の余裕とまとまった時間が必要です。なかなかそんな時間は取れませんので、引き続き妄想しながら勉強をしましょう。
#Ｃ言語 #Rust
AI/Geminiさんに聞いたところ、RaspberryPiでは4byte単位、4kB単位でキリ良く考えるとストレスが少ないのだそうな。1byte単位のデータでも4byteで扱った方が良いってことです。
パディング対策して詰め々々がイイって話を振ってきたのもGeminiさんですが、知識のある年寄りに時間を開けて話を聞いた時のような困惑を感じたりしたり。。。
追記
4byte、64byte、4096byte区切りでメモリを扱う様に構造体などを定義すると良いのだそうです。更に、構造体のメモリ上のアドレスをアトリビュートで64の倍数値にするのもお勧めとのこと。
4byteはCPUのレジスタの長さ、64byteはキャッシュの転送単位、4096byteはメモリページの扱い単位です。
気にしなくても動きますが、CPUやOSの挙動において無駄を省くことに繋がるらしいです。
#Ｃ言語
パディング対策して詰め々々がイイって話を振ってきたのもGeminiさんですが、知識のある年寄りに時間を開けて話を聞いた時のような困惑を感じたりしたり。。。
追記
4byte、64byte、4096byte区切りでメモリを扱う様に構造体などを定義すると良いのだそうです。更に、構造体のメモリ上のアドレスをアトリビュートで64の倍数値にするのもお勧めとのこと。
4byteはCPUのレジスタの長さ、64byteはキャッシュの転送単位、4096byteはメモリページの扱い単位です。
気にしなくても動きますが、CPUやOSの挙動において無駄を省くことに繋がるらしいです。
#Ｃ言語
Ｃ言語の共用体(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以外のパケットにも使えるチェック方法です。
#Ｃ言語
されど、今回の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以外のパケットにも使えるチェック方法です。
#Ｃ言語
先日の現場はヒマな時間が長かったのでＣ言語の教科書を読みまくってみましたがかなり整理出来ました。
昨今の教科書はポインタの説明が丁寧です。ハードウェアとしてのメモリの動作がアタマに入っていないと分かり難いことですが、私はPICのアセンブラで普通に扱ってきたことなので改めてではありますが素直に理解出来ました。わかってしまえばむしろ便利だなと。変数の読み書き方法が何種類もあることになるので混乱すると思いますが、どれもメモリへのアクセス手段だと捉え直せばいいだけでした。このあたりが整理できるとmmapも自然に理解出来ます。
ヘッダーファイルはコピペでテキトウに書いていましたが、意味と書き方が整理できました。後はmakefileが整理出来れば良さそうです。
#Ｃ言語
昨今の教科書はポインタの説明が丁寧です。ハードウェアとしてのメモリの動作がアタマに入っていないと分かり難いことですが、私はPICのアセンブラで普通に扱ってきたことなので改めてではありますが素直に理解出来ました。わかってしまえばむしろ便利だなと。変数の読み書き方法が何種類もあることになるので混乱すると思いますが、どれもメモリへのアクセス手段だと捉え直せばいいだけでした。このあたりが整理できるとmmapも自然に理解出来ます。
ヘッダーファイルはコピペでテキトウに書いていましたが、意味と書き方が整理できました。後はmakefileが整理出来れば良さそうです。
#Ｃ言語