2010-04

2010-03←　→ ＡＶＲ／ＰＩＣ両用ライター　 usbシリアル変換　 usbキーボード　簡易ロジアナ、赤外線リモコン信号観測

４月：ついにＬＨＣ再開3.5TeV　何が見える？†

暗黒物質？Ｈｉｇｇｓ粒子？次元の扉？はたまた地球の破滅？

ＡＴＬＡＳ実験オフィシャルBlog

http://d.hatena.ne.jp/lhcatlasjapan/

ＫＥＫ

http://atlas.kek.jp/

↑

先月のまとめ†

PIC24Fライター--完成
ＦＰＧＡ基板（LatticeXP2）でＬチカ。--完了
ＮＸＰ基板でOpenOCD --玉砕
hidmon-2550/hidmon-14kのソース整理。--済み
hidmon-2550/hidmon-14kのHID転送モードをインタラプト転送に戻す。--ミカン、じゃなくて未完。

今月の~~たわごと~~目標

~~hidmon-2550/hidmon-14kのHID転送モードをインタラプト転送に戻す。~~ --- 済み
（もれなく雑誌が付いてくる）SH2A基板を（万が一）買ったら使い道を考える。
FT2232LでOpenOCD(JTAGkey互換品)を試す（作ってみる）。
- --->多分やらないかも。レベルコンバータ入手が面倒なのと、ＣＱ付録基板でJTAGが必要になるシチュエーションはあまりなさそう。
- 必要になったときに考える。

STM32のDFUビルド環境を整える。

まあ、素人にはどうせこの程度しか出来んのですわ。

↑

hidmon-2550/14kのHID転送モードをインタラプト転送に戻す。†

うまくいった。
コントロール転送系よりコードサイズは大きくなる。
poll系は未実装。
~~bootloaderとしてのテストはこれから。~~

ファーム書き込みテストはパスした。

bootloaderとして使ってみた。一応使えるようになった。

poll系は未実装を返すようにして、ホストＰＣ側で代替処理に切り替えた。

毒味版のダウンロード（仮）

pic18boot-2010-0406.zip

picmon.exeは統合化済み。

使用例１ --- ブートローダーから800番地のアプリ（例えばpic18spxファーム）を起動する。
```
C:>picmon.exe
PIC> boot 800 
PIC> q
```
使用例２ --- pic18spxファームから、ブートローダーに制御を移す。
```
C:>picmon.exe
PIC> boot 0c
PIC> q
```

これで、ブートジャンパーを切り替えてUSBケーブルを挿しなおす手間は不要になった。

↑

PIC関係ツールが（とても）分かりにくい件†

まず、反省

テキトーに作って、作り散らかしていた。（実験している、とも言う）

アーカイブ名	機能	実行ファイル	コメント
hidmon-2550	ブートローダとPICモニタ	picboot.exe / picmon.exe	diolanローダーを改造しただけのもの。18F2550/4550対応品
hidmon-14k50	ブートローダとPICモニタ	picboot.exe / picmon.exe	diolanローダーを改造しただけのもの。18F14K50専用品
pic18spx	PICモニタとAVR/PICライタを実現するパッケージ	picmonit.exe / picspx-gcc.exe / picwriter.exe / writer24.exe	hidmon-2550/14k50ファームウェアをＣ言語でリライトして機能強化した（AVR/PICライター部分を追加した）もの。ファームのサイズが大きいので、ブートローダーとしては使えない。
picspx-classic	ATtiny2313(HIDaspx)ハードウェアを使用してPIC18Fに書き込むWindows上のツール	picspx.exe	読み書きは非常に遅い。最初にPICにブートローダーを書き込むための限定ツール。

さらにもう一個追加される。

アーカイブ名	機能	実行ファイル	コメント
pic18boot	ブートローダとPICモニタ	picboot.exe / picmon.exe	ソースはアセンブラのままで、hidmon-2550/14k50とデバイスごとに別ソースになっていたものを統合し高速化したもの

なにがダメかというと、実行ファイルの名称がダブっているところ。
18F2550/18F14K50で別々になっていなければならない実行コマンドを同一名称のexeにしていた。
picmon.exe / picmonit.exeのように良く似ている実装なのに実行ファイル名称が微妙に違っていること
- picmon.exeはアセンブラ実装側ファームをサポートし、picmonit.exeはＣ言語実装側ファームをサポートしている。

↑

結局のところ、何をやりたいかというと・・・†

3.3〜5V動作で、廉価で、DIP品が売られていて、USB内蔵のPIC18Fxxxxにプログラムを書き込みたかっただけ、とも言える。

じゃあ、PICKit2を買えと言われると、まったく反論できないわけで・・・

↑

図説†

PIC関係ツールを図式化して説明していただきました。

