2019年11月3日日曜日

退屈な

 それはそれは退屈な、微調整作業。



 一応ちゃんと動いているので、速度最適化は目指さず、コードを簡単にする方向に。具体的にはタスクのループでやってる処理をライブラリに押し付ける。

 レジスタを1ビット操作するだけで良さそう、と思っても、実際に試してみると動かなかったりする。いちいちプログラム書き換えてビルドして転送しなきゃいけないので大変。バイナリサイズが大きくなってきて転送に時間がかかるようになってきた。
 static配列ってゼロクリアでもROMから転送されるんだっけ? 確保した配列の大きさがそのままバイナリの大きさに加算されてる気がする。staticの初期化をやらなくて済めばバイナリサイズ100KBは減らせそう。たぶんmallocで確保すればいいんだけど、コンパイル時にメモリ使用量が決定できないのはなんとなく嫌なので、staticで確保してるんだが。
 そういえば、OS自作本にそのあたりの話出てきてた気がする。「静的配列だとバイナリサイズ大きくなるよね! 動的メモリ確保で解決!!みたいな」話。開放しないんだからフラグとかは気にしなくていいんだけど、なんとなくマイコンで動的確保は嫌だなぁ。


 今はYC分離に1ライン遅延方式を使っているけど、どうしてもエッジ部分がギザギザになる。BPF方式だとモヤッとする。
 メモリの容量的に不可能だけど、フレーム間でのYC分離を試してみたい気もする。試すだけなら、1フレーム目のサンプリングを適当な位置で中断して、直後に垂直同期のスキャンを開始し、次のフレームをサンプリングする、みたいなことをやれば、上半分だけなら2フレーム分取れる。ただ、デコードソフトとか書き直すのがめんどい。。。


 今の所、表示領域は464x237pxくらい。だいたい18対9くらいのアス比。16対9くらいになるように横幅を縮めると履歴の時計アイコンの円がいい感じに真円っぽくなるので、16対9の映像信号として出ているはず。
 4対3のカメラとかからの出力の場合は横幅を1.5分の1に圧縮すれば丁度いいアス比になる。オンボードカメラとかのロガーとして使うならそのほうが便利そう。まぁ、オンボードで画像化するわけじゃないので、解析ソフト側の都合になるんだけど。
 試しに↑の画像を4対3に圧縮したらかなり綺麗な感じに出た。等価的には1ピクセルのサンプリングポイントを増やしているわけだから、そりゃ水平方向の画質は改善するわけだが。

 解像度的には、PSP互換液晶が480x272pxなので、ちょうどいい感じ。まぁ、STM32F405RGTじゃ能力的に全然足りないと思うんだが。。。
 それでも、1フレーム分バッファするんでなく、受け取ったNTSC信号を直接RGB888で吐き出すなら、メモリは大して必要ない。計算速度はかなり必要だから、やっぱり無理だと思うけど。

 そういえば、某ミクのSTM使いの人がコンポジットビデオを表示するブツを作ってるらしいんだけど、どうやってるんだろう? H7だそうで、処理能力凄まじそう。液晶はハードウェアで制御できそうだし、デコードさえできればいいのか。クロック480MHzとか強すぎぃぃ。それでもNTSCのデコードにはギリギリな気がするが。


 ワンチップマイコンでのNTSCのキャプチャ、思ったより実用的に動くな、という感想。いや、実用性は全く無いけど、画質は結構良い。解像度は低いけど、色にじみとかは思ったほど出ない。
 IKAROSやはやぶさ2のDCAMや、TRICOMのサブカメラは民生品のNTSCデコーダを使っているらしいけど、データレコーダも含めてワンチップマイコン化できるから、缶サットとかに使うのに良さそう。「はやぶさ2と同じ方式のカメラで映像を記録しました!」とかアピれる。「市販のキーホルダーカメラを改造しました」よりはウケそう。ただ、缶サットは「必要以上に複雑なものは減点対象」だった気がするので「市販品使ったら確実に動くよね?オンボードで解析するわけでもないのになんで自分で写真撮るの?」くらいは言われそうな気もする。


 1フレームキャプチャしてメモリをバイナリダンプするだけならともかくとして、SDカードとかに保存しようとすると、結構辛いかもしれない。
 フライト品として作るならUSB VCPは必要ないから、そこで少しメモリを稼げるか。RTOSのスタックとかもちょっと削ってやれば、FatFSを置いてファイル書き込みをやるくらいの余裕は作れるかもしれない。圧縮後のデータは通常のRAM領域に入ってるからSPIでDMA転送できるし。
 XBeeとか無線で飛ばせば本物のDCAMっぽい使い方もできるようになるけど、データ量が100KiBくらいあるから、115200bpsとして、15秒くらいで1フレームを転送できる。缶サットとかスペースプローブとか、低高度の重力天体でのミッションで使うには厳しいけど、それでもARLISSみたいな高高度からの投下ならミッション期間20分くらいあるので、伝送レートが低かったとしても5枚程度は画像を転送できる。
 キューブサットとかに使ってもいいけど、地球周回衛星はウインドウが短いから大変かも。それでも1ウインドウで1枚くらいは余裕で落とせると思うが。
 (今ググって知ったけど、ARLISSのやつ、2020年以降開催できないかも、みたいな話になってるのね。19年春頃までにアメリカのパブコメにコメントして存続させて!みたいな話になってたらしい)


 発展としてはSDカードに書き込むことを考えていたけど、枚数が少なくていいなら、STM32のFlashに直接書き込んでもいいんだな。ROMが1MiBでバイナリ150KiB未満だから、1枚100KiBとして8枚は保存できる。
 SDカードだと衝撃で瞬断してファイルアクセス瞬断したり、トラブル起こしがちだけど、内蔵Flashならそういう心配はかなり少ない。まぁ、基板が壊れたらマイコンから読み出すのが大変だけど。microSDなら直接重量物突っ込んできて砕け散った、みたいな事にならないような配置を考えておけば、基板割れたりコネクタ割れたりしても、カード自体は残ってる確率が高いし、カード自体が残ってれば読み出しはできる。
 さすがに5枚程度しか保存できないとなると、缶サットとかで使うにも少なすぎると思うけど、普段はSDに保存して、なにかの重要イベントが発生した後(高Gから10秒後とか、分離信号から2秒後とか)の画像だけFlashにもバックアップ、とか? 読み出しの信頼性を考えたらどっちもどっちという感じだけど。

***

 小ネタいくつか書くだけの予定だったのに、思った以上に文章量が増えてしまった。退屈な作業してると逃避したくなる…
 ここ最近NTSCにかかりきりだったし、久しぶりにPDF漁りやりたいなぁ。読みたいファイル増えすぎてChromeのタブ圧迫してる。。。

0 件のコメント:

コメントを投稿