電装工芸日記
- 舞台照明機器の製作とか -
全年全月4日の投稿［35件］（2ページ目）
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年前と一緒にすんなって話ですけどね。
#Ｃ言語
Windows上のVSCodeからSSHでRaspberryPiに接続してコードを編集・コンパイル・実行してみました。
コードは俗に言う「Hello, World」。コンソールに簡単な文字列を表示するだけのモノです。
VSCodeはユーザーインターフェースのデザイン更新が頻繁なのか、ネットの解説は出来るだけ新しいモノを参考にしないと見た目が違います。
インストールと設定は次の通り。
まずはRaspberryPi側から。sshでつながることを前提とする。
１）対象となるRaspberryPiをアップデート
$ sudo apt update
$ sudo apt upgrade
２）build-essentialをインストール。
$ sudo apt install build-essential
デバッカーのgdbが必要になる、上記で入らなかったらインストール
$ sudo apt install gdb
Windows(11)側
１）VSCodeをダウンロード
https://code.visualstudio.comってのが本家みたい。
環境に合わせてインストーラーをダウンロード
２）インストール
ダウンロードしたインストーラーを起動して初期設定のまま進めてインストール。選択項目がある場合はよくわからんけど一番上を選択。
３）起動後、機能拡張の日本語パックを入れる（参考ページは呆れるほどあります）
機能拡張のメニューから「Japanese Language Pack for Visual Studio Code」をインストール
インストール後、アプリを再起動すると大半のメニューが日本語になっています。
４）同じく機能拡張の「Remote Development」を入れる
他に必要な機能拡張は自動的に入ります。
５）ssh接続してみる
以下を参考にすれば繋がると思います。
「Visual Studio Codeを使ったC言語リモートコンパイルからリモートデバッグまで」
６）初回接続ではRaspberryPi側にも色々入れるようで少し時間がかかります。
７）この他にも自動的に入った機能拡張がありますが、よくわからんのでここには書きません。
Windows上のVSCodeでコーディング、コンパイル、デバッグ、実行が出来ました。
ブレークポイントありのデバッカーまで使えるのですから、Turbo-CのトラウマでＣ言語を敬遠していた時間が勿体ないと思える程に便利です。
#Ｃ言語
コードは俗に言う「Hello, World」。コンソールに簡単な文字列を表示するだけのモノです。
VSCodeはユーザーインターフェースのデザイン更新が頻繁なのか、ネットの解説は出来るだけ新しいモノを参考にしないと見た目が違います。
インストールと設定は次の通り。
まずはRaspberryPi側から。sshでつながることを前提とする。
１）対象となるRaspberryPiをアップデート
$ sudo apt update
$ sudo apt upgrade
２）build-essentialをインストール。
$ sudo apt install build-essential
デバッカーのgdbが必要になる、上記で入らなかったらインストール
$ sudo apt install gdb
Windows(11)側
１）VSCodeをダウンロード
https://code.visualstudio.comってのが本家みたい。
環境に合わせてインストーラーをダウンロード
２）インストール
ダウンロードしたインストーラーを起動して初期設定のまま進めてインストール。選択項目がある場合はよくわからんけど一番上を選択。
３）起動後、機能拡張の日本語パックを入れる（参考ページは呆れるほどあります）
機能拡張のメニューから「Japanese Language Pack for Visual Studio Code」をインストール
インストール後、アプリを再起動すると大半のメニューが日本語になっています。
４）同じく機能拡張の「Remote Development」を入れる
他に必要な機能拡張は自動的に入ります。
５）ssh接続してみる
以下を参考にすれば繋がると思います。
「Visual Studio Codeを使ったC言語リモートコンパイルからリモートデバッグまで」
６）初回接続ではRaspberryPi側にも色々入れるようで少し時間がかかります。
７）この他にも自動的に入った機能拡張がありますが、よくわからんのでここには書きません。
Windows上のVSCodeでコーディング、コンパイル、デバッグ、実行が出来ました。
ブレークポイントありのデバッカーまで使えるのですから、Turbo-CのトラウマでＣ言語を敬遠していた時間が勿体ないと思える程に便利です。
#Ｃ言語
2022年11月 この範囲を時系列順で読む この範囲をファイルに出力する
カゲ段はこんなモノです。
１×３の平台を使った１尺４寸用の構成です。段差は４寸７分くらいです。
薄ゲタと呼ぶ７分高の角材を付けた１段目、中箱と仮に呼ぶ５寸３分４厘を取り付けた２段目です。
中箱は１尺×７寸の合板(４分厚=12mm)と４寸５分４厘(１寸５分角)の角材を組み合わせた物ですが、平台の側面の穴と角材にクランプを当てて連結出来ます。当初はボルト連結も考えたのですが、工作精度や床の平面精度を考えると許容誤差が大きい大雑把なのがいいかなと。
写真では空いていませんが、箱の合板にも同様の穴を空けて上下連結出来る様にします。２尺１寸用の３段目は５寸３分４厘の中箱と６寸５分の高箱を重ねて使うからです。
#ガチ工作 #本業
１×３の平台を使った１尺４寸用の構成です。段差は４寸７分くらいです。
薄ゲタと呼ぶ７分高の角材を付けた１段目、中箱と仮に呼ぶ５寸３分４厘を取り付けた２段目です。
中箱は１尺×７寸の合板(４分厚=12mm)と４寸５分４厘(１寸５分角)の角材を組み合わせた物ですが、平台の側面の穴と角材にクランプを当てて連結出来ます。当初はボルト連結も考えたのですが、工作精度や床の平面精度を考えると許容誤差が大きい大雑把なのがいいかなと。
写真では空いていませんが、箱の合板にも同様の穴を空けて上下連結出来る様にします。２尺１寸用の３段目は５寸３分４厘の中箱と６寸５分の高箱を重ねて使うからです。
#ガチ工作 #本業
2022年10月 この範囲を時系列順で読む この範囲をファイルに出力する
忘れないウチにインターカム・パワーサプライの回路図を描いてみました。
基板化する都合で電源モジュールと切替スイッチは記載しておりません。
クリアカムと称すると面倒がありそうなので、インターカム(Inter-Com)としています。
一日に1-2時間、気分転換として触るには良いネタです。
#電子工作
基板化する都合で電源モジュールと切替スイッチは記載しておりません。
クリアカムと称すると面倒がありそうなので、インターカム(Inter-Com)としています。
一日に1-2時間、気分転換として触るには良いネタです。
#電子工作