電装工芸日記
- 舞台照明機器の製作とか -
タグ「Ｃ言語」を含む投稿(時系列順)［57件］（4ページ目）
てなわけで、socketの実験に入る下準備が整いました。Pythonで出来たことですからＣ言語(gcc)で出来ないことではないでしょう。
Art-Netエンジンを構成するにはFIFOというか循環配列というかリングキャッシュというかQueueも勉強しないとけません。例えば1024個の配列を作ったとして、これがリング状に繋がったイメージで使います。1024で折り返すカウンタを使って配列の基点位置を表すだけですが、カウンタの計算モジュールだけでもライブラリ化しないと面倒かなと。
これはDelayで必要な機能です。一定の時間間隔でDMXのデータを保存し続ければ配列サイズが許す範囲で過去情報を取り出せます。つまりDelayになります。受信毎の保存でないことが肝ですが、往年のテープエコーと要領は同じです。
Ｃ言語はボチボチ書けるようになってきましたし、先達の情報も読み取れるようになってきました。パッチマシンとしての完成は先としても、この閑散期にArt-Netエンジンだけでも完成させたいです。
あとは、コマンド入力と処理の方法も考えないといけません。
ルールマップに基づいた入力制限とか、入力されたコマンドや数値のスタック方法とか、それの表示とかです。入力値はコマンドと数値の文字列で処理関数に渡すつもりですが、それをどの様に解析して実行するかも案外難しい。
#[Art-Net] #Ｃ言語
Art-Netエンジンを構成するにはFIFOというか循環配列というかリングキャッシュというかQueueも勉強しないとけません。例えば1024個の配列を作ったとして、これがリング状に繋がったイメージで使います。1024で折り返すカウンタを使って配列の基点位置を表すだけですが、カウンタの計算モジュールだけでもライブラリ化しないと面倒かなと。
これはDelayで必要な機能です。一定の時間間隔でDMXのデータを保存し続ければ配列サイズが許す範囲で過去情報を取り出せます。つまりDelayになります。受信毎の保存でないことが肝ですが、往年のテープエコーと要領は同じです。
Ｃ言語はボチボチ書けるようになってきましたし、先達の情報も読み取れるようになってきました。パッチマシンとしての完成は先としても、この閑散期にArt-Netエンジンだけでも完成させたいです。
あとは、コマンド入力と処理の方法も考えないといけません。
ルールマップに基づいた入力制限とか、入力されたコマンドや数値のスタック方法とか、それの表示とかです。入力値はコマンドと数値の文字列で処理関数に渡すつもりですが、それをどの様に解析して実行するかも案外難しい。
#[Art-Net] #Ｃ言語
自作のライブラリをincludeしてコンパイルするには少し面倒があります。
例えば、
製作するアプリケーションファイル test_inkey
メインのソースファイル test_inkey.c
ライブラリのソースファイル std_inkey.c
とした場合、
$ gcc -Wall -lm -o test_inkey -I ./ test_inkey.c std_inkey.c
などとコンソールからコマンドを打たないといけません。
Cのソースファイルが一つならVSCodeからショートカットで一発なんですけどね。
この場合、makefileを作っておけばmakeコマンドで一発です。
次がわかりやすい。
Makefile の書き方 (C 言語)
makeコマンドの使い方も丁寧に説明してくれています。
#Ｃ言語
例えば、
製作するアプリケーションファイル test_inkey
メインのソースファイル test_inkey.c
ライブラリのソースファイル std_inkey.c
とした場合、
$ gcc -Wall -lm -o test_inkey -I ./ test_inkey.c std_inkey.c
などとコンソールからコマンドを打たないといけません。
Cのソースファイルが一つならVSCodeからショートカットで一発なんですけどね。
この場合、makefileを作っておけばmakeコマンドで一発です。
次がわかりやすい。
Makefile の書き方 (C 言語)
makeコマンドの使い方も丁寧に説明してくれています。
#Ｃ言語
Art-Netの送信にも成功しました。
受信値を転送するだけですが、Art-Netデコーダから正常と思われる値が出力されています。
今日は終わりにしますが、大きな課題がクリア出来て大満足です。
ただ、８ユニバースを出力しているdot2が一杯いっぱいの様子。発熱も凄いし画面もコマ送りです。
ちなみにですが、recvfrom()の４番目のパラメータを「MSG_DONTWAIT」にすると受信待ちしません。先達の例では待ちアリの「0」を定義してioctl()に待ち無し(ノンブロッキング)を設定していることが多いのですが、「MSG_DONTWAIT」を使った方がストレスが無い感じ。
で、気付いたのですが、Ｃ言語は速い。速いが故の対策が必要になる始末。受送信テストでは終了のためのキー入力やタイムアウトを入れるのが面倒だったのでfor文による一定回数の繰り返しで試したのですが、受信待ちを無くした後はPythonでの実験の際に使った回数では一瞬で終わってしまいます。プログラムが間違っているのかと思う程でした。てことは、あまりにも無意味な回数recvfrom()を呼んでいることになりますので、受信が無い場合は100～500usecくらい待ちを入れた方がいいみたいです。バッファを読みに行っているだけなので気にしなくていいって話もありますが、ANSIエスケープシーケンスを用いた画面表示も適度な待ちを入れないと画面がフリッカーを起こす程です。数か月かかりましたが、Ｃ言語を勉強して良かったと思います。遅いのを対策するのは大変ですが、速いのを抑え込むのは比較的簡単ですからね。
ここまで速いとマルチプロセスを使わなくてもいいのではないか？って気持ちも芽生えます。使った方が速さ以外に都合が良いこともあるので使いますケド。
基本的な受送信が確認出来ましたので、関数化しつつArt-Net(正しくはArt-DMX)のデコード/エンコードも書きましょう。
#[Art-Net] #Ｃ言語
受信値を転送するだけですが、Art-Netデコーダから正常と思われる値が出力されています。
今日は終わりにしますが、大きな課題がクリア出来て大満足です。
ただ、８ユニバースを出力しているdot2が一杯いっぱいの様子。発熱も凄いし画面もコマ送りです。
ちなみにですが、recvfrom()の４番目のパラメータを「MSG_DONTWAIT」にすると受信待ちしません。先達の例では待ちアリの「0」を定義してioctl()に待ち無し(ノンブロッキング)を設定していることが多いのですが、「MSG_DONTWAIT」を使った方がストレスが無い感じ。
で、気付いたのですが、Ｃ言語は速い。速いが故の対策が必要になる始末。受送信テストでは終了のためのキー入力やタイムアウトを入れるのが面倒だったのでfor文による一定回数の繰り返しで試したのですが、受信待ちを無くした後はPythonでの実験の際に使った回数では一瞬で終わってしまいます。プログラムが間違っているのかと思う程でした。てことは、あまりにも無意味な回数recvfrom()を呼んでいることになりますので、受信が無い場合は100～500usecくらい待ちを入れた方がいいみたいです。バッファを読みに行っているだけなので気にしなくていいって話もありますが、ANSIエスケープシーケンスを用いた画面表示も適度な待ちを入れないと画面がフリッカーを起こす程です。数か月かかりましたが、Ｃ言語を勉強して良かったと思います。遅いのを対策するのは大変ですが、速いのを抑え込むのは比較的簡単ですからね。
ここまで速いとマルチプロセスを使わなくてもいいのではないか？って気持ちも芽生えます。使った方が速さ以外に都合が良いこともあるので使いますケド。
基本的な受送信が確認出来ましたので、関数化しつつArt-Net(正しくはArt-DMX)のデコード/エンコードも書きましょう。
#[Art-Net] #Ｃ言語
Art-Netのデコード/エンコードも出来ました。受信した１配列のバイナリデータを分類して構造体に取り込むのがデコード、項目別の構造体から送信用のバイナリデータに変換するのがエンコードです。
実験は受信値をデコードして再エンコードして送信です。照明器具としては何の芸も無い状態ですが、これが出来なきゃ先へは進めません。
topコマンドで処理負荷を見ますと、ダンプ表示ありで23%、ダンプ表示無しで7%くらいです。Art-Netのコア処理は思った以上に軽いですが、画面表示が重いっすね。完成イメージの画面表示はもっと重くなりますので、Art-Netのコア処理は画面表示とは別プロセスにしたいですね。出来ることならArt-Netのコア処理でCPUスレッドを１つ占有したいくらいです。ここは余裕をもって確実にしたい処理ですから。
今のところ製作は順調です。３月末までに１日平均3-4時間程度使えますので、「ArtNet-Engine」と呼ぶコア機能はまとめられそうです。
#[Art-Net] #Ｃ言語
実験は受信値をデコードして再エンコードして送信です。照明器具としては何の芸も無い状態ですが、これが出来なきゃ先へは進めません。
topコマンドで処理負荷を見ますと、ダンプ表示ありで23%、ダンプ表示無しで7%くらいです。Art-Netのコア処理は思った以上に軽いですが、画面表示が重いっすね。完成イメージの画面表示はもっと重くなりますので、Art-Netのコア処理は画面表示とは別プロセスにしたいですね。出来ることならArt-Netのコア処理でCPUスレッドを１つ占有したいくらいです。ここは余裕をもって確実にしたい処理ですから。
今のところ製作は順調です。３月末までに１日平均3-4時間程度使えますので、「ArtNet-Engine」と呼ぶコア機能はまとめられそうです。
#[Art-Net] #Ｃ言語
Art-Netの入口と出口は出来ましたので機能を組みます。Ｃ言語に替えた為に処理能力に余裕が出て複座なプロセス処理を多用しなくても良さそうですが、そもそもの処理をどうするか吟味しないといけません。
搭載予定の機能は、ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)です。スタックフェーダー機能はミキサー機能に含まれます。
さて、どうしようかな。
#[Art-Net] #Ｃ言語
搭載予定の機能は、ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)です。スタックフェーダー機能はミキサー機能に含まれます。
さて、どうしようかな。
#[Art-Net] #Ｃ言語
諸々イイ感じに書き進められていますが、処理タイミングという一見簡単そうで実は面倒なことに取り組んでいます。
先日作ったキー入力処理とArt-Net処理を混ぜているのですが、それぞれに合った時間間隔で実行しないといけません。キー入力は100msec、Art-Netは100usecです。求められる処理間隔が３桁も違うので同じ時間間隔ではどちらかが破綻します。それぞれをそれぞれの時間間隔で実行するにはどうするか。他の処理を止めること無く処理を続けるにはどうするか。
基本は前回処理の日時と現在日時の差から経過時間を評価する方法です。一定の時間間隔で処理を呼ぶのではなく、呼ばれても経過時間が要求未満なら何もしない方法です。signal()を用いて一定時間間隔で関数を実行させるのが王道でしょうが、singal()ですと終わっているべき他処理のチェックが必要になるのでどっちもどっちです。私の書き方が悪いのかもしれませんが、signal()を多用するとバグの原因になりやすいようです。
なんにしても前回処理からの経過時間で対策してみます。そのために必要なのは現在日時の取得です。POSIX時間と呼ばれる1970年1月1日0時0分0秒からの経過秒数を取得出来るのでこれを用います。50マイクロ秒くらいの分解能が欲しいので秒単位では不足しますが、精度はともかく1ナノ秒単位で値を得られますから十分です。
下記はその値を取得するテストプログラムです。
秒とナノ秒が別々の変数で得られるので、評価を簡単にするためにひとまとめにします。ただし、int型は4バイト長(OSが32bitの場合)のためデータ長が不足しますので、8バイト長(OSが32bitの場合)の unsigned long long int型を用います。2038年問題はとりあえず気にしない。。。
Raspberry Pi 4B / Rasbian11_32bit(blueseye) / コンパイラ：OS標準gcc
＃include <stdio.h>
＃include <time.h>
int main( int argc, char *argv［］ ) {
struct timespec now ;
unsigned long long int now_nsec ;
// 現在POSIX時を取得
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)
// 確認表示
printf( "%11ld.%09ld sec.\n", now.tv_sec, now.tv_nsec ) ; // 取得値を表示
printf( "%21lld nsec.\n", now_nsec ) ; // ひとまとめにした数値を表示
// 終了
return 0 ;
}
※ このブログシステムでは＃や［が機能文字扱いなので、上記ではこれらを全角文字で書いています。空白も全角です。
◆ 参考
時間情報の取得方法と扱い方
取得に必要なのは「// 現在POSIX時を取得」以下の２行(表記は３行)です。
実際の処理では、取得した秒とナノ秒を合わせた数値がnow_nsec入りますので現在日時値とし、同じ方法で前回の処理で取得した値との差で経過時間を評価します。単位がnsecなら１秒は1000000000(1e9)ですから、100msecは100000000(1e8)、100usecは100000(1e5)です。良い意味で処理が速いＣ言語では多用すべき手法です。
関数化・ライブラリ化するとソースは美しいですが、２行で出来ることなので都度の直書きでもいいかなと。将来、2038年問題に対策しやすくしておくならライブラリ化しといた方がいいけど。
PICのアセンブラでも近いことをしていますが、それがPICで様々なことを実現出来ている要因だったりします。処理タイミングの管理はとても重要です。
#Ｃ言語
先日作ったキー入力処理とArt-Net処理を混ぜているのですが、それぞれに合った時間間隔で実行しないといけません。キー入力は100msec、Art-Netは100usecです。求められる処理間隔が３桁も違うので同じ時間間隔ではどちらかが破綻します。それぞれをそれぞれの時間間隔で実行するにはどうするか。他の処理を止めること無く処理を続けるにはどうするか。
基本は前回処理の日時と現在日時の差から経過時間を評価する方法です。一定の時間間隔で処理を呼ぶのではなく、呼ばれても経過時間が要求未満なら何もしない方法です。signal()を用いて一定時間間隔で関数を実行させるのが王道でしょうが、singal()ですと終わっているべき他処理のチェックが必要になるのでどっちもどっちです。私の書き方が悪いのかもしれませんが、signal()を多用するとバグの原因になりやすいようです。
なんにしても前回処理からの経過時間で対策してみます。そのために必要なのは現在日時の取得です。POSIX時間と呼ばれる1970年1月1日0時0分0秒からの経過秒数を取得出来るのでこれを用います。50マイクロ秒くらいの分解能が欲しいので秒単位では不足しますが、精度はともかく1ナノ秒単位で値を得られますから十分です。
下記はその値を取得するテストプログラムです。
秒とナノ秒が別々の変数で得られるので、評価を簡単にするためにひとまとめにします。ただし、int型は4バイト長(OSが32bitの場合)のためデータ長が不足しますので、8バイト長(OSが32bitの場合)の unsigned long long int型を用います。2038年問題はとりあえず気にしない。。。
Raspberry Pi 4B / Rasbian11_32bit(blueseye) / コンパイラ：OS標準gcc
＃include <stdio.h>
＃include <time.h>
int main( int argc, char *argv［］ ) {
struct timespec now ;
unsigned long long int now_nsec ;
// 現在POSIX時を取得
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)
// 確認表示
printf( "%11ld.%09ld sec.\n", now.tv_sec, now.tv_nsec ) ; // 取得値を表示
printf( "%21lld nsec.\n", now_nsec ) ; // ひとまとめにした数値を表示
// 終了
return 0 ;
}
※ このブログシステムでは＃や［が機能文字扱いなので、上記ではこれらを全角文字で書いています。空白も全角です。
◆ 参考
時間情報の取得方法と扱い方
取得に必要なのは「// 現在POSIX時を取得」以下の２行(表記は３行)です。
実際の処理では、取得した秒とナノ秒を合わせた数値がnow_nsec入りますので現在日時値とし、同じ方法で前回の処理で取得した値との差で経過時間を評価します。単位がnsecなら１秒は1000000000(1e9)ですから、100msecは100000000(1e8)、100usecは100000(1e5)です。良い意味で処理が速いＣ言語では多用すべき手法です。
関数化・ライブラリ化するとソースは美しいですが、２行で出来ることなので都度の直書きでもいいかなと。将来、2038年問題に対策しやすくしておくならライブラリ化しといた方がいいけど。
PICのアセンブラでも近いことをしていますが、それがPICで様々なことを実現出来ている要因だったりします。処理タイミングの管理はとても重要です。
#Ｃ言語
オレメモ
ANSIエスケープシーケンスにおいてカーソルの表示/非表示を定義。
RaspberryPi 4B / Rasbian11_32bit / コンパイラ：OS標準gcc
\e［?25h カーソルの表示
\e［?25l カーソルの非表示
相変わらずの不思議な呪文。
#Ｃ言語
ANSIエスケープシーケンスにおいてカーソルの表示/非表示を定義。
RaspberryPi 4B / Rasbian11_32bit / コンパイラ：OS標準gcc
\e［?25h カーソルの表示
\e［?25l カーソルの非表示
相変わらずの不思議な呪文。
#Ｃ言語
本業もやらねばなりませんがArtNet-Engineも進めたい。
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語
本業はちょいちょいで終わったのでArtNet-Engineを書き進めました。
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
追い込まれる程ではありませんが、本業がジンワリと忙しくなってきました。開発はボチボチペースで進めます。
ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ？という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。
ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。
#Ｃ言語 #RaspberryPi
ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ？という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。
ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。
#Ｃ言語 #RaspberryPi