いろいろ試す60

いろいろ試してきてついに60回を迎えてしまいましたが
ほんっと大したことやってませんね…



●ぶろぐの画像の修正すべて完了の件
2016年からはや7年も経過してしまいましたがdropboxの仕様変更のあおりを
受けて表示できなくなっていた画像ですがすべて修正が完了致しました！！

長かった…一番しんどかったのは東海自然歩道や登山関連の超大量の
画像の差し替え作業でしたがなんとかすべてこなすことができました…
もう10年以上前になるものもあって本当に年月を感じ…
あああああああああああああああああああああ！！！！１１１！！！１



現在はEDGEで見た際に表示が崩れないようにレイアウトの修正を細々と
行っております。
ゆくゆくはwordpressに移行を考えておりますが…何年後かな…？


●Windows10以降対応の64bit版FONTX2コンバータ作りました
FONTX2は現在では電子工作で大人気のフォントフォーマットです。
詳しい解説はおなじみChaN師のサイトでもされており参考になります。

ところで現在Windowsで使われているTrueTypeフォントからFONTX2ファイルを
作成したい場合はかつてはWFONTXという非常に便利なツールが存在して
いたのですがこれはWindowsNT3.1用の代物で、64bitOSが全盛の現在では
動作させることができません。

そこでねむいさんが64bitOS対応のWFONTX64を作成いたしました！
これはオリジナルからXPに対応されたすん様のWFONTX32をベースとしております。
ねむいさんが見つけた細かいバグ等も修正し使い勝手を多少上げました。


☆使い方☆

まずはプログラムを開いたところです。
ここではねむいさんの最近のお気に入りの小夏フォントを12x12pixelの
FONTX2化する例を挙げます。

注:あらかじめ小夏フォントをインストールしているのが前提です！

ドロップダウンメニューから"小夏 等幅"を選択します。


次に高さと幅をピクセル数で指定します。ここで注意ですがたとえば12x12で
表示したい場合はHeightに12,WidthにHeightの半分の6を指定します。


Widthに12をしてしまうと横長になっちゃいます。
12の半分の6を指定してください。


"FontX2 Name"の欄にはFONTX2のヘッダを指定します。FONTX2の仕様上8文字
以上は指定できません(8文字以上入力できないようにしてます)。
ここではKONATHNとします。
また、FontX2Typeは半角の"Ank"を指定します。


Save Nameの欄は生成されるファイル名を指定します。
KONATHN12.FNTとします。

ここまで入力したら"RUN"と"NO STOP"が押せるようになります。
"RUN"はダイアログに1文字ずつ表示しながら変換(遅い)、"NO STOP"は表示
せずに一気に変換します(早い)。


変換が終わるとKONATHN12.FNTが生成されます。
生成されたのはFONTX2の中のAnkフォントで半角のAscii文字だけが
格納されてます。漢字などの2バイト文字は全角用の生成操作が
必要です。


お次は2バイトの全角です。ラジオボタンをAnkからKanjiに変え、
Save NameはKONATZN12.FNTとしましょう。


これで半角・全角のFONTX2ファイルが無事生成されました！


で、こいつをねむいさんのいつものに組み込んでSTM32H5使ってTFT-LCDに
FONTX2ドライバを使って表示できました。


こんなわけで30年の時を超えて現在でもお手軽にマイコンで好きな文字が
お手軽に表示できるようになっております。
また、生成したFONTX2ファイルを含むソースコードの再配布の際は元の
フォントのライセンスに注意し、それに従ってください。




●avrdudeがv7.2になっていた
亀のような更新速度だったころから比べると日々増殖する小宇宙状態と
なっているavrdudeですがいつのまにかv7.1->v7.2に進化しております。

紹介しきれないくらい機能がアップしておりますので特に細かい不具合が
つぶさに修正されておりますので特に理由がない場合以外はv7.2に乗り
変えましょう。

