イライラするなぁ

どうもStellarisを使っているとイライラする。

○データシートに書いてある内容が不十分
○データシートに書いてある内容どおりに動かない
○StellarisWareは間違いだらけ

確かに、アプリケーションノートやサンプルあること”だけ”をやっている限りはちゃんと動くし、パフォーマンスもそこそこよいと思う。もちろん、CPU以外の機能についても豊富で充実はしている。

しかし、そのCPU以外の周辺機能は、本来想定された正常な動作から外れるともうガタガタだと言わざるを得ない。エラー時の対応・回復処理とか、処理途中でキャンセルするとか、そういうことをやろうとするととたんに不可解な動作をし始める。

例えば、uDMAのキャンセル方法。
データシートによると、DMAENCLRの該当ビットに１を書き込めばDMA動作を停止するとあるが、実際にはちゃんと止まってくれない。いや、確かに“止まっている”のだけれど、uDMAコントローラ内部では転送途中の状態をまだ記憶しているようで、新しい別の転送先／転送元アドレスを指定してDMAENSETのビットをセットしても、新しいアドレスには転送してくれない。
結局、DMAを停止させるために、まずDMAの要求トリガを発生させる機能（UARTやUSBなど）でDMA要求を出させないようにした上で、そのDMAチャンネルにソフトウェアトリガを繰り返し発行してDMA転送を“本当に”完了させる、という方法を採用するしかなかった。

他にも、USBの転送のキャンセル方法についても不具合発見。
USBデバイスとして機能させ、USBデバイス→ホスト方向への転送を途中で止めたくなったとする。つまり、ホストへ転送するためにFIFOに入れておいたパケットの内容を取り消して、ホストからIN-NAKとさせたい訳だけれど、データシートどおりにUSBTXCSRLnのFLUSHに１を書いてみてもFIFOの内容は消えていない（ホストからINトークンでパケットが取れる）し、TXRDYビットがクリアされると書いてあるけれど実際には自分で０を書いて消さなければ消えない。どうやら、FLUSHビットへに書き込みは、FIFO内部のポインタをリセットするだけでFIFOの内容を消したり、USBコントローラに送信可能（TXRDY）であることをキャンセルさせたりはしていないようだ。
しかも、FLUSHでFIFOをクリアすると（正確にはクリアするためにTXRDYに０を書き込むと）割り込みが発生する。その割り込みは要らないだろう。しかも、このデバイスは割り込みを発生させた細かい要因を教えてくれないので、「FIFOクリア直前にホストがINトークンでパケットを転送した」のか、「FLUSHによるキャンセルが要因」なのか区別がつかないじゃないか！バカヤロウ！

全体的に見て、正常な場合の動作しか想定しておらず、「もしもこういうことが起きたら・・・」という異常系での振る舞いについてはほとんど考えられていないのではないだろうか？あるいは、文化的な違いから、青い目の人は「異常が起きたら全部リセットして最初からやり直し、それでいいじゃん？」的な考えなんだろうか。

とまぁ、悪態をついてみたところで、巨大企業であるTIが動いてくれるわけでもなく、せいぜいこんないところを愚痴を書き連ねるのが関の山って所か・・・、orz