2011-08
libmapleを使いこなせ!!
- mapleで使われているSTM32用のArduinoチックなライブラリ。
- これが使いこなせるとかなり便利。
対応させる基板:
- なんといってもPCに接続する仮想COMポートをデバイス側から普通のシリアルポートのように扱える。(あまりUSBを意識しなくてgetc(),putc()出来るという感じ)
- なので、これをCQ-STARMとSTM8S-Discovery用に改造中。 ---> 済み
- STBee , STBeeMini , STM32VL-Discovery対応はxshigeさんの成果を利用させていただいております。感謝!!
- 結局自分は(STM32用の)Arduinoが使いたいわけではなく、仮想COMを使ったアプリを書きたいだけだった。
- STM32のサンプルアプリケーションの仮想COMは、とてもやる気ない実装なのと、デバイスから自由にgetc(),putc()出来るように改造するのが面倒なのでそのまま放置している。
- JavaのGUIだとmakeが使えないし好みのテキストエディタが使えないしライブラリソースの改造作業(各種基板への対応)は、ちょとやり辛い。
謝辞
- STBee , STBeeMini , STM32VLD への対応にあたり、xshigeさんのMaple_0011_Adaptation_20110611.zip の成果を思いっきり使わせていただきましたので、ここに謝辞を申し上げます。
DOWNLOAD
CQ-STARM , STM8S-Discovery , STBee , STBeeMini の4基板を追加したバージョンを公開します。
- こちらからダウンロードしてください。
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 を実行してください。
仕様
(1)libmaple/Makefile に基板選択の定義があります。
# Valid BOARDs: maple, maple_native, ... #BOARD ?= maple #BOARD ?= STBee #BOARD ?= STBeeMini #BOARD ?= STM32VLD BOARD ?= CQSTARM #BOARD ?= DISCOVERY
- どれか1つを有効にしてください。
(2)CQSTARM , DISCOVERYは 0x0800_0300 から起動するelf/hexを生成します。
- 開始番地を変更したい場合はlibmaple/support/ld/基板名/flash.ld と、libmaple/libmaple/libmaple.h 内の番地定義の両方を書き換える必要があります。
(3)HEXファイルはelfと同時に生成されます。
- libmaple/*.bat というバッチファイルにて、armboot経由でhexを書き込んで即実行します。
(4)ビルド環境(CodeSourceryG++ Lite)はCodeSourceryのサイトから入手しても良いですし、
- maple-0.0.11 入手してそれを展開して得たコンパイラのbinディレクトリに そのまま実行パスを通してもOKです。
(5)CQSTARMとDISCOVERY(STM8SのSTLINK)のポート名称はSTBeeやMiniの定義順に準じています。
- というよりはSTBee.cppをそのまま流用させていただいております。
ビンテージパソコンにLinuxを突っ込む
レガシーPCのスペック
- SONY VAIO F? (Pentium III 900MHz) i815 15inch LCD WindowsXPモデル
- メモリーは256MB
試行結果
ディストリビューション(Version) | インストールの可否 | 運用実用性の可否 |
ubuntu 10.04 | 1時間程度掛かるけれど可能 | 遅いけれど可能 |
ubuntu 10.10 | 1時間程度掛けても全然進まない | 不可 |
ecoLinux(ubuntu 10.10ベース) | 1時間程度掛けても全然進まない | 不可 |
ubuntu 11.04 | 1時間程度掛けても全然進まない | 不可 |
ubuntu 11.04 Server i386 | CUIインストーラーなので可能 | (CUI)動いているように見えるがVGAモードがグラフィックなのにテキスト文字がドットで描かれて読めない。ブラインドタッチで全て操作できるなら可能かも |
到達した結論
/ | 選択項目 | 寸評 |
○ | ubuntu 10.04を採用 | 1年前のディストリビューションだが、各種パッケージは古くさくはない。むしろ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 OK。
- Xの解像度や設定周りは今ではxrandr とか cvt というツールを使うようになっている。
- そうこうしているうちに、ノートPCのキーがいくつか(dとかw)効かなくなった。
- 強く押し込んだら、入力できる場合がある。
- Windowsで試しても同じ。
やっぱりビンテージPCは諦めたほうが良いのか・・・
- でも最近のノートPCは縦のDot数がたりないし、液晶はツルテカで顔が映るし、WindowsXPがなくて7のstarterとかになるし。
- Atomは嫌だな。遅いから。
- Llanoなノートが出始めているらしい。
- Atomは1コア当たりの性能がCore2の半分もない程度だけれど、Llanoは昔のCore2相当(?)らしい。
- しかしSandyBridgeだとCore2の1.3〜1.5倍(これはサバ読みすぎだ。AVX使うときだけの話だと思う)だからAMDも苦しいと思う。
その後のGNUK
gnuk USB Token を STM8S Discovery Kit で友達の分も作ろう
極力安上がりに作られてます。
こっちも・・・
USB接続(簡易)JTAG Debugger を作る
- http://www.gniibe.org/memo/development/gnuk/hardware/diy-jtag-debugger-ftdi2232
- 秋月FT2232Dと100オーム4本だけで・・
- 以前作ったやつは、手持ち部品から74HC245と、一部ゲートが無かったのでtiny2313をプログラミングして低速CMOSゲートを用意して、あと電圧変換用に抵抗を多数使ったような気がする。
- それから、壊れたNICからEEPROMを外してFT2232Dに半田付けした。
全部省略できたのか・・・
続:libmapleを使いこなせ!!
その1
- libmapleのビルドツリーから、不要なものを除去していってusb_serialだけにしたものを作ってみた。
- で、ファーム内エコーバックでPCにエコーバックを返すようなものを作ってみた。
- サイズは8kB程度。
- 速度は、まだ納得がいかない。
原因は調査中。
その2
- libmapleと同様に、maple-bootloaderもgitから落としてきてビルド。
- ファームサイズが妙にでかい。(20k程度)
- しかし、これはデバッグビルド( -O0指定 )になっているからなので、 -Osに変更してビルドすると6kB程度のファームになるようだ。
相変わらずDFUに興味ない。
- libmapleは比較的改造しやすいし、コードサイズ縮めようとすれば、maple-bootloaderのソースを参考に(C++を切捨てしながら)好きなだけ縮めることも可能。(ただしwiringの部分は無くなるので、普通に自前でポート叩くか、うそっぽいdigitalWrite() 関数をCで起こすとかする)
- Arduino(ATmega328の16MHz)に比べると遥かに性能良いし、リソース(特にSRAM容量)も多い。
- Flashを512KとかSRAMを64Kにしたければ3千円程度で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が動いていないような気がする。
- バッチやコマンドライン直叩きだとOK。
- cygwinな環境では一応OKだけれど、WinAVR/utils/bin環境と比較すると10倍くらいもっさりしている。
- しかし、これにはさらにオチがついていて、
- *.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
- だとOK。
つまり、maple-IDEに付属のCodeSourcery(gcc-4.4ベースのもの)ならOKだが、CodeSourceryが配布しているgcc-4.5ベースのものは全滅だ。
最初は、Windows上でビルドしたものは動いて、Linuxでビルドしたものが動かない ことに気づいた。
- WindowsのCodeSourceryは比較的古くから使っていたので、gcc-4.4ベースだったし、 こないだはmaple-IDEのものをそのまま使ったので、Windows上では常にOKだった。
- Linux用はCodeSourceryから落としてきたものを入れたので偶然gcc-4.5ベースの ものに差し替わってしまった。
もうすこし詳しく調べたところ、
- 動かないほうはコードサイズが微妙に小さくなっている(gcc-4.4と比較して)
- gc-sectionsをはずしても、動かないものは動かない。
- Lチカ(main.cpp.example)なら動く。もちろんLチカでもUSB-CDCデバイスは生きている。(PCから認識できる)
- 同じLチカを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
ビルドオプション | Lチカ動作 | 仮想COMデバイス認識 |
-Os | LED点滅しない | 仮想COMデバイス認識しない |
-O1 | LED点滅OK | 仮想COMデバイス認識OK |
-O2 | LED点滅OK | 仮想COMデバイス認識OK |
-O3 | LED点滅OK | 仮想COMデバイス認識OK |
というわけで、あるコード量(たぶん32k程度)を超えるあたりから、最適化オプション-Osだけ動作がおかしくなっている。(gcc-4.4は問題ない。gcc-4.5 ARMのみの問題)
- main.cpp.example (Lチカ)だと-Osでも正常動作する。
- ただし、gc-sectionを外してリンクさせ、32k越えのHEXを焼くと×になる。(同一*.cソース、同一*.oなのに!!!)
- 元々gcc-armのコードジェネレータはおかしかったけどね。arm7のころも変なコード吐いてたから、あんまり信用してないというのが本音
今のところの回避策は、maple-IDEを落としてきてインストールしたCodeSourceryのbinにパスを通してlibmapleをコンパイルすること。これが確実。
原子力終了のお知らせ
- http://www.asahi.com/international/update/0803/TKY201108030689.html
- セラフィールドが閉鎖されるらしい。
- まさか、あの一発の地震(と1F事故)のせいで・・・。
- この流れは、(全生物にとって)正しい選択の方向。
- 思えば、子供の頃の科学雑誌などで、夢の高速増殖炉「もんじゅ」とか、鉄腕アトム(すこし違う)とか原子力の薔薇色の未来(大嘘)を刷り込まれた気がするな。
- 高速増殖炉は高速に天然ウランをPu化してくれるわけではない*2し、ウランの採掘可能量(期間)をすこしだけ先延ばしする程度にしか増殖してくれないばかりか、再処理コストやリスクを考えると全く利得のない炉だった。
- そういうわけで、Pu利用の道は絶たれ、再処理は閉鎖され、核廃棄物の行き場はもうどこにもない。(だから、原子炉建屋内に大量に存在して運び先が無い)
- 残る手段では、さらに夢の核融合炉が完成する50年くらい先までは風力とか水力とか石油を燃やしながら食いつなぐというシナリオしか残っていない。
- ほかにエネルギーを得る方法って、何かあるかな?太陽炉でマグネシウム還元とか、海草から石油とかそんな儲け話?
- 地球(プレート)は、身を呈してプルトニウム(放射性物質拡散)の恐ろしさをわれわれに教えたなり。(多くの犠牲とともに)
aitendo:ドシメーター
- http://www.aitendo.co.jp/product/3162
- ああ、線量計はついにテスターと一緒に並んでホームセンターで売られる時代になるのだなぁ・・・
- まさかテスターよりポピュラーな測定器になるなんて、今年の3月10までは全く想像だにしなかった。
*1 大名プログラミングとも言う
*2 高速(に移動する)中性子を利用するの意味であって、高速に利殖を増やしてくれる夢の投資話のようなものとは全くベクトルが異なる。s/夢の/悪夢の/としてほしいくらいだ