納期の早い部品から少しずつ届き始めていますが、要するに汎用的なネジ類ばっかりなので、推進系の試作は一向に進んでおりません。継手とかは早めに届く(or届いてる)ので、少しずつ手を付けていますが、まぁ、進捗ありません。
***
久しぶりにNTSCで遊んでます。暇なので。
マイコン側のファームを作り直して、とりあえず9Mspsで高さ180ピクセル分の読み出しだけ実装してます。ハフマン周りはカロリー高いので前回作ったライブラリを流用する予定。。。
前回かなり苦労したので、今回はあっさりと画像化できました。
輝度とか調整してないのでたぶん正しくないですが、色合いは間違ってはいないはずです。
垂直同期周りを確認したかったので、垂直同期から110ライン分遅延して180ラインを読んでいます。頭が切れた1フィールド+次のフィールドの28ラインくらいの範囲が見えています。この画像では垂直同期部分がブランクになってますが。
1フィールド約262ラインの内、240ラインくらい取れればいいわけで、180ラインまで無圧縮で取れてるんだから、あと60ラインくらい…とも思いますが、60ラインでも34Kくらいのメモリが必要なので、結局内部で圧縮しないとだめなんですよね。。。
コアカップル領域も含めれば270行くらいのバッファは確保できるんですが、CCMはDMA転送できないので使えない。。。DMA転送はSRAMにサーキュラで流して、SRAMとCCMに確保したトータル260ライン分のバッファにプログラムループで転送する、というような処理をすれば無圧縮でも取り出せそうな気がする。ハフマンは映像が変わると圧縮率が悪化してフィールドのキャプチャができなくなる危険性があるので、無圧縮で1フィールド丸ごとキャプチャできる方法があれば、かなり安心できます。とりあえずハフマンのライブラリ移植する前にその方向性で試して見る予定。
デコードするにあたって、UV平面やIQ平面、xyやReImといった様々な空間を使っています。とても面倒くさい。変数名的には輝度信号(Y)と垂直位置(Y)が同じだけで、UVIQReImは基本的に変数名で見分けられますが、お互いに変換するのにどういう割当になるのかを考えるのが面倒です。斜めにするIQは面倒なので今回は使っていませんが。
いよいよテスト信号発生機が欲しくなってきますね。STM32で出せないかなーと色々考えてますが、なかなか大変そう。そもそも基準となる波形がほしいわけであって、自分が作った波形が基準として使えるかという問題もあります。アナログ周りはとりあえず問題なく動いているので、テスト信号はデコーダ側の調整に使いたいだけであって、それならわざわざマイコンとかアナログとか低レベルな部分を通さず、直接生成した波形をデコーダに突っ込めばいいわけだし。
***
追記
アクセスログを見ると、綺麗に平日の昼間にピークが出てるの面白い。深夜の時間帯と週末はアクセス数下がる。暇人もいるもんだな(お前が言うな
ここ数日は更新してなかったせいか普段の波形と違う形。数十分毎くらいの統計をCSVで出せたらFFTとか通して遊べるんだけど、Bloggerってそういうことできるのかな?
とりあえず、CCMRAMと非CCMRAMに分けて配置するの、できるようになった。
1ライン572ポイントで、DMA用に16ラインのダブルバッファを確保し、CCMRAMに96ライン、SRAMに160ラインの配列を確保した。DMA用が18304ポイント、実際のデータが146432ポイント、合わせて160KiBほど。RAMは192KiBなのでキワッキワまで確保してる。16Kの整数倍で確保してるけど、CCMもSRAMもこれ以上確保できない。
16ラインの選定理由は、16ラインの転送に1msec以上かかるので、頻繁に処理しなくてもいいように、という感じなので、実際は8ラインとかでも良い。それならもう少し細かくCCM/SRAMを増やせる。まぁ、1フィールド分丸ごと受信できるので、これ以上増やす意味はない。むしろ少し減らしたいので、その意味では分解能を細かくするのにも意味はあるが。
HALのお節介で結構ハマった。CubeでDMAを使おうとすると割り込みが強制的に有効化されるので、ポーリングだけで処理できない(ポーリングでフラグ監視しててキャッチされず気がつくのにだいぶ時間かかった)。デフォルトのHALの割り込みは特定のグローバル関数を呼ぶだけなのであまり便利じゃない。ということでコールバック関数を登録したんだけど、マルチADCはそこまで実装されていないので、グローバル関数からコールバック関数を呼び出すという、何やってんだ、、、という状態。
HAL、「最適化? 移植性を下げるようなコードなんてクソくらえ!!!」みたいな感じ。
PICとか、設計された時代が時代とはいえ、かなり移植性悪かったけど、STM32は少なくとも同じシリーズ(F1とかF4とか)であれば移植性は凄まじく高い。が、シリーズ間では搭載された機能の違いとかもあって移植性はあまり高くない。それを無理やりラッパーで移植させようとしてるんだから、そりゃ面倒なコードになる。
とりあえずコンポジット映像1フィールド分の記録はできるようになったけど、メモリがカツカツ過ぎて他に何もできない感じ。data+bssで184KiBほどになる。残り8KiBくらいだけど、この内の一部はメインループ用のスタックとか、mallocとかで使われるので、全部使い切ると動作しなくなる(printfとかは一部の処理でmallocを使っている)。
一応DMA用のバッファ(18KiB弱)はADC/DMA転送するとき以外は使わないし、排他で使えば多少のメモリ空間は使える。SD SPIライブラリ+FatFsくらいは入りそうな気がする。というか入ってくれないと困る。
今の所デバッグ用にUSB CDCを使ってるから、これを捨ててUSB MSC HostにすればUSBメモリへの書き込みもできるだろうし。
今はDMAバッファからデータ配列への転送はソフトウェアループでやってるけど、SRAMへの転送ならDMAも使えるし、もう少し最適化の余地はありそう。ただ、今回はハフマン圧縮とかを使っていないので、計算能力的には余裕があるはず。コア使用率測ったわけじゃないけど。
USB Hostだけなら若干数のピンを引き出して変換コネクタに通すだけで使えるので楽。SDカードだとピン数が多いしパスコンやプル抵抗も必要なので大変。とはいえ、STBee F4miniはUSB5Vが引き出されてないので、USB Hostを作ろうとするとちょっと工夫する必要がある。STBee F4mini、計算能力はかなり高くて好きなんだけど、細かいところに手が届かないんだよなぁ。。。具体的には5Vが出てないのとPD2が出てない所。あとUSER SWをBOOT0に接続するのが大変なのと。RESET SWかUSER SWを90度回せば数ピン分は空間確保できそうだし、5VとPD2引き出してくれないかなぁ。。。あぁ、そういえば外部からの5V供給ができないのも問題だな。まぁこれはUSB5Vのヒューズ下流を取り出して、ヒューズを除去すればいいので、USB5V取り出せない問題と根本は同じだけど。
とりあえず、リファクタリングと最適化をしつつもう少しいろいろ作り込んでいこう。
0 件のコメント:
コメントを投稿