senshuさんのサイトに飛びます。

http://www-ice.yamagata-cit.ac.jp/ken/senshu/sitedev/index.php?AVR%2Fnews53#n062e049

↑

携帯：SIMロックフリー論争†

そもそも無茶な話。
なぜこのタイミングで出てきたかというと、iPad発売タイミングだから。
おそらくガイアツ（外圧）。

↑

LTEというのは3Gの次の規格なのか？（3.9Gらしい）†

http://www.rbbtoday.com/article/2008/10/01/54649.html

そうすると何が起きるか？

携帯電話（ハードウェア）はコモディティ化する。

iPhone/iPad,Android,Kindleなどに収束してしまう。
ガラパゴス消滅の危機！

Apple、第4世代iPhoneではCDMA版の提供も計画か - WSJ報道

http://journal.mycom.co.jp/news/2010/03/30/065/index.html

つまり、SIMロックフリーになってもAUと他2社間ではそもそも通信方式が違うので端末を融通できないってこと？

まあ、それは置いといて、

iPhone/iPadがどのキャリアでも使えるようになってしまうと携帯キャリアは単なる無線ＷＡＮプロバイダーに成り下がってしまう。（昔のような、端末製造電機メーカーを牽引する強い指導力は無くなる）
そうすると、台湾中国韓国などメーカーもAndroid格安端末を製造するようになり端末のコモディティ化が起こってしまう。
日本国内メーカーもAndroid端末を調達するようになってしまうだろう。（使いやすいのかどうかは別として）

孫さんが言うように、

DoCoMoとSoftbankは端末融通が可能なので、インセンティブを利用した端末安売りが出来なくなり、競争原理がSoftbank不利に働いてしまう。

あとの問題は、

音声通話が廃れてしまうかも。（もう廃れているのかな）
Twitter,メッセンジャー、その他文字ベースのコミュニケーションとか(iPadなどでの/Web)アプリなどが携帯端末の主要用途になってしまう。
音楽や書籍などのダウンロードマーケットは携帯キャリアではなくAppleとAmazonらによる寡占がひどくなってしまうかもしれない。

↑

Appleの驕り†

Apple、「iPhone OS 4 SDK」規約変更 - Flash CS5/MonoTouch排除へ

http://journal.mycom.co.jp/articles/2010/04/09/ip4sdk/index.html

新規約によれば、iPhoneアプリはiPhone OSやWebKitで実行可能なObjective-C/C/C++あるいは
JavaScriptで必ず記述されなければならないという。また、これら言語で記述されたコードのみ
がコンパイルによって規定のAPI群へのアクセスを許可されるという。
中間言語の使用や中間レイヤーを用いるツールの利用も禁止されるということだ。

自分で自分の首を絞めやがれ。
```
Objective-C/C/C++あるいは JavaScript
```
C以外は全部ダメ言語じゃないか。

↑

ARMの難易度はPIC以上？†

やっとビルドが通るようになった。
焼いてみると、案の定デバイス認識出来ない。
やっとスタートラインか。

そうやって、再帰問題ばかり作ってる。†

つまり、

ICEやICEに近いデバッグ環境とか、純正コンパイラ＋すぐ動くUSBサンプルソースとかをすでに持っているのであれば、
わざわざ大昔のマイコンモニターもどきを作ったり、JTAGKeyもどきを作ったり、GDBスタブを移植したりする必要は全くないわけ。
そのような恵まれた環境でＬチカをやったとしても何の達成感も得られない。

禅問答

無いから作る（作ろうとしている）
すでにあるなら、何もしない。（何もする必要がない）

↑

ＣＱ：STARM基板†

久々にクソなシステムを見てしまった。（ＤＦＵのこと）

ビルドはMake一発で出来るようになった。
main()関数をＬチカのものに差し替え(#ifdefで)ビルド。
実行？しようとしたら、何これ珍システム（ＤＦＵのこと）

HEXをDFUに変換するためにわざわざＧＵＩを起動。
HEXファイル選択ウィンドウうざい。
dfuファイル選択ウィンドウうざい。
上書き出来ない。一回dfuを消さないと生成出来ないクソシステム。

そして、DFuSeという変なダウンロードＧＵＩを起動。
dfuファイルを選ぶ。
書き込む。
J6ジャンパーをOPENにする。
USBを一回抜いて挿す。

Ｌチカ成功。

ＧＵＩが生産性を上げるなんて誰が言ったんだっけ？

↑

STARM基板について、今のところ分かっていること。†

キホンノキホン、Ｌチカソフトでさえ、有償コンパイラとgccで全くビルドが通らないくらい書き方が違うこと。
もちろん、ヘッダーファイルもファイル名が違う。
Ｌチカは動くが、USBデバイスをビルドしても不明なデバイスになる。（USBとして全く機能していない）

ビルドのターンアラウンドに要する手間がかかりすぎて駄目。

hexがそのまま書き込めるなら、DFuSeのようなものを起動したままで書き込みボタンを押すだけなのに・・・

↑

この開発環境はDFUが全てを台無しにしている。†

Ｌチカをprintf代わりに使って試したところ、~~Set_System()~~USB_Init()呼出し前までは生きていて、呼出し後に全滅していることが判明した。~~たとえばEVAボードとCQ基板でXtalの周波数が違いすぎていてＧＨｚオーダーで動いてしまうとかそんなオチ。~~ PLL関係は8MHz水晶の９逓倍で同じ設定だった。

~~今のところ何が悪いのか分からない。~~

USB_Interrupts_Config()にて、

NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x3000);

