デバッグ中

今日出来ることは今日やる、の今日。

寒いけどエアコンを使わないことにした。だから
早めに寝るのだ。厚い布団に入ればそれほど寒さを
気にする必要はないのだ。節電、節電。

夜間でも節電すれば、その分夜間の発電で揚水モーター
回して、必要な時間に発電に回せるだろうと。


あとは相変わらずFFTプログラムのデバッグ。この間の
http://brown.ap.teacup.com/nekosan0/1252.html
Ｖフラグの件、よく考えたらＶフラグは単なる桁あふれ
であって、2の補数表示用のキャリーフラグに相当するのは
Ｓフラグだな。
オイラＳフラグって、Ｎフラグを反転させただけだと
思っていたけど、2の補数で加減算した際の、一桁上の
ビットに相当するのがＳフラグなのね。

で、1/2を計算するためにはこのＳフラグをキャリーフラグ
に移してからシフト命令でキャリーごと右シフトすれば
加減算結果をそのまま1/2に出来るというわけ。
Ｓフラグ使うのは、生まれて初めてだ…

チョイチョイとソースを直し、シミュレータで色々な
波形データを流してみる。

…大体良い感じ。表計算ソフトの計算内容と計算途中も
計算結果も合う。三角波、ノコギリ波、ワンショットパルス…

ところが、一つだけうまく動かない波形が有るのを発見。
どうやら、64点分で一波形となる矩形波がおかしい。

シミュレータの出力と表計算の結果を眺めてみると、
どうやらバタフライ演算処理の中で桁あふれしている
と判明。
バタフライの上半分は問題ないんだけど、下半分
がちょっとおかしい。
矩形波のように、半周期ずれた点を扱う時、丁度正負
が逆の値になって引き算（下半分側）で悪さするみたい。
sin、cosとの積を出すときに、折角のＳフラグをうまく
扱えてない…　書いたロジックの問題だな。

どんな修正すれば良いかは、もうちょっと慎重に
見直さないと。
そのほかは、表計算でバッチリ動かしたときと誤差が
ほぼ1前後だから、切り捨て誤差レベルと考えてよい
でしょう。

見えてきた…。

予断を許さない状態

今日も引き続き、被災地された方々や被災地で懸命に支援
をされている方々には只々一日も早い復旧を願いつつ、
亡くなられた方々のご冥福へのお祈り。

現地にオイラが行っても何も出来ないだろうし足手まとい
にしかならないから、今できるのは昨日の募金まで。
他に何か出来れば思いつくたびに逐次やって行きたい
ところ。まずは節電だな。今日はエアコン一切使わなかった。
照明も５Ｗ＋５Ｗの小さい蛍光灯だけ。

それにしても心配なのは福島第一原発２号機の状況。
まったく予断を許さない状態。現場は本当に大変なんだ
ろうけど、門外漢のオイラがあれこれ言うだけのノウミソ
は無いからな。現場で悪戦苦闘している人達にエールを
送るだけ。
安定した冷却状態っていうのは一体どういう状態
なんだろう？今制御が難しくなっているのはなぜ
なんだろう？普段の運転停止とナニが違うんだろう？


久しぶりにオイラのタスクに頭を移してみる。
AVRアセンブラのFFTの続き。

バタフライ演算では、大雑把に言うと８ビットと８ビット
の加算処理と減産処理がそれぞれ２個ずつあって、この
和や差の半分を求める…という処理を延々と繰り返すん
だけど、ここで毛が三本足りなかったのを発見。

FFTの演算自体は一応当初の目論見どおりに動くように
なっているんだけど、２の補数で桁あふれをする場合の
処理をイザやってみると、計算結果がおかしくなっちゃう。

何でだろうと思って色々考えてみる…

８ビット＋８ビットだから、その答えは９ビットの情報に
収まるわけで、その８ビットはDistのレジスタ、残りの
１ビットはキャリーフラグにはみ出ているものと思って
いたんだけど、２の補数だとそうは行かない。

Ｖフラグ（２の補数用のオーバーフローフラグ）が要る
訳ね。情報処理試験レベルのお話。すっかり頭から抜けてた。
そりゃ、大きな数値で計算が狂うのはアタリマエ。

Ｖフラグ使うとなると、単純にローテート／シフト命令
が使えなくなるから、ちょっと弄らないといけないな。
見えてきたからあとは少しずつ進めよう。

デバッグ中

FFTをアセンブラでカリカリ。だいぶ出来てきたので
出来た部分だけでとりあえず実行してみる。
64点分のバタフライ演算の呼び出しと、ビットリバーサル
の処理の部分。

