2010-08

    linux   /boot/vmlinuz-2.6.32-24-generic root=UUID=5b1400da-b09d-423b-a305-ae8f15e7417b ro   quiet splash rootflags=data=writeback
   initrd  /boot/initrd.img-2.6.32-24-generic

つまり、splash のあとに、rootflags=data=writeback　を追加する。

/etc/fstabを編集。

/dev/sda3  /   ext4    errors=remount-ro,noatime,data=writeback  0       1
                                        ~~~~~~~~~~~~~~~~~~~~~~~

errors=remount-ro　のあとにそのまま続けて、「,noatime,data=writeback」を追加する。

rootパーティション以外にパーティションを切っている場合も、それらに「,noatime,data=writeback」オプションを追加しておく。

再起動すると、起動がかなり速くなっている。

ちなみにnoatime はディレクトリやファイルの最終アクセス時刻を打刻しない、というオプション。
data=writebackは、Ext3やExt4のジャーナルの書き込みモードをwritebackキャッシュありにするというオプション。

もちろん、Linuxマシンが頻繁にクラッシュするような使い方（カーネルいじってるとか）をする人はwritebackはおすすめしない（けれど、そういうひとはここの説明を読むまでもないので・・・）

↑

アマゾン新 Kindle 発表、WiFi版 139ドル・3G版189ドル

engadget日本版

http://japanese.engadget.com/2010/07/28/kindle-wifi-139-3g-189/
139ドルって、円に換算したら１万円ちょっと。
Linuxが走るなら（Linux端末として使えるなら）、ちょっと欲しい。
- テキストエディタjedの端末として。

もうここまで来たんだから、次はカラーの電子ペーパーになって、紙の教科書は消滅する？

未来はすぐそこだ。

↑

STM32:GPIOポートの続き。

RCCの関数を呼んで、GPIOにクロックを供給するようにしたら、ポートの読み書きが出来るようになった。
SWIMのRESET#端子をBOOTMODE JUMPERに流用して、JUMPER OPENだったらユーザー側のファーム(0x0800_2000)に飛ぶようにしてみた。
USBが「不明なデバイス」になった。

試しに焼いているユーザー側ファームはHID BOOTLOADERのアドレスを変えただけの同一コード。

JUMPER CLOSEの場合はHID BOOTLOADERは正しく初期化され、BOOTLOADERのコマンドを受け付けたり、ポートアクセスなどが可能になった。

なぜ「不明なデバイス」になるのか分からない。

とりあえずＬチカでもやるか・・・。

↑

で、良く見たら、JUMPER OPEN時に0x0800_2000番地のファームに飛ぶ処理が入ったままだった。

つまり、0x0800_0000番地で最初に起動するHID BOOTLOADERはJUMPERを見てユーザーファームに飛んでも良いが、
0x0800_2000番地で起動する（アプリケーションとしての）HID BOOTLOADERに同じ処理が残っていたので、
無限に0x0800_2000番地側の起動が行われていただけだった。

３秒で修正完了！

↑

0x0800_2000番地のファームを起動する処理は少しだけ気持ちが悪い。

RCCの初期化やPLLの初期化を行ったあとで jmp [0x0800_2004] に飛んでいること。
Reset vector [0x0800_2004]の内容は奇数であること。（Thumbモードなので、プログラムカウンタのLSBが立つていた）

↑

とりあえず、HIDブートローダーが出来た。

HIDブートローダーを使って別の番地のHIDブートローダーを書き換えることも（たぶん）可能。
なので、もうJTAGライターは（マスターのブートローダーをバグらせた時以外は）不要になった。

Orange Computer(SC/MP-II)

Googleで検索してみたけれど画像はないなぁ・・・。
Apple ][ 似だったと思う。
創刊されたばっかりの雑誌I/Oの広告ページに写真を見たような気がする。
Orange Basicという（ファームウェアROM?）があったらしい。
しかし、SC/MP-IIは4MHzで駆動したとしても、8080Aと比べて1/18くらいの処理速度。（内部がマイクロコードでまどろっこしい）
ついでにメモリー空間は64Kあるけれど、プログラムカウンタは4kBでクルクル回る（mod 4096って奴）
CALL / RET がないのでBasicインタープリターを書くのも大変だったんじゃないかな。
（当時のミニコンのように、リターンアドレスをサブルーチンの手前のStaticなワークエリアに（PC相対STORE命令で）保存するしかない。リエントランシがない。ROM上で動かせない・・・）

そもそもどうやってCALLするかって？

LDI #SUBR_ADDRESS_L
XPAL P1   ;; AccとPointer#1Lowの交換.
LDI #SUBR_ADDRESS_H
XPAH P1   ;; AccとPointer#1Highの交換.
XPPC P1   ;; PCとPointer#1の交換.

CALLするのに（7byte）必要だな。

RETURNは、１レベル関数（中で別の関数を呼ばない）ならば、
```
XPPC P1   ;; PCとPointer#1の交換.
```
だけでＯＫだ。
もういちど呼び主がXPPC P1を実行すると、さっき呼んだ関数の戻り場所の次から実行してくれる。（コルーチン？）
１レベル関数でない場合は関数のプロローグでP1を保存(PC相対でRAMに保管)して、エピローグでP1を復帰する必要がある。

これでポインタが１つ潰れるから、残り２本しかない。
16bitポインタは３本ある。４本目がPCだ。
しかし、全てのメモリーアクセスはその４本のポインタ相対(±128byte offset)でしかアクセス出来ない。
6800のゼロページのようなワークが欲しければ、そこを指すポインタが１つ必要。

なので、

サブルーチンを呼ぶためのテンポラリポインタ
ゼロページを参照するためのベースポインタ
スタックポインタ（必要に応じて）の３つで終了だ。

ちなみに、３本のポインタは演算には使えない。

表引きとか、どうすんだろうね。

ある意味、PIC16Fより悲惨。

当時の16bitタイプのミニコンのALUとかレジスタが仮に8bitだったらこうなる、という地獄のアーキテクチャーだ。

このころからNSのあだ名はナショナル・セミデストラクター（半ぶち壊し屋）だったのだ。

↑

トランジスタ技術 2010年9月号増刊

USBに挿すだけ！OPアンプ/センサ/カレンダIC搭載！
ARMマイコンパーフェクト学習基板

http://shop.cqpub.co.jp/hanbai/books/MTR/MTRZ201009.html

CD-ROM&基板付き定価3,780円(税込)

2010年8月16日発売予定！

こいつはやっぱり温度計なんだろうか。

なぜにMicroBasic? LuaとかSquirrelとか組み込みC#とかいろいろあるだろーに。

LPCXpresso持ってるからとりあえずパスかなー。なんかNXPの石は（JTAG書き込みがないので）興味湧かないなぁ。

SWDでの書き込み方法をマスターすれば、また違うんだろうけれど。

↑

筍Pad

Android 2.1搭載のタブレット端末が来週発売、予価2.5万円

全部中国製。パチモン、というか粗悪品？安いけど。（実はiPadだって中国製だし）

液晶やデザイン、ソフトのクォリティなど、総合的に見てAppleのほうがはるかに上を行っているのは確かなので、他の品物がパチモンだと見られるのはあるていどしかたないことかも。

なんか、昔のApple製品(Apple ][とか68000 Macintosh)がとても高価だったころを思い出す。（まるで高級車、対普及車みたいな）、てゆーかApple ][とか車１台買える値段だったし。

つまり、将来的には中国製iPadもどきが席巻する時代になるのか。

だけど、ARMでuni*x系なOSを積んだMID(モバイル端末)って、一般人にそもそも需要はないと思ってたんだけど・・・あったんだね。

↑

STM32:やっとＬチカができるようになった。

例のHIDなARM_Bootloader_兼モニターのこと

同一ソースから、ブートローダー(0x800_0000)とアプリ(0x800_2000)の両方をビルドするようにした。

こうしておくと、お互いに、相手をアップデート出来る。
アプリのほうは、サイズ制限が緩い（56KB)ので、いくらでも機能追加できる。

もう、JTAGライターは使わなくなった。

アプリ側を少し拡張して、Ｌチカしながら、HIDmonが動作するようになった。

printを実装しようとしたけれど、なぜか_sbrkがない、と言われる。
Linuxのarm-eabi-gccを使ったときは大丈夫だったんだけど、WinARMだと駄目っぽい。