が必要らしい。

主な問題はそれだけだった。
vcomとhidは一応ＰＣからデバイス認識するようになった。

機種判別的には、
```
#ifdef USE_STM3210C_EVAL
```
になっているところは使わないのが正解のようだった。

↑

hidが動かない件†

HIDデバイス認識まではこぎつけたが、PICmonから触ろうとすると、ProductID取得で失敗するようだ。

VendorID,ProductID,Serialをオリジナル版に戻すと取得できる何故

実はSerialバッファが書き換え（上書き）バッファになっていて、サイズを大きめに確保しないとハングする仕組みが導入されていた。

定数バッファを上書きするなよと言いたい。酷いつくりだ。
- せめてコメント書いとけよ。＞玩具屋

↑

相変わらずhidが動かない件†

Custom_HIDのサンプルはEP1バッファのサイズが異常に小さい(2byte)
こいつを64byteにして、echobackを返すようなコードを書いている（つもり）なのだが・・・
エコーバックは返ってこない。
というか、EP1エンドポイントへの書き込みコールバックさえ呼ばれていないような感じ。
なんで？

理由はusb_prop.cにあった。

ENDPOINTの初期化はusb_prop.cで行っていた。
ここで、EP1BUFのアドレスやサイズの設定が行われていた。
何故か、EP1BUFのアドレスだけはusb_conf.hに定義していて、サイズに関してはcソース内で決め打ちだったのだ。
てっきりディスクリプタに書いた値を採用するのかと思っていた。(あるいはEPのサイズはヘッダーで定義して、双方がそれを参照するとか。)

↑

一応、ここまで出来た。†

Custom HIDクラスに64byteのEP_INとEP_OUTを用意。
ECHOBACKとPEEK,POKE(両方ダミー)が動作。

PICKit3が安い†

４５００円

http://akizukidenshi.com/catalog/g/gM-03608/
今まではDebugExpress込みで７０００円でしか買えなかった。
PICKit2なら３５００円
http://akizukidenshi.com/catalog/g/gM-02508/

もうライターを自作する時代は終わったな。

その前に、PICKit2互換ライターは（価格的に）終了。

↑

エイヤフィヤトラヨークトル氷河の火山†

アイスランド火山灰：飛行機への影響と「飢饉」の可能性

http://wiredvision.jp/news/201004/2010041923.html

アイスランド南部　エイヤフィヤトラヨークトル（Eyjafjallajokull）氷河

この氷河の名前、覚えられないんだよな。
どこで区切るのかな？
飛行機が飛べないなんて、これから起こるであろう気象への影響に比べれば小さい小さい。

↑

ARMの難易度はPIC以上！†

例えば、USBフレームワークを入手したいとすると、

http://ics.nxp.com/support/documents/microcontrollers/?search=USB&Search.x=9&Search.y=11
どれを落とせばいいのか分からない。
品種依存ソースしか存在しない。
- 品種依存ソースを落としてみると、中身(Copyright)はKeilだったりする。
- つまり、NXPはフレームワークを提供するつもりがないようだ。
- USBスタックが何種類か存在するが、どれも製品のようだった。
MicroChipですら、共通のUSBフレームワークをちゃんと無償提供している。

ある意味、ＡＲＭはＰＩＣ以下。

ＮＸＰの製品ラインナップですら、まともなフレームワークが提供されていなくて、
サードパーティのＵＳＢスタックを買えという有様だ。

フリーソフトでLPCUSBというものがあるんだけど、LPC23xxビルドが見当たらない。
メモリーマップ(*.ld)だけLPC23xx対応してみたんだけど、全然動かない。

↑

ARMクロスコンパイラ構築†

Windowsでやるとビルドがえらい遅いので、Linuxに乗り換え。
- 実はローカルHDD上でやればそんなに遅さは気にならない。
- sambaマウントしたドライブでやると死ぬほど遅い。

ビルドのコツ

最初にＣだけ作って、あとでＣ＋＋を作るよろし。

