電装工芸日記
- 舞台照明機器の製作とか -
タグ「PIC」を含む投稿(時系列順)［23件］（3ページ目）
まだまだ途中ではあるものの使えるっちゃ使える LTC_Player で本業の音源チェックをしています。
思いっきり自画自賛ですが、コレ、便利です。
作った本人だからってのが８１%くらいありそうですけど、こうやって実務で使うと完成イメージが具体的になります。
今は設定変更のロックを機能別にしていますが、Play_Mode という括りで良さそうです。本番モード、リハモード、机上作業モード、プレイリスト編集モードって感じです。各種設定のロックの組み合わせがモードの違いとなりますが、機能単位でロックを掛けられるようにしていますので変更するのは簡単です。
私のプログラムの書き方を整理しますと「状態を把握」「処理の振り分け」「パラメータとフラグの設定」「パラメータとフラグを見て最終処理」ってのを１フェーズ単位にして管理しています。バグが多く発生する書き方は処理を振り分ける際に一部の最終処理までしてしまう書き方だったので、幾重にも重なったふるいにかけて粉を落とすイメージでフラグを立て、最後に落ちて来たフラグを見て最終処理をするのです。その都度結果を求めると整合性を取るのが大変になり、それこぞバグの原因になるのでした・・・私の場合ですけどね。完全独学ですから王道の書き方なんて知りませんが、一本筋の処理フェーズしかないPICのアセンブラで染みついた構築の仕方です。ガチガチで汎用性が狭い感じがしますが、発展させると疑似的なマルチスレッドも構成出来ます。PICではタイマー１個でポーリングによる複数の時間分岐を得る書き方をレギュラー化していますが、これって精度は低いけどRTOSっぽくね？とか思いながら使っています。タイムスレッドと勝手に呼称している書式ですが、余程のレスポンスを求めないなら割込みを使わずタイムスレッドとモジュールの割込みフラグによるポーリング処理で複数の処理をPICの中で実現出来ています。特別なレスポンスを求める要素にだけ割込みを使い、高級言語で言うところの sleep を絶対に使わない方針です。
ソフトウェアは時間の管理が一番大事だと思う今日この頃。適切に時間が管理されていればインプットもアプトプットも整合性を持って管理出来ます。
#Python #PIC
思いっきり自画自賛ですが、コレ、便利です。
作った本人だからってのが８１%くらいありそうですけど、こうやって実務で使うと完成イメージが具体的になります。
今は設定変更のロックを機能別にしていますが、Play_Mode という括りで良さそうです。本番モード、リハモード、机上作業モード、プレイリスト編集モードって感じです。各種設定のロックの組み合わせがモードの違いとなりますが、機能単位でロックを掛けられるようにしていますので変更するのは簡単です。
私のプログラムの書き方を整理しますと「状態を把握」「処理の振り分け」「パラメータとフラグの設定」「パラメータとフラグを見て最終処理」ってのを１フェーズ単位にして管理しています。バグが多く発生する書き方は処理を振り分ける際に一部の最終処理までしてしまう書き方だったので、幾重にも重なったふるいにかけて粉を落とすイメージでフラグを立て、最後に落ちて来たフラグを見て最終処理をするのです。その都度結果を求めると整合性を取るのが大変になり、それこぞバグの原因になるのでした・・・私の場合ですけどね。完全独学ですから王道の書き方なんて知りませんが、一本筋の処理フェーズしかないPICのアセンブラで染みついた構築の仕方です。ガチガチで汎用性が狭い感じがしますが、発展させると疑似的なマルチスレッドも構成出来ます。PICではタイマー１個でポーリングによる複数の時間分岐を得る書き方をレギュラー化していますが、これって精度は低いけどRTOSっぽくね？とか思いながら使っています。タイムスレッドと勝手に呼称している書式ですが、余程のレスポンスを求めないなら割込みを使わずタイムスレッドとモジュールの割込みフラグによるポーリング処理で複数の処理をPICの中で実現出来ています。特別なレスポンスを求める要素にだけ割込みを使い、高級言語で言うところの sleep を絶対に使わない方針です。
ソフトウェアは時間の管理が一番大事だと思う今日この頃。適切に時間が管理されていればインプットもアプトプットも整合性を持って管理出来ます。
#Python #PIC
Open DMX USB の BreakTime について考えていたところ PIC の BreakTime についてもアイデアが出ました。
拡張ミッドレンジPIC16系の EUSART には Break 機能があります。ただし、11bit分の L を出力して StopBit(H) を出すまでが一連の動作なので２回繰り返しても DMX512 の BreakTime にはなりません。今は I/O ピンをプルダウンしておき、入出力設定(TRIS)を Input(Hi-Z) にしてから捨て送信をすることで BreakTime を作っています。
本題です。DMX512 の BreakTime は 最小 88usec ですから 250kbps なら 22bit 分の連続した L を出力すれば成立します。PIC16系の EUSART の Break が DMX512 の BreakTime に使えないのはこれが理由ですが、BaudRate を変更した Break を出力したらよくね？ってのが今回のアイデアです。手段を問わず、L 送信が 88usec 以上ならいいのです。私の理解が間違っていなけば、アイドル時なら BaudRate をバイト送信毎に変更しても EUSART は正しく動くハズです。単純計算なら BaudRate を半分にすれば規格値が出ます。現状でも BaudRate の調整だけで 1/50 くらいには出来ますから十分な BreakTime を作れると思われます。もちろん、BaudRate を 1/3 以下にして Break ではなく 0x00 を通常出力しても同じことです。こちらの方が汎用性が高いかも。受信も併用する構成ではＮＧですけどね。
この方法が成立すればプルダウン抵抗は不要です。たった一つの抵抗ですが、部品を減らすことは絶対の正義ですので検討する価値はありそうです。
#PIC #器具の製作
拡張ミッドレンジPIC16系の EUSART には Break 機能があります。ただし、11bit分の L を出力して StopBit(H) を出すまでが一連の動作なので２回繰り返しても DMX512 の BreakTime にはなりません。今は I/O ピンをプルダウンしておき、入出力設定(TRIS)を Input(Hi-Z) にしてから捨て送信をすることで BreakTime を作っています。
本題です。DMX512 の BreakTime は 最小 88usec ですから 250kbps なら 22bit 分の連続した L を出力すれば成立します。PIC16系の EUSART の Break が DMX512 の BreakTime に使えないのはこれが理由ですが、BaudRate を変更した Break を出力したらよくね？ってのが今回のアイデアです。手段を問わず、L 送信が 88usec 以上ならいいのです。私の理解が間違っていなけば、アイドル時なら BaudRate をバイト送信毎に変更しても EUSART は正しく動くハズです。単純計算なら BaudRate を半分にすれば規格値が出ます。現状でも BaudRate の調整だけで 1/50 くらいには出来ますから十分な BreakTime を作れると思われます。もちろん、BaudRate を 1/3 以下にして Break ではなく 0x00 を通常出力しても同じことです。こちらの方が汎用性が高いかも。受信も併用する構成ではＮＧですけどね。
この方法が成立すればプルダウン抵抗は不要です。たった一つの抵抗ですが、部品を減らすことは絶対の正義ですので検討する価値はありそうです。
#PIC #器具の製作