電装工芸日記
- 舞台照明機器の製作とか -
全年全月7日の投稿［39件］
2024年1月 この範囲を時系列順で読む この範囲をファイルに出力する
お世話になっている工場からの依頼品は完成しました。
明日がデッドタイムなのでギリギリです。明朝納品してきます。
これが納品出来たら修理大会に突入です。
PegasysG10の修理も手を付けたいですが、その前に急ぎの修理が１件ありました。以前製作販売した調光ユニットです。以前の現場でフリッカーが止まらなくなったとか。作った本人ですので全く同じモノを使っていますが、手元の製品では今まで発生したことがないのでどうしたものかと思案しています。
かなり前の製作ですので電源のゼロクロスのセンシングのファームウェアに甘さがありそうな気がします。改めてソースコードを読み直して手直しを試みます。
PegasysG10は殻割りをしての修理ですので、ついでにケーブルも交換するつもりです。純正の電源ケーブルは腰が強すぎて正直使いにくい。3P平行7Aのケーブルに交換してあるのですが、中華TRUE1に換装したいので、2PNCT1.25sqに付け替えます。信号線も4E6Sに付け替え、コネクタは防滴のSP13-3Pにします。手間はかかりますが、やっておけば後々現場が楽なので。
この際、直電源は総じてTRUE1化します。ムービングライトも全てです。コネクタの種類が多すぎてイチイチ面倒なのです。手間はかかりますけど、メス-レセプタクルはPowerCONと取り付けパネルの切り欠きが同じなので、ボルトオンで付け替えが可能です。
SP13ってのはコレです。
一部の防滴LEDスポットは中華TRUE1/SP13にしていますが、数か月間の野外のライトアップに使ってもトラブルはありません。安価な割にこの性能なら全てこれにしたいくらいです。
中華TRUE1のパッキンにはKUREのラバープロテクタントを塗布するといいようです。
つか、防滴スポットの筐体や防滴コネクタのパッキン類にはこれを塗布するのをお勧めします。
#器具の修理
明日がデッドタイムなのでギリギリです。明朝納品してきます。
これが納品出来たら修理大会に突入です。
PegasysG10の修理も手を付けたいですが、その前に急ぎの修理が１件ありました。以前製作販売した調光ユニットです。以前の現場でフリッカーが止まらなくなったとか。作った本人ですので全く同じモノを使っていますが、手元の製品では今まで発生したことがないのでどうしたものかと思案しています。
かなり前の製作ですので電源のゼロクロスのセンシングのファームウェアに甘さがありそうな気がします。改めてソースコードを読み直して手直しを試みます。
PegasysG10は殻割りをしての修理ですので、ついでにケーブルも交換するつもりです。純正の電源ケーブルは腰が強すぎて正直使いにくい。3P平行7Aのケーブルに交換してあるのですが、中華TRUE1に換装したいので、2PNCT1.25sqに付け替えます。信号線も4E6Sに付け替え、コネクタは防滴のSP13-3Pにします。手間はかかりますが、やっておけば後々現場が楽なので。
この際、直電源は総じてTRUE1化します。ムービングライトも全てです。コネクタの種類が多すぎてイチイチ面倒なのです。手間はかかりますけど、メス-レセプタクルはPowerCONと取り付けパネルの切り欠きが同じなので、ボルトオンで付け替えが可能です。
SP13ってのはコレです。
一部の防滴LEDスポットは中華TRUE1/SP13にしていますが、数か月間の野外のライトアップに使ってもトラブルはありません。安価な割にこの性能なら全てこれにしたいくらいです。
中華TRUE1のパッキンにはKUREのラバープロテクタントを塗布するといいようです。
つか、防滴スポットの筐体や防滴コネクタのパッキン類にはこれを塗布するのをお勧めします。
#器具の修理
某芸能人さんが1,000食分の炊き出しをしてきたとか。
一般に告知せずのことですから阿呆を集めることもなく、ご当地の方々の気分転換にもなったと思います。
ただ、今現地で必要なのはその場限りの1,000食の炊き出しカレーか、日持ちする1万食のレトルトカレーかどちらなんでしょう。コストも手間も大差ないように思います。
現地に負担をかけない配慮と報道をシャットアウトしたのは好印象ですが、同じ手間なら売名をってニュアンスは拭えません。同じ手間なら実を取って欲しかったかも。
現地では何が求められているのでしょう。十分な装備を携えた屈強な土木職人は間違いなく歓迎されるでしょうけど。
インフラがやられ食料が満足でないことは想像できますが、優先されるのは食料なのか、資材なのか、道具なのか、技能なのか。
全てかもしれませんが、この辺りが見えないから使いようのない古着や足の早い食品を宅配便で送る阿呆が湧いてくるのだと思います。
こんなときは赤十字社に寄付するのが間違いないと思いますが、阿呆はわかりやすい実感を求めますので、カタログショッピング形式で支援品を購入できるようにしたらいいんじゃないかと。こうすりゃ、私ナニナニを被災地に送ったんだぁって自慢もしやすくなりますし、お金も集まるし、不適切な品も減るしでいいかなと。電通さんが仰る通り、バカにあわせるのも大事です。
つか、必要な物と量を公募してくれたら分かりやすいのにね。ナニナニ求むみたいな。不適切な品があふれるのは適切なリクエストが無いからでもあります。不適切な品を選り分けて処分する手間とリクエストをまとめる手間とどちらが大変だろう？
身勝手な支援品もどきは送らなきゃいいし、宅配便業者も引き受けなきゃいい、って根本的な話しもあります。
#自然災害
一般に告知せずのことですから阿呆を集めることもなく、ご当地の方々の気分転換にもなったと思います。
ただ、今現地で必要なのはその場限りの1,000食の炊き出しカレーか、日持ちする1万食のレトルトカレーかどちらなんでしょう。コストも手間も大差ないように思います。
現地に負担をかけない配慮と報道をシャットアウトしたのは好印象ですが、同じ手間なら売名をってニュアンスは拭えません。同じ手間なら実を取って欲しかったかも。
現地では何が求められているのでしょう。十分な装備を携えた屈強な土木職人は間違いなく歓迎されるでしょうけど。
インフラがやられ食料が満足でないことは想像できますが、優先されるのは食料なのか、資材なのか、道具なのか、技能なのか。
全てかもしれませんが、この辺りが見えないから使いようのない古着や足の早い食品を宅配便で送る阿呆が湧いてくるのだと思います。
こんなときは赤十字社に寄付するのが間違いないと思いますが、阿呆はわかりやすい実感を求めますので、カタログショッピング形式で支援品を購入できるようにしたらいいんじゃないかと。こうすりゃ、私ナニナニを被災地に送ったんだぁって自慢もしやすくなりますし、お金も集まるし、不適切な品も減るしでいいかなと。電通さんが仰る通り、バカにあわせるのも大事です。
つか、必要な物と量を公募してくれたら分かりやすいのにね。ナニナニ求むみたいな。不適切な品があふれるのは適切なリクエストが無いからでもあります。不適切な品を選り分けて処分する手間とリクエストをまとめる手間とどちらが大変だろう？
身勝手な支援品もどきは送らなきゃいいし、宅配便業者も引き受けなきゃいい、って根本的な話しもあります。
#自然災害
能登半島地震の被災状況がマスメディアやSNSなどを通じて一般にも見えてきました。お世辞にも交通の便が良いとは言えない地域でのことですから時間がかかったのでしょう。
自分は3.11の被災地域の末端に住んでいますし、直後に仙台やいわき付近まで行った経験から、切り取り報道のニュアンスはなんとなくわかります。嘘ではないが全体の真実でもない、パニック映画の様なドラマチックは無いという塩梅ですが、今回の能登半島地震でも同様のようです。酷いところはあるけれど全てではないということです。
3.11当時の私の状況に似た境遇の方がyoutubeにアップされていました。そこでのコメントが印象に残りましたのでご紹介したいと思います。
とても冷静だなぁ～ってのが一番の感想です。「心配で居ても立っても居られないお気持ちは有難いけれど、被災地外の方々は過度に心配されず日常を普通にお過ごしください。」といったコメントが印象的でした。自分の経験からもそうだよなって思います。芸能人の炊き出しに観光気分で押し寄せた阿呆は論外ですが、物資の扱いの素人が頑張っても現地の交通・流通インフラのリソースを無駄遣いするだけで非効率です。自家用車５台のリソースで11tトラック１台が動けますが、運べる物資の量は11tトラックの方が数百倍あるからです。もちろん、ご当地ご出身の方が親類縁者のために行動することはこの範囲に含まれませんけど。
部外者ながら居ても立っても居られない方は今はその気持ちを抑え、状況が落ち着いてきたら現地のリソースに負担をかけない準備をしてお手伝いボランティアに行けばいいし、復興と言える状況になったら観光に行ってお金を落としてくればいい。100人分の何かが出来ない人は今は何もするなって感じです。3.11の時もお手伝いボランティアに来たはいいけれど「私のご飯は？宿は？お風呂は？」とのたまう人が居たとか居ないとか。客人をおもてなし出来たら被災地ぢゃねーって。その場に居合わせたワケではありませんのでウワサ話ですが、こんな人はその場に居ないのが一番の手助けでしょう。
#自然災害
自分は3.11の被災地域の末端に住んでいますし、直後に仙台やいわき付近まで行った経験から、切り取り報道のニュアンスはなんとなくわかります。嘘ではないが全体の真実でもない、パニック映画の様なドラマチックは無いという塩梅ですが、今回の能登半島地震でも同様のようです。酷いところはあるけれど全てではないということです。
3.11当時の私の状況に似た境遇の方がyoutubeにアップされていました。そこでのコメントが印象に残りましたのでご紹介したいと思います。
とても冷静だなぁ～ってのが一番の感想です。「心配で居ても立っても居られないお気持ちは有難いけれど、被災地外の方々は過度に心配されず日常を普通にお過ごしください。」といったコメントが印象的でした。自分の経験からもそうだよなって思います。芸能人の炊き出しに観光気分で押し寄せた阿呆は論外ですが、物資の扱いの素人が頑張っても現地の交通・流通インフラのリソースを無駄遣いするだけで非効率です。自家用車５台のリソースで11tトラック１台が動けますが、運べる物資の量は11tトラックの方が数百倍あるからです。もちろん、ご当地ご出身の方が親類縁者のために行動することはこの範囲に含まれませんけど。
部外者ながら居ても立っても居られない方は今はその気持ちを抑え、状況が落ち着いてきたら現地のリソースに負担をかけない準備をしてお手伝いボランティアに行けばいいし、復興と言える状況になったら観光に行ってお金を落としてくればいい。100人分の何かが出来ない人は今は何もするなって感じです。3.11の時もお手伝いボランティアに来たはいいけれど「私のご飯は？宿は？お風呂は？」とのたまう人が居たとか居ないとか。客人をおもてなし出来たら被災地ぢゃねーって。その場に居合わせたワケではありませんのでウワサ話ですが、こんな人はその場に居ないのが一番の手助けでしょう。
#自然災害
2023年10月 この範囲を時系列順で読む この範囲をファイルに出力する
拾いモノですが、こういうの大好きです。
#雑記
#雑記
2023年9月 この範囲を時系列順で読む この範囲をファイルに出力する
「Open DMX USB」について考えていたのは移動中アタマが空いていたからです。
学園祭への機材レンタルで搬送をしていたのですが、片道１時間半くらいかかるので考え事をするには丁度良い時間でした。
そんな中で Art-Net Patch も思い出す。余りに難しく、数日アタマを全振りしないと進められないネタのために止まっています。
ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)が主な機能ですが、これらの処理(エフェクターと呼称)は参照して計算、参照して計算、参照して計算をひたすら繰り返します。一つ一つはとても簡単な処理ですが、タイミング良く群のデータを短時間で処理しないといけないので構成が難しく、僅かな無駄が後からボディブローの様に効いてきます。
年齢が年齢なので経験量に対し学習量が少ないなぁ～と思いつつも、オブジェクト指向やマルチスレッドなどが普通に使える様になってきますと今までと違った構成がアタマに浮かんできます。全体を一度に見ると難しい処理ですが、構成を分解・整理すれば分割したライブラリとして進められるんじゃないかと。
厄介なのはミキサーとディレイですが、これらを実現するには最大遅延時間分の過去を送信元分保存しておく必要があります。このデータ構成を良く考え、エフェクターの出入りを一般化して進めれば機能単位での製作が可能になりそうな気がします。
目的に対しその環境や言語をどう使えばいいか具体的な見込みを付けてからデータ構造と処理アルゴリズムの本構成を考えることが大切だと思う今日この頃。
開発のプロからしたら当たり前過ぎることなんでしょうけど。
#[Art-Net] #Ｃ言語 #器具の製作
学園祭への機材レンタルで搬送をしていたのですが、片道１時間半くらいかかるので考え事をするには丁度良い時間でした。
そんな中で Art-Net Patch も思い出す。余りに難しく、数日アタマを全振りしないと進められないネタのために止まっています。
ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)が主な機能ですが、これらの処理(エフェクターと呼称)は参照して計算、参照して計算、参照して計算をひたすら繰り返します。一つ一つはとても簡単な処理ですが、タイミング良く群のデータを短時間で処理しないといけないので構成が難しく、僅かな無駄が後からボディブローの様に効いてきます。
年齢が年齢なので経験量に対し学習量が少ないなぁ～と思いつつも、オブジェクト指向やマルチスレッドなどが普通に使える様になってきますと今までと違った構成がアタマに浮かんできます。全体を一度に見ると難しい処理ですが、構成を分解・整理すれば分割したライブラリとして進められるんじゃないかと。
厄介なのはミキサーとディレイですが、これらを実現するには最大遅延時間分の過去を送信元分保存しておく必要があります。このデータ構成を良く考え、エフェクターの出入りを一般化して進めれば機能単位での製作が可能になりそうな気がします。
目的に対しその環境や言語をどう使えばいいか具体的な見込みを付けてからデータ構造と処理アルゴリズムの本構成を考えることが大切だと思う今日この頃。
開発のプロからしたら当たり前過ぎることなんでしょうけど。
#[Art-Net] #Ｃ言語 #器具の製作
なんとなーくネットを眺めていたところ「Open DMX USB」に目が止まる。
「Open USB USB」
PCから DMX512 を出力する USB インターフェースです。仕様がオープンになっていてハードウェアは極めてシンプルです。FT232RL を用います。
ライセンス仕様は GPLv2 です。大雑把に言うなら、改変しない限り商用/私用を問わず自由に使えます。
FT232RL は LTC Generator でも使っているので、その延長線で使えるなら悪くないなぁ～と。
このところ JASCII のオフライン打ち込みソフトのリクエストがあります。もちろん、ASCII や Comos-Text との変換を含めてです。
正直言うと面倒臭い。有料にするとライセンスの管理やサポートが面倒だし、無料にすると空振り感が強い。プロでない私がコレを開発するには本業を1/3にして半年かかります。卓を持ち込めば済むことに掛ける手間ではありません。
ですが、JASCII 関係は解決したいなぁ～って気持ちはあります。最近は、劇場間でデータを使いまわすためではなく、事前の空打ちが目的になっているからです。有志がお作りになったオフラインソフトもありますが、操作感に照明を作るリズム感がありません。テンキー操作でバンバン打ち込めるシステムがあってもいいのかなとは思います。
もし作るなら、JASCIIベースでプレイバックも出来る様にしてPC卓にしてもいいのかなと。DoctorMX や Open DMX USB で DMX512 を出せばいいのです。
イロイロ想うことはあるので、システムの構成だけでも考えていいのかなと。
#ガチ工作 #照明器具
「Open USB USB」
PCから DMX512 を出力する USB インターフェースです。仕様がオープンになっていてハードウェアは極めてシンプルです。FT232RL を用います。
ライセンス仕様は GPLv2 です。大雑把に言うなら、改変しない限り商用/私用を問わず自由に使えます。
FT232RL は LTC Generator でも使っているので、その延長線で使えるなら悪くないなぁ～と。
このところ JASCII のオフライン打ち込みソフトのリクエストがあります。もちろん、ASCII や Comos-Text との変換を含めてです。
正直言うと面倒臭い。有料にするとライセンスの管理やサポートが面倒だし、無料にすると空振り感が強い。プロでない私がコレを開発するには本業を1/3にして半年かかります。卓を持ち込めば済むことに掛ける手間ではありません。
ですが、JASCII 関係は解決したいなぁ～って気持ちはあります。最近は、劇場間でデータを使いまわすためではなく、事前の空打ちが目的になっているからです。有志がお作りになったオフラインソフトもありますが、操作感に照明を作るリズム感がありません。テンキー操作でバンバン打ち込めるシステムがあってもいいのかなとは思います。
もし作るなら、JASCIIベースでプレイバックも出来る様にしてPC卓にしてもいいのかなと。DoctorMX や Open DMX USB で DMX512 を出せばいいのです。
イロイロ想うことはあるので、システムの構成だけでも考えていいのかなと。
#ガチ工作 #照明器具
2023年8月 この範囲を時系列順で読む この範囲をファイルに出力する
本業がイイ感じに忙しいのでプログラム作業は思った程進みません。仕方ありませんけど。
LTC Player は音楽プレーヤー機能が一応組めたので、LTC の送出部を本格的に進めます。
どういった構造にしましょうかね。
クラスライブラリの書き方も体に入ってきましたので、本格的なドライバっぽい書き方に挑戦してみようと思います。LTC Generator は LTC Player と別な時間軸で動かさないといけませんのでマルチスレッドを使うことはマストだと思われます。LTC Generator は import する別ファイルとし、LTC Player とやりとりする部分はクラスとして記述し、そのクラスからスレッドを立ち上げてシリアル通信を制御するのです。これならLTC Player からはシンプルな関数にしか見えませんので構造的に美しく如何にもドライバって風味になりますw シリアルポートのリストを得る関数も別枠で作り、LTC Generator のインスタンスを起こす際にシリアルポートを指定するようにすれば複数の LTC Generator を扱えます。実際には音声信号を分ければいいので複数扱う必要はないのですが、ドライバとしてならこうあるベキかもしれません。
#Python
LTC Player は音楽プレーヤー機能が一応組めたので、LTC の送出部を本格的に進めます。
どういった構造にしましょうかね。
クラスライブラリの書き方も体に入ってきましたので、本格的なドライバっぽい書き方に挑戦してみようと思います。LTC Generator は LTC Player と別な時間軸で動かさないといけませんのでマルチスレッドを使うことはマストだと思われます。LTC Generator は import する別ファイルとし、LTC Player とやりとりする部分はクラスとして記述し、そのクラスからスレッドを立ち上げてシリアル通信を制御するのです。これならLTC Player からはシンプルな関数にしか見えませんので構造的に美しく如何にもドライバって風味になりますw シリアルポートのリストを得る関数も別枠で作り、LTC Generator のインスタンスを起こす際にシリアルポートを指定するようにすれば複数の LTC Generator を扱えます。実際には音声信号を分ければいいので複数扱う必要はないのですが、ドライバとしてならこうあるベキかもしれません。
#Python
Python の VLC ライブラリで mp3 を再生するとタイムオーバーします。長さ30秒の音源が32秒くらいまでカウントされて終わるのです。mp3 はデータの前後関係から復号する圧縮データのためでしょうか。
再生ポイントがズレてのことかと思いましたがお尻に無音が付くだけの様子。VLCの再生が終了していなくても再生秒数が長さ分になったことで終了と同じ扱いにしました。
付け焼刃な対策ですが、wav などの非圧縮データでは起こらないことですから、厳密を求めたいなら mp3 などの圧縮データを使わなければいいだけ、、、とします。
条件を織り交ぜた Play List で一晩連続再生しましたがエラーはありません。今後は頻繁な操作を続ける試験が必要です。
#Python
再生ポイントがズレてのことかと思いましたがお尻に無音が付くだけの様子。VLCの再生が終了していなくても再生秒数が長さ分になったことで終了と同じ扱いにしました。
付け焼刃な対策ですが、wav などの非圧縮データでは起こらないことですから、厳密を求めたいなら mp3 などの圧縮データを使わなければいいだけ、、、とします。
条件を織り交ぜた Play List で一晩連続再生しましたがエラーはありません。今後は頻繁な操作を続ける試験が必要です。
#Python
2023年7月 この範囲を時系列順で読む この範囲をファイルに出力する
LTC Player はいい感じに進んできました。
PlayListには「Continue」って項目を入れています。音終わりで止める(AutoPauseする)か曲を続けるかの設定です。単に止めて続けても面白くないし、曲間の時間を設定出来たら面白そうなので、曲が終わって次の曲が始まるまでの待ち時間を設定出来るようにしました。0秒にしておけば普通の曲ツナギです。もちろん、待ち時間が終わらなくても PLAY を押せば次の曲に行きます。ついでにマイナス秒も設定出来るようにしてみました。前倒しで曲を終りにする機能です。お尻の無音が長い曲を曲続きにしたい場合に便利かなと。使う人がいるかわかりませんが、ソースを見たら簡単に入れ込めそうだったので欲を出してみました。ライブラリがVLCなので厳密な時間再現は出来ませんけどね。
それにしても、Python のソースなのに明らかにアセンブラっぽい。どう見ても一般的な Python の流儀から外れています。勉強しながら考えなら書いていると体に染みついたアセンブラ風味になってしまうようです。ソースコードを誰かに納品するワケじゃありませんのでオレ流で構わないのですけどね。けど、オブジェクト指向でクラス・インスタンスをベースにするより、フラグベースでリニアな処理手順にした方が分岐が少なくてバグを見つけやすいかもと思ったり。リニアに書くのが非合理的なのでオブジェクト指向なんでしょ！という正論は聞きませんwww
#Python
PlayListには「Continue」って項目を入れています。音終わりで止める(AutoPauseする)か曲を続けるかの設定です。単に止めて続けても面白くないし、曲間の時間を設定出来たら面白そうなので、曲が終わって次の曲が始まるまでの待ち時間を設定出来るようにしました。0秒にしておけば普通の曲ツナギです。もちろん、待ち時間が終わらなくても PLAY を押せば次の曲に行きます。ついでにマイナス秒も設定出来るようにしてみました。前倒しで曲を終りにする機能です。お尻の無音が長い曲を曲続きにしたい場合に便利かなと。使う人がいるかわかりませんが、ソースを見たら簡単に入れ込めそうだったので欲を出してみました。ライブラリがVLCなので厳密な時間再現は出来ませんけどね。
それにしても、Python のソースなのに明らかにアセンブラっぽい。どう見ても一般的な Python の流儀から外れています。勉強しながら考えなら書いていると体に染みついたアセンブラ風味になってしまうようです。ソースコードを誰かに納品するワケじゃありませんのでオレ流で構わないのですけどね。けど、オブジェクト指向でクラス・インスタンスをベースにするより、フラグベースでリニアな処理手順にした方が分岐が少なくてバグを見つけやすいかもと思ったり。リニアに書くのが非合理的なのでオブジェクト指向なんでしょ！という正論は聞きませんwww
#Python
2023年6月 この範囲を時系列順で読む この範囲をファイルに出力する
今後のこともあり、移動時間にPICのI2Cを勉強し直してみました。
これまではイマイチ理解出来なかったのですが、ボチボチ使い方がわかってきました。わからなかったのはハードウェアとソフトウェアの棲み分けとソフトウェアの手順です。
I2Cの規格を頑張って説明するのはありがたいのですが、一番知りたいソフトウェアの手順がボンヤリした文書ばかり。ちょっと複雑な手順を踏むので突っ込んだ理解が望ましいのはわかるのですが、その説明で力尽きしまうのか、どとのつまりどうすればいいの？に応えてくれる資料が少ないように思います。特に、I2Cの特徴的な要素である「ACK」を扱うのがハードウェアなのかソフトウェアなのかが見えないのです。
正直、Pythonなどではライブラリを使うだけで済んでしまいますので、いくらPICマイコンでもそこまでローレベルの機構まで理解しないといけないのか不思議です。
わかったことは、設定さえしてしまえばソフトウェアの手順はUARTと大差ないことです。
マスタが送信する場合はスレーブアドレスを先頭にしたバイトリストをハードウェアモジュールに渡す(PICではバイト単位で渡す)。
マスタが受信する場合はスレーブアドレスを送り、返信されたバイトデータを取り込んだら取り込み済みのフラグを立てる。
スレーブは、自分のアドレスを設定しておけば自分向けの通信かハードウェアが判断してくれるので、マスターの要望に従って受信値を取り込むか返信値を投げる。
データの終りのストップコンディションは、マスター/スレーブ・送信/受信の立ち位置で違うけどフラグを立てるだけ。
波形をコマンド操作で作るワケじゃありませんし、前後関係で調整することもありません。規格はザックリ概要がわかっていれば十分なのに、ソフトウェアの手順の説明がボンヤリしているのはイマイチ理解不能なワケです。
#PIC
これまではイマイチ理解出来なかったのですが、ボチボチ使い方がわかってきました。わからなかったのはハードウェアとソフトウェアの棲み分けとソフトウェアの手順です。
I2Cの規格を頑張って説明するのはありがたいのですが、一番知りたいソフトウェアの手順がボンヤリした文書ばかり。ちょっと複雑な手順を踏むので突っ込んだ理解が望ましいのはわかるのですが、その説明で力尽きしまうのか、どとのつまりどうすればいいの？に応えてくれる資料が少ないように思います。特に、I2Cの特徴的な要素である「ACK」を扱うのがハードウェアなのかソフトウェアなのかが見えないのです。
正直、Pythonなどではライブラリを使うだけで済んでしまいますので、いくらPICマイコンでもそこまでローレベルの機構まで理解しないといけないのか不思議です。
わかったことは、設定さえしてしまえばソフトウェアの手順はUARTと大差ないことです。
マスタが送信する場合はスレーブアドレスを先頭にしたバイトリストをハードウェアモジュールに渡す(PICではバイト単位で渡す)。
マスタが受信する場合はスレーブアドレスを送り、返信されたバイトデータを取り込んだら取り込み済みのフラグを立てる。
スレーブは、自分のアドレスを設定しておけば自分向けの通信かハードウェアが判断してくれるので、マスターの要望に従って受信値を取り込むか返信値を投げる。
データの終りのストップコンディションは、マスター/スレーブ・送信/受信の立ち位置で違うけどフラグを立てるだけ。
波形をコマンド操作で作るワケじゃありませんし、前後関係で調整することもありません。規格はザックリ概要がわかっていれば十分なのに、ソフトウェアの手順の説明がボンヤリしているのはイマイチ理解不能なワケです。
#PIC