画像をダウンロードして表示する機能を作成しています。画像表示をおこなうためには、大きく分けてふたつの処理が必要です。
ひとつは、LCDへのダウンロード画像の表示ルーチンの作成です。使用しているNokiaカラー液晶は、256色と4096色の2種類の表示モードをもっています。文字については、256色を使って表示してきましたが、画像には4096色を使うことにします。4096色はRGBそれぞれ4ビットづつの12ビットで表現されます。LCDにSPIで送る際にはLCDコントローラの仕様で、2ドット分のデータ24ビットを3バイトで送ることになっています。具体的には、次のようなビット列です。
RRRRGGGG BBBBRRRR GGGGBBBB
このような仕様のため、1ドットだけ書き換えたい場合には、隣接するドットのデータを読み出す必要が生じます。LCDのコントローラは、ドットの読み出し機能も持っているのですが、実際のLCDにはSPIでの読み出しデータ線が用意されていません。つまり、書き込みしかできないデバイスになってしまっています。このような制約があるため、常に偶数ドットを書き込むことにします。というか、どうせ横132ドットという狭い画面なので、画面幅いっぱいの画像しか表示しないことにしてしまいます。
上記のような2ドット分を3バイトにパックするのが、この液晶を使ううえでのお約束だったのですが、Sparkfunから最近出荷されているLCDでは、違うフォーマットをサポートできることを、先日Sparkfun経由でこのページで知りました。
0000RRRR GGGGBBBB
というように1ドットあたり16ビットを送るフォーマットをサポートしているとのことです。送るデータ量は増えますが、任意のドットの書き換えをするには好都合です。わたしも、先日実験してみたのですが、残念ながらわたしのLCDは、この機能をサポートするコントローラではないようです。
もうひとつ必要となる処理は、ダウンロード機能です。プロトコルとしては、HTTPを使うことにします。TCPポートをひとつしか使いませんし、画像ファイル名を指定してGET要求を送れば、その応答として画像ファイルのデータを送り返してくれるので、処理も簡単です。もっとも、HTTPの構文解析はトコトン手抜きして、エラー処理もほとんどしないことにしちゃいます。ブラウザを作るわけじゃなくて、画像表示に利用したいだけですので。
LCDの画面は3分割して使用していますが、画像は中央部分のメインスクリーンに表示することにします。ログ用のエリアとして4行分32ドットを使っていましたが、画像領域を広げるために、ログ領域は3行に減らすことにします。結果として、画像を表示する領域のサイズは132 X 96ドットとなります。AT91SAM7S256にはRAMは64Kしかありません。132X96ドット分の画像データとしては、132X96X1.5 = 19008バイトが必要となり、全部をメモリに保持しようとすると、全メモリの1/3近くが必要になってしまいます。そこで、ダウンロードしながら表示することとし、メモリを節約することにします。
通常Webページ上の画像には、JPGやPNG形式を用います。しかし、これらのフォーマットでは画像を圧縮していますので、展開作業のためにメモリやCPUパワーが必要となってしまいます。そこで、非圧縮の24ビットBMP形式を使うことにしました。これなら、ダウンロードしながら、24ビットを12ビットに落して表示すればいいだけです。
このような作業を終えて、どうにか画像を指定して表示できるようになりました。ところが、ダウンロードと表示にずいぶんと時間がかかります。当面の対処として、BMPとしては非標準になってしまいますが、色数を12ビットとし、LCDへ送りやすいフォーマットに変更することにしました。それでもまだ、1画面を表示するのに15秒くらいかかっていますので、まだまだ改善努力が必要です。
ひとつは、LCDへのダウンロード画像の表示ルーチンの作成です。使用しているNokiaカラー液晶は、256色と4096色の2種類の表示モードをもっています。文字については、256色を使って表示してきましたが、画像には4096色を使うことにします。4096色はRGBそれぞれ4ビットづつの12ビットで表現されます。LCDにSPIで送る際にはLCDコントローラの仕様で、2ドット分のデータ24ビットを3バイトで送ることになっています。具体的には、次のようなビット列です。
RRRRGGGG BBBBRRRR GGGGBBBB
このような仕様のため、1ドットだけ書き換えたい場合には、隣接するドットのデータを読み出す必要が生じます。LCDのコントローラは、ドットの読み出し機能も持っているのですが、実際のLCDにはSPIでの読み出しデータ線が用意されていません。つまり、書き込みしかできないデバイスになってしまっています。このような制約があるため、常に偶数ドットを書き込むことにします。というか、どうせ横132ドットという狭い画面なので、画面幅いっぱいの画像しか表示しないことにしてしまいます。
上記のような2ドット分を3バイトにパックするのが、この液晶を使ううえでのお約束だったのですが、Sparkfunから最近出荷されているLCDでは、違うフォーマットをサポートできることを、先日Sparkfun経由でこのページで知りました。
0000RRRR GGGGBBBB
というように1ドットあたり16ビットを送るフォーマットをサポートしているとのことです。送るデータ量は増えますが、任意のドットの書き換えをするには好都合です。わたしも、先日実験してみたのですが、残念ながらわたしのLCDは、この機能をサポートするコントローラではないようです。
もうひとつ必要となる処理は、ダウンロード機能です。プロトコルとしては、HTTPを使うことにします。TCPポートをひとつしか使いませんし、画像ファイル名を指定してGET要求を送れば、その応答として画像ファイルのデータを送り返してくれるので、処理も簡単です。もっとも、HTTPの構文解析はトコトン手抜きして、エラー処理もほとんどしないことにしちゃいます。ブラウザを作るわけじゃなくて、画像表示に利用したいだけですので。
LCDの画面は3分割して使用していますが、画像は中央部分のメインスクリーンに表示することにします。ログ用のエリアとして4行分32ドットを使っていましたが、画像領域を広げるために、ログ領域は3行に減らすことにします。結果として、画像を表示する領域のサイズは132 X 96ドットとなります。AT91SAM7S256にはRAMは64Kしかありません。132X96ドット分の画像データとしては、132X96X1.5 = 19008バイトが必要となり、全部をメモリに保持しようとすると、全メモリの1/3近くが必要になってしまいます。そこで、ダウンロードしながら表示することとし、メモリを節約することにします。
通常Webページ上の画像には、JPGやPNG形式を用います。しかし、これらのフォーマットでは画像を圧縮していますので、展開作業のためにメモリやCPUパワーが必要となってしまいます。そこで、非圧縮の24ビットBMP形式を使うことにしました。これなら、ダウンロードしながら、24ビットを12ビットに落して表示すればいいだけです。
このような作業を終えて、どうにか画像を指定して表示できるようになりました。ところが、ダウンロードと表示にずいぶんと時間がかかります。当面の対処として、BMPとしては非標準になってしまいますが、色数を12ビットとし、LCDへ送りやすいフォーマットに変更することにしました。それでもまだ、1画面を表示するのに15秒くらいかかっていますので、まだまだ改善努力が必要です。