https://www.densokogei.jp/tegalog/tegalog.cgi ja Copyright 2026 Fri, 24 Apr 2026 07:46:09 +0900 Powered by てがろぐ Ver 3.4.0 ]]> 　ディナーショーの現地照明をいただいているホテルさんは学者様の学会で忙しいらしく今期は控えるとか、暑いから時期をずらしますって野外イベントだとか、開店休業ってほどではありませんが少しノンビリした夏であります。

　９月上旬には納品しなければならない開発案件があります。
　DMX切替器ですが、新規に１台とHOLDを搭載しないといけません。
　HOLDは２バンクのスタックに延々と受信値を保存して出力し、親からHOLD信号を受けたらスタックの更新を止めるって機能です。
　基板の入荷に１０日くらいみないといけませんので、まずは基板を描いて入稿しましょう。

#器具の製作 -- Posted by 電装工芸 〔306文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=1096 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=1096 tegalog Sat, 26 Jul 2025 12:53:44 +0900 　これは基本情報です。

　課題は Windows サイズに合わせて Table のカラム幅を自動調整する方法です。
　純正のドキュメントには解決策が無くネットをしばらく徘徊。
　結論から言うと解決したのですが、Tkinter のパラメータを PySimpleGUI から直接操作すると思われるコマンドでカラム幅を直接指定しました。
　Tkinter を知らないので全く理解出来ていませんが、先達の例文にあった定型文を試したところビンゴでした。
　細かい調整は沢山ありますが、根本的なところは解決したので一安心です。

#Python -- Posted by 電装工芸 〔301文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=672 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=672 tegalog Wed, 26 Jul 2023 20:41:47 +0900 　困ったような仕方ないような。

　さて、合間に調べモノと妄想はしています。
　課題は PysimpleGUI のウィンドウのサイズを変更しても画面レイアウトを成立させるにはどうするかです。

　まずは基本情報の位置とサイズの取得です。
　位置(左上の角)は sg.window.current_location() を用います。Tupleで(width, height)を取得出来ます。
　ウィンドウサイズを取得するには sg.window.size を用います。Tupleで(width, height)を取得出来ます。ちなみに size の後にカッコは入れません。
　ウェジットのサイズも同様の方法で取得出来ます。
　ただ、PysimpleGUIはウェジットのサイズ指定が文字数/行数単位とピクセル単位が混在していますので、取得したサイズ情報からウェジットのサイズ指定をどのようにするか熟慮しないといけません。

#Python -- Posted by 電装工芸 〔438文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=671 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=671 tegalog Wed, 26 Jul 2023 11:52:24 +0900 　これは表面実装部品を多用しているのでリフローの条件が整わないとどうにもならなかったのです。
　リフローでこれに付ける部品はチップ抵抗とチップコンデンサですから温度条件は比較的緩い。185度のソルダーペーストでも部品は持つと思いますので、138度のを使えば比較的簡単に出来そうです。

　このSPI-DMXはRaspberryPiからレガシーDMXを出力するためのインターフェースです。PICのファームウェアを書かなければなりませんし、トリッキーな処理の検証もあるので完成まで時間がかかりますが、最終的にはArt-Netデコーダになるので速やかに進めたいですね。LCDディスプレイモジュールをI2C化するのもこれに使いたいからだったりしますが・・・。

#電子工作 -- Posted by 電装工芸 〔380文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=342 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=342 tegalog Tue, 26 Jul 2022 23:42:25 +0900 　熱電対温度計で計測しながらの作業です。

　まず100度設定でオーブン自体の予熱。外装が暖かくなるまで行い、庫内温度が85度くらいになるようにする。
　物を入れてダイヤルを140度にし、庫内温度が100度になるまで待つ。
　庫内温度が100度になったらダイヤルを100度にし90秒計測開始。この間、庫内温度が100～110度を維持する様に操作する。
　90秒経ったらダイヤルを180度にし、ソルダーペーストを観察。
　庫内温度が150度近くになるとソルダーペーストが熔け始めるのがわかる。
　庫内温度が160度になったらダイヤルを100度まで下げ20秒計測開始。この時間ならヒーターの残熱で庫内温度が上がるくらいですが、160～170度を維持するように操作。180度は越えない方がいい。
　20秒経ったら(30秒を越えない様に注意)オーブンの電源を落としフタを開いて冷却。
　素手で触れるくらいに冷めたら完成。

　ハンダの溶ける様が分かりやすいので思ったより簡単で、前回の様にLEDの樹脂が変形することなく綺麗にハンダが付きました。
　185度のソルダーペーストと違い部品の耐熱温度に対して十分に余裕のある温度ですから、高すぎず長すぎずに注意しながらも十分に余熱をし、160～170度20秒間をキッチリやればよいようです。予熱後から最高温度までの過程はオーブンの成り行きに任せてＯＫ。部品を100度以上の環境にさらす時間は3分以内ってイメージも大事かもしれません。

