Blog2Viewer

以前、Movable Typeで運用していたブログの内容を表示させるために作成したページです。
月ごとのリンク
2011:
1
2
3
4
5
6
7
8
9
10
11
12
2012:
1
2
3
4
5
6
7
8
9
10
11
12
2013:
1
2
3
4
5
6
7
8
9
10
11
12
2014:
1
2
3
4
5
6
7
8
9
10
11
12
2015:
1
2
3
4
5
6
7
8
9
10
11
12
2016:
1
2
3
4
5
6
7
8
9
10
11
12
2017:
1
2
3
4
5
6
7
8
9
10
11
12
2018:
1
2
3
4
5
6
7
8
9
10
11
12
前の月
2012年7月の記事
次の月
2012-07-03(Tue)
ファイラーみたいなものが動いた
自作stm32f4モジュールではSDカードが読めてTFTモジュールに表示ができるのだから、ファイラーみたいなものが動くと、いろんな機能の実験・デモに便利なので、chanさんのファイラー( ffsample.zipに含まれているもの)を移植中。なんとかテキスト・ファイルを表示したり、jpegファイルも表示することができるようになった。TFTパネルに、いろいろ情報が表示されると機能している気がして嬉しい。

[caption id="attachment_4634" align="alignright" width="150"] SDカード上のjpeg画像[/caption]操作は外付けのタクトスイッチ4個で行なっている。問題なく使えるが、すこし、まだるっこい。タッチパネルが欲しい。aitendoなどで売っているタッチパネル付き液晶モジュールを使えば良いのかもしれないが、在庫数が限られていると、基板を起こして遊ぼうという気持ちになれない。秋月のTFTモジュールには長期安定供給という意味で期待している。TFTモジュールの活用という意味からすると一緒に使えるタッチパネルが欲しいところだ。

jpegファイルの伸長には、これもまたchanさんのTJpgDecモジュールを使用させてもらっている。少しずつ試すと、思ったより簡単にjpeg画像を表示できた。

といいつつ、実は用意したjpegファイル10個中2個ぐらいしか表示できていない。表示できないファイルはJDR_FMT1: Data format error (may be damaged data) というエラーになるのだが、PCでは問題なく表示出来ているのでデータが壊れているわけでは無さそうだ。


[caption id="attachment_4635" align="alignright" width="150"] こちらはROM上のBMP画像[/caption]最初に試したファイルが、たまたま読めるデータなのでよかった。最初のファイルがエラーになってしまっていたら、またいろいろとハマッてしまったことだろう。今後調査してみたい。

chanさんのファイラーには、動画や音声を再生する機能もあるが、それらは、まだ移植していない。jpegファイルのエラーの問題が解決したら、それらにも手を出してみたい。でも動画の再生はSPI接続だと更新速度が無理っぽい。

表示の更新速度は下の動画で見て欲しい。まだ高速化は、あまりやっていないので、頑張れば数倍程度は速くできると思っている。



7/2 追記.

エラーになるjpegファイルの件は、調査の結果、ファイル読み込み処理の実装ミスと判明。読み飛ばし処理が間違っていた。修正して、全てのjpegファイルを表示できることを確認した。
2012-07-05(Thu)
プログラムにバイナリーファイルを組み込む方法
ffsample.zipの中にあるchanさんのファイラーのプログラムではFONTX形式(FONTX2?)のファイルを直接プログラムに組み込んでいる。やり方を調べると、IMPORT_BINというマクロが定義されていた。


