電装工芸日記
- 舞台照明機器の製作とか -
全年全月1日の投稿(時系列順)［35件］（3ページ目）
2023年1月 この範囲を新しい順で読む この範囲をファイルに出力する
新年あけましておめでとうございます
本年もよろしくお願い申し上げます
さて、さかのぼること大晦日の夕方、実家に顔を出そうと思ったのですがどうも熱っぽい。計ると37.2度。
ダルさは若干あるものの、抜けきっていない疲れなのか、流行り病の前兆なのかわかりません。
大事を取って自宅に引きこもり。
暇なんでRaspberryPiをＣ言語で開発する環境についてアレコレ調べています。
大晦日に何してんの？って突っ込みは正しいと思いますが、外出出来ないのだから仕方ない。
PythonはTeraTermでSSH接続してRaspberryPi上のViとかnanoとかで書いていました。debianに標準搭載のテキストエディタです。Windows上で操作すればコピペも出来るので特に不自由はありませんが、色々調べるウチにVSCodeが便利そうで使いたくなりました。Ｃ言語はカッコや行末のセミコロンを忘れてコンパイルエラーになることが多いのですが、これを防止する為だけに使っても意味があります。
世の中進歩するというか便利なツールを作ってくれる貴兄がおりまして、VSCodeはプラグインを入れるとSSHで完全にリモート操作が出来る。コーディングはもちろんのこと、コンパイルもデバッグも出来るとのこと。すばらしい。
Visual Studio Codeを使ったC言語リモートコンパイルからリモートデバッグまで
ゼロから設定するなら本文中にあるリンク「参考にした解説」も読む必要があります。
Visual Studio CodeでLinux ホストリモート開発
ちょっと面倒ですが、SSHでリモート開発したいなんて考える人ならそれほど苦にならないでしょう。
VSCodeは様々な言語をサポートしてくれる超絶強力なコーディングエディタです。
#Ｃ言語
本年もよろしくお願い申し上げます
さて、さかのぼること大晦日の夕方、実家に顔を出そうと思ったのですがどうも熱っぽい。計ると37.2度。
ダルさは若干あるものの、抜けきっていない疲れなのか、流行り病の前兆なのかわかりません。
大事を取って自宅に引きこもり。
暇なんでRaspberryPiをＣ言語で開発する環境についてアレコレ調べています。
大晦日に何してんの？って突っ込みは正しいと思いますが、外出出来ないのだから仕方ない。
PythonはTeraTermでSSH接続してRaspberryPi上のViとかnanoとかで書いていました。debianに標準搭載のテキストエディタです。Windows上で操作すればコピペも出来るので特に不自由はありませんが、色々調べるウチにVSCodeが便利そうで使いたくなりました。Ｃ言語はカッコや行末のセミコロンを忘れてコンパイルエラーになることが多いのですが、これを防止する為だけに使っても意味があります。
世の中進歩するというか便利なツールを作ってくれる貴兄がおりまして、VSCodeはプラグインを入れるとSSHで完全にリモート操作が出来る。コーディングはもちろんのこと、コンパイルもデバッグも出来るとのこと。すばらしい。
Visual Studio Codeを使ったC言語リモートコンパイルからリモートデバッグまで
ゼロから設定するなら本文中にあるリンク「参考にした解説」も読む必要があります。
Visual Studio CodeでLinux ホストリモート開発
ちょっと面倒ですが、SSHでリモート開発したいなんて考える人ならそれほど苦にならないでしょう。
VSCodeは様々な言語をサポートしてくれる超絶強力なコーディングエディタです。
#Ｃ言語
2023年2月 この範囲を新しい順で読む この範囲をファイルに出力する
自作のライブラリを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]
先達の情報をいくつか合成しましたが、思った以上に簡単でした。
ネットワークインターフェースの指定も出来ました。
一安心ですが、次は送信しないといけません。
デコード/エンコードをせずに受信値をリレーするだけですが、これが成功しないようでは受信値を加工する努力をしても意味がありません。
#[Art-Net]
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] #Ｃ言語
2023年3月 この範囲を新しい順で読む この範囲をファイルに出力する
商売柄ＣＤを大量に焼くことがあります。
今となっては選挙委員会からの依頼がメインですが、外注するには少ないけど手焼きするにはそこそこという枚数です。
これをやるにはデュプリケーターを使うのが王道ですが、ドライブを限界まで搭載したパソコンを使う手もあります。所属会社ではデュプリケーターがとても高価だった時代の名残りでそういうパソコンを使っています。
ところがです、このパソコンがどうも不調。動くには動くけれどエラーで頻繁に止まる。あまりに頻発するので改めてチェックしたところメモリーが不良。正しくはマザーボードのDIMMスロットの一つがダメのようです。
メモリの搭載量は減るものの、不良と思われるスロットを使わないセッティングにして回復。
改めてメモリーチェックをしていますがエラーは出ていません。動作も快調です。
必ずしもではありますが、不調のパソコンはメモリーチェックをした方がいいですね。
不調ならメモリを交換するか機体の入れ替えとなりますが、原因を特定するには良い方法です。
WindowsならOSの機能にありますし、重チェックをしたいならMemtest86というフリーウェアがお勧めです。
#パソコン
今となっては選挙委員会からの依頼がメインですが、外注するには少ないけど手焼きするにはそこそこという枚数です。
これをやるにはデュプリケーターを使うのが王道ですが、ドライブを限界まで搭載したパソコンを使う手もあります。所属会社ではデュプリケーターがとても高価だった時代の名残りでそういうパソコンを使っています。
ところがです、このパソコンがどうも不調。動くには動くけれどエラーで頻繁に止まる。あまりに頻発するので改めてチェックしたところメモリーが不良。正しくはマザーボードのDIMMスロットの一つがダメのようです。
メモリの搭載量は減るものの、不良と思われるスロットを使わないセッティングにして回復。
改めてメモリーチェックをしていますがエラーは出ていません。動作も快調です。
必ずしもではありますが、不調のパソコンはメモリーチェックをした方がいいですね。
不調ならメモリを交換するか機体の入れ替えとなりますが、原因を特定するには良い方法です。
WindowsならOSの機能にありますし、重チェックをしたいならMemtest86というフリーウェアがお勧めです。
#パソコン
2023年5月 この範囲を新しい順で読む この範囲をファイルに出力する
2023年6月 この範囲を新しい順で読む この範囲をファイルに出力する
MUSES02D化したDI-1はとても良い音ですが、どこか物足りない。オペアンプが鳴りきっていないというか躓いているような気がするのです。勘ですが、入口か出口のコンデンサがMUSES02Dに対して性能不足の様に感じます。
当初はオペアンプの交換に留めようと思ったのですが、コンデンサは安価で元に戻すのも簡単なので試してみようかと。
別な部品と共にコンデンサも手配しました。
#音の世界
当初はオペアンプの交換に留めようと思ったのですが、コンデンサは安価で元に戻すのも簡単なので試してみようかと。
別な部品と共にコンデンサも手配しました。
#音の世界
気分転換にFIFOを書いてみました。初期設定を含めても50行くらいです。
ループメモリを非同期で読み書きする構造ですから、それぞれのアドレスカウンタの扱いが肝です。当初悩んだものの、条件を整理すれば案外簡単でした。アルゴリズムの設計大事です。
こういったモジュールは例外も想定して慎重に動作確認をしなければなりませんが、実機だと確認が難しいのでMPLABXのシュミレータの出番です。ステップ毎のレジスタの変化を観察したいのです。
MPLABXのシュミレーターは使い方がイマイチわからんのですが、操作メニューが違うだけでやることはv8.92と同じでしょうから、先達の書き込みを参考に探ってみます。
追記
シュミレーターの使い方は次のサイトがわかりやすい。というか、この通りにやったらシュミレート出来ました。
MPLAB X の使い方（Simulator編）
MPLABv8.92とはデザインが違いますが、やっていることは同じなので慣れればいいかなと。PICの中身を知らないと何が何やらですけど・・・
テスト用に少し書き換えればFIFOの挙動をチェック出来ます。
#PIC
ループメモリを非同期で読み書きする構造ですから、それぞれのアドレスカウンタの扱いが肝です。当初悩んだものの、条件を整理すれば案外簡単でした。アルゴリズムの設計大事です。
こういったモジュールは例外も想定して慎重に動作確認をしなければなりませんが、実機だと確認が難しいのでMPLABXのシュミレータの出番です。ステップ毎のレジスタの変化を観察したいのです。
MPLABXのシュミレーターは使い方がイマイチわからんのですが、操作メニューが違うだけでやることはv8.92と同じでしょうから、先達の書き込みを参考に探ってみます。
追記
シュミレーターの使い方は次のサイトがわかりやすい。というか、この通りにやったらシュミレート出来ました。
MPLAB X の使い方（Simulator編）
MPLABv8.92とはデザインが違いますが、やっていることは同じなので慣れればいいかなと。PICの中身を知らないと何が何やらですけど・・・
テスト用に少し書き換えればFIFOの挙動をチェック出来ます。
#PIC
FIFOの動作チェックをしました。
バク無し・・・嬉しいような怖いような。
FIFOはループメモリです。例えば10個のメモリを使うなら10個目を書いた後は１個目から書きます。これを続けます。読出しも同じ。
ただ、読出しと書き込みはタイミングがシンクしませんので、読出しが書き込みを追い越さないこと、書き込みは一周以上先行しないことが重要です。これらの確認も出来ました。
処理のタイミングとしては、読出しはLTCの送出に合わせてになりますが、書き込み(パソコンへのデータ要求とも言う)はメモリが空いたら行います。
パソコンとの通信速度がLTCの送信速度より十分に速く、パソコン側のレスポンスも十分に早ければタイミングがズレることはありません。たぶん。
読出しが書き込みに追いついてしまえばデータが無いことになりますので、新しいデータが入るまでLTCを送出しないだけです。
#PIC #タイムコード
バク無し・・・嬉しいような怖いような。
FIFOはループメモリです。例えば10個のメモリを使うなら10個目を書いた後は１個目から書きます。これを続けます。読出しも同じ。
ただ、読出しと書き込みはタイミングがシンクしませんので、読出しが書き込みを追い越さないこと、書き込みは一周以上先行しないことが重要です。これらの確認も出来ました。
処理のタイミングとしては、読出しはLTCの送出に合わせてになりますが、書き込み(パソコンへのデータ要求とも言う)はメモリが空いたら行います。
パソコンとの通信速度がLTCの送信速度より十分に速く、パソコン側のレスポンスも十分に早ければタイミングがズレることはありません。たぶん。
読出しが書き込みに追いついてしまえばデータが無いことになりますので、新しいデータが入るまでLTCを送出しないだけです。
#PIC #タイムコード
2023年11月 この範囲を新しい順で読む この範囲をファイルに出力する
午前中の作業が早く終わって時間が半端に空いたのでLED-Barの脚を組んでみました。
吊るし塗装の状態です。
溶接がヘタクソなのはご愛嬌。こんな溶接がされた物に体を預けたくありませんが、小物の脚ですからいいかなと。
メスダボの内側の防錆をどうするか考えてしまいましたが、缶スプレーを一瞬吹き付けすればいけるようです。ダレないように本当に一瞬ですから数回吹き付ける必要がありそうです。
塗装の前に本体に取り付けてみましたがイイ感じ。
#器具の製作
吊るし塗装の状態です。
溶接がヘタクソなのはご愛嬌。こんな溶接がされた物に体を預けたくありませんが、小物の脚ですからいいかなと。
メスダボの内側の防錆をどうするか考えてしまいましたが、缶スプレーを一瞬吹き付けすればいけるようです。ダレないように本当に一瞬ですから数回吹き付ける必要がありそうです。
塗装の前に本体に取り付けてみましたがイイ感じ。
#器具の製作