#ガチ工作 #電子工作 -- Posted by 電装工芸 〔688文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=341 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=341 tegalog Tue, 26 Jul 2022 23:20:38 +0900 　BFで送受信の終了を監視し、SSPIF(ACKの終了)を監視してCKPをセットすれば良いっちゃ良いのだけど、不可能ではないけど面倒くさい処理の典型と化します。
　クロックストレッチングを使わなくても(ACKの直後に次の送受信が始まっても)動く様にしておけばよいのはわかっていますが、PICのI2Cはクロックストレッチングが前提の構成(特にスレーブ送信)だし、RaspberryPiに限った問題なのでi2c-gpioを使ってクロックストレッチングを用いた方が素直な気がします。i2c-gpioが凄い足かせになるワケでもないようですし。

追記
　どうにもモヤモヤするのでクロックストレッチングを使わない方法を考え続けてみました。帰りの車中は考え事に最適です。
　条件を整理します。RaspberryPiのI2CがクロックストレッチングをしてくれないのですからPIC側の条件です。
　タイミングチャートを読みますと、ACKのクロック(ワードの９クロック目)の立下りで割り込みフラグSSPIFがアクティブになった後、次のワードの最初のクロックの立ち上がりまでに送受信のコンディションを整えられれば何事もなく次のワードが扱えるようです。これはSSPIFで割り込みが発生してから半クロック分の時間が使えるとも言えます。I2Cのビットレートは一意ではありませんが、標準的なビットレートである100kbpsに限って考えるなら半クロックは5usec。32MHz動作のPICなら40命令ステップに相当する時間です。
　PICは割り込みの入りと出にパイプラインロスが発生するのでそれぞれ１命令ステップが消費され、I2CのクロックとPICの動作クロックは同期していないし信号の立ち上がり立下り時間もあるので２命令ステップくらいの誤差は起こりえます。となると実処理のために使える命令ステップ数は最大で36程度です。
　ザックリと考えるならSSPIFで割り込みに入ってから30命令ステップ以内に送受信コンディションを整えて割り込みから抜ければよいのでは？となる。
　30命令ステップあれば書き込み(RaspberryPi→PIC)は間に合いそうです。
　I2Cは１フェーズ内では読み出しか書き込みかどちらかしか出来ませんので、Pythonの読み出しコマンド(PIC→RaspberryPi)はI2Cにおいて２フェーズ(１つ目のフェーズでコマンドや読み出すアドレスを書き込み、２つ目のフェーズでデータを読み出す)で実行されます。すなわち、PICが受け取ったワードをキーに処理して次のワードで即応する必要はありません。受け取るだけ受け取ってから処理をし、次の返信フェーズに備えればいいのです。もし鬼連続でコールされても２つ目の読み出しフェーズでデバイスアドレスを送受信する時間は返信データを作るのに使えます。１ワードは9bit分ですから100kbpsなら720usecです。足りる足りないではなくこの時間で済むように作ればいいのです。つか、PICにとっては5,760命令ステップに相当する時間です。私はPIC16をアセンブラで書きますが、5000ステップ以上の処理など書きたくもない・・・。
　割り込みベクタが一つしかないPIC16系で多重割り込みをするとI2Cのタイミングを外す可能性があります。他の処理はポーリングとなりますが、DMX512の送受信や位相制御のトリガー処理もポーリングで十分間に合っているので問題ないっしょ。むしろPIC１個にそんな沢山の仕事させるなってね(笑

　あれ？クロックストレッチングを使わないで組めそうな気がしてきた。

　なんのことやらオレメモ暴走独り言ですみません。

#RaspberryPi #電子工作 -- Posted by 電装工芸 〔1606文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=340 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=340 tegalog Tue, 26 Jul 2022 18:12:04 +0900 　2022年7月現在、Broadcom社製のBCMシリーズを使ったRaspberryPiは総じてダメなようで、ソフトウェアデバイスであるi2c-gpioを使うのが有効な対策だと思います。
　もちろん、ハードウェアデバイスに比べたらCPUに負担がかかるので、CPU負荷が多いシステムやI2Cメモリなどの扱うデータ量が多いデバイスでの使用は避けるべきかもしれません。
　あくまで、扱いデータ量が比較的少なく多少の遅延が発生しても支障がない機内通信で使うのがよいと思われます（I2Cはそもそもそういうモノらしいですけど）。

　今回はPICをインターフェースとして用い、パラレルバスのLCDキャラクタディスプレイ(SC1602やSC2004を用いた製品)をI2Cで接続しANSIエスケープシーケンスっぽいASCII文字列で制御できるシステムを目指します。
　もちろん、UART(シリアル)でも動く様に考えます。8PのDIPスイッチを取り付け、1PでI2C/UARTを選択し、残りの7PでI2CのアドレスやUARTのビットレートを設定できる様にすれば汎用性が高まるでしょう。

#RaspberryPi #電子工作 -- Posted by 電装工芸 〔560文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=339 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=339 tegalog Tue, 26 Jul 2022 10:58:55 +0900