まず、アーカイブを適当なところに展開

$ mkdir build
$ cd build/
$ tar xvfz binutils-2.19.tar.bz2
$ tar xvfz newlib-1.17.0.tar.gz
$ tar xvfz gcc-4.3.0.tar.bz2

ビルド用ディレクトリを作成

$ mkdir _binutils
$ mkdir _gccbuild
$ mkdir _newlib

まず、binutilsから。

$ cd _binutils
$ ../binutils-2.19/configure --target=arm-eabi --prefix=/usr/local/arm
$ make 
$ sudo make install
$ cd ..

次、gccのＣ言語のみ。config内容はWindowsのWinARMコマンドラインのhelpから取得

$ cd _gccbuild
$ ../gcc-4.3.0/configure --prefix=/usr/local/arm \
--target=arm-eabi  --disable-nls --disable-shared --disable-threads \
--with-gcc --with-gnu-ld --with-gnu-as --enable-languages=c,c++ \
--enable-interwork --enable-multilib --disable-libssp --disable-libstdcxx-pch \
--with-dwarf2 --program-prefix=arm-eabi- --with-newlib \
--disable-newlib-supplied-syscalls --disable-libunwind-exceptions \
--disable-newlib-atexit-dynamic-alloc

$ make LANGUAGES=c all-gcc 
$ sudo make LANGUAGES=c install-gcc 
$ cd ..

次はNewlib

$ cd _newlib
$ ../newlib-1.17.0/configure \
--prefix=/usr/local/arm --target=arm-eabi
$ make
$ sudo make install
$ cd ..

最後に、残りのＣ＋＋も含める。

$ cd _gccbuild
$ make
$ sudo make install
$ cd ..

だいたいこんな感じ。

↑

LPC2388:USBが動かない理由†

どうやら、割り込み関係でLPC214xと互換性がないようだ。
どちらもarm7tdmiなので同じだと思っていたが・・・。
IRQハンドラーの処理が、LPC214xだと、

example/crt.s

