No.550
Linux上のC言語でLTCの波形を起こせたらと思ったのですが、処理能力の総量は余裕タップリなものの、Art-Netエンジンを作った際に感じた挙動ムラから想像するに許容範囲を越える波形ムラが起こりそうです。LinuxはOSそのものや他のモジュールに引っ張られて100~300usecくらい待たされることがあるのですが、LTCの波形を起こすのにこの条件はよろしくありません。RTOSを使わないなら普通のことですけどね。
ならばLTCを起こすところにはPICを使ったらいいかな?適材適所?
LinuxからUARTなどでフレーム情報を送ってPICでLTCを生成するのです。2~4フレーム分くらいPICにバッファすればLinux側に動作ムラがあっても安定した波形を出すと思われます。
差動バイフェーズで信号を反転する時間ピッチは25fpsで250usecです。29.97fpsではなく25fpsとしているのは、PALのレートなのでLTC対応の演出機器は100%対応するし、何よりも計算がしやすく誤差も出にくいために当面の試作には良いかなと。250usecは32MHzのPICで2,000命令相当の時間です。これだけあれば大概ことは1フェーズ分実行出来ます。実行周期はTMR1やTMR2による周期割込みを使えばPICのクロック素子相当の精度を得られます。
求める精度は、周期が0.001%未満、差動バイフェーズの立ち上がり立下り精度が5%未満です。無理は無さそうです。
書いてて思ったのですが、こんなLTCジェネレーターをこれまでに作らなかった自分が不思議。
#タイムコード #PIC #電子工作
ならばLTCを起こすところにはPICを使ったらいいかな?適材適所?
LinuxからUARTなどでフレーム情報を送ってPICでLTCを生成するのです。2~4フレーム分くらいPICにバッファすればLinux側に動作ムラがあっても安定した波形を出すと思われます。
差動バイフェーズで信号を反転する時間ピッチは25fpsで250usecです。29.97fpsではなく25fpsとしているのは、PALのレートなのでLTC対応の演出機器は100%対応するし、何よりも計算がしやすく誤差も出にくいために当面の試作には良いかなと。250usecは32MHzのPICで2,000命令相当の時間です。これだけあれば大概ことは1フェーズ分実行出来ます。実行周期はTMR1やTMR2による周期割込みを使えばPICのクロック素子相当の精度を得られます。
求める精度は、周期が0.001%未満、差動バイフェーズの立ち上がり立下り精度が5%未満です。無理は無さそうです。
書いてて思ったのですが、こんなLTCジェネレーターをこれまでに作らなかった自分が不思議。
#タイムコード #PIC #電子工作