このあいだのXbeeの電力ロガーのデータはテキストデータで定型なので、少しでもエラーがあると目立つのだが、どこまでも綺麗に出力される(前は、3回に一回はどこかしらデータの乱れがあった)。いやあ満足、満足である。勢いに乗って消費リソースを調べてみた。今度のソースコード全体のスライスは366、前は382だった。差はわずかだが、このスライス量はすべてのルーチン(UART受信、SRAMアクセス、ビデオ信号、SPI、10進変換など)を含んでいる。送信UARTだけならスライス量は80程度と考えられ、それでこの差は大幅な削減だ。調子に乗って、またソースコードを公開してしまうことにした。送信の部分だけだが、Latticeの環境では、間違いなく雑誌のコードより信頼性の高いVerilogHDLソースである。コメントに日本語が入っているが、これは公開のために追加したもので、Latticeのエディターでは日本語は化けてしまうので注意されたい。デジタル液晶インターフェース実装(2010.09.28)コメントがた老です。コメントありがとうございました。>かなり腕が上がった証拠ですね。いやいや、褒められるとは思わなかったので嬉しいですね。ありがとうございます。>何かの状態(stateとか)をデコードして生成した信号だと>ハザードの危険が出てきます。あの雑誌ソースは、ステートレジを足し算で作っていますので、これが問題かと思っています。ステート15から16は、01111から10000になり5ビットが一気に変わります。これがMSBのボーレートが短くなる原因かと思いましたが、MSBのステートは17と18。追求はこれ以上あきらめました。雑誌に載っているソースの問題点が見えてくるのはかなり腕が上がった証拠ですね。同期回路内で発生するハザードは問題ありません。ハザードがあっても、その信号を参照するのはするのは次のクロックのタイミングなので、そのときに信号が安定していればいい訳です。PINに出力する信号にハザードがあっては問題になります。出力PINに接続される信号がDFFの出力そのものなら原理的にハザードはありません。何かの状態(stateとか)をデコードして生成した信号だとハザードの危険が出てきます。pCLK)内で出力信号を直接生成するとその信号はDFFの出力そのものになるので、ハザードの心配はありません。05時19分コメントを書く名前:メールアドレス:(ウェブ上には掲載しません)アドレス(URL):この情報を登録するコメントは記事投稿者が公開するまで表示されません。デジタル液晶を動かす準備。