WinARMに決めうちするなら、適当な_sbrkとか_lseekとかをソースに埋めておけば動くけれど、
こんどはLinuxでビルドするときに変なことが起きるのだろう。

やっぱりWinARMとかnewlibを自分でビルドしないと駄目だな。

↑

stm32 ToDo List

□　ブート完了後、'-r'オプションにより、USB disconnectが出来るようにする.(今はdisconnectしないで実行されるようだ)
□　バスエラーへの対処
□　Flash read処理の最適化
□　armon.exeからのbootコマンド
□　printfの実装
□　逆アセンブラをPIC用から差し替える

↑

STBeeが来た。

stm32 続き

Linuxでビルドしたarm-eabi-gccを使うと、printfのコードはちゃんとビルドしてくれる。
しかし、SVC_Handlerを書いていないので、当然ながらハングする。

正確には、SVC_Handlerは何もせずreturnするだけなので、printしないだけでハングしないのが正しいと思う。

それよりも、fputsを入れただけでバイナリーサイズが32kBに膨れ上がるのはどうにかならないのか。
stdioの実装が大げさなのはわかるが、それにしても追っかけるの大変だな。

PIC18Fのstdio周りなんて、すごくシンプルなんだけど。

K&R本の実装みたいなシンプルなので十分なんだけどな。

選択肢としては、

（１）このままnewlibの実装を受け入れて、なんとか動かしてみる。
（２）μCLibcのようなもっと別の実装を探す。
（３）独自の（newlibに頼らない）もっと小さなstdioを書く。

（３）だとたいていサブセットになっちゃって書式指定とか簡略化されるのがオチだけど。

昔WindowsCE用の簡易コンソールにX68000のLibcを借りてきたけど、あれくらいが丁度良い。

あれ？そもそもprintを動かす目的って、何だっけ？

float演算がちゃんとできるかどうか確認したかった？

だんだん、面倒くさくなってきたので、既製のコンパイラでお茶を濁そうかな。

http://www.lineo.co.jp/modules/codesourcery/editions.html
ところで、こいつだと、SVC_Handlerとか書かなくてもprintf出来るのかな？

↑

即実行

ありゃ？WinARMと挙動は同じだなぁ・・・

Linking: main-2000.elf
arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -mthumb -I. -gdwarf-2 -DROM_RUN -DUSE_
STDPERIPH_DRIVER -DSTM32F10X_MD  -D__WinARM__ -D__WINARMSUBMDL_STM32F103__ -D_RO
MADRS=0x2000 -I../HW/Libraries/STM32F10x_StdPeriph_Driver/inc/ -I../HW/Libraries
/CMSIS/Core/CM3/ -I../HW/Libraries/STM32_USB-FS-Device_Driver/inc/ -I../inc/ -I.
./HW/STM32_EVAL/ -I../HW/STM32_EVAL/STM3210B_EVAL  -Os -Wall -Wcast-align -Wimpl
icit  -Wpointer-arith -Wswitch -ffunction-sections -fdata-sections -Wredundant-d
ecls -Wreturn-type -Wshadow -Wunused -Wa,-adhlns=../HW/Libraries/CMSIS/Core/CM3/
startup/gcc/startup_stm32f10x_md.lst  -ICommon/inc -MD -MP -MF .dep/main-2000.el
f.d ../HW/Libraries/CMSIS/Core/CM3/startup/gcc/startup_stm32f10x_md.o    main.o
monit.o usercmd.o print.o stm32f10x_it.o usb_desc.o usb_endp.o usb_istr.o usb_pr
op.o usb_pwr.o hw_config.o ../HW/Libraries/STM32F10x_StdPeriph_Driver/src/stm32f
10x_exti.o ../HW/Libraries/STM32F10x_StdPeriph_Driver/src/stm32f10x_flash.o ../H
W/Libraries/STM32F10x_StdPeriph_Driver/src/stm32f10x_adc.o ../HW/Libraries/STM32
F10x_StdPeriph_Driver/src/stm32f10x_rcc.o ../HW/Libraries/STM32F10x_StdPeriph_Dr
iver/src/stm32f10x_dma.o ../HW/Libraries/STM32F10x_StdPeriph_Driver/src/stm32f10
x_usart.o ../HW/Libraries/STM32F10x_StdPeriph_Driver/src/stm32f10x_gpio.o ../HW/
Libraries/STM32F10x_StdPeriph_Driver/src/misc.o ../HW/Libraries/STM32_USB-FS-Dev
ice_Driver/src/usb_int.o ../HW/Libraries/STM32_USB-FS-Device_Driver/src/usb_core
.o ../HW/Libraries/STM32_USB-FS-Device_Driver/src/usb_sil.o ../HW/Libraries/STM3
2_USB-FS-Device_Driver/src/usb_mem.o ../HW/Libraries/STM32_USB-FS-Device_Driver/
src/usb_regs.o ../HW/Libraries/STM32_USB-FS-Device_Driver/src/usb_init.o ../HW/L
ibraries/STM32_USB-FS-Device_Driver/src/otgd_fs_int.o ../HW/Libraries/STM32_USB-
FS-Device_Driver/src/otgd_fs_dev.o ../HW/Libraries/STM32_USB-FS-Device_Driver/sr
c/otgd_fs_cal.o ../HW/Libraries/STM32_USB-FS-Device_Driver/src/otgd_fs_pcd.o ../
HW/Libraries/CMSIS/Core/CM3/core_cm3.o ../HW/Libraries/CMSIS/Core/CM3/system_stm
32f10x.o      --output main-2000.elf -nostartfiles -Wl,-Map=main-2000.map,--cref
,--gc-sections -lc  -lm -lc -lgcc     -T./STM32F103-ROM2000.ld

