電装工芸日記
- 舞台照明機器の製作とか -
ユーザ「電装工芸」の投稿［863件］（53ページ目）
2022年7月 この範囲を時系列順で読む(電装工芸の投稿に限定) この範囲をファイルに出力する
パワーLEDをリフローして秋月さんのドライバ基板で点灯させました。
単色の3w品はかなり明るく、LEDの樹脂部品の変形もありませんので思ったよりも良好な照射をしています。
30度のレンズを取り付けた５発が2m離れた位置で中心150Lx。期待値は200Lxだったので足りませんが、電流値を調整すれば180Lxくらいまで上げられそうな気もします。
課題は明るさを増して個体ムラを軽減することです。実作業はLEDに送り込む電流値の調整となります。半導体は付加電圧に入力電流が単純比例しないために半導体と呼ばれますがLEDもその部類です。LEDの明るさは主に入力電流に比例しますが、電圧特性が個体によってバラつきがあるくせに入力電流は付加電圧によって増減します。制御回路は電流を計測してフィードバック制御してはいますが、電流の計測も結局は電圧の計測なので累積誤差は決して少なくありません。設計値のままの部品で回路を組んでもある程度の範囲には収まるのですが10%くらいの照度差は発生するようです(抵抗やコンデンサの誤差は5%程度あるので当たり前？)。なので、最後は人の手で計測して調整できるようにしなければなりません。
さて、どうしよう！？
追記
気になったので再計測。
同条件で260Lx出ている・・・十分に期待値なのでホッとしましたが、なんで100Lxもアップ？
考えられるのは温度。
昨日のチェックはリフローの熱が完全に抜ける前に実施したと言ってもいい。アルミアングルをヒートシンクにしているけど冷却不足かも。制御回路には気になる発熱が無いので無関係だと思う。
しばらく点灯して十分に熱を持たせて再計測します。
追記・・・30分後
ヒートシンクが十分に温まったところで計測。
照度258Lx。
わずかに下がったけれど計測の誤差レベルでしょう。十分に期待値が出ているので細かい調整は考えないことにします。
アルミアングルは温まっても素手で握っていられる程度なので、筐体放熱だけで足りそうな気がします。触った感じ、昨日よりも低い気がしなくもないけど・・・
これなら実試作を始めてもいいので、基板を設計して中国に発注しますかね。
LED基板も制御基板もアルミの片面基板にしましょう。短絡を避けるために基板の周囲にパターンの余白を大きめにとる必要がありますが、基板を筐体やヒートシンクに直付け出来るなど、クーリングの処理にメリットがあります。それに、国内でアルミ基板を作ると樹脂基板の数倍の価格になるのに対し中国ではほんの数割しか違いません。クーリングの機構が簡単になるならアルミ基板を用いた方が全体としては安く仕上がります。
#電子工作 #LED
単色の3w品はかなり明るく、LEDの樹脂部品の変形もありませんので思ったよりも良好な照射をしています。
30度のレンズを取り付けた５発が2m離れた位置で中心150Lx。期待値は200Lxだったので足りませんが、電流値を調整すれば180Lxくらいまで上げられそうな気もします。
課題は明るさを増して個体ムラを軽減することです。実作業はLEDに送り込む電流値の調整となります。半導体は付加電圧に入力電流が単純比例しないために半導体と呼ばれますがLEDもその部類です。LEDの明るさは主に入力電流に比例しますが、電圧特性が個体によってバラつきがあるくせに入力電流は付加電圧によって増減します。制御回路は電流を計測してフィードバック制御してはいますが、電流の計測も結局は電圧の計測なので累積誤差は決して少なくありません。設計値のままの部品で回路を組んでもある程度の範囲には収まるのですが10%くらいの照度差は発生するようです(抵抗やコンデンサの誤差は5%程度あるので当たり前？)。なので、最後は人の手で計測して調整できるようにしなければなりません。
さて、どうしよう！？
追記
気になったので再計測。
同条件で260Lx出ている・・・十分に期待値なのでホッとしましたが、なんで100Lxもアップ？
考えられるのは温度。
昨日のチェックはリフローの熱が完全に抜ける前に実施したと言ってもいい。アルミアングルをヒートシンクにしているけど冷却不足かも。制御回路には気になる発熱が無いので無関係だと思う。
しばらく点灯して十分に熱を持たせて再計測します。
追記・・・30分後
ヒートシンクが十分に温まったところで計測。
照度258Lx。
わずかに下がったけれど計測の誤差レベルでしょう。十分に期待値が出ているので細かい調整は考えないことにします。
アルミアングルは温まっても素手で握っていられる程度なので、筐体放熱だけで足りそうな気がします。触った感じ、昨日よりも低い気がしなくもないけど・・・
これなら実試作を始めてもいいので、基板を設計して中国に発注しますかね。
LED基板も制御基板もアルミの片面基板にしましょう。短絡を避けるために基板の周囲にパターンの余白を大きめにとる必要がありますが、基板を筐体やヒートシンクに直付け出来るなど、クーリングの処理にメリットがあります。それに、国内でアルミ基板を作ると樹脂基板の数倍の価格になるのに対し中国ではほんの数割しか違いません。クーリングの機構が簡単になるならアルミ基板を用いた方が全体としては安く仕上がります。
#電子工作 #LED
リフローは基本が見えたので、棚上げになっていたSPI-DMXの組み上げも可能になりました。
これは表面実装部品を多用しているのでリフローの条件が整わないとどうにもならなかったのです。
リフローでこれに付ける部品はチップ抵抗とチップコンデンサですから温度条件は比較的緩い。185度のソルダーペーストでも部品は持つと思いますので、138度のを使えば比較的簡単に出来そうです。
このSPI-DMXはRaspberryPiからレガシーDMXを出力するためのインターフェースです。PICのファームウェアを書かなければなりませんし、トリッキーな処理の検証もあるので完成まで時間がかかりますが、最終的にはArt-Netデコーダになるので速やかに進めたいですね。LCDディスプレイモジュールをI2C化するのもこれに使いたいからだったりしますが・・・。
#電子工作
これは表面実装部品を多用しているのでリフローの条件が整わないとどうにもならなかったのです。
リフローでこれに付ける部品はチップ抵抗とチップコンデンサですから温度条件は比較的緩い。185度のソルダーペーストでも部品は持つと思いますので、138度のを使えば比較的簡単に出来そうです。
このSPI-DMXはRaspberryPiからレガシーDMXを出力するためのインターフェースです。PICのファームウェアを書かなければなりませんし、トリッキーな処理の検証もあるので完成まで時間がかかりますが、最終的にはArt-Netデコーダになるので速やかに進めたいですね。LCDディスプレイモジュールをI2C化するのもこれに使いたいからだったりしますが・・・。
#電子工作
ようやくですが、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