ldr     PC, [PC,#-0xFF0]	/* see page 71 of "Insiders Guide to the Philips ARM7-Based Microcontrollers" by Trevor Martin  */
ldr     PC, FIQ_Addr

になっているが、

LPC23xxだと、

	LDR	PC, [PC, #20]	@ IRQ entry, jump to IRQ handler
	LDR     PC, [PC, #20]	@ FIQ entry, trap
	.word	Reset_Handler	@ Reset handler
	.word	Trap		@ Undefined Instruction handler
	.word	SWI_Handler	@ Software Interrupt handler
	.word	Trap		@ Prefetch Abort handler
	.word	Trap		@ Data Abort handler
	.word	IRQ_Handler	@ IRQ handler
	.word	Trap		@ FIQ handler

になっていて、

IRQ_Handler:
	SUB	LR, LR, #4		@ Adjust LR_irq and push it
	STMFD	SP!, {LR}

	MRS	LR, SPSR		@ Save SPSR need to be saved for nested interrupt
	STMFD	SP!, {R0-R3,IP,LR}	@ Push scratch/used registers and SPSR
	LDR	R0, =LPC_BASE_VIC	@ Get the ISR address pointed by VIC_VectAddr
	LDR	R0, [R0, #VIC_VectAddr]
	MSR	CPSR_c, #M_SVC		@ Enter SVC mode and enable Irq and Fiq

	STMFD	SP!, {LR}		@ Call the ISR
	MOV	LR, PC
	BX	R0
	LDMIA	SP!, {LR}

	MSR	CPSR_c, #M_IRQ | B_Irq	@ Enter IRQ mode and disable Irq
	LDMIA	SP!, {R0-R3,IP,LR}	@ Restore scratch/used registers and SPSR
	MSR	SPSR_cxsf, LR		@ Restore SPSR_irq

	LDR	LR, =LPC_BASE_VIC	@ Issue EOI command to the VIC
	STR	LR, [LR, #VIC_VectAddr]

	LDMIA	SP!, {PC}^		@ Reruen from the IRQ handler

と、なっている。

つまり、lpc214xのあっさりジャンプと上記コードは違いすぎる。

ldr     PC, [PC,#-0xFF0]	/* see page 71 of "Insiders Guide to the Philips ARM7-Based Microcontrollers" by

さらに、

.equ LPC_BASE_VIC,	0xFFFFF000
.equ VIC_VectAddr,	0xF00

なのも意味不明。

そもそも

ldr     PC, [PC,#-0xFF0]	/* see page 71 of "Insiders Guide to the Philips ARM7-Based Microcontrollers" by

って、どこに飛ぶつもり？
```
-0000_0ff0だから、ffff_f010か？ 
```
この命令が置かれている場所は0000_0018だから、ffff_f010を足すと ffff_f028(f024??)になる（？？？）
おそらくそこに原因ベクター（飛び先）が現れるようなハードになっているのだろうが、
その番地もLPC23xxだとFFFF_F000+0000_0F00=FFFF_FF00だから、どのみち辻褄は合っていない。

しかし、マニュアルを見ると、どちらの石もVICがFFFF_Fxxxあたりに出ていて、それほど違いがないようにも取れる。
なんかこういう根っこの部分はメーカー側がしっかりしたフレームワークを提供しないと困るなぁ。

で、結局・・・

LPC214xとLPC23xxで、VICのつくりは似ているように見えるが、アドレスが違うので、ソースを流用できない。
LPCUSBは、残念ながらＣソース内にVICなどのアドレスをじか書きしているのでポータビリティがない。
そもそもARMの多品種を製造しているNXPは周辺定義ヘッダーなどを正しく管理して提供すべきなのに（意図してかどうか不明だが）そうしていない。モスバーガー屋だけじゃなくってRenesasだって、ちゃんと、やってるんだぞう！

続・・・

VIC周りは直したつもり。
TIMER割り込みはちゃんと来ている。
USB割り込み許可したあたりでのハングも直したつもり

だけどUSBデバイスとしてちっとも認識しやしない。

なんかI/OピンをUSBコントロールに使っていて、またチップ間の非互換があるっぽいな。

いやいや、そんな生易しいもんじゃなかった。

LPCUSBのusbhw_lpc.c に書かれてるUSB関係のポートアドレスはLPC23xxと全く互換性がないし、全部絶対アドレスで書いてあるじゃん。
さらに、LPC23xx.hにそれ相当のポートアドレスが載っているなら許すけれど、そっちはそっちでUSBOTGポートと混ざっていて分かりにくい。

これ全部ＮＸＰが悪い。でたらめにも程がある

続き。

とりあえずUSB周りのポートアドレスをFIXしてみた。
やっと、「不明なデバイス」というメッセージが出るようになった。（今まではそれさえ出なかった）
メインループのハングはしていない。
「不明なデバイス」になる原因は不明。

↑

LPCXpresso微妙に値下がり†

http://akizukidenshi.com/catalog/c/clpc/
２８００円。
ここであえてCortex-M0を選択する理由ってあるのだろうか・・・。

↑

Apple死ねばいいのに。†

きまぐれ日記より

http://chasen.org/~taku/blog/archives/2010/04/mecabiphoneosx.html
そもそもMacOS-Xって、最初からFreeBSDじゃないのか？
iPhoneやiPadだって、カーネルはFreeBSDベースなんだろ？
だったらソース公開しろよって感じ。
いっそFreeBSDカーネルをＧＰＬにしちゃったら？

↑

思いつきで†

Mega644のピン配置

8bit Port x 4というほぼ理想的なPIN Out.

アドレスバス16bit , データバス(双方向)8bit , /RD , /WR , /CE （64k全部埋めるならCE要らない？）あと5bit余り。外部ラッチ無しだとちょっと厳しいかな。

SRAMはHM-628128LPとかなら腐るほど（といっても４０個くらいしかないけど）余っている（もちろん5V DIP品。要る人いるなら差し上げますけど）

コードエリア64Kあるので、マルチアーキテクチャエミュレータ(8080/6800/6809/SCMP/...)になれる。たぶん。
うまく作れば、内蔵SRAM 4Kのうち1KくらいをSRAMからキャッシュするように出来るかも。
起動時に内蔵FlashからSRAMにブートコードを書きこむようにすれば自力ブート出来る。

ＣＰ/Ｍエミュレータというよりむしろ、ＭＺ−８０Ｋエミュレータが欲しい。

ビデオ回路は外付けのPIC24Fか別のAVRかな。５ビットではつらいけれど。

あ、そうか、/CE のかわりに /IOREQのようなピンを１つだけ設ければ、外部バス信号を他のモジュールとの通信に24bit全開で使用できるんだっけ。

当然20MHz動作。場合によってはOverClockingもありで。

問題は・・・ＢＩＯＳ　ＲＯＭ（ＳＰ−１００２）と、ＳＰ−５０３０とかをもう紛失済みであることだ。（カセットテープなら残っているかもしれないのでサウンドブラスターで吸い出すことも考えられるが・・・）

単なる思い付きだけんね。実行するとは限らないし。誰かかわりにやって欲しいくらいだ。

はたしてAVRの20MHzに、レトロＣＰＵを何ＭＨｚ換算でエミュレート出来るのか？
ただそれだけが関心があるのであって・・・。
FPGAだと出来て当たり前なんで全くやる気がしない。AVRでやるところに意味があると思う。

↑

今日の、Apple死ねばいいのに。†

アップル、ARM買収を検討か--英報道

http://japan.cnet.com/clip/global/story/0,3800097347,20412583,00.htm
あくまでも金融街の噂だが、

アップル、ARMを一人占め。
ARmチップのライセンス料金吊り上げ開始。
性能上限を設けて、他社には高性能チップを生産させない。(Adobeへの仕打ちと同様に)

これで、他社（Android,Microsoft製うんちゃら携帯)を全部殲滅だ！

そうなると、Renesasチャンスだ！
- RXマイコンのＩＰライセンス商売開始だ。

・・・って、ならないよな。

↑

石油は採掘する時代から生産する時代へと変る。†

藻類から作られる石油はジェット燃料となり、日本から石油が世界に輸出されるようになる。

http://blog.goo.ne.jp/2005tora/e/f9d52904c89abac55615365d1275f82b
凄い。
日本も捨てたもんじゃないね。

↑

苺：STM32F103VET6基板が３１５０円†

ＤＷＭ誌付録のSTM32F103のFlash増量（４倍）版。RAMも64kB

http://strawberry-linux.com/catalog/items?code=32103
ピンヘッダーとかUSB Bコネとかのパーツも付いているのでＤＷＭ誌を買うより断然お買い得感がある。
なんといってもＳＲＡＭが多い（64K）
しかもＤＦＵが焼かれているので、JTAGケーブルを持っていなくても即使用できる気軽さ。

↑

天安門事件を役立てる方法†

● 簡単で完璧な阻止率100%のスパム対策の実装について

http://wota.jp/ac/?date=20100401

最近 .cnサイトからのアクセスが多いので(w
やってみた。
ここはdump2html.inc.phpで生成しているので、./skin/pukiwiki.skin.phpとかそれの代替のphpソース１個に埋めて、あとは再生成するだけだ。

はたして効果あるのかな？
理論上、.cn以外の全サイトにこれを埋めることで、.cnの中からは世界が消滅したように見えるはずだ。

Webサイトアクセスは遮断できるようだが、.cnからのこうげきをふせぐのはむりそうだ。

Google、パスワード管理システムのコードを盗まれていた - スラッシュドット・ジャパン

http://slashdot.jp/security/10/04/22/0228212.shtml

↑

今日も、Apple死ねばいいのに。†

オンラインでApple純正製品が購入できるのはApple StoreとAmazonのみになる模様。
AmazonはアメリカのApple Catalog ＆ Internet Resellersで登録されているが、
日本ではこの登録プログラムが無い為、日本の小売り店にはオンライン販売が許可されないとのこと。

http://temple-knights.com/archives/2010/04/apple-yodobashi-stop.html
いっそ、日本でのApple製品の販売を全部禁止しろ！ ---いや、禁止しない代わりに独禁法違反で制裁金だな。トヨタの仕返しだ！
ついでに所持も。（児ポルノかよ？）

ってゆーかあの会社の方針、なんとかならんのか？

↑

WinARM(arm-eabi-gcc)でfloatが使えない件†

Linuxでビルドしなおしたarmgccでは、ちゃんと使えている。
WinARMのほうは浮動小数点を使った瞬間にリンクエラーでこける。
なんかlibgcc.aに
```
__aeabi_dmul
```
とかもろもろのsoftfloat関数が無い。

なんでだろ？

よく分からないけれど、ARMクロスコンパイラ構築Linuxで作ったlibgcc.aをコピーすればリンクは大丈夫のようだ。
まだ動作テストまでやってないけれど、ちゃんと動くことがわかったらlibgcc.aをuploadしておこう。
普通にLinuxを使っている人なら簡単に(10分くらいで)arm-gccをビルドできるので、出来たlibgcc.aをWinARMの該当ディレクトリにコピーすれば浮動小数点も使えるようになる（はず）

参考文献。

http://mpu.seesaa.net/article/1166157.html

↑

LPC2388:USBが動かない理由†

いろいろいじくり回しすぎたので、何が原因だったのかさっぱり覚えていない。
print文を埋めてデバッグする要領で、Ｌチカを埋めて試行錯誤を繰り返すしかなかった。
JTAGがあれば簡単に原因が分かるかと言われるとそれも違うような気がする。無限ループになる箇所くらいなら分かるのだろうけれど、無限ループにはならずにUSB認識しないというだけなので、デバッガで追えない。
そりゃ、どっかでASSERTするのであれば、シリアルコンソールを見れば何が起きたかは分かるけれど。普通にスルーしてメインループは回っているので、デバッガを使っても何が悪いのかなんて分からない。
PICのときはUSBプロトコルアナライザが大いに役に立った。それはディスクリプタストリングを返すルーチンが元から腐っていた（ページアドレス決め打ちで書かれていた）のを見つけられたからだ。
今回のARMではUSBDevice側が全く微動だにしていなかったのでアナライザも役に立たない。
結局ソース書き換えてから試すまでのサイクルをどれだけ短縮できるかか勝負だった。

で、何が悪かったんだろう。いろいろあった。

crt.S（？）swi（？）その辺は弄り回しすぎて一回りした。
LPC23xx.hとかUSB周りのポートアドレスが腐っていたのが一番やられた。
USBCLKCFG ポートの設定が抜け落ちていた。
HW初期化周りにもいろいろ不文律があるようだ。自分にはさっぱり分からない。
で、とにかくLPC214xとLPC2388ではアドレスも初期化手順も違いが多くて、まともではないような気がした。
この様子だと、LPCXpresso(Cortex-M3)はもっとひどいかも。

あとでまとめよう。ARMはもう飽きた。

↑

Ｃ級出版：ＳＨ−２Ａさっそく落とし穴が†

水晶は何ＭＨｚ？

http://d.hatena.ne.jp/pcm1723/20100426/1272275049

デフォルトはキャッシュOFF？

http://d.hatena.ne.jp/pcm1723/20100430/1272616341

ほかにもありそうだ。
開発環境がＨＥＷなので、いろいろとね・・・色々。
内蔵ＳＲＡＭが１Ｍバイトとか言ってるけれど、~~殆どはフレームバッファ（データ用）としてしか使えないとか・・・~~（？コード用は６４Ｋとか書いてあったので心配だ）

んなこたあなさそうだ
高速SRAMは64kしかない。
i-cache,d-cacheは各8kB,高速SRAMはcacheしない。

付録基板は所詮ジャンク基板なのか？

↑

Ｃ級出版：ＳＨ−２Ａって、国産ロケットみたいだな。†

２枚冊も買った。

SPDIFいじりにも使えそうだし。
ほんとにSRAMが1MBも載っているんだな。

だれもが思いつくネタその１

uCLinux動かんかいな。
- 内蔵1MBではさすがに厳しいといわざるをえない、たぶん。カーネルは600kBくらいらしいけどあぷりは動かないか。外部RAMを増設できるなら良いと思う。
CP/Msh-2a
- きっと速かろう。
- ビデオ出力でコンソールが出せるといいのに。
- なんかこうフレームバッファがキャプチャを兼ねてるところといい、ＱＶＧＡなところといい、ＲＧＢ５６５なところといい、オーバレイするところといい、まるでデジカメのパーツみたい。

だれもが思いつくネタその２

CP/Mは古すぎて誰もソフト持ってないと思うので、（それにディスク入れ替えのたび＾Ｃは２１世紀には理解されないと思う）MS-DOSくらいはエミュれないかハニー！というわけでDOSエミュ。

もうひとつ、往年の名機ＰＣ９８０１エミュ。だって主記憶１Ｍバイトもあるじゃん。るねさすもＮＥＣに買収されたことだし頃合も良かろう。
- ＰＣ９８０１って６４０ｋＢしかＲＡＭがなかったんだよしかもＤ-ＲＡＭ。こっちはＳＲＡＭで１Ｍバイト。夢みたいだ。
- クロック比：元祖ＰＣ９８０１は８０８６−~~８ＭＨｚ（だっけ？？）~~いや５ＭＨｚなんだな。だから１４４対５。
- CISCとRISCの違いがあるしＳＨ−２Ａは２命令同時issueなのでたぶんこの１０倍、１４４０対５くらいの開きがあるので、ＪＩＴコンパイラなんて載せなくてチンタラエミュレーションしても１０倍速くらいになるかもしれない。

これもビデオアウトをどうするかが鍵なんだがな。難しそうだな。ＴＥＸＴ-ＶＲＡＭがないから全部グラフィックバッファに持ってかれるとメモリー無くなるもんな。どうやるかだな。
ウルトラＣとしては２冊同時購入して片方がＴＥＸＴＶＲＡＭ担当ってやつ。接続はUSB host--deviceかな？

ギャグにしかなってないや。

↑

Ｃ級出版：ＳＨ−２Ａ：†

Ｌチカ完了！＜＝今ここ

このままで終わりそうな予感。
１４４ＭＨｚＲＩＳＣ　ＣＰＵ、１ＭＢの内蔵ＳＲＡＭがＬＥＤを秒単位で点滅させる程度の仕事しかさせていない。
なんという情けなさ。

チップを見て微妙に気になったこと。

型番だけしか刻印されていない。
昔のＨ８-３０４８ＦやＨ８Ｓ−２１４４には日立マークが刻印されていたのだけど。
RENESASになってから刻印やめたのかな？

↑

CQ-FRK-SH2Aはワンチップセガサターン（性能相当）なのか？†

＼	セガサターン	CQ-FRK-SH2A
発売	1994年11月22日	2010年4月24日
メインＣＰＵ	SH-2(HD6417095)28.64MHz×２	SH-2A(SH7262)144MHz
メインメモリー	DRAM 2MB	内蔵SRAM 1MB
ＦＰＵ	なし	あり
発売当初の価格	44,800円	2,310円(雑誌込)

雑誌付録マイコンとしては破格の性能。

なんといっても外部バスにSDRAMを接続してメモリー増設が可能。（サターンは不可）
ＦＰＵ内蔵
デュアルＣＰＵではないが、１クロックに２命令実行可能。

↑

ＡＲＭ(thumb)とＳＨのアーキテクチャー上の違い（レジスタ本数など）†

どちらも３２ビット長の整数レジスタ１６本を持つ。

    ARM           SH
  +--------+   +--------+
  |   R0   |   |   R0   |
  +--------+   +--------+
  |   R1   |   |   R1   |
  +--------+   +--------+
  |   R2   |   |   R2   |
  +--------+   +--------+
  |   R3   |   |   R3   |
  +--------+   +--------+
  |   R4   |   |   R4   |
  +--------+   +--------+
  |   R5   |   |   R5   |
  +--------+   +--------+
  |   R6   |   |   R6   |
  +--------+   +--------+
  |   R7   |   |   R7   |
  +--------+   +--------+
  |   R8   |   |   R8   |
  +--------+   +--------+
  |   R9   |   |   R9   |
  +--------+   +--------+
  |   R10  |   |   R10  |
  +--------+   +--------+
  |   R11  |   |   R11  |
  +--------+   +--------+
  |   R12  |   |   R12  |
  +--------+   +--------+
  |R13(SP) |   |   R13  |
  +--------+   +--------+
  |R14(LR) |   |   R14  |
  +--------+   +--------+
  |R15(PC) |   |R15(SP) |
  +--------+   +--------+

               +--------+
               |  PR(LR)|
               +--------+
               +--------+
               |  PC    |
               +--------+

ARMは１６本の汎用レジスタ内にPC,LRを含めている
SHではPR(LR),PCは独立していて汎用レジスタ扱いではない。

Thumbではレジスタ指定フィールドが3bit(実質レジスタ８本)なので、これでよいのかも。

参考：http://www.bomber.co.jp/chaola/docs/ARM/inst_THUMB.html

↑

LPC2388:まだ動かない。†

HIDクラスデバイスを作って、64byte書いて64byte読むというのをやってみた。
１回目はＯＫなのだが、
２回目の書き込みデータが前と同じままという変な現象が起きていて
先へ進まない。

シリアルデバッグでもするかのう・・・（面倒くさい）

↑

最新の20件

2010-04

４月：ついにＬＨＣ再開3.5TeV 何が見える？†

先月のまとめ†

hidmon-2550/14kのHID転送モードをインタラプト転送に戻す。†

PIC関係ツールが（とても）分かりにくい件†

結局のところ、何をやりたいかというと・・・†

図説†

携帯：SIMロックフリー論争†

LTEというのは3Gの次の規格なのか？（3.9Gらしい）†

Appleの驕り†

ARMの難易度はPIC以上？†

そうやって、再帰問題ばかり作ってる。†

ＣＱ：STARM基板†

STARM基板について、今のところ分かっていること。†

この開発環境はDFUが全てを台無しにしている。†

hidが動かない件†

相変わらずhidが動かない件†

一応、ここまで出来た。†

PICKit3が安い†

エイヤフィヤトラヨークトル氷河の火山†

ARMの難易度はPIC以上！†

ARMクロスコンパイラ構築†

LPC2388:USBが動かない理由†

LPCXpresso微妙に値下がり†

Apple死ねばいいのに。†

思いつきで†

今日の、Apple死ねばいいのに。†

石油は採掘する時代から生産する時代へと変る。†

苺：STM32F103VET6基板が３１５０円†

天安門事件を役立てる方法†

今日も、Apple死ねばいいのに。†

WinARM(arm-eabi-gcc)でfloatが使えない件†

LPC2388:USBが動かない理由†

Ｃ級出版：ＳＨ−２Ａさっそく落とし穴が†

Ｃ級出版：ＳＨ−２Ａって、国産ロケットみたいだな。†

Ｃ級出版：ＳＨ−２Ａ：†

CQ-FRK-SH2Aはワンチップセガサターン（性能相当）なのか？†

ＡＲＭ(thumb)とＳＨのアーキテクチャー上の違い（レジスタ本数など）†

LPC2388:まだ動かない。†

ubuntu10.04がリリースされたらしい。†

４月：ついにＬＨＣ再開3.5TeV　何が見える？†