そもそもお試しに書いただけっていうところもいっぱい
残っているので、まともに動くはずが無い…んだけど、
いざ動かしてみたら…やっぱり変。

とりあえずいい加減に書いてあった間に合わせ部分を
集中的に書き直して、とりあえず再実行…。うーーーん。

以前表計算ソフトで実験したものとくらべて、部分的に
合ってたり部分的に合ってなかったり。

根本的に間違えているってことじゃなくて、多分どこか
部分的に間違えている感じ。一番怪しいバタフライ演算
もアレだけど、それを呼び出すFFT演算本体もアレ。

計算式とロジックの対応は明確に出来ているはずなので、
多分2の補数関係のフィッティングがおかしいんだと思う。

もうちょっと弄って見てみよう…。

ちょっとだけお試し

相変わらずAVRのアセンブラでFFTフルスクラッチの
続きを黙々と。

そこそこソースが書けてきたので、出来た範囲だけで
シミュレーション掛けてみる。入力データ的には
シミュレーション画面で適当なノコギリ波を模したもの
を入れてみる。

一通り実行してみると…

なんかデータが出力されたのは見れた…けど、入って
いる場所がなんか変だなぁ…

…あれだ。ビットリバーサルがまだ未実装だからだ。
そりゃそうだな。


ってことで引き続きビットリバーサル処理を練ってみる。
ロジックでうまいことやっちゃおうと思ったんだけど、
意外に処理時間食いそうなので、こういうときは
手っ取り早く定数テーブル化しちゃったほうが賢い。
処理時間も速い。

ってことで例によって99BASIC。定数テーブルをサクッと。

で、具体的な処理方法をちょっと考えてみて、64要素なら
64回ループすりゃいんじゃん…って思ったんだけど
そうするとおかしくなりそう。2つの要素を入れ替えて
64要素順に舐めると、「ひっくり返し」てさらに「ひっくり返し」
なおすから、元に戻っちゃう。
2進数のビット反転前後の値を眺めれば、単に頭から半分
（0～31）を舐めて、そいつらをビット入れ替えすればいい
はずだな。ロジック的には単純で大丈夫。


そっちが出来たら、その次は最初に適当に組んでた
バタフライ演算の部分。負数を無視して作ってあるので
これを2の補数表示で計算できるように変更しないとな。

そこまで出来ればコーディング終了は近い。


そういえば、平方和の平方根（スカラー値）を求める処理
は、１回あたり120クロックほどかかるので、正の周波数
だけ考えても32要素必要。スカラー値にする時間だけでも
単純計算で4000クロックほど要するんだなぁ…。
なんだか馬鹿らしい時間な気がしてしまう…

当初10000クロックちょっとで64点FFTが1回計算できそうだ
と思ってたんだけど、仕上がってきてみたら20000クロック
近い値になってしまいそう。もうちょっと速いと良かった
んだけどな。

FFTのクロック数計測

アセンブラフルスクラッチのFFT。

とりあえず64点を6段階でFFT掛けるところまで
組めたので、シミュレーションかけてクロック数を
概算してみることに。まだビットリバーサルも
平方和の平方根（実数、虚数をスカラー値に変換）する
ところまでは出来てないんだけど、そっちはそれほど
処理クロック要らないだろうから概算レベル。

イザ！

1回の64点FFTがおよそ14000クロック。まだロジックの
正確さも未確認、小数点位置も誤ったままなので、
微調整したらもうちょっと長くなるかもしれないけど、
桁違いにはならないはず。若干の上乗せだろうと。
仕上がりでざっくり16000クロックと考えてみる。

すると、16Mhzで16000クロックなら毎秒1000回。
8チャンネルを並行的に処理するとなると、1000÷8
で毎秒125回といったところ。遅延時間は10m秒以下
かな。まぁいい感じ。

考え違いをしていなければ、そこそこのスペックで
処理できる目処たった感。64点FFTに特化したロジック
ってことでそこそこ効率化を練りこんでみた結果。
高級言語だとさすがにここまでは行かないはず。


そういえば、ＦＦＴの各段階でSRAMを別々に用意
しないといけないかも…と思ってたんだけど、単に
洗い換えで充分だった。データ量を最小化するなら
64点×（実数＋虚数）の128バイトだけで済んじゃう。
ビットリバーサルや平方和の平方根を求めるのに
同じSRAMを流用しちゃえばそれ以上のメモリは不要。
意外に食わないのねぇ。
（レジスタはかなりアクロバティックだけど）

プログラムメモリも、定数テーブル＋ロジックで
現状1KB程度。ビットリバーサルと平方和の平方根を
付け足して、ちゃんと計算どおり動くようにガンバロウ。


そしたら、その後は極力汎用的に使えるように改良だな。