C言語のasm文でアセンブラ(gnu assembler)を呼び出し、.incbinという命令でバイナリーファイルを直接プログラムに組み込んでいるわけである。.incbinという命令は知らなかった。便利な命令があるものだ。
[caption id="attachment_4651" align="aligncenter" width="385"] バイナリーファイルを組込むマクロ[/caption]
この機能を使ってフォントファイルとBMP形式の画像ファイルをプログラムに埋め込んでしまった。それ以外に、C言語の形式でShiftJISとUNICODEの変換表(chanさんのFatFSのサンプル実装に入っていた)も組み込まれている。画像ファイルはJpegファイルを表示できるようになる前の表示テスト用で、今となっては不要なのだが、まだ入っている。で、プログラムサイズが650Kbyteほどにもなってしまった。stm32f4xxのFlash容量は1Mbyteもある(品種によっては512Kbyte）ので大丈夫なのだが、プログラム書き込みに1分ぐらいかかってしまう。これでは、プログラム開発に支障が出てしまう。



そこで、フォント等の固定データは、別のセクションに分けて特定のアドレスに配置し、プログラムと分けて書き込めるようにした。gcc上では、__attribute__((section(".big_rodata")))で、固定データの変数にsectionを指定しする。linkerスクリプトを修正し、固定データのセクションを特定のアドレスに配置し、あと、objcopyコマンドで .elfを .hex(インテルヘキサ形式)に変換する際に、 -Rオプションで不要なセクションを削ってやると、欲しい部分だけの .hexファイルができる。

で、固定データは1度だけ書き込んでやると、プログラム部分は、現在のところ5秒ぐらいで書き込むことができている。今後プログラム部分がが大きくなってくると、少しづつ書き込み時間は長くなってくるだろうが、まぁ満足している。

将来的には、プログラム開発時に変更しないライブラリー部分も同様に分けて書き込む、なんてこともできると嬉しいかもしれない。
2012-07-25(Wed)
単なる価格設定のミスでは？
MAKE: Japanに「絶望の落とし穴」に落ちないためにはという記事がある。


大変にクールな電子製品（この場合はとくに手作り品）を売る企業は、この数年で爆発的に増えた。新しい製品が市場に登場するたびにとても興奮させられるが、とりわけ驚かされるのは、それらの企業が繰り返し直面する困難についてだ。そうした製品は、3つの「バケツ」に分類することができる。ハッピーなバケツ、仕事のバケツ、そして絶望の落とし穴だ。

...

びっくりするほど多くの製品が3つめのバケツに落ちていく。私はこれを「絶望の落とし穴」と呼んでいる。これらの製品は、開発者が期待していたよりもずっと多くの注目を集めている。非常によくできているが、趣味の範囲の、一度に10個も作れたらよいというツモリで作られている。そこへ数千の単位で注文が入ると、開発者は厳しい決断を迫られることになる。本業の収入ではその注文に応えきれない。それを作るために生活のあらゆるものをなげうって、週末はすべて製作にあてなければならない。150袋もの抵抗やLEDを数えたことのある人ならわかるだろう。それは苦痛以外のなにものでもない。


これって、単なる価格設定のミスだろうと思うのだが違うだろうか。自分のクールな電子製品に安い価格を設定したい気持ちは良くわかる。安い方が、より受けるだろうと思うし、高かったらクールでないし存在価値が無い。それに、この製品で大儲けできると思っているわけでもない。

そこで部品代に少しばかりの手数料を加えて、損はしない程度の価格で売り出す。注文があれば嬉しい。手間の割に、儲かっていない気がするが、喜んでもらうと嬉しい。

しかし、記事にあるように数千個の注文が来たらパニックだ。人を雇えるほどの利幅は無いから、全て自分でやらなければならない。自分でやるにしても、利益を作業時間で割ってみると、時給など無いに等しい。

ここで気付くべきだ。価格設定のミスだと。自分がやってきたことはビジネスではなく、ボランディアだったと。自分の労力を極めて低価格で提供し、同好の士に喜んでもらうボランティア活動だったと気付くべきだ。数千個単位の注文が来たら、そんなにボランティア活動する余力はありませんのでお受けできませんと断るべきだ。

全ての作業を他人に任せ、費用を払っても利益が残るのが正しい価格設定だろう。そうでなければボランティア価格ということになる。

となると、記事にある「コミュニティで支えあう」というのが何のことだかわからない。利益が出なくて有償では他人に頼めないから「支えあう」？ ボランティア活動なら、負担を「支えあって」なんとかするというのはあるかもしれないが、企業への数千個の注文に応えるために「支えあう」のであれば、低報酬の作業を分けあい、企業に利益をもたらすだけでまったく意味が見出せない。間違っていると思う。

中規模の生産について、さまざまなノウハウを集めて、安く作る方法を広めるというような活動の方が嬉しいのだけれど、どうだろう。
前の月
2012年7月の記事
次の月