電装工芸日記
- 舞台照明機器の製作とか -
全年全月4日の投稿［48件］（3ページ目）
2023年9月 この範囲を時系列順で読む この範囲をファイルに出力する
VLC が入っていて Python を入れていないパソコンが一台あったので exeファイルを試してみました。
問題なく動きます。
python-vlc は VLC を入れていなくても動くハズですが、入れておいた方がいいのかもしれません。
VLC をアンインストールして試す手もありますが、DLL などが残る可能性もあるので、一度 VLC に触れたパソコンはインストール済みと思うしかありません。
いずれにしても、VLC のインストールを推奨することにしましょう。
「VLC media player」
とても便利なアプリです。特にこだわりがなければ、デフォルトアプリとしてもお勧めする一品です。
#Python #タイムコード
問題なく動きます。
python-vlc は VLC を入れていなくても動くハズですが、入れておいた方がいいのかもしれません。
VLC をアンインストールして試す手もありますが、DLL などが残る可能性もあるので、一度 VLC に触れたパソコンはインストール済みと思うしかありません。
いずれにしても、VLC のインストールを推奨することにしましょう。
「VLC media player」
とても便利なアプリです。特にこだわりがなければ、デフォルトアプリとしてもお勧めする一品です。
#Python #タイムコード
2023年7月 この範囲を時系列順で読む この範囲をファイルに出力する
某所に設置したサーバー機の OS は Debian です。
それ自体が素晴らしいのもありますが、細かい解説を残してくれる先達が多いので、自分がやりたいと思うことはネットを検索すればほとんど解決します。
samba を用いてのファイル共有はその昔の文字コード問題は全く無くアクセスも速いですね。Windows-Server で共有するのと遜色ありません。
Wi-fi のアクセスポイントにもしていますが、汎用の USB-Wifi トングで問題ありません。
VPN(openvpn)で本社のサーバーとも繋げています。ファイルを直接開くのはお勧め出来ないものの、特別なことをせずに本社の共有フォルダにアクセス出来ますから作業性は良いですね。VPNとは拠点間LANとも呼ばれる手法で、疑似的にLANケーブルが繋がっているのと同じ状態を作り上げる手法です。openvpn 以外にDNSサーバーに細工をしてルーティングを施さないといけませんが、要領がわかってしまえば簡単です。
#サーバー
それ自体が素晴らしいのもありますが、細かい解説を残してくれる先達が多いので、自分がやりたいと思うことはネットを検索すればほとんど解決します。
samba を用いてのファイル共有はその昔の文字コード問題は全く無くアクセスも速いですね。Windows-Server で共有するのと遜色ありません。
Wi-fi のアクセスポイントにもしていますが、汎用の USB-Wifi トングで問題ありません。
VPN(openvpn)で本社のサーバーとも繋げています。ファイルを直接開くのはお勧め出来ないものの、特別なことをせずに本社の共有フォルダにアクセス出来ますから作業性は良いですね。VPNとは拠点間LANとも呼ばれる手法で、疑似的にLANケーブルが繋がっているのと同じ状態を作り上げる手法です。openvpn 以外にDNSサーバーに細工をしてルーティングを施さないといけませんが、要領がわかってしまえば簡単です。
#サーバー
PysimpleGUI は簡単な画面を簡単に作れますが、母体である Tkinter の機能の一部を直接引っ張り出すことで思った以上に細かい作り込みも出来ます。
もちろん、直接使うのに比べたら出来ることは少ないのですが、少ない学習量と記述量でここまで出来るなら御の字だと思います。主なGUIライブラリは、一つのことをするのに「あっちにコレ」「そっちにソレ」と彼方此方に記述をしなければなりません。細かく言うなら、雛形 class をオーバーライドして自分用の class 定義を延々とやらねばならず、Pythonの書き方としては王道なのでしょうが、簡単なことを簡単に実現するには程遠い感じです。
何を以って良しとするかは難しいですが、GUI画面製作の入門として PysilmpleGUI がお勧めなのは間違いありません。class ってイマイチわからない、って人も使えると思います。
もちろん、オブジェクト指向の書き方が出来るプログラム言語で class を使わないのは魅力が半減ですから身に付けるべきですケドね。
本業が詰まってしまい LTC Player の製作は完全に止まっていますが、合間に勉強を進めていきましょう。
#Python
もちろん、直接使うのに比べたら出来ることは少ないのですが、少ない学習量と記述量でここまで出来るなら御の字だと思います。主なGUIライブラリは、一つのことをするのに「あっちにコレ」「そっちにソレ」と彼方此方に記述をしなければなりません。細かく言うなら、雛形 class をオーバーライドして自分用の class 定義を延々とやらねばならず、Pythonの書き方としては王道なのでしょうが、簡単なことを簡単に実現するには程遠い感じです。
何を以って良しとするかは難しいですが、GUI画面製作の入門として PysilmpleGUI がお勧めなのは間違いありません。class ってイマイチわからない、って人も使えると思います。
もちろん、オブジェクト指向の書き方が出来るプログラム言語で class を使わないのは魅力が半減ですから身に付けるべきですケドね。
本業が詰まってしまい LTC Player の製作は完全に止まっていますが、合間に勉強を進めていきましょう。
#Python
2023年6月 この範囲を時系列順で読む この範囲をファイルに出力する
以前から考えていたことですが、MTCのデータを差動バイフェーズで送るのはどうかなと。
データ構成はLTCよりMTCの方が簡単です。通信インフラはMTC(MIDI)より差動バイフェーズの方が選択肢が多く遠距離でも使えます。双方のいいとこ取りをしたらどうかって発想です。
LTCに比べMIDIの方がビットレートは速いのですが、MIDIを占拠しないためにMTCのデータレートはLTCより遅いのです。通信媒体を占有するならLTCベースでもMTCを送ることは可能です。
なぜこうするかいうと、専用の通信インフラを使わず、音響さんに迷惑をかけずに音響回線を借りられたら汎用性が高いと思うからです。LTCは電気的には音声信号相当ですからダンテなどのEtherも通せます。
差動バイフェーズとUARTの変換は作らねばなりませんが、この変換はタイムコードに限らず他の制御にも使えると思うのです。データレートの制限はありますが、MSCをマイクケーブルで送れたらいいなぁ～なんて妄想してます。
#電子工作
データ構成はLTCよりMTCの方が簡単です。通信インフラはMTC(MIDI)より差動バイフェーズの方が選択肢が多く遠距離でも使えます。双方のいいとこ取りをしたらどうかって発想です。
LTCに比べMIDIの方がビットレートは速いのですが、MIDIを占拠しないためにMTCのデータレートはLTCより遅いのです。通信媒体を占有するならLTCベースでもMTCを送ることは可能です。
なぜこうするかいうと、専用の通信インフラを使わず、音響さんに迷惑をかけずに音響回線を借りられたら汎用性が高いと思うからです。LTCは電気的には音声信号相当ですからダンテなどのEtherも通せます。
差動バイフェーズとUARTの変換は作らねばなりませんが、この変換はタイムコードに限らず他の制御にも使えると思うのです。データレートの制限はありますが、MSCをマイクケーブルで送れたらいいなぁ～なんて妄想してます。
#電子工作
LTC Generator のPICはFIFOにデータを突っ込んで波形が出力するまでまとまりました。
内部のテストルーチンによるものですが、データのリレーはシュミレーターで、波形はオシロスコープで確認出来たので、最も面倒な部分が成立した模様です。
昨日一見動いたものの波形が安定せず悩みましたが、バグを手直しして今は期待した波形が出ています。0x00や0xFFはもちろん他の数値もＯＫ。オシロスコープのトリガが引っかからず波形が読み取れない数値もありますが、この値が確認出来ればいいでしょうって値はいけたので、デバイスドライバ的なところが終わったと言えます。
今後の課題はパソコンとの通信です。PIC側は過去実績、パソコン側はライブラリに頼れば左程難しくないハズ・・です。パソコンから受信した値をFIFOに突っ込んで期待した波形が出れば重要な機能は完了です。
完成に至るには、PICからパソコン側にデータ送信の要求を送ったり、コマンドでfpsのモードを切り替えたりと課題は残っていますが、ハードウェアとデバイスドライバ的な部分がまとまればハードルは低くなります。
ちなみに、今作っているのはシリアルで受信したバイトデータを差動バイフェーズで出力するだけの物ですから、TASCAMのプレーヤーのリモコンと組み合わせることも可能(正しくは不可能ではない)です。曲ごとのタイムコードをユニークする方法を考えなければなりませんが、これはこれで欲しい一品です。
当然リモコンはフルスクラッチとなりますが、出来るだけ音響さんの環境を変えないためにこういった発想もありかなと。
#PIC #タイムコード
内部のテストルーチンによるものですが、データのリレーはシュミレーターで、波形はオシロスコープで確認出来たので、最も面倒な部分が成立した模様です。
昨日一見動いたものの波形が安定せず悩みましたが、バグを手直しして今は期待した波形が出ています。0x00や0xFFはもちろん他の数値もＯＫ。オシロスコープのトリガが引っかからず波形が読み取れない数値もありますが、この値が確認出来ればいいでしょうって値はいけたので、デバイスドライバ的なところが終わったと言えます。
今後の課題はパソコンとの通信です。PIC側は過去実績、パソコン側はライブラリに頼れば左程難しくないハズ・・です。パソコンから受信した値をFIFOに突っ込んで期待した波形が出れば重要な機能は完了です。
完成に至るには、PICからパソコン側にデータ送信の要求を送ったり、コマンドでfpsのモードを切り替えたりと課題は残っていますが、ハードウェアとデバイスドライバ的な部分がまとまればハードルは低くなります。
ちなみに、今作っているのはシリアルで受信したバイトデータを差動バイフェーズで出力するだけの物ですから、TASCAMのプレーヤーのリモコンと組み合わせることも可能(正しくは不可能ではない)です。曲ごとのタイムコードをユニークする方法を考えなければなりませんが、これはこれで欲しい一品です。
当然リモコンはフルスクラッチとなりますが、出来るだけ音響さんの環境を変えないためにこういった発想もありかなと。
#PIC #タイムコード
2023年4月 この範囲を時系列順で読む この範囲をファイルに出力する
お陰様で本業が忙しい今日この頃です。
部下が照明の空打ちをしていた時に話していたのですが、CUEの送りを曲に合わせて自動化出来ないかとのこと。
ストリートダンス系の仕事が頻繁にあるのですが、打ち込みはいいとしても本番オペが案外大変。照明のリクエストをしてくるのが振付をしている指導者ですから要望が年々細かくなってきているのです。さらに、多いと60曲はある長い本番を最後まで集中し続けるのは現実的ではありません。
１曲あたりのリクエスト数を制限する手もありますし、リクエストに100%応えているワケでもありませんが、空打ちの際にタイミングもプログラム出来たらってことです。
音源に則したタイムコードを得ることが王道でしょうか。音源をモノラルにしてタイムコードも録音するのが常套手段としても、誰がその編集をすんだって話。
ようやく本題ですが、mp3プレーヤーからタイムコード(SMPTE12M-LTC)が出ないかなと思った次第。
そんなアプリがあればいいのですが、RaspberryPiで作れのでしょうかね。mp3やWAVファイルの再生は可能ですし、タイムコードを吐き出すことも可能です。可能なモノをミックスすればいいのでプログラムは作れると思われます。
#本業 #RaspberryPi
部下が照明の空打ちをしていた時に話していたのですが、CUEの送りを曲に合わせて自動化出来ないかとのこと。
ストリートダンス系の仕事が頻繁にあるのですが、打ち込みはいいとしても本番オペが案外大変。照明のリクエストをしてくるのが振付をしている指導者ですから要望が年々細かくなってきているのです。さらに、多いと60曲はある長い本番を最後まで集中し続けるのは現実的ではありません。
１曲あたりのリクエスト数を制限する手もありますし、リクエストに100%応えているワケでもありませんが、空打ちの際にタイミングもプログラム出来たらってことです。
音源に則したタイムコードを得ることが王道でしょうか。音源をモノラルにしてタイムコードも録音するのが常套手段としても、誰がその編集をすんだって話。
ようやく本題ですが、mp3プレーヤーからタイムコード(SMPTE12M-LTC)が出ないかなと思った次第。
そんなアプリがあればいいのですが、RaspberryPiで作れのでしょうかね。mp3やWAVファイルの再生は可能ですし、タイムコードを吐き出すことも可能です。可能なモノをミックスすればいいのでプログラムは作れると思われます。
#本業 #RaspberryPi
「オジサンの休日」はツボです。
最近はアップの頻度が月に2-3回に減ったのが残念ですが、専業youtuberさんではない家族持ちの本業持ちのお方がここまでやるのは尊敬します。
その昔はサザエさんを観ると月曜日が怖くなったものですが、オジサンのチャンネルを観る様になってからは日曜日が待ち遠しくなってます。
#雑談
３Ｄプリンタが不調です。
起動直後は正常ですが、しばらくするとプラットホームの温度が０度を示すかエラーを吐いてプリントが止まります。以前は極稀な現象でしたが、徐々に頻度が増えてきて、昨日今日は毎回発生してプリントが終わらなくなりました。
原因は不明ですが、プラットホームの温度を測るサーミスタ(温度抵抗)が寿命かもしれません。サーミスタに寿命あるとは思ってもいませんでしたが、先達の書き込みによると連続運転での寿命は１～３年とのこと。購入したのは５年くらい前ですから使用頻度を考えればそんなもんかなと。
プリンタの買い替えも視野に入れていますが、その前にサーミスタを交換してみます。定格は不明ですが、壊れかけながらも正常な値を示しているであろう室温で98kΩ前後を示しますので100ｋΩの物と思われます。形状とサイズは表面実装3216(JIS)サイズですが、基板のパターンは2012(JIS)サイズでも取り付けられそうです。表面実装タイプは最大でも100kΩなので、定格を間違っても壊れることは無いと思います。
追記
国内で探したところ1608(JIS)サイズばかりです。さすがに小さすぎて基板のパターンに合いません。
中華電機に3216(JIS)サイズの100kがありましたので発注。最小単位50個です。送料含めて1,000円以下なので許容範囲ですが、この数をどうしろと・・・。安いのは有難いことですが、中華電機で部品を求めると数が多くて困ることが少なくありません。サーミスタのハンダ付けは温度条件が厳しいので、失敗しても構わないと思えばいいのかもしれませんけどね。
配送予定は4/20です。このところ配送が早い中華電機に期待しますが、３Ｄプリンタ作業はしばらく中断です。
追記
4/20到着予定のサーミスタが4/10に届きました。
早い！
#３Ｄプリンタ
起動直後は正常ですが、しばらくするとプラットホームの温度が０度を示すかエラーを吐いてプリントが止まります。以前は極稀な現象でしたが、徐々に頻度が増えてきて、昨日今日は毎回発生してプリントが終わらなくなりました。
原因は不明ですが、プラットホームの温度を測るサーミスタ(温度抵抗)が寿命かもしれません。サーミスタに寿命あるとは思ってもいませんでしたが、先達の書き込みによると連続運転での寿命は１～３年とのこと。購入したのは５年くらい前ですから使用頻度を考えればそんなもんかなと。
プリンタの買い替えも視野に入れていますが、その前にサーミスタを交換してみます。定格は不明ですが、壊れかけながらも正常な値を示しているであろう室温で98kΩ前後を示しますので100ｋΩの物と思われます。形状とサイズは表面実装3216(JIS)サイズですが、基板のパターンは2012(JIS)サイズでも取り付けられそうです。表面実装タイプは最大でも100kΩなので、定格を間違っても壊れることは無いと思います。
追記
国内で探したところ1608(JIS)サイズばかりです。さすがに小さすぎて基板のパターンに合いません。
中華電機に3216(JIS)サイズの100kがありましたので発注。最小単位50個です。送料含めて1,000円以下なので許容範囲ですが、この数をどうしろと・・・。安いのは有難いことですが、中華電機で部品を求めると数が多くて困ることが少なくありません。サーミスタのハンダ付けは温度条件が厳しいので、失敗しても構わないと思えばいいのかもしれませんけどね。
配送予定は4/20です。このところ配送が早い中華電機に期待しますが、３Ｄプリンタ作業はしばらく中断です。
追記
4/20到着予定のサーミスタが4/10に届きました。
早い！
#３Ｄプリンタ
2023年2月 この範囲を時系列順で読む この範囲をファイルに出力する
諸々イイ感じに書き進められていますが、処理タイミングという一見簡単そうで実は面倒なことに取り組んでいます。
先日作ったキー入力処理と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で様々なことを実現出来ている要因だったりします。処理タイミングの管理はとても重要です。
#Ｃ言語
2023年1月 この範囲を時系列順で読む この範囲をファイルに出力する
VSCodeのSSH環境作りは予想外に簡単でした。
自宅でファイルサーバーになっているRaspberryPiに接続してC言語の実習をしております。
まずは基本であり多用するであろうポインタによる関数の呼び出し方です。ポインタはその昔挫折した要素でありますが、どうも勘違いのままアタマに刷り込まれてしまったようで、わかっているつもりなのに間違った組み立てが浮かんできます。これは正しい組み方を刷り込み直すしかありませんので、自分なりの課題で実験を繰り返すしかありません。
つい先ほど整理出来たのですが、ポインタ変数は定義した直後はnull値であって特定のアドレスは持っていません。int *num では実体の変数は定義されないということがわかったのですが、正にこういった点がその昔の勘違いなんですよね。「ポインタは実体変数の扱いを補助するための機能」という前提がアタマに入ったのでスッキリしました。「実体ではない」ということが明確になっただけでも私の中では大革命です。
あと、インクリメントとデクリメントについてメモ。
C言語では++numと書かないと期待値になりません。雰囲気的にnum++と書いてしまいがちですが、エラーにならんのにインクリメントされんのです。
デクリメントも--numとしないといけません。
計算記号が行頭にあっていいのかって疑問が湧きますが、慣用句として覚えておきましょう。
それにしてもVSCode+SSH+gcc+gdb環境は便利ですねぇ。
コンパイルから実行までの手数や所要時間が画期的に短い。エラーも丁寧に教えてくれるし、メモリがマネージされているからヘタなモノ書いてもシステムが飛ぶこともない。スクリプト言語をチョイチョイ書いているのと大差ありません。
デバッカーのお世話になるレベルになるにはまだまだかかりそうですが、こんなに簡単にＣ言語が扱えるなんて私の中では画期的過ぎです。25年前と一緒にすんなって話ですけどね。
#Ｃ言語
自宅でファイルサーバーになっているRaspberryPiに接続してC言語の実習をしております。
まずは基本であり多用するであろうポインタによる関数の呼び出し方です。ポインタはその昔挫折した要素でありますが、どうも勘違いのままアタマに刷り込まれてしまったようで、わかっているつもりなのに間違った組み立てが浮かんできます。これは正しい組み方を刷り込み直すしかありませんので、自分なりの課題で実験を繰り返すしかありません。
つい先ほど整理出来たのですが、ポインタ変数は定義した直後はnull値であって特定のアドレスは持っていません。int *num では実体の変数は定義されないということがわかったのですが、正にこういった点がその昔の勘違いなんですよね。「ポインタは実体変数の扱いを補助するための機能」という前提がアタマに入ったのでスッキリしました。「実体ではない」ということが明確になっただけでも私の中では大革命です。
あと、インクリメントとデクリメントについてメモ。
C言語では++numと書かないと期待値になりません。雰囲気的にnum++と書いてしまいがちですが、エラーにならんのにインクリメントされんのです。
デクリメントも--numとしないといけません。
計算記号が行頭にあっていいのかって疑問が湧きますが、慣用句として覚えておきましょう。
それにしてもVSCode+SSH+gcc+gdb環境は便利ですねぇ。
コンパイルから実行までの手数や所要時間が画期的に短い。エラーも丁寧に教えてくれるし、メモリがマネージされているからヘタなモノ書いてもシステムが飛ぶこともない。スクリプト言語をチョイチョイ書いているのと大差ありません。
デバッカーのお世話になるレベルになるにはまだまだかかりそうですが、こんなに簡単にＣ言語が扱えるなんて私の中では画期的過ぎです。25年前と一緒にすんなって話ですけどね。
#Ｃ言語