いろいろ試す20…という名の今年の反省会

今年もいろいろありましたが私としてはやってることはほとんど変わらず
山走りとかに行ったりLチカを極めるべく研究したりOpenOCDのエンバグ
とかです。

特にステップアップらしき事をしたのは今まで利用だけしていたOpenOCDの
プロジェクトに対してパッチを提出する形で能動的に参加したことでしょうか。
言葉の壁はもちろんありますが何度もこなしていくうちにある程度分かって
きますので皆様もオワコンとか言わずにどんどん参加してほしいと思います。



●マイコン向けの最強最後のTFT-LCDをゲッツか

i8080バスで接続できるもので現時点でほぼ最強かと思われるモジュールを手に入れ
ました。320x480(HVGA)・ILI9486L・超広野角・3.8inch・抵抗膜式タッチパネル
付と至れり尽くせりでSTM32F4系のFSMCで接続するには最適です。
これ以上のピクセルサイズになるとRGBやMIPI-DSIのほうが速度的に有利になるので
やはり"マイコン"で使用するのなら320x480が上限と感じます。

以前の主力だった3.45inchの奴(コントローラIC:R61581/B0)と比較してみました。
一回り大きいのがわかると思います。


GCC ARM Embedded in Launchpadがアップデート
読んで字のごとくですがクリスマス前に合わせて更新というなかなかニクいアップ
デートです。今回からGCC4.8.x系になりました。また今回の目玉は新しいコンパイラ
オプションの"-mslow-flash-data"の追加です。これはどういうものかというとリテ
ラルロードを極力movtに変えてバスの競合を避けパフォーマンスのアップを図る

いわれるものです。ARM本家のこちらこちらもご参照のこと。


"-mslow-flash-data"のありなしで吐かれたアセンブラリストの比較をしました。
使用したプログラムはSTM32F4のいつものです。赤でハイライトしてる部分がその違い
ですがLDRで行っていたリテラルロードがmovtに置き換わってるのがわかります。
LDR命令の場合、最短3クロックサイクルかかりバスの競合があるとさらに5クロック
サイクル以上掛かることになります。movtに置き換えた場合はサイズは増加しますが
2クロックサイクル固定です。

次に実際のパフォーマンスを比較してみました。libjpegとlibpngのデコード速度の
実時間を計測して比較しました。表示に使ったのLCDはもちろん最初の項で紹介した
これです!
また表示に使用した画像は320x480サイズにしさらにpngとjpegに変換を行った
いないさんのおぱn…いないさんのイラスツをサンプルとして計測結果をuSec単位で
こんな感じで表示し



…ゲフンゲフフン
さて実際の結果ですが、せっかくなのでfreddiechopinさんとこのBleeding-Edgeツール
チェイン
や役立たずに堕ちたSourceryCodebenchも(←今回の比較のためにわざわざ
登録してインストールしためっちゃめんどくさいF**K!)交えコンパイラオプションも
いろいろ変えて各コンパイラ性能比較も兼ねて行いました。

↓とりあえず各条件の計測時間の羅列です
 (※-mfloat-abi=softの時はlibjpegのDCT_FLOATは無効にしていますのでバイナリ
   サイズが全般的に下がっております。)


libjpeg/libpng rendering speed compare
uses inai-san's oketsu-pantsu gazou.
PNG : INA~1.png 96128kByte
JPEG : INA~1.jpg 40491kByte

LAUNCHPAD
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]

@@L1111
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496760 0 496760 79478 main.hex
***libjpeg
182341uSec
***libpng
168305uSec

@@L2222
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 489144 0 489144 776b8 main.hex
***libjpeg
181903uSec
***libpng
168485uSec

@@L2222 (nano-lib)
(Using nanolib -u _printf_float) -Ofast-mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 470620 0 470620 72e5c main.hex
***libjpeg
194318uSec
***libpng
234706uSec

@@L3333
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496752 0 496752 79470 main.hex
***libjpeg
182345uSec
***libpng
168311uSec

@@L4444
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 489136 0 489136 776b0 main.hex
***libjpeg
181925uSec
***libpng
168588uSec

@@L5555
(Using newlib) -Ofast -mfloat-abi=soft -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496152 0 496152 79218 main.hex
***libjpeg
186999uSec
***libpng
168740uSec

@@L6666
(Using newlib) -Ofast -mfloat-abi=soft
=== Total Binary Size ===
text data bss dec hex filename
0 488592 0 488592 77490 main.hex
***libjpeg
187095uSec
***libpng
168490uSec







BLEEDING-EDGE
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors / bleeding-edge-toolchain-130810) 4.7.4 20130613 (prerelease)

