2011-08

2011-05

libmapleを使いこなせ!!†

  • mapleで使われているSTM32用のArduinoチックなライブラリ。
  • これが使いこなせるとかなり便利。


対応させる基板：

/ATMEL_AVR/jpg/ARM/stbee.jpg

http://akizukidenshi.com//img/goods/L/M-04276.jpg

  • なんといってもPCに接続する仮想COMポートをデバイス側から普通のシリアルポートのように扱える。（あまりUSBを意識しなくてgetc(),putc()出来るという感じ）
  • なので、これをCQ-STARMとSTM8S-Discovery用に改造中。 ---> 済み
  • STBee , STBeeMini , STM32VL-Discovery対応はxshigeさんの成果を利用させていただいております。感謝!!
  • 結局自分は(STM32用の)Arduinoが使いたいわけではなく、仮想COMを使ったアプリを書きたいだけだった。
  • STM32のサンプルアプリケーションの仮想COMは、とてもやる気ない実装なのと、デバイスから自由にgetc(),putc()出来るように改造するのが面倒なのでそのまま放置している。
  • JavaのGUIだとmakeが使えないし好みのテキストエディタが使えないしライブラリソースの改造作業（各種基板への対応）は、ちょとやり辛い。




↑

謝辞†

↑

DOWNLOAD†

CQ-STARM , STM8S-Discovery , STBee , STBeeMini の４基板を追加したバージョンを公開します。


↑

QuickStart†

CQ-STARM基板:

  • libmaple.zipを解凍します。
  • libmaple/ 直下のMakefileがありますので、
    • Linux コマンドライン
    • もしくはWindowsのコマンドプロンプトから 
      D:\libmaple> make
             ~~~~
    • を実行してください。
  • makeに成功したら、libmaple/build/CQSTARM.hex が生成されています(0x0800_3000番地スタート)
  • armbootを使用する場合は、 
    D:\libmaple> w.bat
  • もしくは、dfuw.exeを使用してCQ-STARMに転送し、実行してください。
  • シリアルポートのinfファイルはwin32drivers/serial/ にあります。
    • (STM32のサンプル用infを使用する場合はVID:PIDを書き換えるかファーム側のVID:PIDをSTM32のものに合わせるかして、デバイス認識するようにください）
  • libmapleのファームウェアが起動して、仮想COMポートが使えるようになったら、そのポートにteraterm等で接続します。
  • SerialUSBに「?」を入力すると、HELPが出るようになっています。
  • SerialUSBに「a」を入力すると、ADCの結果をコンソールにリアルタイム表示するようです。

その他

  • より単純なアプリ（Lチカ)が好ましい場合は、libmaple/直下の main.cpp.example を main.cpp に上書きして make を実行してください。





仕様

（１）libmaple/Makefile に基板選択の定義があります。

# Valid BOARDs: maple, maple_native, ...
#BOARD ?= maple
#BOARD ?= STBee
#BOARD ?= STBeeMini
#BOARD ?= STM32VLD
BOARD ?= CQSTARM
#BOARD ?= DISCOVERY
  • どれか１つを有効にしてください。


（２）CQSTARM , DISCOVERYは 0x0800_0300 から起動するelf/hexを生成します。

  • 開始番地を変更したい場合はlibmaple/support/ld/基板名/flash.ld と、libmaple/libmaple/libmaple.h 内の番地定義の両方を書き換える必要があります。