d:/browser/codesourcery/sourcerylite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../..
/../arm-none-eabi/lib/thumb2\libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x12): undefined reference to `_sbrk'
d:/browser/codesourcery/sourcerylite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../..
/../arm-none-eabi/lib/thumb2\libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text+0x16): undefined reference to `_write'
d:/browser/codesourcery/sourcerylite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../..
/../arm-none-eabi/lib/thumb2\libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text+0x12): undefined reference to `_close'
d:/browser/codesourcery/sourcerylite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../..
/../arm-none-eabi/lib/thumb2\libc.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text+0x14): undefined reference to `_fstat'
d:/browser/codesourcery/sourcerylite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../..
/../arm-none-eabi/lib/thumb2\libc.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text+0x12): undefined reference to `_isatty'
d:/browser/codesourcery/sourcerylite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../..
/../arm-none-eabi/lib/thumb2\libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text+0x16): undefined reference to `_lseek'
d:/browser/codesourcery/sourcerylite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../..
/../arm-none-eabi/lib/thumb2\libc.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text+0x16): undefined reference to `_read'
collect2: ld returned 1 exit status
make: *** [main-2000.elf] Error 1

stdio周りの関数がリンクエラーになる。
組み込み向けによくやる、 --nostartfilesが悪い？
いや、--nostartfilesを外してもだめなようだ。stdioはlibc (-lc)じゃない？

あ、そうか。

libc.a はちゃんと _sbrk_r を持っている。
_sbrk_r が一番下位のシステムコール _sbrk とか _lseek とか _read を要求している。
一番下位のシステムコール _sbrkは libc.a から呼び出されるべきものであり、中身はたいていの場合、int xxとか svc xxになっている。
そのシステムコールの実装がないだけのようだ・・・。どこから持ってくるのかな？

Linuxでnewlibをビルドしたディレクトリを見たら、

newlib/libc/sys/arm/syscalls.c:31:caddr_t _sbrk     _PARAMS ((int));

みたいなところにあった。

caddr_t
_sbrk (int incr)
{
 extern char   end asm ("end");    /* Defined by the linker.  */
 static char * heap_end;
 char *        prev_heap_end;
 if (heap_end == NULL)
     heap_end = & end;
 prev_heap_end = heap_end;
 if (heap_end + incr > stack_ptr)
   {
     /* Some of the libstdc++-v3 tests rely upon detecting
    out of memory errors, so do not abort here.  */
     errno = ENOMEM;
     return (caddr_t) -1;
   }
 heap_end += incr;
 return (caddr_t) prev_heap_end;
}

そもそもこいつらは libc.a には含まれないのか？

CodeSourceryやWinARMのlibc.aには含まれないようだ。

しかし、Linuxでビルドしたnewlibには含まれている謎

$ arm-eabi-nm /usr/local/arm/arm-eabi/lib/libc.a

lib_a-syscalls.o:
         U __errno
         U __sinit
000005dc T _close
00000110 T _exit
00000930 T _fstat
00000130 T _getpid
00000144 T _gettimeofday
         U _impure_ptr
00000534 T _isatty
000000bc T _kill
00000138 T _link
000007d8 T _lseek
00000434 T _open
00000140 T _raise
00000830 T _read
00000218 T _rename
00000454 T _sbrk
000008d8 T _stat
00000570 T _swiclose
000006e0 T _swilseek
00000350 T _swiopen
000007f0 T _swiread
000005f4 T _swiwrite
00000274 T _system
0000018c T _times
00000308 T _unlink
00000634 T _write

なんかもう、この辺になると、ＬチカだけしかやらないようなLiteなArduino野郎 には手におえない領域になってくる。
ARM/Thumbへのsyscallのポーティング屋とか、newlibのメンテナになることを要求してくるわけだから。

この辺がお手軽に出来ないとAVR->ARMへの移行は難しいな。

実はWinARMで再度試したところ、リンクエラーになるのは _sbrkのほうではなくて _sbrk_r のほうだった。
たぶん _r 付きはリエントラントなやつなので、ここのレベルで欠落しているとなると話はやっかいだ。
足を踏み入れないほうがよかったかな。
WinARMのnewlibを入れ替えるかLinux版のnewlibをコピーしてきたほうが少し楽だろう。

しかしあれだな。

WinAVRで同様にprintfを呼び出してみると、全然リンクエラーもしないし、FILE構造体もシンプルでわかりやすいに、
WinARMのstdioのほうは、やたらと複雑で無駄にコードサイズも大きくなっているようだ。

↑

STM32:コンパイラをCodeSourcery にしたら、かなり縮んだ。

CodeSourcery G++ Lite

http://www.lineo.co.jp/modules/codesourcery/editions.html

バイナリーサイズが、WinARMだと0x1f80 くらいあったのに、同一ソースが0x1d64にまで縮んだ。

Makefileの変更箇所はただの１箇所

#TCHAIN = arm-eabi     ・・・WinARM:gcc version 4.3.0 (WinARM March 2008)
TCHAIN = arm-none-eabi　・・・CodeSourcery:gcc version 4.4.1 (Sourcery G++ Lite 2010q1-188)

コンパイルオプション等は変更していないのに、こんなに縮むと嬉しいなぁ
半信半疑だったが、焼いたファームは正しく動いた。

ついでなので、_sbrkとか_writeとか_swiwriteとかのコードも追加しておいた。
- とはいえ、まだprintfが動くわけではない。

コード品質？？？

WinARM:gcc version 4.3.0 (WinARM March 2008)

と

CodeSourcery:gcc version 4.4.1 (Sourcery G++ Lite 2010q1-188)

を比較してみた。

コンパイルオプションは同一。(-Os)

本質的な違いはない。

ただ、コンパイラの癖として、

4.3.0のほうは、関数をインライン化したがる傾向にある。
条件分岐より、条件スキップを使いたがる傾向にある。
中身のない関数に対するコードが、WinARMでは" bx lr ; nop "なのに対し、CSでは "bx lr"だけで、4byteの関数アラインメントがない。
WinARMの関数エントリーは4byteアラインメントされていて、CSではされていないということか。

それから、WinARMの、アドレス定数をひねりだすコードは変だ。

void SetEPTxCount(uint8_t bEpNum, uint16_t wCount)
{
 _SetEPTxCount(bEpNum, wCount);
8001d44:	4b06      	ldr	r3, [pc, #24]	(8001d60 <SetEPTxCount+0x1c>)
8001d46:	681a      	ldr	r2, [r3, #0]
8001d48:	f103 4360 	add.w	r3, r3, #3758096384	; 0xe0000000
8001d4c:	b292      	uxth	r2, r2
8001d4e:	f5a3 5330 	sub.w	r3, r3, #11264	; 0x2c00
8001d52:	eb02 02c0 	add.w	r2, r2, r0, lsl #3
8001d56:	3b4e      	subs	r3, #78
8001d58:	4413      	add	r3, r2
8001d5a:	005b      	lsls	r3, r3, #1
8001d5c:	6019      	str	r1, [r3, #0]
}
8001d5e:	4770      	bx	lr
8001d60:	40005c50 	.word	0x40005c50

CSではこうなる。

void SetEPTxCount(uint8_t bEpNum, uint16_t wCount)
{
 _SetEPTxCount(bEpNum, wCount);
8001b3c:	4b04      	ldr	r3, [pc, #16]	; (8001b50 <SetEPTxCount+0x14>)
8001b3e:	4a05      	ldr	r2, [pc, #20]	; (8001b54 <SetEPTxCount+0x18>)
8001b40:	681b      	ldr	r3, [r3, #0]
8001b42:	b29b      	uxth	r3, r3
8001b44:	eb03 03c0 	add.w	r3, r3, r0, lsl #3
8001b48:	189a      	adds	r2, r3, r2
8001b4a:	0052      	lsls	r2, r2, #1
8001b4c:	6011      	str	r1, [r2, #0]
}
8001b4e:	4770      	bx	lr
8001b50:	40005c50 	.word	0x40005c50
8001b54:	20003002 	.word	0x20003002

CSのほうは0x20003002を32bit定数として置いているけれど、WinARMではまったく別のアドレス定数0x40005c50 から、むりやりひねり出そうとしている。そのコードが無駄に長くなる。

バグなんじゃないか？
もしかしたら変数の配置が違うのでアドレスがずれるせいかもしれないけれど・・・素直じゃないことだけは確かだ。

↑

なんかswi命令の先あたりでハングする。

OpenOCDで追っかければいいのだろうけれど・・・

swi命令を発行すると、SVC_Handler()に来るのだろうか？？？
- Cortex-M3に、SWI_Handlerがないんだけど・・・？？？？なんで？

SVC_Handler()は普通に bx lr; でリターンしてるけれどいいのかな？
- 普通、特権とかスーパバイザーとかあるはずなので、RTEのような命令で戻るべきなんだけど、
- ARM(Cortex-M3)では、どう書けばいいのか不明。

PICでは #pragma interrupt <FUNCNAME>か、#pragma interruptlow <FUNCNAME>だったし、
AVRはISR(Vector_Name) で関数を書けばいいはずだった。
ARMで
```
void SVC_Handler() __attribute__((interrupt("SWI")));
```
とか書いてみたけどよくわからない・・・・

解説書きぼんぬ。

http://www.kimura-lab.net/wiki/index.php/CMSIS:_Cortex_Microcontroller_Software_Interface_Standard

なんかCortex-M3の例外復帰は、普通じゃないな。

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337gj/DAFCDHGG.html

PC=0xfffffffX の Xの値でどうのこうのと・・・。
つまり、４ＧＢの最後の16byteはリザーブなのか。

割り込みが連続した場合のpopとpushをサボるようなinterrupt chainも持ってるし、ハード割り込み後に遅延ソフト割り込みの予約が出来たりと、いろいろ変なことができるらしいので、マニュアルをちゃんと読まないと駄目か。

ARMのサイトを見る限りだと、

http://www.jp.arm.com/document/whitepater/pdf/fin_IntroToCortex-M3%20reviewed.pdf

例外が発生すると、プログラム・カウンタ、プログラム・ステータス・レジスタ、
リンク・レジスタ、R0～R3、R12 の汎用レジスタがスタックにプッシュされます。
データ・バスがレジスタをスタックする一方、命令バスはベクタ・テーブルから
例外ベクタを特定し、例外コードの最初の命令をフェッチします。

スタッキングと命令フェッチが終了すると、割り込みサービス・ルーチンまたは
フォールト・ハンドラが実行され、割り込まれたプログラムが通常実行を再開できるよう、
レジスタが自動的に復元されます。

ハードウェアでスタック操作を処理することにより、Cortex-M3 プロセッサは、
従来のCベースの割り込みサービス・ルーチンにおけるスタック操作に必要な
アセンブラ・ラッパの記述を不要にし、アプリケーション開発を大幅に容易にします。

と、書いてあるので、68000のような RTS / RTE の使い分けすら不要な感じ。
つまりレジスタ退避とか特権チェンジとかさえ、意識しないで、単純にＣの関数がそのまま割り込みハンドラーに登録できるというのか？

半信半疑だな。

しかし、Cortex-M3のマニュアルを見ると、

https://www.jp.arm.com/document/manual/files/fin_1226_DDI0337.pdf

例外発生時には、【xPSR,PC,LR,R12,R3,R2,R1,R0】の８本のレジスタを積んだ後、
LRに 0xfffffffX (最後のXは例外からの退出方法が書かれている)を代入する、とある。

なので、普通に、割り込みハンドラーは、Ｃ言語の関数のままで良いのか。
関数リターンでPCに0xfffffffX という値が代入されたら、ハードウェアが自動的に例外退出シーケンスを実行するので、
上記８本のレジスタはきれいに元通りになるというわけだ。

↑

え？５兆桁って、日本人が達成したの？

円周率５兆けた、ＰＣで計算　長野の会社員、３カ月かけ

５兆＝ 5 x 10^12 ＝ 5 Tera

なので、到底オンメモリーに入りません。
HDDが２２ＴＢ要るんだ。

いまどき、1TB＝5千円とはいえ、１１万円掛かるんだよなーストレージだけでも。

google先生がその気になれば、クラウドパワーで簡単に記録を抜けるんだろうけれど・・・

超多桁のπの使い道がない・・・。

↑

y-cruncherというPiの計算ソフト（x86/x64バイナリー含む）は、以下のサイトからＤＬ出来る。

http://www.numberworld.org/y-cruncher/#Download
計算公式はChudnovsky Formula
手元のパソコンで試してみた。（誰でも試せる）

２５００万桁

Decimal Digits    :   25,000,000  
Hexadecimal Digits:   Disabled

Threads:    1
Mode   :    Ram Only

Start Time: Fri Aug 06 06:42:12 2010


Allocating and Reserving Memory...       167 MB
Constructing FFT lookup tables...


Begin Computation:

Summing Series:  1,762,845 terms
Time:    106.343 seconds  ( 0.030 hours )
InvSqrt...
Time:    5.250 seconds  ( 0.001 hours )
Final Multiply...
Time:    3.392 seconds  ( 0.001 hours )

Pi:  114.987 seconds  ( 0.032 hours )

CPUはPentiumE5200(2.5GHz)シングルスレッド。

なんかこんな結果。

Total Computation Time:             131.814 seconds  ( 0.037 hours )
Total Time (with output + verify):  137.509 seconds  ( 0.038 hours )

CPU Utilization:        99.5843 %
Multi-core Efficiency:  49.7922 %

Last Digits:  Pi
3803750790 9491563108 2381689226 7224175329 0045253446  :  24,999,950
0786411592 4597806944 2455112852 2554677483 6191884322  :  25,000,000 

Version:          0.5.4 Build 9148 (fix 1) (x86 SSE3 - Windows)
Processor(s):     Pentium(R) Dual-Core CPU E5200 @ 2.50GHz
Logical Cores:    2
Physical Memory:  1,542,631,424 ( 1.43 GB )
CPU Frequency:    2,493,810,399 Hz  (frequency may be inaccurate)

Benchmark Successful. The digits appear to be OK.

Result File: Validation - Pi - 25,000,000.txt

５兆桁計算した人は、アマ無線の人だった。

http://ja0hxv.calico.jp/pai/start.html

計算プログラムは日本人のオリジナルではなくて、米国のアレクサンダー・Ｊ・イーという人のものらしい。

Xeonが２個刺さるマザーでやったのね。

2 x Intel Xeon X5680 @ 3.33 GHz
96 GB DDR3 @ 1066 MHz
16 x 2 TB

これだけのマシンとなると、メモリーやＨＤＤも当然高価だけれど、
Windows2008のOSが高そう・・・。

軽く４Ｇで回りそうな石を定格で回して求めているところが男らしい

↑

こっちは、半年前の２.７兆桁の記事。

２.７兆桁計算したFabrice Bellardさんは、QEMUの作者らしい。

http://bellard.org/

しかも、スパコンですらない、普通のパソコンで！

↑

ひと目でわかる、アニメーションで説明したメキシコ湾・原油流出100日間

らばＱ

http://labaq.com/archives/51486901.html

悲惨
そもそもこれは試掘井だったらしい。
まだ止まってないという情報もある。
http://ytaka2011.blog105.fc2.com/blog-entry-182.html

↑

Cortex-M3:浮動小数演算でハング

とりあえず、インチキprintを実装した。
- ＰＩＣで使われていた、_user_putc()と_user_puts()だ。
- ARMのnewlibのprintは、まだ動かない。
それで、sprintfは使えるはずなので、適当な浮動小数点数をsprintfしようとするとハングする。

理由は良く分からない。

これから調べる。

浮動小数演算のみではハングしない。
演算結果をメモリーダンプすると正常っぽい。
sprintfで"%g"とか"%f"が全滅だ。

なんで？

malloc()を呼び出しただけでハングしているので、おそらく_sbrk()のアドレスがおかしいのだろうと仮定を立ててみる。
_sbrk()は、最初に呼び出されると、 endというラベルの値を返す。
が、ARM(STM32)では、微妙にendが_bss_endでもなくてuser_stackとかぶっていたりする。
試しに手動で空き番地を返すようにしてみたのだが・・・やっぱりハングする。

真面目にmalloc()を読むしかないか。

↑

_sbrkの動作そのものがおかしいことが分かった。

staticな変数が０初期化されていないため、初回のsbrkの戻り値が、とんでもない値（バスエラーするアドレス）になっている。

かといって、他の場所のstatic変数はちゃんと初期化できている謎・・・。

_sbrk()関数にprint文を埋め込んで調べることが出来るようになった。

大きな進歩だ。

↑

とりあえず、動くようにはなったが・・・

原因は、malloc()が悪いのではなくて、あくまでも_sbrk()が持つstaticなポインタの初期値が悪い、ということが分かった。
何故なのか分からない。

static な変数に初期値０を与えているのは自明なのだけれど、その初期値はとんでもない数値が入っているのだ。

回避策は、初期値０チェックのところに、異常値チェックも入れて、ともかくheapの先頭の値に初期化するようにした。
そうしたところ、malloc()は正しいポインタを返すようになり、sprintfの"%g"も正常に動作するようになった。

↑

現在の問題点

Flashの書き込みが遅い。(コードサイズが３２ｋより大きくなったので、書き込みに１０秒くらいかかる)
Flash書き込み後、自動スタートしない。---直さなきゃ。
アプリケーションをスタートさせたあとで、BOOTLOADERに戻すのが面倒くさい。
- ジャンパーをCLOSEして、USB挿抜を１回。

とりあえず、浮動小数点は使えるし、printも出来るようにはなったのだが、

なぜ、sbrk(というかsyscall.c)だけ、static変数の初期値がおかしくなるのかを調査しなければ・・・。

↑

sbrkだけ、static変数の初期値がおかしくなるのは何故か？

gccのスマートリンク機構にバグ？

gccのオプション -fdata-sections を入れると、以下のようなmain.lssファイルが生成される。

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
 0 .isr_vector   0000010c  08002000  08002000  00002000  2**0
                 CONTENTS, ALLOC, LOAD, READONLY, DATA
 1 .ARM.exidx    00000008  0800210c  0800210c  0000210c  2**2
                 CONTENTS, ALLOC, LOAD, READONLY, DATA
 2 .text         00007534  08002118  08002118  00002118  2**3
                 CONTENTS, ALLOC, LOAD, READONLY, CODE
 3 .data         000005e4  20000000  0800964c  00010000  2**2
                 CONTENTS, ALLOC, LOAD, DATA
 4 .bss          000002b8  200005e4  08009c30  000105e4  2**2
                 ALLOC
 5 .bss.led_cnt.4435 00000004  2000089c  08009ee8  000105e4  2**2
                 ALLOC
 6 .bss.sbrk_heap_end.2983 00000004  200008a0  08009eec  000105e4  2**2
                 ALLOC
 7 .bss.bIntPackSOF 00000001  200008a4  08009ef0  000105e4  2**0
                 ALLOC
 8 .bss.bDeviceState 00000004  200008a8  08009ef4  000105e4  2**2
                 ALLOC
 9 .bss.Data_Mul_MaxPacketSize 00000001  200008ac  08009ef8  000105e4  2**0
                 ALLOC
10 ._usrstack    00000103  200008ad  08009ef9  000105e4  2**0
                 ALLOC
                 ・・・・

.bssセクションは０クリアされるが、 .bss.sbrk_heap_end セクションは .bssセクションの外だと認識されていて、０クリアの対象外になっているのが、不定値を取る原因だ。

なぜ、他のセクション（.text.funcname とか .data.xxxxとか）は、正しく統合されているのに .bssセクションだけ、中途半端にバラけるのだろう？？？

理由はわりと簡単だった。

リンカースクリプトの
.bss :
{
       ・・・
       *(.bss)    
       ・・・
}

の中に、

       *(.bss.*)

を追加し忘れているようだ。（犯人は俺じゃない！）

sbrk以外にも、上記 .bss.ナントカと付いた変数も全て０クリアされないので、バグの原因になる。

-fdata-sectionsを外せば、全部 .bssに統合され、バグらなくなる。（ので、そうした）
-ffunction-sectionsだけでも、充分に不要コードを削除してくれているので、これでもＯＫ。

そもそも、-ffunction-sectionsと-fdata-sections、そして、リンカオプションの -gc-sections　の役割は、
- .text , .data , .bss の各セクションをさらに関数名（や、配列名）で細分化して、.text.funcname とか .data.arrayname のような細かいセクションに分割した後、リンク時に、未参照セクションをガベージコレクションで取り外すことによって、実行ファイルのサイズを小さくするオプションだ。
- 普通は、「スマート・リンク」などと呼ばれているし、Visual-C++などでも標準的にそのようなリンクになっている。
- （けれど、gccとldでは、上記のように明示的にオプションを入れない限り、スマートリンクしてくれないことになっている）

とりあえず、解決!!

read more : STM32ブートローダー

↑

さて、次なるターゲットは・・・

LPCXpresso(LPC3154+LPC1343)

２つに割ってみた。
普通にＰカッターで少し溝を掘ったあとで、普通のカッターナイフで深く切ってみた。
ベークならそれですぐパキッと割れるんだけど、ガラエポなんで中の繊維が意外としつこい。

LPC3154はFlashが載っていない。
このため、接続時に毎回DFUでファームを送り込む必要があるはず。（未確認）

↑

Cortex-M3:浮動小数演算でハングは解決

とりあえず、解決!!

ついでに、printf("%g")もＯＫになった。

read more : STM32ブートローダー

↑

300MHzのARM9搭載ノート風PDA:14,970円。

1万5千円のネットブック風PDA発売、WinCE

http://akiba-pc.watch.impress.co.jp/hotline/20100619/ni_cnote7.html
RAM 256MB,Flash 2GBだそうな。
Android動作も辛そうなクロック。
ubuntu動作も辛そうなRAMサイズ。
じゃあTinyCoreのようなLinuxでも乗せる？

キーボードが英語キー!!

一応USBは2.0だな。

↑

玄箱: lenny化失敗

debian etchでは、知らん間にapt-get出来なくなっている。
しかたないのでlenny化を模索中。

試したこと

まず、backup。てきとーに。
fdiskでパーティションを見かけ上全部消して再起動。

起動してもBusyBoxが反応しない。192.168.11.150もだめ。DHCPのアドレスっぽいのも全部試したけれどだめ。

もちろん、別のLinuxBox上で以下のおまじないは実行してある。
```
# ifconfig eth0:0 192.168.11.10 netmask 255.255.255.0 broadcast 192.168.11.255
```

RESET５秒押しもだめ。

別のx86なPCに繋いで、適当なCDROM-Linuxから起動し、パーティションテーブルを元に戻す。

一応元通りのdebian etchは起動する。
/dev/mtd3をマウントして、０バイトのファイル２個（ChangeMeDevHDD ChangeMyUbootEnv）を消してみる。
ブート。だめ。

それでもdebian etchに戻っている。

netを探していたら、大抵はシリアルコンソールで切り替えているようだ。

◆Flash Bootモードへの切り替え
Marvell>> setenv bootargs_root root=/dev/mtdblock2 rw panic=5
Marvell>> setenv vootcmd 'nboot $(default_kernel_addr) 0 $(nand_uImage_offset);  bootm $(default_kernel_addr)'
Marvell>> setenv nand_boot yes
Marvell>> setenv bootargs $(bootargs_base) $(bootargs_root) $(buffalo_ver)
Marvell>> saveenv
Marvell>> reset

◆HDD Bootモードへの切り替え
Marvell>> setenv bootargs_root 'root=/dev/sda4 rw panic=5'
Marvell>> setenv vootcmd 'ide reset; ext2load ide 0:1 $(default_kernel_addr) / $(kernel); bootm $(default_kernel_addr)'
Marvell>> setenv nand_boot no
Marvell>> setenv bootargs $(bootargs_base) $(bootargs_root) $(buffalo_ver)
Marvell>> saveenv
Marvell>> reset

シリアル繋ぐの面倒くさいなぁ・・・。

なんでDIP-SWくらい実装しないんだろう・・・。

Linux の nvram コマンドを使う 
  nvram は KURO-BOX/PRO 特有のコマンドです。 
 環境変数を書き込むには以下のようにします。 setenv と違い、変更内容は直ちに書き込みされます。 
# nvram -c set [環境変数名] [環境変数の内容]
以下のようにコマンド発行すると、環境変数の全リストが表示されます。上記の変更に入力誤りはないか、このコマンド操作でチェックします。 
# nvram -c printenv

という方法もあるみたいだが、/dev/mtd2/をマウントした/mnt/mtd2/usr/local/sbin/nvram というコマンド(elf)は残念ながらdebian(etch)上では動かない。

ということはシリアルコンソール確定なのだろうか？？？

HDDを物理的に外してみてBusyBoxが立ち上がればいいのだが・・・。

それでもだめなら、ダミーの空HDDを用意してBusyBoxの立ち上げをこころみる・・・。

面倒臭いなぁ・・・。

結局、アーキテクチャーarm-oabiのまま、dist-upgradeしてしまった。
とりあえずapt-get出来るようにはなった。
lennyの次でarm-oabi(arm-elf)は切り捨てられるのだろう・・・。

↑

ARMプロセッサの系譜

WikiPedia

http://ja.wikipedia.org/wiki/ARM%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3

IT Media

http://plusd.itmedia.co.jp/mobile/news/0108/22/arm2.html

こうなると、Cortexなんてごく最近のアーキテクチャーなのか。
組み込み用途ではCortex-M0,M3なんてのがある。ARM
Cortex-M4は、なんとDSP機能とかFPU付きとかSIMDとか言っているらしい。クロックも多少上がるのか。
ならば、もう他のマイコン(H8/AVR/PIC/PIC32/AVR32/SH2)は今後いらなくなるかも・・・。

EE TIMES

http://eetimes.jp/news/3709

↑

作りかけのARM用HID bootloader

CQ-STARMとSTBEEで仮バージョンが動くようになった。
しかし、STBEE Miniで全く動かない。
理由は不明。
一応JTAGはOFFったつもり。
USBのPULL-UPポートは全部バラバラに違っているし、Miniだけ正論理(HでPULL-UP)なはず。
そこまでは対応したのだけれど、そもそもＬチカしないって何だよ。

意味わかんない。

とりあえず、純正Ｌチカでも試すか・・・。

↑

原因はJTAGのDISABLE忘れだった。

STBEE MiniではJTAG機能PinをUSBのpull-up(PA14=TCK)やLED(PA13=TMS)で使う(PA14)ので、JTAGをDisableしないとトラブルが起きるようになっている。（地雷）
で、DISABLEコードを埋め込んだつもりがビルドエラーしているのに気づかず古いHEXを焼いて動かない動かないと・・・。アホか。

read more : STM32ブートローダー

↑

ARMマイコンパーフェクト学習基板

http://www.cqpub.co.jp/hanbai/books/mtr/mtrz201009.htm

買うべき？それとも・・・

LPCXpressoとの抱き合わせ販売まである。

http://shop.cqpub.co.jp/hanbai/books/I/I000021.html
3780 + 2800 = 6580 かあ・・・まあ秋月の送料が要らないというだけ。

LPCXpressoは基板を切り離しただけで、飽きて放置していたり。
LPCXpresso(LPC3154+LPC1343)

ARMマイコンのダメなところを吐露してしまおう。

チップ単体で買っても、基板を起こすのが大変というか面倒。
開発環境が（gccとかEclipseのくせに）オープンソースでもなくフリーでもない制限つき。（無償版はいくつか制限がついている）微妙にセコい。
複数の開発環境ベンダーがあって、それぞれに互換性がない。
- まあ自分でクロスgccをビルドする人には関係ないが。
いわゆるJTAGデバッグケーブルが高い。（LPCXpressoは例外的に安いけれど、実はJTAGじゃなかったりする）
同じCortex-M3アーキテクチャーを謳いながら、STMicroとNXPでペリフェラルが全然違うし、
同じNXPでもLPCxxxxのxxxxが違うとペリフェラルが全然違っていて、あのMicroChipでさえ、きちんと互換になるようなヘッダーやライブラリを提供しているのにNXPにはその気配がない。

↑

次なるターゲット

LPCXpresso(LPC3154+LPC1343)

２つに割った基板をこんどは連結できるようにピンヘッダーを立ててみた。
連結方法は、適当なＩＣソケットをひっくり返して差し込むという投槍的なヤツを作ってみた。（ケーブルを作るのが面倒だから）

そして、LPC1343側にUSB-Bコネクタを結線して、インチキ臭いＬＤＯレギュレータ（嘘。2SC1815だよーん）を載せた。
そしたら、ファームを焼いた覚えは全くないのに、勝手にＬチカが走っているようだ。
最初からテストが焼かれているのかな？

↑

とりあえず結線だけはほぼ終了。

実はUSBのpull-up回路だけ未配線。--- USB-VBUS(0-3)とUSB-CONNECT(0-6)を配線した。（但しUSB-CONNECT pullupは正論理つまり抵抗へ直結）

これでもうトラ技はパスかなー。

最初+5Vの接続場所を間違えて、3V3に4V強を入れてしまったのは内緒だ。（それでも妙に明るいＬチカしてたけど）

↑

あれ？次なるターゲットLPC-1343って、ROMもRAMも少ないな(32k+8k)

http://akizukidenshi.com/catalog/g/gM-03598/
printfも試せないくらい。
てゆーかPIC18F2550とおんなじじゃないか。(Flash ROM)
それどころじゃない。Flashのアドレスは０始まりだし、RAMは1000_0000だし、GPIOも5000_0000で全然違うやん。
RCCもないようだ。これじゃあSTM32とは全くの別物

おなじCortex-M3なんだから、統一しろ!!と言いたい。

2800円の割りに全然おいしくないぞ＞NXP

むしろLPC3154のほうを攻略すべきなのか？そうなのか？
そうすると、またLPC1343が焼けなくなる？というわけではない。だって3154側にはFlash-ROMは一切載ってないし、ハードウェア改造もしないし。
STM8S-DiscoveryのST-LINK側だって、JTAGのピンヘッダーを立てただけで、パターンカットや配線追加は行ってはいない。

・・・

ところが、こいつ(LPC1343)、マニュアルによると、CPU内部に16kBものBOOT ROMを持っていて、 UARTかUSB(MSCデバイス)からブートする機能があるらしい。
- PIO0-1がboot選択で、PIO0-3がUART/USBの選択になっているっぽい。
- MSCデバイスって、何？--- たぶんMass Strage Classのことなんだろうな。
- じゃあ、とりあえずシリアルからブートさせよっかなー。
内蔵Flashが32kしかないのにBOOT-ROMを16k持っているとは、なかなか手ごわい。

実際に試してみた。

PIO0-1をGNDに繋ぐとＬチカせずにＬ点灯固定になり、USBは不明なデバイスになった。
PIO0-3は一応USB-VBUS(5V)に繋いだつもり。（直結でよかったのかな？？？やばいのかな）

もう一度配線を確認すると、USB D-に2kΩpullupを繋いでいた。（AVRの回路を参考にしたもが間違いだった）
良く考えたら、ARMはUSB FullSpeedであり、AVRはLowSpeedなので、ARMの場合はUSB D+をpullupしなければならないのだ。

で、配線を直して試してみると、

↑

あらびっくり、ほんとにUSBマスストレージデバイスが出現

32kB容量のCRP DISABLDというドライブが出来て、そのなかにfirmware.binという32kBのバイナリーが現れた。
hex dumpすると、どうやらファームウェアＲＯＭが見える。
ということはこのMSCデバイスに書き込めればファーム更新まで出来るというのか？？？？

へぇー。ブートローダー書かなくてよくなった。

↑

ほんとうにやってみた。

firmware.bin をWindowsにコピーする。
Bzエディタ（兵藤さん作）で空き領域に落書きする。
こんどはそれを32kBのMSC（マスストレージクラス）のドライブに書き戻す。

USBケーブルを一回抜いて挿しなおす。

もいっかいfirmware.bin をBzエディタで開いて落書きが残っているのを確認。

ＯＫだった

↑

armon:ARM用HID bootloader

一応、手持ちのSTM32全ての基板をarmon化して、動作確認を行った。

問題ない

サポートする基板は４種類

STM8S-Discovery
CQ-STARM
STBEE
STBEE Mini

HIDクラスのbootloaderとして機能する。

bootloaderのサイズは８ｋＢ。
いずれの基板においても、0x0800_2000～にユーザーアプリケーション(HEX)を焼いて、即時起動する機能がある。
ユーザーアプリケーションがUSBを使用する場合でもUSBデバイスは再接続されて機能する。
書き込みは(DFUと比較する限り)充分高速だ。

Thumb2の逆アセンブラ機能も実装した。

これまではPIC18Fの恥ずかしい逆アセンブラが動作していた。

I/Oポートの名称解決機能はない。

read more : STM32ブートローダー

↑

次なるターゲット・・・

LPCXpresso(NXP全般)は、もういいや。
STM32ブートローダーの改良はぼちぼちやっていくとして、
次なにしょぅ。

とりあえずOpenOCDをcygwinでビルド出来るようにしようかなとか考えているけれど、
うまくできることがわかったら、例のUSB-Blasterもどきの続きでもやるかなぁ・・・。

なんかARM系全般的に需要がないんだなぁ・・・。なんでだろ。

まあ、今頃DWM2008-5付録基板なんか引っ張りだしてもねぇ・・・。

今月のトラ技なんて、その2008年5月の付録よりもだいぶ劣化したCPU積んでるし。もうネタ尽きたのかな。

↑

Oracle、Java 特許侵害で Google を提訴、Android 配布中止求める

http://slashdot.jp/it/10/08/20/0147235.shtml
ついにOracleは特許ゴロになったか。
というかAndroidもこれを機に別の仮想バイトコードにするとかARMネィテイブちっくな仮想マシンコードにするとかJavaやめてgolangにするとかきっぱりJavaと手を切ればいいのに。

そうしてJavaの死
Sunもこの世に存在しないんだし。

↑

次なるターゲット・・・

本屋で見かけたので、買ってしまった。

今は、後悔している。

ちなみに、ＰＣに繋ぐと、MSCデバイス（32kBのストレージデバイス）として認識された。

USB D+は、1.5kΩで3.3Vに問答無用pull-upされている。
と同時に、読者が2SA1015を実装するとPIO0_6をLレベルにすることでさらに1.5kΩアクティブpull-up出来るようになる。
ただし、問答無用側のpull-up抵抗（表面実装されている米粒）を読者が除去する必要がある。
除去しない場合は、0.75kΩ/1.5kΩ切り替えという全く意味のない回路が構成されてしまう。

USBに挿すだけで、温度計とかタッチセンサとか時計とかOPAMPに繋がると思ったら大間違い
- 第一に、プログラムを書かなきゃならない。
- 第二に、基板上に所定のピンヘッダーを自分でハンダ付けして、ジャンパーでピン間を接続しなければLPCマイコンと他のICは接続されないのだ。（プログラム書くのも面倒だが、いちいちジャンパー挿すほうも面倒だと思うよ。おまい電子ブロック（電子ボード）基板かよとか言いたくなる）
- まあ、逆に言うと、ピンヘッダー間をショートさせるかわりに別の用途先に接続すれば、JTAGライターにするとかAVR/PICライターにするとかそういう応用は利く。
- それから、時計ICは実装されているけれど32.768kHzの水晶は実装されていないので、適当な壊れた互換機のマザーボードなどからもぎとってハンダ付けせねばならない。

↑

MicroBasic

昔のGame言語のままみたいな（だけど劣化している）、残念な言語。
コードサイズは19kもある。昔のGame言語はZ80でも1K以内とか、えらく小さかった。(整数BASICは4kくらいだったし、実数Basicは8kくらいでどれも実装されていた時代)
変数はA-Z(32bit整数)
テキストエリア4kまで
１行80字まで

このままじゃあ、Gameコンパイラ書いてThumb2のコードを落とすとかいう遊びにすら、使えないレベル

ていうかBasicいらない。
せめてLuaとかSquirrelとかＣ言語風じゃないと。

おまけはてんこ盛り。

結局何なの、この基板

やっぱり、温度計。
温度計なんだけど、I2Cの勉強して温度計ICにアクセス出来るようにならないと温度を教えてくれないツンデレ温度計

関連情報の~~やる気なさ具合は、半端ねぇぜ。~~ --- 最近すこしづつ増えてるような気がする。

STM32のA/D分解能は12bitあるけれどLPC1343とかは10bitしかない。
STM32はオンチップの温度センサーがあるけれどLPC1343にはない。

あーそれからGPIOの(AVRで言うところの)DDR相当レジスタ周りがSTM32と全然違ってる。
Arduino風に使いたいなら、このメーカー差異が相当ガンだと思う。CMSISなんかで矯正不能なレベル。
それに、Flash32kなんて(Arduinoマニア系)ユーザー舐めてるとしか思えない。printfと書いただけで軽く32kオーバーするlibcっていったい・・・。
今時のArduinoでさえATMega32実装が当たり前なのに。
ちょっとしたスケッチを書くのに必要な最低容量はFlash128k,RAM 32kくらいは欲しいところ。

↑

armon:ARM用HID bootloader

USBフレームワークとCMSISを最新のものに差し替えてみた。
いろいろディレクトリ配置が替わっていて、手直しが面倒だった。
システム周りのソースを差し替えたので一時的に動かなくなった。
- STのソースはEVALボード用なので、CQ-STARMなどと少し違う。
- そのあたりの修正が上書きされて消滅したため、こちらの基板で動かなくなった。

一応リカバリーしてみた。

まだ全部の基板で試してないのでソースはUPしていない。

read more : STM32ブートローダー

↑

準天頂衛星初号機「みちびき」

http://www.jaxa.jp/countdown/f18/overview/orbit_j.html

すげー。
そもそもＧＰＳの補完情報とか勝手に流していいのかな。

もちろん、こいつも一緒に受信して補正計算するようなファームにVerUpしない限り、現存するＧＰＳの精度が上がるわけではないけれど。

一種のＧＰＳのガラパゴス化？

（軌道をずらして）８機くらい上げればもう米国に頼らなくても済むようになるのかな？

日本国近辺でしか使えないＧＰＳというのもどうかと思うけど。（国産車カーナビに限定すればそれでも良いけど）

↑

LPC1343:不思議なことに・・・

NXPのサンプルを見てみたら、面白いものを見つけた。

_LPCXpresso1343_readme% cat readme.txt

LPCXpresso LPC1343 Examples V1.30
Build date: 3/11/2010
---------------------------------

This package of examples is designed to run on the LPCXpresso LPC1343
board with the LPCXpresso IDE by Code Red. Many of the examples will
also benefit from the Embedded Artists' LPCXpresso base board.

Here is a list of the examples and a brief description of what they
do:

adc                    Demonstrates using the ADC to read voltages

autoisp                        Shows how to enter ROM in-circuit programming
                       and use the watchdog timer to reset back into
                       the new code

blinky                 Blinks an LED using a 32-bit timer

CMSISv1p30_LPC13xx     CMSIS library- defines all of the I/O registers
                       on the LPC1343

crp                    Demonstrates how to add Code Read Protect (CRP)
                       to a project

extint                 Shows how to configure external interrupt pins

gpio                   Shows how to set up the gpio

i2c                    Implements an i2c master that communicates with
                       the slave project

i2cslave               Implements an i2c slave that communicates with
                       master project

pwm                    Initializes two timers to output PWM waveforms

rs485                  Shows use of the UART in RS485 mode

ssp                    Shows use of the SSP in SPI mode

systick                        Shows how to use the Cortex core systick timer

uart                   Demo of the UART

usbcdc                 USB example that implements a virtual UART and
                       routes characters to the hardware UART on the
                       LPC1343

usbhid                 USB example that implements a Human Interface
                       Device allowing control of I/O pins

usbhid_rom             USB example using the on-chip ROM USB driver
                       that implements a USB HID device.
★
usbhid_rom_tiny        USB example showing several techniques to reduce
                       the flash size of code. The compiled project takes
                       404 bytes of flash.

usbmsd                 USB example that implements a Mass Storage Class
                       device with a readme.txt file on it.

usbmsd_rom             USB example that implements a Mass Storage Class
                       device using the on-chip ROM USB driver.

wdt                    Initializes the watchdog timer. It is set to
                       generate an interrupt that increments a timer
                       upon timeout. The wdt can be made to timeout
                       by stopping the code in the debugger.

HIDデバイスをわずか４０４バイトで実装できるらしい。
もちろん、16kBの(USB-MSD)BOOTROMをライブラリとして利用する。

これは凄いかも。
コードもあまり書かなくてよいらしい。
Flash 32kで足りないよーとか言ってたけれど、BIOS ROMが 16kもあって、USBのフレームワークを自前で持たなくてよい、というんだったら、結構いけてるかも。

まあ、RAMが8Kしかない、というのがつらいことに変わりは無いけど。

↑

これも、ほんとに試してみた。

わずか４０４バイトで、HIDデバイスとして使用できた。

LPC1343:TRZ1010Nのバカヤロー

LPCXpressoと同じバイナリーを転送してみた。
不明なデバイスになった。

理由はわからない。

まさかBOOT-ROMの互換性がない、なんてことはないよね。

ありえない展開に。

↑

LPC1343:続：ありえない展開

TRZ1010N基板は、別のＰＣに接続したところ、HIDデバイスとして認識され、ＰＣ側のクライアントソフトから制御することができた。

しかし、それは、たまたまだった。
その後USBの挿抜では、ついに認識されることは無かった。

同じファームを入れて、同じＰＣ上でLPCXpresso基板はほぼ９０％くらいの確率でちゃんとHIDデバイスとして認識する。

また、FT/GPIOをGNDに落とした状態(MSDデバイス)でＰＣがUSBドライブとして認識するかのテストでもLPCXpresso基板のほうはほぼ確実に認識するけれど、
TRZ1010N基板は、認識しない場合がけっこうある。（３割くらいが駄目な感じ）

やっぱり、ＣＱ基板は電源周りが弱いというのは定説だな。

今のところ基板をいじった箇所は、
- ブートジャンパーを実装。
- ＬＥＤを実装。
の２つのみ。

最初のＰＣで認識しなかった時点では、基板は一切の加工を行っていなかったので、上記実装に関しては犯人ではないことがわかっている。

いつのまにかＣＱ基板はトラブルシュートを楽しむものと化してしまっている。

それって、かなり駄目じゃないか。

少なくとも、入門者向けではないような気がする・・・

もうひとつ問題が・・・

usbhid_romのビルドでは、libcr_c.aが必要とか言われるけれど、そんなもの無い。
usbhidのビルドがはたして正しいかどうか判定できない。
- LPCXpressoに転送したところ、正しく動かない。

なんかどうもLPCXpressoと相性悪いな。

このチップ(LPC1343)、きっぱり切り捨てるかも。

↑

LPC1343:続：いったん収束

全く使ったことが無かったけれど、eclipseを起動。
QuickStartというWindowにある、「Import Example Project(s)」のようなメニューをクリック。
LPCXpressoをインストールしたディレクトリのExamples/LPC1000/にある、LPC13xxExamples.zipのようなファイルを指定。
すると、サンプルプロジェクトを全部展開してくれる。

試行錯誤している間は、zipファイルを手動で展開したディレクトリのプロジェクトファイルのようなものを指定しようとしても全然駄目（開いてくれない）だったのに。

Build Allのようなプルダウンメニューを選ぶと、とりあえず全部コンパイルしてくれる。

さて、hexファイルはどこ？

あれ、ない。

調べたところ、拡張子axfファイルが、elfだと分かった。
なので、CodeSourceryについてきた arm-none-eabi-objcopyを使って、こんどはelfをバイナリーにする。
```
D:> arm-none-eabi-objcopy -O binary usbhid.axf firmware.bin
D:> srec2bin.exe -w firmware.bin
```

srec2binというのはちっぽけな自作ツールで、リセットベクターの０番から７番までの整数和がゼロになるように、７番目のベクター値を補正するプログラム。

これをかまさないと、ブートローダーはアプリケーションを実行してくれない。

出来たfirmware.bin (13kBほど)をMSDデバイスのドライブにコピー。

こんどは、ほぼ１００％の確率でHIDデバイスとして動作するようになった。（TRZ1010N基板にて）結論：
TRZ1010N基板は何故かusbhid_rom_tinyが動かない疑惑中。

↑

TRZ1010N基板：念のためusbhid_rom_tinyも!

eclipseでビルドしたaxfファイルからfirmware.binを作り、TRZ1010N基板に転送。
HIDデバイスとしての認識率はやはり１０％以下。（というか試行１０回中認識ゼロ）全部不明なデバイスになる。

これはどう解釈すべきなんだろうか。

BOOT-ROMを実行時ライブラリとして（呼び出して）使うタイプのUSBデバイスサンプルは
TRZ1010N基板では全滅。
LPCXpressoのターゲット基板では、大体動作する。

しかし、回路的に大きな違いはない。
念のためUSBケーブル側に10μFの電解コンデンサを入れてケーブル挿抜を繰り返してみたが、TRZ基板は駄目なことに変わりはなかった。

お前の信頼度はそんなものなのか＞LPC1343

↑

ARM関連：Apple A4プロセッサを分解

「革命」ではなく「進化」の産物　EE Times

http://eetimes.jp/content/4153
Cortex-A8がそのまま入ってた。

【Hot Chips 22レポート】 ARM、次期ハイエンドコア「Eagle」の内容を一部公表

http://pc.watch.impress.co.jp/docs/news/event/20100825_389138.html
物理アドレス拡張(40bit)と仮想化
サーバー用途なのか。

↑

LPC1343:usbhidのビルドを試みる。

usbhid_rom_tinyと同じ要領でビルドツリーを作成。
ビルドはＯＫ。コードは4Kくらい。
LPCXpresso側に転送すると、「不明なデバイス」

eclipseでビルドされたコードは12kもあり、こっちだとちゃんと動作する。
CDEFSに
```
-D__USE_CMSIS=CMSISv1p30_LPC13xx
```
を加えてやったら、やっと動作するバイナリーが得られた。
でもコードは4kくらい。
eclipseはgc-sectionしないのかな。

TRZ1010N基板でも正しく動作した。

↑

ついでだから、usbhid_romもビルドしてみた。

TRZ1010N基板でも正しく動作した。
こっちはコードサイズが1.2kB程度。

サイズ404バイトのやつはストリングディスクリプタが腐っている様子なので、デバイス認識しない理由はそのへんにあるのかも知れない。

LPC1343:armonの移植に取り掛かる

切り捨てようかと思っていたLPC1343だが、一応HIDデバイスにはなりそうなので、armonを移植することにした。
やはり、USB周りの定義や処理が全然違う。
そればかりでなく、Flashの書き換え関数も違ってるような気がする。
- というか、Flash書き換え関数なんてない。
autoispというサンプルは、BOOT-ROMに制御を戻すためのサンプルのような気がする。

やっぱり切り捨てよう。

usbhid-romのサンプルはBOOT-ROM内蔵のUSB関数を使用することでUSBデバイス記述を簡易にしてコードサイズも節約する狙いがあるようであるが、
残念なことにエンドポイントの細かい制御が出来ないのでarmonには使えないことが判明した。
また、ストリングディスクリプタを登録できるところまではよいが、文字数が決めうちになっていて、文字数を変えると正しいストリングを返さなくなってしまう欠点がある。

抜け道としては、

BOOTROMのサービス関数エントリーは使わずに、usbhidサンプルに含まれる関数のうち、ROM内に同じ形で残っている関数をリストアップして、そっちを呼び出す方法がある。
まるで、昔の８ビットパーソナルコンピュータのBASIC-ROMを解析して、サブルーチンとして使うような手法だ。
BOOT-ROMが更新されてアドレスがずれたらアウトだ。

そんなことしなくてもHIDデバイスは書けるからしないけど。

↑

LPC1343用: HID簡易モニター（armon） .(LPCXpresso / TRZ1010N 両対応)

とりあえず、作ってみた。
やっぱり、STM32とはUSB周りが全く違っている。
Flash書き換え方法が分からないので、ブートローダーにはならない。
printfを使うと、32kBを越えるので、焼けない・・・（この時点でLPCマイコンはArduinoのようなプロトタイピング用途には向かない）・・・っていうのは、まるで、H8-Tinyみたいだな。

最新の20件

2010-08

８月：脱皮したばかりのセミ＝セミヌード という妄想が頭をよぎって離れない。ミーン

先月のまとめ

ubuntu10.4を快適に使う。

（１）メニューバーを全部下に持ってくる。

（２）当然Ext4でフォーマットする。

アマゾン新 Kindle 発表、WiFi版 139ドル・3G版189ドル

STM32:GPIOポートの続き。

で、良く見たら、JUMPER OPEN時に0x0800_2000番地のファームに飛ぶ処理が入ったままだった。

0x0800_2000番地のファームを起動する処理は少しだけ気持ちが悪い。

とりあえず、HIDブートローダーが出来た。

Orange Computer(SC/MP-II)

トランジスタ技術 2010年9月号増刊

筍Pad

STM32:やっとＬチカができるようになった。

stm32 ToDo List

STBeeが来た。

stm32 続き

即実行

STM32:コンパイラをCodeSourcery にしたら、かなり縮んだ。

コード品質？？？

なんかswi命令の先あたりでハングする。

え？５兆桁って、日本人が達成したの？

y-cruncherというPiの計算ソフト（x86/x64バイナリー含む）は、以下のサイトからＤＬ出来る。

こっちは、半年前の２.７兆桁の記事。

ひと目でわかる、アニメーションで説明したメキシコ湾・原油流出100日間

Cortex-M3:浮動小数演算でハング

_sbrkの動作そのものがおかしいことが分かった。

とりあえず、動くようにはなったが・・・

現在の問題点

sbrkだけ、static変数の初期値がおかしくなるのは何故か？

さて、次なるターゲットは・・・

Cortex-M3:浮動小数演算でハングは解決

300MHzのARM9搭載ノート風PDA:14,970円。

玄箱: lenny化失敗

ARMプロセッサの系譜

作りかけのARM用HID bootloader

原因はJTAGのDISABLE忘れだった。

ARMマイコン パーフェクト学習基板

次なるターゲット

とりあえず結線だけはほぼ終了。

あれ？次なるターゲットLPC-1343って、ROMもRAMも少ないな(32k+8k)

あらびっくり、ほんとにUSBマスストレージデバイスが出現

ほんとうにやってみた。

armon:ARM用HID bootloader

次なるターゲット・・・

Oracle、Java 特許侵害で Google を提訴、Android 配布中止求める

次なるターゲット・・・

MicroBasic

armon:ARM用HID bootloader

準天頂衛星初号機「みちびき」

LPC1343:不思議なことに・・・

これも、ほんとに試してみた。

LPC1343:TRZ1010Nのバカヤロー

LPC1343:続：ありえない展開

LPC1343:続：いったん収束

TRZ1010N基板：念のためusbhid_rom_tinyも!

ARM関連：Apple A4プロセッサを分解

LPC1343:usbhidのビルドを試みる。

ついでだから、usbhid_romもビルドしてみた。

LPC1343:armonの移植に取り掛かる

LPC1343用: HID簡易モニター（armon） .(LPCXpresso / TRZ1010N 両対応)

８月：脱皮したばかりのセミ＝セミヌード　という妄想が頭をよぎって離れない。ミーン

ARMマイコンパーフェクト学習基板