@@B1111
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 555460 0 555460 879c4 main.hex
***libjpeg
183801uSec
***libpng
170161uSec

@@B2222
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 555436 0 555436 879ac main.hex
***libjpeg
183797uSec
***libpng
170156uSec

@@B3333
(Using newlib) -Ofast -mfloat-abi=soft
=== Total Binary Size ===
text data bss dec hex filename
0 553492 0 553492 87214 main.hex
***libjpeg
187582uSec
***libpng
170098uSec






SOURCERY CODEBENCH
arm-none-eabi-gcc (Sourcery CodeBench Lite 2013.11-24) 4.8.1
@@S1111
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 504568 0 504568 7b2f8 main.hex
***libjpeg
184072uSec
***libpng
203915uSec

@@L2222
(Using newlib) -Ofast -msoft-float
=== Total Binary Size ===
text data bss dec hex filename
0 504040 0 504040 879c4 main.hex
***libjpeg
186811uSec
***libpng
203920uSec


かなり条件が入り乱れているので要点をかいつまんで紹介しますと、
まず"-mslow-flash-data"有だと、無しのものより逆にlibjpegのデコード速度が若干
下がるといった結果になりました。libpngはちゃんと速くなったのですが…全体的に
スピードアップすると思っていたのでちょっと微妙な結果です。
おきぱにて公開してるいつものはつぶしが聞くように"-mslow-flash-data"オプションは
デフォルトではコメントアウトにしてます。
↑2014年が明けて一週間たったころにようやくlibpngとlibjpegの評価をあべこべに
 書いてたの気づきましたすみませんorzちゃんと修正しました。
 "-mslow-flash-data"オプションを付与するとlibjpegでは逆効果になってしまいます。

またLaunchpad特有のnewlibをシュリンクしたnano-libを使用した場合、全体的な
パフォーマンスが低下することが分かりました。libjpegもlibpngもmallocを使用
するので、そこにパフォーマンスの違いが現れていると思われます。
作成するアプリケーションの目的に応じて使い分けるのがよいでしょう。

次に各コンパイラ比較ですが同条件(-Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16)
の場合、LaunchpadのGCCがサイズの小ささ/速度ともにトップになりました。
さらにLaunchpadのは"-mfloat-abi=hard"も選択できる(Sourceryのはsoftしかない)
ので、もはやわざわざ登録してまでSourceryCodebenchを利用する意味が全くなく
なりました。
皆様も早急にLaunchpadに乗り換えられることをお勧めいたします。

すぐにだっ!




●よくいただく質問に対する回答とか
というわけで今年のぶろぐもこれでお開きですが、毎年恒例の尺が余ったので
メールや虹裏でいただいた変な質問にぶろぐ上で返信をさせていただきます。