ねむいさんもVerupのスピードに振り落とされないようにしがみついており、
おきぱでも常に最新のavrdudeのwindowsバイナリを公開しておりますので

よろしくお願いします！！


●CMSISもv6になっていた
10年ほどの間CMSISはver5のままメンテが行われておりましたが今年の
春くらいからver6に移行しております。

大まかな構成は変わっておりませんのでそのまま置き換えてビルドが
可能になっております。

この記事を書いてる現在では修正されましたがGCCでコンパイルした際に
"#pragma clang system_header"が引っかかってワーニングが出まくる
事態となっておりましたが10月末にようやく修正されました。
おきぱで紹介しているいつものたちはその修正されたものを適用してますので
こちらもどしどしご利用ください！


●そのGCCも13になっていた
そしてGCCも12から13にバージョンアップしておりました。

arm-none-eabi-gcc (Arm GNU Toolchain 12.3.Rel1 (Build arm-12.35)) 12.3.1 20230626

->
arm-none-eabi-gcc (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1 20231009



ねむいさんのSTM32H7-Discovery向けプロジェクト"いつもの"のバイナリサイズを
比較してみましょう。

GCC12
Built Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_OTM8009A_DSI_TFT

USING_DEVBOARD = USE_STM32H747I_DISCO



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 709212	      0	 709212	  ad25c	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 707324	   1888	2384060	3093272	 2f3318	main.elf

main.elf  :

section               size         addr

.text              0xac840    0x8000000

.ctors                 0x0    0x80ac840

.dtors                 0x0    0x80ac840

.eh_frame             0xb0    0x80ac840

.ARM.exidx            0x98    0x80ac8f0

.itcm                0x174          0x0

.data                0x760   0x24000000

.bss               0x11f2c   0x24000760

.heap                  0x0   0x2401268c

.dtcm                0x20c   0x20000000

.stack                 0x4   0x2000020c

.ram1_d2               0x0   0x30000000

.ram2_d2               0x0   0x30020000

.ram3_d2               0x0   0x30040000

.ram4_d3               0x0   0x38000000

.batram                0x0   0x38800000

.extram           0x233f80   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x45          0x0

.debug_frame        0x1f7c          0x0

.ARM.attributes       0x30          0x0

.debug_line_str      0x1f4          0x0

Total             0x2f54fd

GCC13
Built Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_OTM8009A_DSI_TFT

USING_DEVBOARD = USE_STM32H747I_DISCO



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 709868	      0	 709868	  ad4ec	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 707980	   1888	2384060	3093928	 2f35a8	main.elf

main.elf  :

section               size         addr

.text              0xacad0    0x8000000

.ctors                 0x0    0x80acad0

.dtors                 0x0    0x80acad0

.eh_frame             0xb0    0x80acad0

.ARM.exidx            0x98    0x80acb80

.itcm                0x174          0x0

.data                0x760   0x24000000

.bss               0x11f2c   0x24000760

.heap                  0x0   0x2401268c

.dtcm                0x20c   0x20000000

.stack                 0x4   0x2000020c

.ram1_d2               0x0   0x30000000

.ram2_d2               0x0   0x30020000

.ram3_d2               0x0   0x30040000

.ram4_d3               0x0   0x38000000

.batram                0x0   0x38800000

.extram           0x233f80   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x44          0x0

.debug_frame        0x1d1c          0x0

.ARM.attributes       0x30          0x0

.debug_line_str      0x1f4          0x0

Total             0x2f552c



あれ…なんかバイナリサイズが600Byte近くも増えてるような…


と、とりあえず速度比較もしてみましょう
jpegファイルのデコード速度を比較します。-O2でコンパイルしました。


GCC12:(236704uSec)


GCC13:(237486uSec)

…
あ…あれ…結構遅くなってる…！？

ま、まぁ多分何かの安定性が上がったかもなのでよしとしましょう…
(脂汗)

Go to top of page