（３）HEXファイルはelfと同時に生成されます。

  • libmaple/*.bat というバッチファイルにて、armboot経由でhexを書き込んで即実行します。

（４）ビルド環境(CodeSourceryG++ Lite)はCodeSourceryのサイトから入手しても良いですし、

  • maple-0.0.11 入手してそれを展開して得たコンパイラのbinディレクトリに そのまま実行パスを通してもＯＫです。

（５）CQSTARMとDISCOVERY(STM8SのSTLINK)のポート名称はSTBeeやMiniの定義順に準じています。

  • というよりはSTBee.cppをそのまま流用させていただいております。




↑

ビンテージパソコンにLinuxを突っ込む†

レガシーＰＣとubuntu最終章の続き

レガシーＰＣのスペック

  • SONY VAIO F? (Pentium III 900MHz) i815 15inch LCD WindowsXPモデル
  • メモリーは256MB
↑

試行結果†

ディストリビューション(Version)インストールの可否運用実用性の可否
ubuntu 10.04１時間程度掛かるけれど可能遅いけれど可能
ubuntu 10.10１時間程度掛けても全然進まない不可
ecoLinux(ubuntu 10.10ベース)１時間程度掛けても全然進まない不可
ubuntu 11.04１時間程度掛けても全然進まない不可
ubuntu 11.04 Server i386CUIインストーラーなので可能（CUI）動いているように見えるがVGAモードがグラフィックなのにテキスト文字がドットで描かれて読めない。ブラインドタッチで全て操作できるなら可能かも
↑

到達した結論†

／選択項目寸評
○ubuntu 10.04を採用１年前のディストリビューションだが、各種パッケージは古くさくはない。むしろunityを採用した11.04よりも、定番かつ安定感がある
△GNOMEデフォルトのウィンドウマネージャー。多機能だが、重いしメモリーを多く使う。256MBメモリーのパソコンでは相当きつい
○LXDE軽量・高速なウィンドウマネージャー。GNOMEから切り替えると、とても快適にきびきび動いてくれる
  • 切り替え方は 
    # apt-get install lxde
  • して、設定の「ログイン画面」を選び、GNOMEをLXDEに変更すればOK


  • 現在、そのLXDE上から書き込んでテストしている。
  • 漢字変換のキーがGNOME（Windows）流ではなく、昔のX-Window流（ctrl+SPACE）なので、使いにくい。（まだカスタマイズ法を知らないから）
  • 液晶の解像度がいまだにMax 800x600になっていて、1024x768に出来ていない・・・
    • 解決策を検索しました　--> https://forums.ubuntulinux.jp/viewtopic.php?id=8317
    • 要約すると、/etc/X11/xorg.confを新規に用意して、内容は 
      Section "Monitor"
   Identifier    "Configured Monitor"
   Horizsync    31.5-80.0
   Vertrefresh    56.3-75.0
EndSection

Section "Screen"
   Identifier    "Default Screen"
   Monitor        "Configured Monitor"
   SubSection    "Display"
       #Depth    16
       Modes    "1024x768"  "800x480"  "640x480"
   EndSubSection
EndSection
    • で1024 x 768 ＯＫ。
  • Xの解像度や設定周りは今ではxrandr とか cvt というツールを使うようになっている。


  • そうこうしているうちに、ノートＰＣのキーがいくつか(dとかw)効かなくなった。
  • 強く押し込んだら、入力できる場合がある。
  • Windowsで試しても同じ。


やっぱりビンテージＰＣは諦めたほうが良いのか・・・

  • でも最近のノートＰＣは縦のDot数がたりないし、液晶はツルテカで顔が映るし、WindowsXPがなくて7のstarterとかになるし。
  • Atomは嫌だな。遅いから。
  • Llanoなノートが出始めているらしい。
  • Atomは１コア当たりの性能がCore2の半分もない程度だけれど、Llanoは昔のCore2相当（？）らしい。
  • しかしSandyBridgeだとCore2の1.3〜1.5倍（これはサバ読みすぎだ。AVX使うときだけの話だと思う）だからAMDも苦しいと思う。




↑

その後のGNUK†

gnuk USB Token を STM8S Discovery Kit で友達の分も作ろう

極力安上がりに作られてます。


こっちも・・・

USB接続(簡易)JTAG Debugger を作る

  • 以前作ったやつは、手持ち部品から74HC245と、一部ゲートが無かったのでtiny2313をプログラミングして低速CMOSゲートを用意して、あと電圧変換用に抵抗を多数使ったような気がする。
  • それから、壊れたNICからEEPROMを外してFT2232Dに半田付けした。

全部省略できたのか・・・





↑

続：libmapleを使いこなせ!!†

その１

  • libmapleのビルドツリーから、不要なものを除去していってusb_serialだけにしたものを作ってみた。
  • で、ファーム内エコーバックでPCにエコーバックを返すようなものを作ってみた。
  • サイズは8kB程度。
  • 速度は、まだ納得がいかない。

原因は調査中。


その２

  • libmapleと同様に、maple-bootloaderもgitから落としてきてビルド。
  • ファームサイズが妙にでかい。（20k程度）
  • しかし、これはデバッグビルド( -O0指定 )になっているからなので、 -Osに変更してビルドすると6kB程度のファームになるようだ。

相変わらずDFUに興味ない。


  • libmapleは比較的改造しやすいし、コードサイズ縮めようとすれば、maple-bootloaderのソースを参考に（Ｃ＋＋を切捨てしながら）好きなだけ縮めることも可能。（ただしwiringの部分は無くなるので、普通に自前でポート叩くか、うそっぽいdigitalWrite() 関数をＣで起こすとかする）
  • Arduino(ATmega328の16MHz)に比べると遥かに性能良いし、リソース（特にSRAM容量）も多い。
  • Flashを512KとかSRAMを64Kにしたければ３千円程度でSTBee基板を使うことが出来るので、STM32は殿様プログラマー*1な人たち（初心者にも意外と多い：リソースに糸目をつけない太っ腹）には特にお勧め。

（さすがにチップ単体買って基板起こす気にはなれないけれど・・）

↑

ダウンロード†

libmapleを流用したusb_serialエコーバック（ファームサイズ約8kB）


↑

libmapleのDOS(Windows)上ビルドで、オブジェクトサイズが表示されない件†

  • ビルドのリンクフェーズでLinux版だと以下のようなメッセージが出る。 
      text    data     bss     dec     hex filename
   500       4      48     552     228 build/wirish/comm/HardwareSerial.o
   904       0       0     904     388 build/wirish/comm/HardwareSPI.o
   388       0       0     388     184 build/wirish/wirish_digital.o
    50       0       0      50      32 build/wirish/wirish_math.o
    66       0       0      66      42 build/wirish/wirish_shift.o
   551       4      16     571     23b build/wirish/HardwareTimer.o
    38       0       0      38      26 build/wirish/wirish_time.o
   128       0       0     128      80 build/wirish/ext_interrupts.o
    28       0       0      28      1c build/wirish/wirish_analog.o
    48       0       0      48      30 build/wirish/pwm.o
   324       4       4     332     14c build/wirish/usb_serial.o
  1001       0       0    1001     3e9 build/wirish/Print.o
   378       0       0     378     17a build/wirish/boards.o
     2       0       0       2       2 build/wirish/cxxabi-compat.o
     0       0       0       0       0 build/wirish/boards/STBeeMini.o
     0       0       0       0       0 build/wirish/boards/DISCOVERY.o
     0       0       0       0       0 build/wirish/boards/maple_native.o
     0       0       0       0       0 build/wirish/boards/STBee.o
     0       0       0       0       0 build/wirish/boards/STM32VLD.o
     0       0       0       0       0 build/wirish/boards/maple_RET6.o
     0       0       0       0       0 build/wirish/boards/maple.o
     0       0       0       0       0 build/wirish/boards/STBee2.o
   386     708       0    1094     446 build/wirish/boards/CQSTARM.o
     0       0       0       0       0 build/wirish/boards/maple_mini.o
  8558      16      46    8620    21ac build/main.o
    18       0       0      18      12 build/libmaple/pwr.o
    44       0       0      44      2c build/libmaple/iwdg.o
   202      24       0     226      e2 build/libmaple/adc.o
   846      52      19     917     395 build/libmaple/usb/usb_callbacks.o
   164       0       0     164      a4 build/libmaple/usb/usb_hardware.o
  1145     144      10    1299     513 build/libmaple/usb/usb.o
  2170       0       1    2171     87b build/libmaple/usb/usb_lib/usb_core.o
    82       0       0      82      52 build/libmaple/usb/usb_lib/usb_mem.o
    56       0       0      56      38 build/libmaple/usb/usb_lib/usb_init.o
   512       0       0     512     200 build/libmaple/usb/usb_lib/usb_int.o
  1934       0       0    1934     78e build/libmaple/usb/usb_lib/usb_regs.o
   184       0       0     184      b8 build/libmaple/usb/descriptors.o
   682     128       4     814     32e build/libmaple/exti.o
    32       0       0      32      20 build/libmaple/flash.o
   272      40       0     312     138 build/libmaple/gpio.o
   407       0       0     407     197 build/libmaple/rcc.o
   100       0       0     100      64 build/libmaple/nvic.o
    76       0       4      80      50 build/libmaple/systick.o
     0       0       0       0       0 build/libmaple/fsmc.o
   429       0       0     429     1ad build/libmaple/util.o
  1211      56       0    1267     4f3 build/libmaple/i2c.o
   957     164       0    1121     461 build/libmaple/timer.o
                                       ・・・
   254       4    8212    8470    2116 build/libraries/FreeRTOS/utility/heap_2.
 36054    1720    8928   46702    b66e (TOTALS)

Final Size:
  text    data     bss     dec     hex filename
 27800    1648     664   30112    75a0 build/CQSTARM.elf
  • けれどDOS(Windows)では、Final Sizeしか出ない。
  • 理由は不明。
  • build-target.mkの、 
    $(BUILD_PATH)/$(BOARD).elf: $(BUILDDIRS) $(TGT_BIN) $(BUILD_PATH)/main.o
	$(SILENT_LD) $(CXX) $(LDFLAGS) -o $@ $(TGT_BIN) $(BUILD_PATH)/main.o -Wl,-Map,$(BUILD_PATH)/$(BOARD).map

$(BUILD_PATH)/$(BOARD).bin: $(BUILD_PATH)/$(BOARD).elf
	$(SILENT_OBJCOPY) $(OBJCOPY) -v -Obinary $(BUILD_PATH)/$(BOARD).elf $@ 1>/dev/null
	$(SILENT_OBJCOPY) $(OBJCOPY) -v -Oihex   $(BUILD_PATH)/$(BOARD).elf $(BUILD_PATH)/$(BOARD).hex 1>/dev/null
	$(SILENT_DISAS) $(DISAS) -d $(BUILD_PATH)/$(BOARD).elf > $(BUILD_PATH)/$(BOARD).disas
	@echo " "
	@echo "Object file sizes:"
★	@find $(BUILD_PATH) -iname *.o | xargs $(SIZE) -t > $(BUILD_PATH)/$(BOARD).sizes
★	@cat $(BUILD_PATH)/$(BOARD).sizes
	@echo " "
	@echo "Final Size:"
	@$(SIZE) $<
	@echo $(MEMORY_TARGET) > $(BUILD_PATH)/build-type
  • ★をつけた行を以下のように書き換える。 
            obj1.bat
  • そして、バッチファイルを用意して

obj1.bat:

find build -iname *.o | xargs arm-none-eabi-size.exe -t

としておくと、DOS(Windows)でもちゃんとサイズが出てくる。

何故かは不明。

  • findやxargsはC:\WinAVR\utils\bin などにあるものを使用。
  • なんとなく、Makefileから呼び出されたxargsが動いていないような気がする。
  • バッチやコマンドライン直叩きだとＯＫ。
  • cygwinな環境では一応ＯＫだけれど、WinAVR/utils/bin環境と比較すると１０倍くらいもっさりしている。


  • しかし、これにはさらにオチがついていて、
    • *.oのセクションサイズを arm-none-eabi-size.exeでレポートさせても、リンク後の実情と異なる値になっている場合がある。
    • gc-sectionがリンカオプションに指定されているため、使用されていない関数やデータセグメントはリンク時に削除されることがあるからだ。
  • だったら、最初からいらないような気もする。




↑

比較的最新のCodeSourcery-G++ Liteにて、libmapleの動作が怪しい件†

gcc version 4.5.1 (Sourcery G++ Lite 2010.09-51)  Windows/Linux
gcc version 4.5.2 (Sourcery G++ Lite 2011.03-42)  Windows/Linux
  • にて、libmapleのusbサンプルをビルドしてもちっとも動かない。
gcc version 4.4.1 (Sourcery G++ Lite 2010q1-188)  Windows/Linux
  • だとＯＫ。

つまり、maple-IDEに付属のCodeSourcery(gcc-4.4ベースのもの)ならＯＫだが、CodeSourceryが配布しているgcc-4.5ベースのものは全滅だ。


最初は、Windows上でビルドしたものは動いて、Linuxでビルドしたものが動かない ことに気づいた。

  • WindowsのCodeSourceryは比較的古くから使っていたので、gcc-4.4ベースだったし、 こないだはmaple-IDEのものをそのまま使ったので、Windows上では常にＯＫだった。
  • Linux用はCodeSourceryから落としてきたものを入れたので偶然gcc-4.5ベースの ものに差し替わってしまった。

もうすこし詳しく調べたところ、

  • 動かないほうはコードサイズが微妙に小さくなっている（gcc-4.4と比較して）
  • gc-sectionsをはずしても、動かないものは動かない。
  • Lチカ(main.cpp.example)なら動く。もちろんＬチカでもUSB-CDCデバイスは生きている。（PCから認識できる）


  • 同じＬチカをgc-sectionsをはずしてビルドすると、急に動かなくなる。（逆だろ？と突っ込みたくなるが・・・）
  • コードサイズに絡むバグなのか？


さらに調べるには、出来たコードのバイナリーを吟味していくほかはない。

  • gcc-4.4と4.5で何かスタートアップコードやライブラリの仕様が変化したのかな？


↑

結論: gcc-4.5.xのバグ†

  • gcc version 4.5.2 (Sourcery G++ Lite 2011.03-42) Windows にて試行してみた。
  • 試行プログラムはlibmaple.zipのmain.cpp
ビルドオプションＬチカ動作仮想COMデバイス認識
-OsＬＥＤ点滅しない仮想COMデバイス認識しない
-O1ＬＥＤ点滅ＯＫ仮想COMデバイス認識ＯＫ
-O2ＬＥＤ点滅ＯＫ仮想COMデバイス認識ＯＫ
-O3ＬＥＤ点滅ＯＫ仮想COMデバイス認識ＯＫ

というわけで、あるコード量（たぶん３２ｋ程度）を超えるあたりから、最適化オプション-Osだけ動作がおかしくなっている。(gcc-4.4は問題ない。gcc-4.5 ARMのみの問題）

  • main.cpp.example (Ｌチカ)だと-Osでも正常動作する。
  • ただし、gc-sectionを外してリンクさせ、32k越えのHEXを焼くと×になる。（同一*.cソース、同一*.oなのに!!!）
  • 元々gcc-armのコードジェネレータはおかしかったけどね。arm7のころも変なコード吐いてたから、あんまり信用してないというのが本音

今のところの回避策は、maple-IDEを落としてきてインストールしたCodeSourceryのbinにパスを通してlibmapleをコンパイルすること。これが確実。


続き:libmapleで仮想COM








↑

原子力終了のお知らせ†

  • http://www.asahi.com/international/update/0803/TKY201108030689.html
  • セラフィールドが閉鎖されるらしい。
  • まさか、あの一発の地震（と１Ｆ事故）のせいで・・・。
  • この流れは、（全生物にとって）正しい選択の方向。
  • 思えば、子供の頃の科学雑誌などで、夢の高速増殖炉「もんじゅ」とか、鉄腕アトム（すこし違う）とか原子力の薔薇色の未来（大嘘）を刷り込まれた気がするな。
    • 高速増殖炉は高速に天然ウランをＰｕ化してくれるわけではない*2し、ウランの採掘可能量（期間）をすこしだけ先延ばしする程度にしか増殖してくれないばかりか、再処理コストやリスクを考えると全く利得のない炉だった。
    • そういうわけで、Ｐｕ利用の道は絶たれ、再処理は閉鎖され、核廃棄物の行き場はもうどこにもない。（だから、原子炉建屋内に大量に存在して運び先が無い）
    • 残る手段では、さらに夢の核融合炉が完成する５０年くらい先までは風力とか水力とか石油を燃やしながら食いつなぐというシナリオしか残っていない。
    • ほかにエネルギーを得る方法って、何かあるかな？太陽炉でマグネシウム還元とか、海草から石油とかそんな儲け話？


  • 地球（プレート）は、身を呈してプルトニウム（放射性物質拡散）の恐ろしさをわれわれに教えたなり。（多くの犠牲とともに）




↑

aitendo:ドシメーター†

  • http://www.aitendo.co.jp/product/3162
  • ああ、線量計はついにテスターと一緒に並んでホームセンターで売られる時代になるのだなぁ・・・
  • まさかテスターよりポピュラーな測定器になるなんて、今年の3月10までは全く想像だにしなかった。




次の月へ

*1 大名プログラミングとも言う
*2 高速（に移動する）中性子を利用するの意味であって、高速に利殖を増やしてくれる夢の投資話のようなものとは全くベクトルが異なる。s/夢の/悪夢の/としてほしいくらいだ