Q:GDBで接続した瞬間に"Remote 'g' packet reply is too long"とい(ry
A:長き戦いよ、さらば!
 ていうかちゃんとぐぐりなさいよー!

Q:USB3.0でLibUSBが(ry
A:こちらをご覧ください
 USB3.0のホストのほうもファームやドライバの最新化は必須ですよぅ!

Q:いままで問題なく動いてたのに急にOpenOC(ry
A:変なことやらかした人に限って口をそろえたように"問題なく動いていたのに急に
 何ちゃら"は何らかのシンクロニシティなのでしょうか…???

Q:(ブラジルポルトガル語と思われるFatFsに関する質問)
A:Sorry,I cannot understand your language,at least in English.

Q:(簡体字中国語と思われるSTM32(←中国で人気のマイコンだそうです)に関する
  何らかの質問)
A:Sorry,I cannot understand your language,at least in English.

Q:(日本語と思われる文字列だが日本語としてまったく解読不能の何らかの質問)
A:Sorry,I cannot understand your language,at least in English.

Q:ねむいさんとか言うサイトみたけど役立つ情報が全くない上に何が
 言いたいのかよくわからないので
A:私もそう思う。
 特に今日の前半のとことか。意識他界方がこんなトコ来ちゃ駄目ですよ…

Q:OpenOCDのWindowsバイナリは配布されておらず
A:ここが見えないのですかここが!!

Q:(企業のメールアカウントで)***なのですが****を希望しますor早く修正してくだ
 さい。以上。(←回答納期をつけてくる場合も…#)
A:今年に入ってなぜか急にたくさんいただくようになりましたが……企業内で開発を
 行われる場合は有償のサポートが付いたツールを使用されるほうがいいと思います。
 もしくはgpl.txtを1000000000000回音読して"利用者が全責任を負う"っていうこと
 を体で理解してください。ちなみに私の副業先ではARMはIARで開発しております。

Q:ルネサA:帰れや!

Q:ギンギンに勃○してるのですが
A:ヤダモウ///

Q:ギンギンに○起してるのですが
A:ヤダモウ///
 これデザインしたの私と同性の方でしょうか…?
 本来のとは逆向きに付いてますし///

Q:ねむいさんで検索すると候補に入院と出てきます。これは何ですか?

A:これは重篤なサジェスト汚染ですね〜!
 当職が入院したとかいう体だけ(非性的な意味で)が取り柄のねむいさんのあいでん
 てぃてぃを否定する検索が多数行われているのは絶対に許さないよれません!!
 力を。

Q:ねむいさんのぶろぐに右端にあるブラウザベンチマークというリンクをクリック
 したら突然大量の画像が貼られるページにいどうして動作が重たくなり、ブラウザ
 がクラッシュしてしまいました!!!1!!ファ*クユー!!!
A:びぃぶろ君が悪いんですけぉ!1!!ねむいさんは悪くないんですけぉ!1!!1

Q:ねむいさんはさんざモロはあかんといっときながらブログでモロを進めていたのは
 どういうことなの?虹裏メイドだからって何か許された特別な人間だと思ってるの?
A:わかりましたから落ち着いてください。かつて存在した虹裏novという場所があった
 のですが話はそこにさかのぼります。そこでは魅力的ないやらしい口元をした紳士
 画像を赤と黄色を交互に放射状にした…いわばマケドニア国旗のような非常に目立
 ちやすい注目をひく画像に加工したものをスレッドの頭画像とし、おもに紳士に関
 する話題やコラージュを中心としたスレッドの進行体系をとっておりました。
 しかし、実写のコラージュを用いたスレッド信仰であったためふたば☆ちゃんねる
 のクンニリンサンにとって二次元裏のポリシーに反する目の上のタンコブだったのです。
 紳士画像のスレッドの住人はそれには構いなしにナイフみたいに尖っては触る者皆
 すべてに不許を貫いておりクンニリンサンに対する反逆とも呼べる行為を続けていました。
 そしてある日ついに、ついに虹裏novはクンニの怒りによってなんと板ごと御取り潰し
 に遭うという悲劇的な結末を迎えました。しかし紳士画像のスレッド住人はそれで
 息絶えたわけではありません。住人達はもといたimg,may,jun,decにとしあきとして、
 「」として溶け込みつつもマジスタンスとして
2014年になろうとする今現在も続く許
 されざるビューティフル・ウォーを繰り広げているのでございます。
 現在では、前途の紳士画像を二次元裏@ふたばに貼付するという行為はクンニに対する
 反逆の証として児童ポルノ画像の貼り付けよりも重篤な一発アウト(スレッド削除・
 アクセス禁止措置)が取られるようになっております。safetyに紳士を語るためには
 紳士を構成する目元といやらしい口元を隠す黒塗りを施した"加工済紳士画像"の
 貼付けにて進行を行わざるを得ないのですがそういった処理前の未加工な紳士画像
 がモロ画像もしくは縮めてモロと呼ばれ、爆発性の危険物として扱われています。
 しかしながらそういったモロが貼られない状況が紳士スレッド内で続くと突然日清
 チキンラーメンのパッケージをはじめ鶏肉を主体とした調理済の料理画像が貼られ、
 あたかも"(モロを貼れない)お前はチキンだ!チキン野郎だ!"と言わんばかりの
 挑発を受けることになります。挙句の果てには手描きを用いチキンとかはたまた妙に
 ウイットに富んだ発音でティキンとかいうモロにストレートな心温まる発言を行ッ
 てくれやがります。ですがあなたたちは紳士です!そのような挑発には決して乗っ
 てはいけません!奴らはあなたの正義感を巧みに利用してモロを貼らせるように仕
 向けているだけです!!1!もし挑発に負けて大人の男怒らせるなよオメーラと言
 わんばかりに未加工の紳士画像を張り付けてしまったらゲーム・セットです。たち
 どころに大勢のアンパイアが現れつぎつぎにアウトの判定を下され、ポケットモン
 スターのアチャモにも「あちゃ〜…もろ」と吐き捨てられ、仲間であったはずのスレ
 ッド住人にdelを叩き込まれてとどめにクンニリンサンになーとアク禁を喰らうでしょう!

Q:東海自然歩道の静岡バイパイコースについて質問です。
 玉露の里にかかる橋のマークはなかなかイカス植物ですね?
A:し…しらない…
 気のせいでしょうハハ

Q:東海自然歩道の静岡バイパイコースについて質問です。
 休暇村富士の玄関で栽培されてる葉っぱはなかなかイカス植物ですね?
A:し…しらない…
 き、気のせいでしょうハハ







ー…そろそろ大掃除しますか…

それではみなさま、よいお年を〜

Go to top of page