電装工芸日記
- 舞台照明機器の製作とか -
2022年7月 この範囲を時系列順で読む この範囲をファイルに出力する
ようやくですが、138度の低融点ソルダーペーストでリフローを試してみました。
熱電対温度計で計測しながらの作業です。
まず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分以内ってイメージも大事かもしれません。
#ガチ工作 #電子工作
熱電対温度計で計測しながらの作業です。
まず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分以内ってイメージも大事かもしれません。
#ガチ工作 #電子工作
RaspberryPiのハードウェアI2Cをマスタにしてどうにかならないかと考えてみました。
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 #電子工作
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 #電子工作
クロックストレッチングについて改めて調べましたが、最新のRaspberryPiで治っている情報はありません。
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 #電子工作
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 #電子工作
ちょいと調べたところ、RaspberryPiのI2Cにはバグがあってクロックストレッチングが機能しないとか・・・マジかい！？
確かに、クロックストレッチングを多用すると噂のジャイロセンサBMX055を扱った時に数値が変だったりしたかも。
i2c-gpioと呼ばれるソフトウェアI2Cを使えばクロックストレッチングが機能するとのことですが、こんな大事な機能にバグがあるとは困ります。
クロックストレッチングを使わなくても機能する様にPIC側を作ればいいか。100kbpsならACKの間に10usecありますから、割り込みを使い5usec程度で処理すれば大丈夫と言えば大丈夫です。複雑な返信はしませんしね。
#電子工作 #RaspberryPi
確かに、クロックストレッチングを多用すると噂のジャイロセンサBMX055を扱った時に数値が変だったりしたかも。
i2c-gpioと呼ばれるソフトウェアI2Cを使えばクロックストレッチングが機能するとのことですが、こんな大事な機能にバグがあるとは困ります。
クロックストレッチングを使わなくても機能する様にPIC側を作ればいいか。100kbpsならACKの間に10usecありますから、割り込みを使い5usec程度で処理すれば大丈夫と言えば大丈夫です。複雑な返信はしませんしね。
#電子工作 #RaspberryPi
これまではPIC16系でI2Cを扱う方法はデータシートを読んでも理解出来なかったのですが、次のページのサンプルプログラムを読みながらフラグの意味を整理したところなんとなくわかってきました。
「Ｉ２Ｃのスレーブモードの使い方」
サンプルソースはPIC18系っぽいですが、違いを読み変えればPIC16系のサンプルにもなります。
SPIもそうですが、シフトレジスタ系の通信方法で重要なことは受信値を処理して次の受信コンディションが整うまで送信を一次停止させることです。
I2Cではこの処理をハードウェア的に行うことが可能です。SSPCON2:SENをセット(フラグを1に)しておくと１バイトの受信が終わったところでクロックストレッチングと呼ばれる一時停止がハードウェア的に自動発生するモードになります。クロックストレッチングを解除し受信コンディションにするにはSSPCON1:CKPをセットするだけです。
スレーブ受信処理の流れは、
１）SSPCON2:SENとSSPCON1:CKPをセットして受信コンディションにする（SSPCON2:SENのセットは初期化処理の時だけでいい）
２）バイトデータが受信されたらSSPBUFからデータを取り出す(この時点でSSPCON1:CKPはハードウェアでクリアされクロックストレッチングが発生している)
３）データを取り出したら(取り出したデータの処理が済んだら)SSPCON1:CKPをセットし次の受信コンディションにする
４）以下、ストップビットが検出されるまで(2)から繰り返し
となります。
スレーブ送信(返信)の場合も同様で、所定のレジスタにデータを入れた後、SSPCON1:CKPをセットするとマスターがクロックを刻み始めて送信となります。
所定のレジスタにデータを入れると自動的にSSPCON1:CKPがセットされて送信が始まるモードもあるようです。
ただ、SSPCON3:AHENとSSPCON3:DHENの意味がわかったようなわからないような状況です。両方ともクリア(=0)で良いような気もしますが、便利機能かもしれないのでデータシートを良く読んで整理しましょう。
I2Cは敷居が高いイメージがありましたが、ハードウェアによる自動処理が多くソフトウェアで細かいタイミングを考える必要が無いため、この調子で整理していけば案外簡単に使えるかもしれません。
PICでI2Cを扱うことが可能になれば、今回のパラレルバスLCDなどのI2Cに対応していないデバイスをI2C化することが容易になります。
通信速度や即応性、RTOS的なリアルタイム性を求めるのは難しいと思われますが、7bitアドレスのノーマルモードでもI2Cバス上に126個のデバイスを置けますので、RaspberryPi、Arduino、ESP32などの製作の幅が広がるような気がします。
#電子工作
「Ｉ２Ｃのスレーブモードの使い方」
サンプルソースはPIC18系っぽいですが、違いを読み変えればPIC16系のサンプルにもなります。
SPIもそうですが、シフトレジスタ系の通信方法で重要なことは受信値を処理して次の受信コンディションが整うまで送信を一次停止させることです。
I2Cではこの処理をハードウェア的に行うことが可能です。SSPCON2:SENをセット(フラグを1に)しておくと１バイトの受信が終わったところでクロックストレッチングと呼ばれる一時停止がハードウェア的に自動発生するモードになります。クロックストレッチングを解除し受信コンディションにするにはSSPCON1:CKPをセットするだけです。
スレーブ受信処理の流れは、
１）SSPCON2:SENとSSPCON1:CKPをセットして受信コンディションにする（SSPCON2:SENのセットは初期化処理の時だけでいい）
２）バイトデータが受信されたらSSPBUFからデータを取り出す(この時点でSSPCON1:CKPはハードウェアでクリアされクロックストレッチングが発生している)
３）データを取り出したら(取り出したデータの処理が済んだら)SSPCON1:CKPをセットし次の受信コンディションにする
４）以下、ストップビットが検出されるまで(2)から繰り返し
となります。
スレーブ送信(返信)の場合も同様で、所定のレジスタにデータを入れた後、SSPCON1:CKPをセットするとマスターがクロックを刻み始めて送信となります。
所定のレジスタにデータを入れると自動的にSSPCON1:CKPがセットされて送信が始まるモードもあるようです。
ただ、SSPCON3:AHENとSSPCON3:DHENの意味がわかったようなわからないような状況です。両方ともクリア(=0)で良いような気もしますが、便利機能かもしれないのでデータシートを良く読んで整理しましょう。
I2Cは敷居が高いイメージがありましたが、ハードウェアによる自動処理が多くソフトウェアで細かいタイミングを考える必要が無いため、この調子で整理していけば案外簡単に使えるかもしれません。
PICでI2Cを扱うことが可能になれば、今回のパラレルバスLCDなどのI2Cに対応していないデバイスをI2C化することが容易になります。
通信速度や即応性、RTOS的なリアルタイム性を求めるのは難しいと思われますが、7bitアドレスのノーマルモードでもI2Cバス上に126個のデバイスを置けますので、RaspberryPi、Arduino、ESP32などの製作の幅が広がるような気がします。
#電子工作
色んなデバイスを考えますと表示装置は避けて通れない課題となります。
数個のLEDで済む事もありますが、ガッツリモニタを組まないといけない事もあります。この中間が望ましいこともあります。
案外必要にして十分なのが16字×2行や20字×4行くらいのLCDディスプレイモジュールです。ただ、制御は難しくありませんが、パラレル信号なので面倒が少なくありません。ならばエスケープシーケンスをシリアルやI2cで受けて動く様にしたらどうかと。PICでインターフェースを作るワケです。
幸い16F1939が沢山あるのでコレを使えばI/Oピンに余裕を持って作れます。
色んなアイデアを出しても製作が進まないのは補助的な周辺機器を作らんからかもしれません。
#ガチ工作 #電子工作
数個のLEDで済む事もありますが、ガッツリモニタを組まないといけない事もあります。この中間が望ましいこともあります。
案外必要にして十分なのが16字×2行や20字×4行くらいのLCDディスプレイモジュールです。ただ、制御は難しくありませんが、パラレル信号なので面倒が少なくありません。ならばエスケープシーケンスをシリアルやI2cで受けて動く様にしたらどうかと。PICでインターフェースを作るワケです。
幸い16F1939が沢山あるのでコレを使えばI/Oピンに余裕を持って作れます。
色んなアイデアを出しても製作が進まないのは補助的な周辺機器を作らんからかもしれません。
#ガチ工作 #電子工作
ちょっと気になって「ESP32」について調べてみました。
IoT向けの汎用マイコンです。安価な割に処理能力が高く、wi-fiでIPネットワークが組めて、私にとってはRaspberryPiとPICマイコンの間を埋められる製品だと思われます。
Arduinoの使用も考えたことはあるのですが、私にとってはPICマイコンをアセンブラで書いた方が手っ取り早く、ケースバイケースのハードウェア製作ではArduinoだとパッケージの調整が面倒です。画期的で素晴らしい製品だと思いますが、私にとっては立ち位置が中途半端です。
RaspberryPiも含め、この手のマイコン製品は開発環境が重要です。安価で高性能でも開発環境がボトルネックになってアマチュア界隈では普及しなかったマイコン製品は少なくありません。AVR対PICにおいても高性能なAVRよりも少し劣るPICなのは開発環境の影響です。AVRはArduinoの本体なので別な意味で普及はしていますけどね。ESP32はArduinoの開発環境が使えます。Arduinoではありませんが、ArduinoIDEに開発ライブラリを追加すればほぼ同じに使えるようです。間借りと言えば間借りで、関数ライブラリに違いはありますが、ほぼ同じ使用感。Arduionoを使える人ならわずかな違いを勉強すれば使えてします。これは画期的かもしれません。
Arduino言語はANSI-Cがベースでフル実装でないもののC++っぽいオブジェクト指向な書き方も出来る言語です。基本書式と変数の考え方がANSI-Cと同じマクロ言語と思えばストレス無く使えそうです。
#電子工作
IoT向けの汎用マイコンです。安価な割に処理能力が高く、wi-fiでIPネットワークが組めて、私にとってはRaspberryPiとPICマイコンの間を埋められる製品だと思われます。
Arduinoの使用も考えたことはあるのですが、私にとってはPICマイコンをアセンブラで書いた方が手っ取り早く、ケースバイケースのハードウェア製作ではArduinoだとパッケージの調整が面倒です。画期的で素晴らしい製品だと思いますが、私にとっては立ち位置が中途半端です。
RaspberryPiも含め、この手のマイコン製品は開発環境が重要です。安価で高性能でも開発環境がボトルネックになってアマチュア界隈では普及しなかったマイコン製品は少なくありません。AVR対PICにおいても高性能なAVRよりも少し劣るPICなのは開発環境の影響です。AVRはArduinoの本体なので別な意味で普及はしていますけどね。ESP32はArduinoの開発環境が使えます。Arduinoではありませんが、ArduinoIDEに開発ライブラリを追加すればほぼ同じに使えるようです。間借りと言えば間借りで、関数ライブラリに違いはありますが、ほぼ同じ使用感。Arduionoを使える人ならわずかな違いを勉強すれば使えてします。これは画期的かもしれません。
Arduino言語はANSI-Cがベースでフル実装でないもののC++っぽいオブジェクト指向な書き方も出来る言語です。基本書式と変数の考え方がANSI-Cと同じマクロ言語と思えばストレス無く使えそうです。
#電子工作
3D-CADとしてFusion360を使っていますが、初めてインストールしてから５年以上経っていますから無料で使うのは難しくなり、昨年からサブスクにしています。サブスクの価格は65,000円/年。機能からすれば妥当な価格だと思いますが、小遣い払いとしては厳しい価格。
フリーな3D-CADには「FreeCAD」があります。私が3D-CADを使い始めた当時ではFusion360が実質無料で圧倒的に高性能だったので他に選択肢はありませんでしたが、Fusion360が実質有料化しFreeCADが高機能化したならば改めて比較評価してみる意味はありそうです。
#CAD
フリーな3D-CADには「FreeCAD」があります。私が3D-CADを使い始めた当時ではFusion360が実質無料で圧倒的に高性能だったので他に選択肢はありませんでしたが、Fusion360が実質有料化しFreeCADが高機能化したならば改めて比較評価してみる意味はありそうです。
#CAD
今週は比較的時間に余裕があるのでホール資料の編集です。
今日の課題は小ホール(大練習室)です。約7.5間四方で天井も高いのでリハーサル室としてはかなり贅沢な寸法です。
建築図面を整理することにも随分慣れましたし、線が少ないので、取り急ぎ必要な図面は１日で終わりました。
ちなみにまだ建築中ですが、議員さんの後援者様は内部の見学が出来て、資料を作っている私は立ち入ることが出来ないのはアルアルですね。
#本業
今日の課題は小ホール(大練習室)です。約7.5間四方で天井も高いのでリハーサル室としてはかなり贅沢な寸法です。
建築図面を整理することにも随分慣れましたし、線が少ないので、取り急ぎ必要な図面は１日で終わりました。
ちなみにまだ建築中ですが、議員さんの後援者様は内部の見学が出来て、資料を作っている私は立ち入ることが出来ないのはアルアルですね。
#本業
低融点ソルダーペーストは入荷したのですが、落ち着いて作業する時間が取れずテストは出来ておりません。自宅の冷蔵庫で休憩中です。
#電子工作
#電子工作