2010-10

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

１０月：



↑

先月のまとめ



今月の目標

  • OpenOCDの改造に着手。
    • 改造といってもドライバーをいじるだけ。
    • オレオレブラスターを作ってみる。
  • ライターばかり作ってて良く飽きないね〜。
    • だってほら、ライター以外に作りたいものって、無いじゃん。（がっくり）





↑

USB-Blaster（もどき）でOpenOCD

  • OpenOCDが知らん間にFTDIのd2xx経由のUSB-Blasterをサポートしていたので、 
           --enable-usb-blaster-ftd2xx
  • 勢いでやってみるテスト。

まず、USB-Blasterとは何なのか？を参照。

  • で、これがUSB-Blaster（もどき）。製作中のもの。

https://raw.github.com/iruka-/ATMEL_AVR/master/web/jpg/PIC/usb-bl2.jpg https://raw.github.com/iruka-/ATMEL_AVR/master/web/jpg/PIC/usb-bl3.jpg

  • 部品代は
    PIC18F14K50200円
    12MHz水晶50円
    3.3Vレギュレータ100円
    USB-Bコネクタ40円（最近、このデカいコネクタは、珍しいUSBコネクタと呼ばれているらしい。嘘だろ？）
    あとは金目のものは使われていない。（Ｂコネクタこそ、由緒正しいデバイス側のＵＳＢコネクタなのに）

実際のところ、まだ18F14K50用ファームが存在しないので、 下記の18F2550版の実装を使わせていただいている。


準備

  • 次、ビルドする。
$ ./configure \
       --build=i686-pc-linux-gnu \
       --host=i586-mingw32msvc \
       --enable-maintainer-mode \
       --enable-usb-blaster-ftd2xx \
       --enable-ft2232_ftd2xx \
       --with-ftd2xx-win32-zipdir=../libftd2xx-win32
$ make
  • 出来た。
  • USB-Blaster（もどき）18F2550実装に、LPC2388基板(interface付録)をJTAG接続。
  • おおお、接続ＯＫ。動いた。
  • telnetから操作する場合のレスポンスは、それほど悪くない。
  • しかし、かなり（転送は）遅い。
  • USB-Blasterをサポートしている部分のソースを見たら、あんまり変わってなかった。




↑

OpenOCD研究: 

src/jtag/drivers/minidriver_imp.h
  • ドライバーのフレームワークはこのヘッダーに書かれた関数をインプリメント することで実装されるようだ。


src/jtag/drivers/driver.c
  • driver.cは、minidriver_imp.hの実装部だ。
src/jtag/commands.h
src/jtag/commands.c
  • JTAGのコマンドをコマンドキューにためて、それをドライバーに渡して実行してもらう形式になっている。


  • で、各JTAGケーブルごとに書かれたドライバー 
    src/jtag/drivers/*.c
  • は、そのコマンドキューを解釈実行することが出来ればよい。


  • さらに、解釈実行が面倒くさい場合は、ミニドライバーのようなものに委譲してしまうこともできる。 
    src/jtag/drivers/bitbang.c
src/jtag/drivers/bitbang.h
  • これは、コマンド解釈部を書かなくても、 
    struct bitbang_interface {
   /* low level callbacks (for bitbang)
    */
   int (*read)(void);
   void (*write)(int tck, int tms, int tdi);
   void (*reset)(int trst, int srst);
   void (*blink)(int on);
};
  • だけ実装すればＯＫだ。これを利用しているハードは 
    at91rm9200.c
ep93xx.c
parport.c
usb_blaster.c
  • 気になったのがread,writeの単位で、たぶん１tickというか１サンプル単位のデータ(int tckとなっているけれどたぶん1bitだと思う）でIN/OUTを行っているようなので、これをUSBの１パケットに変換して送ると、１秒にたったの１０００回(最速でも１０００ビット分）しか、bitbang出来ない。
  • だからといって、適当バッファリングを行うわけにもいかないというインターフェースだ。(バッファフラッシュのタイミングが分からない)
  • byte-blasterのようなＰＣのパラレルポートを叩く処理に接続するのであれば、このインターフェースでも充分な速度が出るのかもしれない。



  • もうひとつのミニドライバーは 
    src/jtag/drivers/bitq.c
src/jtag/drivers/bitq.h
  • 用意されているフレームワークは 
    struct bitq_interface {
   // function to enqueueing low level IO requests
   int (*out)(int tms, int tdi, int tdo_req);
   int (*flush)(void);

   int (*sleep)(unsigned long us);
   int (*reset)(int trst, int srst);

   /* delayed read of requested TDO data,
    * the input shall be checked after call to any enqueuing function
    */
   int (*in_rdy)(void);
   int (*in)(void);
};
  • となっていて、これを利用するハードは 
    presto.c
  • のみ。
  • 速度的にbitbangと変わらないような気がする。


  • bitbang,bitqのような簡易フレームワークを使用しないタイプのドライバーは、すべて自前で JTAGコマンドキューを解釈実行しなければならない。 
    src/jtag/commands.h
src/jtag/commands.c
    を参照するとよい。




↑

Android-x86 v1.6をVMWareで動かす。

  • そう。今頃。
  • v2.2 froyoのisoファイルが出回っているが、遅くてだめだったのでv1.6に戻る。

read more : Android




↑

Toshiba AC100(dynabook AZ)にUbuntuをインストールする方法

ひとりぶろぐ

元ネタ

東芝クラウドブックの仕様

  • これも残念な製品のひとつ、なのか。(NetWalkerのようなスキマ商品)

デザインや品質は決して悪くないので、せめて、

  • Androidだけでなく、ubuntuもサポートしてほしい。(NetWalkerはubuntuだ)
  • 電池の持ちは、もう一声欲しい（１０時間くらいは）
  • 軽さも、もう一声欲しい。（ネットブックと差別化するために）
  • CPUは充分なスペックだが、RAMは1G欲しい。
  • 電池の持ちをよくするための手段として、サスペンド以外に、ハイバネーションはないのか？（不明）---今時のWindows7はサスペンドして一定時間が経つとハイバネーションを行うようだ。


今のままだと、半値くらいにならないと買う気しない。



↑

OpenOCD : ドライバーの分離実装を考えてみる。

  • OpenOCDのドライバーはJTAGケーブルごとにまちまちで、特にbitbang.cを利用する実装だと低速になる問題がある。
  • bitbangというのはFT232のbitbangモードのことではなく、ＰＣのパラレルポート（プリンタポート）直叩きモードのことだ。
  • 昔のパソコンＯＳならいざしらず、現在のＰＣでリアルタイムに叩いて即時に反応が返ってくるようなポートはもはや存在しない。（仮想化されてしまっているのでオーバヘッドが大きい）
  • ましてや、bitbangで叩く先がUSBケーブルの向こう側になってしまう(usb_blaster.cがそうだ）ともっと悲惨で、１秒回にたったの１０００回しかポーリングできなくなってしまう。
  • ということは、なんらかのバッファリングと、JTAGケーブルの先にあるマイコン側への処理の委譲が必要になる。


では、OpenOCDとJTAGケーブルのドライバーを分離できないか考えてみることにする。

  • 現状のOpenOCDではドライバーのダイナミックリンクをサポートしていないので、とりあえず適当なＤＬＬをつくってそっちに処理を全部任せてみる。

メリットとして、

  • OpenOCDのビルドは最初に１回やっておくだけで済む。
  • DLLの差し替えは比較的簡単に出来る。（ファイルを差し替えるだけ）


  • 実は、ATtiny2313にUSBなJTAGケーブルを実装できないか考えているところ。
  • 現状のHIDaspxライターのファームウェアからSPIのインライン展開コードを取り除き、代わりにJTAGの信号処理プロトコルを入れることになる。
  • デバイスクラスはHIDで、転送するデータは

コマンドパケットの内容（ベンダーリクエスト）

   0      1      2      3      4      5      6      7
+------+------+---------------------------+-------------+
| req  | cmd  | 送信データ（最大４バイト）|   wlength   |
+------+------+---------------------------+-------------+
  • cmd内にはJTAG送信データの有効ビット数を(1〜32の範囲で)入れておく。

後続する受信パケット

   0      1      2      3      4      5      6      7
+---------------------------+---------------------------+
|受信データ（最大４バイト） |     空き                  |
+---------------------------+---------------------------+
  • １回のコントロールパケットでわずか４バイト（３２ビット）までしか処理できないが、それでも、１ビットしか処理できないUSB-Blasterよりは３２倍速いものが作れるはずだ。
  • ATtiny2313は3.3V駆動する必要がある。(ARM側と同じ電圧にするため)
  • PIC18Fに実装する場合は、同じくHIDであるけれどインタラプト転送で行う（エンドポイントを独立させる）ようにして、 送受信するデータは１パケットで６４バイトまでとなる。
  • もちろんPIC18FではHIDにこだわる必要はなく、CDCかGenericなデバイスにしてもっと長いストリーム単位にすることで 高速化は出来るはず。



↑

LPC2388 : armon/armboot用のサンプルアプリケーションを追加

  • とりあえず、vcom（仮想COM）サンプルのビルドが通るようにしてみた。


read more : NXP用armon/armboot



↑

OpenOCD : ドライバーの分離実装:やや苦戦中

  • といっても全然たいした問題じゃないんだけど。
  • 実はWindowsでDLLの呼び出し方を知らないんで、いろいろ調べ中
  • Win32API使って良いなら、 
       hDLL = LoadLibrary("mydll.dll");
   myfunc = GetProcAddress(hDLL, "myfunc");
   mufunc();
  • という感じなんだろうか？？？
  • そうじゃなれれば 
    __declspec(dllimport) int __stdcall myfunc();
    みたいなヘッダーを用意して、 
    myfunc();
  • でいいのかな？
  • 後者のやりかただと、DLLのファイル名を指定するところがどこにもなくて、
  • DLLを作る時点で
dll:
      dllwrap -mwindows -mno-cygwin --enable-stdcall-fixup \
             --add-stdcall-alias -o hidmon.dll $(OBJS) -lsetupapi -Wl,--out-implib,hidmon.lib
  • みたいなことをやっていた。（遠い目）
  • dllwrapについて調べればいいのか。
  • 問題は、openocdのソースツリーのMakefileの LIBS += の項目追加方法だな。
  • Makefileを手で書き換えてもconfigureしたときに上書きされるので、automakeについても勉強しないといけない。

あー面倒面倒・・。


ところで、話をARMに限定すればUSB-JTAGアダプターなんて、ARMチップですぐ作れそうな気がするし、実際Versaloon がそうなんだけど、どうして皆んな作ろうとしないんだろう。

  • 推測１）アマチュアがぼこぼこそんなものを作られると純正アダプター(ST-LinkとかLPC-Link)が売れなくなる
  • 推測２）ARMチップでARMライター(デバッガー)を作るとなると、必ず鶏と卵問題が発生するので、生物がそう簡単に無から発生しない理由によって禁則事項になっている。
    • つまりだ、ARMチップでARMライターを作るには、まず、別のJTAGアダプター(FT2232の奴とか)を入手する必要がある。
    • で、それを入手した途端、ARMライターを作る必要が無くなるので、誰も手がけようとしない。
  • 推測３）ライター作るの面倒くさい。
    • これは確かだ。AVRライターやPICライターと違って、ARMのJTAGは面倒くさい。OpenOCDをベースにでもしないとやってられない。
  • 推測４）ライターが安く入手できるので作る必要が無い。
    • 半分当たっている。
    • ST-Link(2700円くらい)とかLPCXpresso(ターゲット基板込みで2800円とか)ふざけている。
    • しかし、両方とも自社のチップしか書けないとか、デバッガーと開発ツールにコードサイズ制限が掛かっていて、自由に開発できないし、当然OpenOCDでは使えない代物。



↑

OpenOCD : オレオレブラスターをでっちあげてみた。

  • DLLの呼び出し方法は、前者の方法を採った。 
    Open On-Chip Debugger 0.5.0-dev (2010-10-04-20:01)
Licensed under GNU GPL v2
For bug reports, read
       http://openocd.berlios.de/doc/doxygen/bugs.html
if load
Warn : Adapter driver 'hid_blaster' did not declare which transports it allows; assuming legacy
Info : only one transport option; autoselect 'jtag'
1000 kHz
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x000000ff (mfg: 0x07f, part: 0x0000, ver: 0x0)
Warn : JTAG tap: stm32.cpu       UNEXPECTED: 0x000000ff (mfg: 0x07f, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32.cpu  expected 1 of 1: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x000000ff (mfg: 0x07f, part: 0x0000, ver: 0x0)
Warn : JTAG tap: stm32.bs       UNEXPECTED: 0x000000ff (mfg: 0x07f, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 1 of 5: 0x06412041 (mfg: 0x020, part: 0x6412, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 2 of 5: 0x06410041 (mfg: 0x020, part: 0x6410, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 3 of 5: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Error: JTAG tap: stm32.bs  expected 4 of 5: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 5 of 5: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Error: stm32.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0 in JTAG-DP transaction
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
Polling target failed, GDB will be halted. Polling again in 700ms
Polling target failed, GDB will be halted. Polling again in 1500ms
Polling target failed, GDB will be halted. Polling again in 3100ms
Polling target failed, GDB will be halted. Polling again in 6300ms
バッチ ジョブを終了しますか (Y/N)? y

まず、

  • configureは --enable-dummy だけ指定して、FTDIやlibusb不要のopenocd.exeを作ってみた。
  • それだけだと、何にも出来ないopenocd.exeになるので、 
    src/jtag/adapter.c
  • にて、jtag_interfaces[]を参照している部分（２箇所）の参照直前に、DLLを読み込む初期化関数を呼び出してみた。
  • jtag_interfaces[0]にはdummyのstructアドレスしか入っていないので、DLLが読み込まれたら、DLL側のstructのアドレス を上書きするようにしてみた。（かなり野蛮な改造）
  • そうすると、interfaceの名前もDLL側が供給できるようになる。
  • DLLが存在しない場合はロードに失敗するので、jtag_interfaces[0]の書き換えは実行されずに、dummyドライバーが残る。
  • で、DLL側のjtag_interface structは適当に用意してみたものの、処理関数は全部ダミーなので、上記の結果となる。


  • 以上、かなり適当な方法でドライバー部分を独立して開発できるようにしてみた。
  • 本来なら、openocd.exeと同じディレクトリに存在するDLLを全部スキャンして、登録するようにすべきだし、 jtag_interfaces[0]を書き換えるのではなく、配列要素を追加するようにしたほうが良いだろう。
  • しかし、ドライバーを分離してはみたものの、ドライバー実装のために、openocd側ヘッダーをいろいろ参照しなければならないという欠点に気づいた。
  • 気づくの遅い。
  • けど、Linuxを使わずに、<windows.h> なオレオレ環境上でドライバー開発できるのは便利だ。
  • もちろん、LinuxにはLoadLibrary()など無いし、<windows.h>をインクルードしてはいけない。
  • Windows上でしか動かないが、それはそれで仕方が無いかな。

ここまで、やっつけてみたら、OpenOCDのやる気無いUSB-Blaster対応ドライバーと同程度のものをATtiny2313で作るのは ２，３日もあれば出来る気がしてきた。（それはほとんど実用性がないけれど）

  • パラレルポート叩きの bitbang.c 組み込んで、(*read)()と(*write)()を実装するだけなので、簡単なはずだ。
  • その状態でとりあえず動くようにしておいて、組み込んだbitbang.cに、詳細なログを吐くデバッグコードを仕込んで、AVRでの最適実装を探ることになると思う。



↑

OpenOCD : オレオレブラスターの続き。

ここまで出来た。

  • OpenOCDソースツリーの、src/jtag/drivers/bitbang.c と dummy.c それに必要なヘッダーのみをいただきストリート。（ぱくり）
  • Windows上のMinGWでビルドできるオレオレMakefileでビルドできるようにしてDLL作成可能にした。
  • もちろん上のLinuxでビルドしたOpenOCD.exeから読み込まれて実行できる。

つぎに、

  • pic18spxのpicwriterソースツリーをぱくり。PIC18F2550に実装した、なんちゃってBitBangのソースとともにバインドしてDLL になるようにした。
  • とりあえず全部ビルドが通るようになった。
  • openocdから、 
    interface hid_blaster
  • とすると、DLL側のdummy.cが反応して、初期化が行なわれ、PIC18F2550に接続出来るところまで出来た。
  • JTAG接続まで、あと一息なんだけど、
  • まだハードウェアを作っていない。（PIC,ARM単独の基板はある。JTAGケーブルとピンヘッダーがない。）

ここで一休み。

ソースは、まだUPしない。



↑

OpenOCD : またまた挫折か？

  • ハードウェアは作った。（JTAGケーブルの配線をしただけ）
  • ソフトも書いた。
  • しかし動作しない。
  • 調べてみたところ、driver(bigtang.c)に渡すjtag_command_queが、どうやらグローバル変数渡しに なっていて、openocd本体とDLLで共有しなければならないかもしれないということが分かった。
  • このままだと大幅な改造が必要。

だめじゃんOCD



↑

OpenOCD : なんとなく、うまくいっているかも。

  • しめしめ。
  • 結局、DLL読み込み時に、グローバル変数jtag_command_queのアドレスをDLLに渡して、 DLL側はそのアドレスからqueを取得してもらうようにした。（投げ槍的？）
  • 本当はドライバーのexecute_que(void)関数に引数を追加すべきなんだが・・・
C:\>openocd.exe -f blaster.cfg -f stm32.cfg

Open On-Chip Debugger 0.5.0-dev (2010-10-04-20:01)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
if load
Warn : Adapter driver 'hid_blaster' did not declare which transports it allows;
assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
1000 kHz
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
=*= dummy_init(void)
TARGET DEV_ID=25 VER=1.1
Info : clock speed 1000 kHz
=*=bitbang_execute_queue(cmd=4) JTAG_RESET
Debug: 1 0 hidblast.c:167 dummy_reset(): reset to: RESET
=*=bitbang_execute_queue(cmd=7) JTAG_STABLECLOCKS
=*=bitbang_execute_queue(cmd=7) JTAG_STABLECLOCKS
=*=bitbang_execute_queue(cmd=2) JTAG_TLR_RESET
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x3 size=0x280)
tms:0000000000000000000000000000000000000000000000000000000000000000000000000000...
tdi:1111111100000000000000000000000011111111000000000000000000000000111111110000...
tdo:1111111111111111111111111111111111111111111111111111111111111111111111111111...
=*=bitbang_execute_queue(cmd=2) JTAG_TLR_RESET
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x3 size=0xb)
tms:00000000001
tdi:11111111111
tdo:11111111111
Error: stm32.cpu: IR capture error; saw 0x0f not 0x01
=*=bitbang_execute_queue(cmd=2) JTAG_TLR_RESET
Warn : Bypassing JTAG setup events due to errors
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x2 size=0x9)
tms:000000001
tdi:010111111
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x2 size=0x24)
tms:000000000000000000000000000000000001
tdi:110000000000000000000000000000000000
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x3 size=0x24)
tms:000000000000000000000000000000000001
tdi:111000000000000000000000000000000000
tdo:111111111111111111111111111111111111
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x2 size=0x24)
tms:000000000000000000000000000000000001
tdi:010000001000000000000000000000000000
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x2 size=0x24)
tms:000000000000000000000000000000000001
tdi:110000000000000000000000000000000000
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x3 size=0x24)
tms:000000000000000000000000000000000001
tdi:111000000000000000000000000000000000
tdo:111111111111111111111111111111111111
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x2 size=0x24)
tms:000000000000000000000000000000000001
tdi:010000000000000000000000000000010100
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x2 size=0x24)
tms:000000000000000000000000000000000001
tdi:110000000000000000000000000000000000
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x3 size=0x24)
tms:000000000000000000000000000000000001
tdi:111000000000000000000000000000000000
tdo:111111111111111111111111111111111111
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x2 size=0x24)
tms:000000000000000000000000000000000001
tdi:110000000000000000000000000000000000
=*=bitbang_execute_queue(cmd=1) JTAG_SCAN
=*=bitbang_scan(type=0x3 size=0x24)
tms:000000000000000000000000000000000001
tdi:111000000000000000000000000000000000
tdo:111111111111111111111111111111111111
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
Polling target failed, GDB will be halted. Polling again in 700ms
Polling target failed, GDB will be halted. Polling again in 1500ms
Polling target failed, GDB will be halted. Polling again in 3100ms
Polling target failed, GDB will be halted. Polling again in 6300ms
=*= dummy_quit(void)
  • これは、実際にPIC18spxのファームのポートを叩いている。（ので、240bitのJTAG_SCANに数秒掛かっている）
  • PIC18spx(PIC18F2550)の先には何も繋いでいない。



↑

v-usb本家 : vusb-20100715/example

  • AVRマイコンによる、ソフトウェアUSB実装。
  • 昔と比べると、だいぶ整備されている。(exampleディレクトリが追加されている)
  • example/hid-data/commandlineにあるhiddata.cはusbhidGetReport()とusbhidSetReport()が実装されていて、Linuxと同様に使えるようになっている。
  • commandlineツールはWindowsビルドとLinux/MacOSビルドの両方が出来るようになっている。



↑

OpenOCD : オレオレブラスターの第一歩が、動いた。

  • Linuxでクロスビルドした、素の(dummyドライバーのみしか内蔵していない)openocd.exeに、
  • pic18spx（PIC18F14K50）そのままのファームウェアをドライブするDLLを接続して、
  • CQ付録のLPC2388にJTAG接続が成功した。 
    C:\>openocd.exe -f blaster.cfg -f lpc2378.cfg
Open On-Chip Debugger 0.5.0-dev (2010-10-04-20:01)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
if load
Warn : Adapter driver 'hid_blaster' did not declare which transports it allows; assuming legacy JTAG-
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
500 kHz
=*= dummy_init(void)
TARGET DEV_ID=14 VER=1.1
Info : clock speed 500 kHz
Debug: 1 0 hidblast.c:175 dummy_reset(): reset to: RESET
Info : JTAG tap: lpc2378.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 7
Error: EmbeddedICE v7 handling might be broken
Info : lpc2378.cpu: hardware has 2 breakpoint/watchpoint units
Info : accepting 'telnet' connection from 4444
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 lpc2378.cpu            Y     0x4f1f0f0f 0x4f1f0f0f     4 0x01  0x0f
requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
background polling: on
TAP: lpc2378.cpu (enabled)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
===== ARM registers
(0) r0 (/32): 0xFFFFFFFF (dirty)
(1) r1 (/32): 0xFFFFFFFF (dirty)
(2) r2 (/32): 0xFFFFFFFF (dirty)
(3) r3 (/32): 0xFFFFFFFF (dirty)
(4) r4 (/32): 0xFFFFFFFF (dirty)
(5) r5 (/32): 0xFFFFFFFF (dirty)
(6) r6 (/32): 0xFFFFFFFF (dirty)
(7) r7 (/32): 0xFFFFFFFF (dirty)
(8) r8 (/32): 0xFFFFFFFF (dirty)
(9) r9 (/32): 0xFFFFFFFF (dirty)
(10) r10 (/32): 0xFFFFFFFF (dirty)
(11) r11 (/32): 0xFFFFFFFF (dirty)
(12) r12 (/32): 0xFFFFFFFF (dirty)
(13) sp_usr (/32)
(14) lr_usr (/32)
(15) pc (/32): 0x00000000 (dirty)
(16) r8_fiq (/32)
(17) r9_fiq (/32)
(18) r10_fiq (/32)
(19) r11_fiq (/32)
(20) r12_fiq (/32)
(21) sp_fiq (/32)
(22) lr_fiq (/32)
(23) sp_irq (/32)
(24) lr_irq (/32)
(25) sp_svc (/32): 0xFFFFFFFF (dirty)
(26) lr_svc (/32): 0xFFFFFFFF (dirty)
(27) sp_abt (/32)
(28) lr_abt (/32)
(29) sp_und (/32)
(30) lr_und (/32)
(31) cpsr (/32): 0x000000D3 (dirty)
(32) spsr_fiq (/32)
(33) spsr_irq (/32)
(34) spsr_svc (/32)
(35) spsr_abt (/32)
(36) spsr_und (/32)
===== EmbeddedICE registers
(37) debug_ctrl (/6): 0x05
(38) debug_status (/5)
(39) comms_ctrl (/6)
(40) comms_data (/32)
(41) watch_0_addr_value (/32)
(42) watch_0_addr_mask (/32)
(43) watch_0_data_value (/32)
(44) watch_0_data_mask (/32)
(45) watch_0_control_value (/9)
(46) watch_0_control_mask (/8)
(47) watch_1_addr_value (/32)
(48) watch_1_addr_mask (/32)
(49) watch_1_data_value (/32)
(50) watch_1_data_mask (/32)
(51) watch_1_control_value (/9)
(52) watch_1_control_mask (/8)
  • まだ、bitbangモードのままなので、遅い。(USB-Blasterと同程度。実用にはならない。)
  • やや不安定。

read more : pic18blaster



↑

OpenOCD : STM32への書き込みに成功! 

Open On-Chip Debugger
> scan_chain
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 stm32.cpu              Y     0x3ba00477 0x3ba00477     4 0x01  0x0f
 1 stm32.bs               Y     0x16410041 0x06412041     5 0x01  0x03
                                           0x06410041
                                           0x06410041
                                           0x06410041
                                           0x06410041
> reset halt
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000120 msp: 0x20005000
> flash write_image erase main-0000.hex
auto erase enabled
device id = 0x20036410
flash size = 64kbytes
wrote 8192 bytes from file main-0000.hex in 27.562500s (0.290 KiB/s)
>
  • 遅っ！
  • 遅い理由は、jtag_command_queueのコマンドパケットが0x24(36bit)しか長さがないためらしい。
  • 書き込むmain-0000.hexのファームサイズは約８ｋＢ。書き込みに３０秒掛かる。
  • 毎秒２９０バイトしか送れない。
  • １回のjtag_command_queueは36bit長であり、TCKを0->1 にする都合上、BitBangの回数（パラレルポートにたとえるなら、ポートを叩く回数）は36x2=72bitある。
  • PICに実装したbitbangは１回のUSBパケットに48bitしか乗せられないので２回(最速でも2mS)の転送を要する。
  • 要約すると、どんなに速くても2mSに４バイトのファームしか書けないのだ。
  • 秒あたりに換算すると、２ｋＢ。
  • 実際その１/７程度しか出ていないけれど。

まるでHIDaspx並の遅さ。



↑

OpenOCD : 次はATtiny2313でOpenOCD

  • 昔のtiny2313実験基板を掘り出してJTAGハードウェアを用意した。
  • ST-Link(のJTAG書き込み端子)と互換のJTAGケーブルでSTM8S-DのSTM32側に接続するようにした。
  • HIDspxファームを元にしてファームウェアのフレームワークを用意した。

問題は、プロトコルをどうするかという点。

  • Low SpeedのUSBではControl転送しか使えない。
  • スループットを上げるためには、Control転送のHID SetReportのサイズを32byte〜128byte程度に大きく取る必要がある。
  • しかし、tiny2313にはRAMが全部で128byteしかなく、HIDaspx実装では38byteのバッファを確保するのがやっとだ。（しかも送受で共用）
  • なので、JTAGの双方向読み書きでは8byteまでのパケットしか扱えないだろう。(送受で独立バッファがおそらく必要だし、返答用には全データを保持しないとならないから)
  • JTAG書き込みだけならReportサイズを128byteまで伸ばすことは可能。(実際は8byteごとに処理をして(捨てて)いかないといけない)
  • しかし、LowSpeedのControl転送は、どうあがいても１フレーム(1mS)に8byte、秒間8kBが上限になってしまう。
  • 性能目標としては、書き込みのみのスループットで4kB/秒、読み書きだと1kB/秒というところか。
  • BitBangで帯域を食われると非常にもったいないので、JTAGビットストリーム(TDIのビットが最密に詰まったストリーム) でのやりとりになる。書き込みのみならTDOは無視。TCKは010101と交互にしか変わらないのでUSBでは伝送しない。TMSが変化する場合は一旦ストリームを閉じて、TMS変更コマンドを挿入するようにする。
  • JTAG送受信 
       0      1      2      3      4      5      6      7
+------+------+---------------------------+-------------+
| req  | cmd  | 送信データ（最大４バイト）|   wlength   |
+------+------+---------------------------+-------------+
  • cmd内にはJTAG送信データの有効ビット数を(1〜32の範囲で)入れておく。
  • 後続する受信パケット 
       0      1      2      3      4      5      6      7
+---------------------------+---------------------------+
|受信データ（最大４バイト） |     空き                  |
+---------------------------+---------------------------+
  • JTAG送信のみ 
       0      1      2      3      4      5      6      7
+------+------+---------------------------+-------------+
| req  | cmd  |     使用せず              |   wlength   |
+------+------+---------------------------+-------------+
  • cmd内にはJTAG送信データの有効ビット数を(1〜32の範囲で)入れておく。
  • 後続する送信パケット(8byte〜128byte) 
       0      1      2      3      4      5      6      7
+------+--------------------+---------------------------+
| cmd  |  JTAGストリーム(56bitまで)                     |
+------+--------------------+---------------------------+
      ・・・
+------+--------------------+---------------------------+
| cmd  |  JTAGストリーム(56bitまで)                     |
+------+--------------------+---------------------------+
  • cmdはストリームのビット数(6bit)とTMSの初期値(1bit),TMSの最終値(1bit)をパックする。
  • v-usbで処理する都合上、後続する送信パケットは８バイト単位に細分化され、TMSが変化する場合は８バイトのうちでも、変化する位置までしか使用しない。



↑

OpenOCD : 次はATtiny2313でOpenOCD : その２

  • openocd側のATtiny2313対応フレームワークも用意した。
  • 試しに現状のHIDaspxファームウェアを最小構成にしてみた。
  • こんな感じ。 
    avr-objcopy -j .text -j .data -O ihex main-12.elf main-12.hex
avr-size --mcu=attiny2313 main-12.elf
  text    data     bss     dec     hex filename
  1816       2      83    1901     76d main-12.elf
  • 全然余裕じゃん。
  • コマンドを２つ追加して、TDIビットの詰まったパケット(最大長38byte程度)を処理するようにする。
  • 読み書きを要する場合はTDOビットの詰まったパケットを返却する。
  • 返却パケットは受け取ったバッファを再利用することでメモリー使用量を増やさずに実装出来る気がする。
  • HIDaspx(AVRライター機能)と相乗りする都合上、受け取りパケットは38byte程度を全部受信した後、JTAG書き込みを実行するようになるしかない。
  • HIDaspx(AVRライター機能)を捨てる場合は、8byte受け取るたびにJTAG書き込みを実行することでインターリーブな高速化が可能。ただしパケット構造が8byte単位に依存してしまう。
  • ファーム圧縮の差分はこんな感じになっている。(main.c)
189,195d188
< /* ------------------------------------------------------------------------- */
< /* -----------------------------  JTAG          ---------------------------- */
< /* ------------------------------------------------------------------------- */
< 
< #if	INCLUDE_JTAG_CMD
< void jtag_command()
< {
197,198d189
< }
< #endif
221d211
< #if	0
231a222,234
> #else
> 		uchar CR0=(1<<USIWM0)|(1<<USICS1)|(1<<USITC);
> 		USICR=CR0;
> 		uchar CR1=(1<<USIWM0)|(1<<USICS1)|(1<<USITC)|(1<<USICLK);
> 		//↑これは1clkなので↓直後に nop必要.
> 					asm("nop");	USICR=CR1;	DLY_2clk();
> 		USICR=CR0;	DLY_2clk();	USICR=CR1;	DLY_2clk();
> 		USICR=CR0;	DLY_2clk();	USICR=CR1;	DLY_2clk();
> 		USICR=CR0;	DLY_2clk();	USICR=CR1;	DLY_2clk();
> 		USICR=CR0;	DLY_2clk();	USICR=CR1;	DLY_2clk();
> 		USICR=CR0;	DLY_2clk();	USICR=CR1;	DLY_2clk();
> 		USICR=CR0;	DLY_2clk();	USICR=CR1;	DLY_2clk();
> 		USICR=CR0;	DLY_2clk();	USICR=CR1;//DLY_2clk(); :else のrjmpで代用.
237,239c240
< 	}else
< #endif
< 	{
---
> 	}else{
242c243
< 			while(d > 2) {		// 1+1: cpi,breq
---
> 			while(d != 2) {		// 1+1: cpi,breq
340,346d340
< 
< #if	INCLUDE_JTAG_CMD
< 	if ( cmd == HIDASP_JTAG_WRITE) { // JTAG
< 		jtag_command();
< 	} else
< #endif
<



↑

OpenOCD : 次はATtiny2313でOpenOCD : その３

  • おおむねJTAG用のファームウェアは書いてしまった。
  • まだFlashは余っている。
  • 動作確認するためには、OpenOCD用のDLLを書かないといけない。（まだ書いていない）
  • たぶん動くと思う。
    • 秒間２Ｋの転送で実用になるかどうかは別だが、ARM用ライターが無いときは有用だと思う。



↑

CPUを設計するべからず


  • 新規にアーキテクチャ設計するのは無謀というものだ。なぜかというと、CPUコア以外にバスやら周辺やらコンパイラやらbinutilsなど、ありとあらゆるものを用意しないといけないからだ。
  • エコサイクル的には、現存するCPUのサブセットか改良（変形）程度にとどめて、現存する開発環境をちょっと改造するだけで使えるのがいいかと。
  • サブセット化すればFPGAの占有面積を節約できるし、特殊用途向けの拡張だってそれなりの効果はあると思う。
  • しかし、そうするといろいろな特許部分があるので、商売には出来ない罠。
  • 個人的には、現行のARM/Thumbを少し変形してみたい気分もある。
  • 32bit即値のロードと32bitアブソリュートアドレスのアクセスを命令コードに含めると、現在の２命令分割とかPC相対の32bit定数フェッチとかが要らなくなる。
  • 但し、命令コードが可変長になってしまうのでどちらが有利なのかはすぐには分からない。少なくともキャッシュラインが64bitまとめてフェッチできなければ無意味になる。
  • そうやってちょっと最適化したところで、やっとx86と同等になるだけの効果しかないのかもしれない。

で、現行のARM/Thumbにdalvik VM向けのサポート機構なんてあったら便利なんじゃないだろうか。

  • 昔、携帯電話でJavaが流行ったときのARM/Jazelle拡張みたいな風に。
  • 頻繁に使用される中間コードはそのまま実行して、そうでない複雑なコードは例外ハンドラーに飛ばせるようなやつ。
  • JITコンパイラとどっちが有利なんだろう。



↑

OpenOCD : 次はATtiny2313でOpenOCD : その４

  • まるで、悪い冗談みたいだ。
  • ATtiny2313を使って、ARMのflash書き込みに成功した

read more : hid_blaster


  • 死ぬほど遅い理由は BitBang.c（パラレルポート直叩きドライバー）のプリンタポートがそのままUSBの先 にあるAttiny2313のPB4〜PB7に移動しただけという手抜き実装だから。
  • 死ぬほど遅いんだけれど、PICより安定している何故？(PIC18F14K50固有の不安定要素をまだ引きずっているようだ。PICはUSBパケットの処理が間に合わないときinterruptパケットを捨てる癖があるらしく、そこでハンドシェイクが死ぬことがある問題)
  • これから、JTAG専用のコマンドを拡充する予定。



↑

OpenOCD : 次はATtiny2313でOpenOCD : その５

  • 専用コマンドが使えるようになった。
  • 高速化してみた。
  • しかし、それほど速くなっていない。
  • 理由は、JTAG_SCAN（４バイトのFLASH書き込み）の合間にJTAG_RUNTESTが走るので、せっかくの高速化が台無し。
  • RUNTESTはpath_move()を伴うようだが、runtestもpath_moveも専用パケットで処理できない。
  • 接続は非常に安定している。書き込みに失敗することはない。
  • ただし遅い。

今のところ8kB書き込みに12秒。(USB2.0HUBを入れた状態)

  • それでもUBS-Blasterよりは速い（はず)

read more : hid_blaster


↑

ログ 

Open On-Chip Debugger
> scan_chain
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 stm32.cpu              Y     0x3ba00477 0x3ba00477     4 0x01  0x0f
 1 stm32.bs               Y     0x16410041 0x06412041     5 0x01  0x03
                                           0x06410041
                                           0x06410041
                                           0x06410041
                                           0x06410041
> reset halt
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000120 msp: 0x20005000
> reg
===== arm v7m registers
(0) r0 (/32): 0x00000000
(1) r1 (/32): 0x2000032C
(2) r2 (/32): 0x40005C40
(3) r3 (/32): 0x00000000
(4) r4 (/32): 0xFFFF3F86
(5) r5 (/32): 0xFEFFEFFC
(6) r6 (/32): 0x62CC05DD
(7) r7 (/32): 0x7974BB6F
(8) r8 (/32): 0xFFFF7FDF
(9) r9 (/32): 0xF7FADDFC
(10) r10 (/32): 0xB2586ED2
(11) r11 (/32): 0x993AE28E
(12) r12 (/32): 0x00000000
(13) sp (/32): 0x20005000
(14) lr (/32): 0xFFFFFFFF
(15) pc (/32): 0x08000120
(16) xPSR (/32): 0x01000000
(17) msp (/32): 0x20005000
(18) psp (/32): 0xA6076F68
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x00
===== cortex-m3 dwt registers
(23) dwt_ctrl (/32)
(24) dwt_cyccnt (/32)
(25) dwt_0_comp (/32)
(26) dwt_0_mask (/4)
(27) dwt_0_function (/32)
(28) dwt_1_comp (/32)
(29) dwt_1_mask (/4)
(30) dwt_1_function (/32)
(31) dwt_2_comp (/32)
(32) dwt_2_mask (/4)
(33) dwt_2_function (/32)
(34) dwt_3_comp (/32)
(35) dwt_3_mask (/4)
(36) dwt_3_function (/32)
> flash write_image erase main-0000.hex
auto erase enabled
device id = 0x20016410
flash size = 128kbytes
wrote 8192 bytes from file main-0000.hex in 12.484375s (0.641 KiB/s)



↑

OpenOCD : 次はATtiny2313でOpenOCD : 高速化完了！

今のところ8kB書き込みに4.8秒。(USB2.0HUBを入れた状態)

  • BitBang,JTAGなどいずれのパケットも出来る限りバッファに溜めてからUSB経由で送るようにしてみた。
  • 接続は非常に安定している。書き込みに失敗することはない。
  • JTAG_SCAN（４バイトのFLASH書き込み）の合間にJTAG_RUNTESTが走るので、せっかくの高速化が台無しだが、それでもだいぶ速くなった。
  • RUNTESTを減らしたり、FLASH書き込み中は抑止できるようにすればあと２倍くらいは速くなる。
  • そのためにはOpenOCDの内部をもう少し勉強しないといけない。


現状のファーム＋DLLでも、大きなファームを書き込むのでなければ充分実用になります。

read more : hid_blaster

Open On-Chip Debugger
> scan_chain
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 stm32.cpu              Y     0x3ba00477 0x3ba00477     4 0x01  0x0f
 1 stm32.bs               Y     0x16410041 0x06412041     5 0x01  0x03
                                           0x06410041
                                           0x06410041
                                           0x06410041
                                           0x06410041
> reset halt
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000120 msp: 0x20005000
> flash write_image erase main-0000.hex
auto erase enabled
device id = 0x20016410
flash size = 128kbytes
wrote 8192 bytes from file main-0000.hex in 4.828125s (1.657 KiB/s)



↑

OpenOCD : 次はATtiny2313でOpenOCD : さらに高速化に成功。

今のところ8kB書き込みに3.4秒。(USB2.0HUBを入れた状態)

  • RUNTESTを減らした。


現状のファーム＋DLLでも、大きなファームを書き込むのでなければ充分実用になります。

read more : hid_blaster

Open On-Chip Debugger
> scan_chain
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 stm32.cpu              Y     0x3ba00477 0x3ba00477     4 0x01  0x0f
 1 stm32.bs               Y     0x16410041 0x06412041     5 0x01  0x03
                                           0x06410041
                                           0x06410041
                                           0x06410041
                                           0x06410041
> reset halt
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000120 msp: 0x20005000
> flash write_image erase main-0000.hex
auto erase enabled
device id = 0x20016410
flash size = 128kbytes
wrote 8192 bytes from file main-0000.hex in 3.406250s (2.349 KiB/s)



↑

OpenOCD : 次は何しょぅ・・・

  • 同じプロトコル、アルゴリズムをPIC18Fに移植するとだいたい８倍程度速くなる予定
  • （何故なら、USBのコントロール転送はLOW SPEEDで8byte/1mSフレームなのに対して、FULL SPEEDだと64byte/1mSフレームになるから）
  • HIDデバイスにこだわらないのであれば、８倍（最大で64kB/sec）のさらに４倍くらい（最大で250kB/sec）になるはず。
  • FULL SPEEDだから12Mbps=約1.2MB/sec行くと思ったら大間違い。それはハンドシェークしないで無限長パケットを送りつける場合の話。実際USBはそんなに速くない（無駄が多い）し、PIC18Fの遅さを知らない発言だ。
  • 現状では18F14K50がJTAG接続中に不安定で使い物にならないレベルなので、代打として、3.3V駆動している18F2550基板を改造してPIC18Fへのインプリメントを続けるか、
  • PICの需要が無い、と勝手に判断してARMに移ることも考えている。(ARMでARMに書くのか？共食いだな、いや鶏卵問題か)


  • 自分的には、8kファームを4秒で書けるなら、それで充分だし、OpenOCDはARMライターとしてしか見てないし（gdbやEclipseなどを使うつもりが全く無いと言うか・・・）
  • 8k以上のファームを書く必要性すらない（それ以上のサイズはブートローダー経由で自力で書き込むことにしている）ので、 これで開発終了してもいいかなとか思っているところ。


  • JTAG以外にSWD(SWIM)サポートしたい気はする。でもSTM32ではJTAGで充分速いし、SWDしか使えないチップって何だっけ？
    • LPC1343だけか。でもあれはBOOT ROMが良く出来ていて自力でPCのUSBストレージになってくれるのでSWDで書く必要性は薄い。（SWDデバッグ出来ない問題は残る）
  • OpenOCDのドライバー部分だけを別DLLにして、オレオレブラスター（実はUSB-Blasterのぱくりと言えなくも無いパケット構造なので、ナントカブラスターにしてみただけ）を作ってみたけれど、実のところOpenOCDのライセンス制約を把握できていないので、こんなことをやっていいのかどうかさえあんまり分かっていなかったりもする。



と、まあ勝手なことを連ねてみたが、結論としては

  • 現状のHIDなオレオレブラスターをARMに載せるところまではやってみるつもり。たいして手間は掛からない。
  • PIC18Fは（現状ファームが不安定なので）放置予定。
  • HID以外のUSBクラスにするつもりは今のところない。ドライバーを用意するのが面倒なので。速くはなるけれど。



↑

OpenOCD : 次はUSB-Blaster(もどき)用に対応してみたり。

PIC18F2550対応

read more : pic18blaster


  • OpenOCDをちゃんとUSB-Blasterに対応させたほうが利便性は高いはず。（でも面倒なので）
  • PIC18F2550はブートローダーを入れているのでファームの差し替えはそれほど手間が掛からないことを利用して、
  • USB-Blasterファームとpic18blasterファームを差し替えて試してみた。
  • とりあえず動いている。
  • 比較のため、 
    --enable-usb-blaster-ftd2xx
  • にてビルドしたopenocdを用意して、USB-BlasterからARMにファームを書き込んでみた。
  • 以下はそのログ 
    C:\OpenOCD>openocd.exe -f blaster.cfg -f lpc2378.cfg -f batch.cfg
Open On-Chip Debugger 0.5.0-dev (2010-10-11-14:52)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'usb_blaster' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
500 kHz
Warn : no usb_blaster device description specified, using default 'USB-Blaster'
Error: Translation from khz to jtag_speed not implemented
Error: Translation from khz to jtag_speed not implemented
Error: Translation from jtag_speed to khz not implemented
Error: Translation from khz to jtag_speed not implemented
Info : adapter-specific clock speed value 0
Info : JTAG tap: lpc2378.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 7
Error: EmbeddedICE v7 handling might be broken
Info : lpc2378.cpu: hardware has 2 breakpoint/watchpoint units
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 lpc2378.cpu            Y     0x4f1f0f0f 0x4f1f0f0f     4 0x01  0x0f
Info : JTAG tap: lpc2378.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0xa00000d3 pc: 0x00000020
Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
Warn : NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'.
Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.
requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0xa00000d3 pc: 0x00000000
auto erase enabled
Warn : Verification will fail since checksum in image (0x00000000) to be written to flash is different from
calculated vector checksum (0xb8a06f60).
Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
wrote 8192 bytes from file main-0000.hex in 449.296875s (0.018 KiB/s)
shutdown command invoked
  • 8kBのファーム書き込みに449.2秒掛かった。
  • pic18blasterを使うと、30秒くらいで書ける。
  • ATtiny2313で作ったhid_blasterなら3.4秒で書ける。



↑

FRISK-JTAG

  • STBEE MINIをFRISKのプラケースに入れて、基板を固定してみた。
  • いい感じ。

https://raw.github.com/iruka-/ATMEL_AVR/master/web/jpg/ARM/frisk-jtag.jpg

  • STBEE MINIの裏側にチップ部品が少し張り付いていたので、その部分だけ、裏張りの基板をえぐってある。（電動ドリルで穴あけすこし手前まで掘る）
  • まだ未配線。
  • ファームも書いてないし、OpenOCDドライバーも書いていない。
  • 一応AVR,PIC18,ARM(OpenOCD)まで対応する予定。
  • 予定稿としては、pic18spxをほぼ丸ごと移植するつもり。


↑

AVR用6PIN-ISPピンヘッダー仕様

  • 使いまわし的に微妙に無理があるけれど、全機種共通配置。
  • AVR-ISP用:ピンヘッダーを基板上から見た配置 
       5    3    1
 +----+----+----+
 |Rset|SCK |MISO|
 +----+----+----+
 |GND |MOSI|Vcc |
 +----+----+----+
   6    4    2
  • PIC18FのISPにもそのまま使いまわし 
       5    3    1
 +----+----+----+
 |MCLR|PGC |PGD |
 +----+----+----+
 |GND |PGM |Vcc |
 +----+----+----+
   6    4    2
  • それをまたARM(JTAG)にも使いまわし 
       5    3    1
 +----+----+----+
 |TMS |TCK |TDO |
 +----+----+----+
 |GND |TDI |Vcc |
 +----+----+----+
   6    4    2
  • 対応表 
    AVR用ISP 6PIN     PIC18Fへ書き込み場合の対応表    ARM-JTAG
-------------------------------------------------
	1 MISO    ------------------>   PGD       TDO (唯一の入力端子。ARMからは出力)
	2 Vcc     ------------------>   Vcc       Vcc
	3 SCK     ------------------>   PGC       TCK
	4 MOSI    ------------------>   PGM       TDI
	5 RESET   ------------------>   MCLR      TMS
	6 GND     ------------------>   GND       GND
-------------------------------------------------
  • 実際は、要らなくなった互換機の9PINシリアル外出しフラットケーブル(ピンヘッダーとDSUB9-PIN)を ばらして使ったり、秋月の10PINフラットケーブルを使っているので、6PIN以外に4PIN分を余らせている。 （そこにnTRSTとかを割り当てることは可能）

JTAGなんて、結局AVRの6PIN ISPと（必要ピン数は）大差ないのに、全部バラバラ仕様なので、

  • http://www.geocities.jp/rev_eng_lab/jtag/connector.html
  • その都度変換コネクターでも作るしかないと思っている。
  • ピンが全部バラけているような（ＡＴ互換機のマザーとフロントパネルとかオーディオを繋いでいるような）ケーブルを全部手で差し込むのだけは嫌だ。絶対間違える。


今手元にある基板としては、こんな感じ。

CQ-FRK-NXP-ARMとSTBEE (FULL SIZE)ARM準標準の20PIN
STM8S-DiscoverySTMicroの変な？配置の8PINピンヘッダー
CQ-STARMJTAGは独立したピンヘッダーがないので、適当な変換基板を挟んでSTM8S-D配置に変換してみた
STBEE MINIJTAGは独立したピンヘッダーに出ていない
LPC1343JTAGはサポートされていない。SWDのみ

なので、汎用ライターの端子はAVRISPの6PIN配置にしておいて、

  • AVRISPからARM準標準の20PINに変換するケーブル。
  • AVRISPからSTM8S-Dの変な8PINに変換するケーブル。

が必要らしい。



↑

『Windows Phone 7』がAndroidを上回る理由

Wired Vision

  • 中華Padより端末の品質が良いことは分かった。
  • 広まるかどうかは別だ。Xboxはまあまあ成功したがZuneは悲惨だったし、WindowsCEベースの端末の屍の数を知っている者としては・・・疑問符だらけ？
  • 世間的にはiOSやLinuxカーネルベースのMIDだらけになっているところに、いきなりWindowsCEのださい環境は受け入れられるのかどうか・・・。
  • だけどこれら全部OSは違えど、ガワ（ハードウェア）は驚くほど似ている(全部ARMだし)
  • だったらＡＴ互換機みたいにOS差し替え出来るようにするとか、VMWareのような仮想化ソフト入れて複数OSが走るようにすればいいのに。
    • すでにiPadにChromeとか入れてる人もいるらしいけれど。

Gigazineのほうでは悲鳴が聞こえているらしい。



↑

OpenOCD : PIC18spxファームを更新

  • 割り込みを止めたら途端に安定化した。
  • なんかレジスタ壊してるのかな？
  • ということはpic18spxの18F14K50も割り込みを止めたら安定化するかも（未確認）

read more : pic18blaster

  • もしかしたら、スタックサイズが足りてないのかもしれない。
  • BitBangの処理とかPIC24Fの書き込みの処理ではlongな変数が多く使われているので、フォアグランド側がスタックを多く使う。
  • PIC18F14K50は元々メモリー(SRAM)が512byteしかないので、スタックもワークもバッファも全部ぎりぎり状態。
  • スタックオーバーのときのPICは全く意味不明の動作をする。
  • 18F2550はRAMが2Kあるので楽勝。(ほんとか？)



↑

OpenOCD : pic18spx ファームだけ高速化

  • あーどうしようAVR用のファームのJTAGコマンドを簡単にPICに移植できてしまった。
  • ハードウェア支援SPI機能など一切使っていないコードだから当然と言えば当然なんだけど。
  • しかし動作確認するにはOpenOCD用のDLLソースを激しく書きなおさないといけない。
  • いっそのことAVR用とPIC用を統合したらいいのに・・・＞俺



↑

OpenOCD : PIC18spxをJTAGアダプターにする。

  • 高速化完了!

read more : pic18blaster

C:\pic18blaster>openocd.exe -f blaster.cfg -f stm32.cfg -f batch.cfg
Open On-Chip Debugger 0.5.0-dev (2010-10-10-20:52)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
if load
Info : only one transport option; autoselect 'jtag'
1000 kHz
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
=*= dummy_init(void)
TARGET DEV_ID=14 VER=1.1
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 stm32.cpu              Y     0x3ba00477 0x3ba00477     4 0x01  0x0f
 1 stm32.bs               Y     0x16410041 0x06412041     5 0x01  0x03
                                           0x06410041
                                           0x06410041
                                           0x06410041
                                           0x06410041
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Warn : Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000120 msp: 0x20005000
auto erase enabled
Info : device id = 0x20036410
Info : flash size = 64kbytes
wrote 37888 bytes from file main-2000.hex in 7.921875s (4.671 KiB/s)
verified 36912 bytes in 0.671875s (53.651 KiB/s)
shutdown command invoked
=*= dummy_quit(void)



↑

OpenOCD : STBEE MINIをJTAGアダプターにする。

  • 完成!
  • OpenOCDはＯＫ。
  • avrwriter(HIDspx相当)も動作した。
  • picwriterはまだ動かない。 --- 動くようになりました。
  • pic24f_writerは未コンパイル。

read more : arm_blaster



↑

OpenOCD : 次のテーマ（予定）

  • Arduinoのスケッチでやってみようと思うんだけれど、問題はATmegaが5V駆動なことなんだな。
  • そのまえにArduino持ってないんで、そっち方面から。
  • まず、基板はこれ。古いのを発掘した。

https://raw.github.com/iruka-/ATMEL_AVR/master/web/jpg/PIC/arduino14k1.jpg https://raw.github.com/iruka-/ATMEL_AVR/master/web/jpg/PIC/arduino14k2.jpg

  • 写真はPIC 18F14K50とATmega328搭載基板（Arduino機能互換）
  • 今やATmega328は秋月で＠250円なので、マイコンチップ２個の価格は合わせて450円しかしない。


  • ファームはこれ

PIC14K50側

  • usbserial-uno.zip
  • 昔のファームとの違いは、単にDTRの出力論理を反転しただけのもの。
  • AVRのリセットへ行く線はコンデンサカップリングのまま。（配線を変えるのも面倒だから）

AVR側

  • http://www.arduino.cc/
  • Arduino-0021をダウンロードして、ＰＣにインストール。
  • AVR側には、ブートローダーとして、Arduino-0021に入っているoptibootのmega328用hexを焼いた。

Arduino-0021のボード設定はunoがデフォルトになっていたので、そのままスケッチを転送して実行できた。

  • サンプルにあった、Basics->DigitalReadSerialのボーレートだけ115200bpsに変えたものをコンパイル＆転送して、 一応115200で受けてみてなんとなく動いているところまで確認した。

今日はここまで。



↑

OpenOCD : 今度はArduino？

まず、

  • arm_blasterでAVRに書き込んだときにエラーする問題は対処した。
  • 同じくarm_blasterでPIC24Fライターがビルドできるようにしておいた。
  • たぶん繋げば焼けるはず。(PIC24Fって、需要あるのかな)

次、

  • COMポートの列挙の実験 --- ＯＫ。
  • COMポートのどれがArduino(OpenOCDポート)なのかを検索する --- あれ？出来ないんじゃぁ？
  • COMポートとUSBデバイス名を紐付ける方法が無いらしい。
  • ここに書いてあるんだけどユーザー名って面倒くさい。どうやって取得するんだろう。 
    C:\Documents and Settings\ユーザー名\Application Data\Arduino\preferences.txt
  • しかしOpenOCDデバイス(Arduino)のスケッチを書き込んだパソコンで常に試すとは限らない。
  • どっかに持って行って、OpenOCDを動かすときは、そもそもArduinoすら 入っていないので、preference.txtは存在しない。
  • 急に面倒くさくなってきた。



↑

Windows8はARMプロセッサ上で動作？？？

  • つまり、デスクトップＣＰＵは死んだ。
  • これからはモバイルWindows8なのか？

まるで悪い冗談だ

  • Atomの立場はどうなる？



↑

OpenOCD : Arduino版の開発はペンディング？

  • 簡単に作れるのが分かった途端に、急激に興味が失せてしまった。
  • それに5Vなので接続がやっかいだ。

ところで、Arduinoのスケッチを集積したCPANのようなサイトはないのだろうか？

  • スケッチなんて、どうせ先にだれかが作っているに違いないと思うようになった。
↑

久々に互換機組み立て

  • あまり変わり映えしないんだけれど、BIOSTAR(G31)のマザーをGIGA G41M-ES2Lのと取り替えてみた。
  • CPUもCeleron420(1.6GHz single-core)からCeleron E3300(2.5GHz dual-core)に変えてみた。

コストは１万円と少し。

  • オーバークロックは3.2GHz(FSB 1066MHz)までやってみたものの、Windowsがメモリーエラーを吐いて止まるので
  • 逆にFSB533MHz(1.6GHz駆動)に落としてみた。
  • ついでにCore電圧も1V未満にした。
  • GIGAのEasyTuneでファンスピードも落として静かにした。
  • Atomと比べると、ここまで落としても倍速×２CPUだ。ただ、G41チップセットの発熱はやや大きいのでどうしてもファンは回さなければならない。
  • intelの石では、このあたりの組み合わせ(Core2の45nmCPUで最も廉価な当たり)が一番好きだな。速い安い旨い。
  • チップセットの発熱がもっと抑えられれば尚良しなんだけれど、昔持っていた発熱の少ないSiS671マザーは、へたれてしまって不安定で使えなくなった。
  • 現行のCore i3/i5はCPUもマザーも高価だし、性能比はCore2とあんまり変わらないので割高に感じる。
  • その先の世代はどうなんだろう。性能が上がっていくのは確かだが、ユーザーニーズに合わなくなってきていないだろうか。
↑

Android携帯は流行るのか？

  • iPhoneのキャリアがSBM一社であるので、他社auとdocomoは対抗馬Android端末を推しているわけで、流行り現象のひとつであることは確か。

疑問点

  • iPhoneと同様に、パケットがだだもれ（自動的に大量発生する）になるので、パケホーダイを使わざるをえなくなる。
  • そうすると月間維持費は（従来より）高くなる。
  • それが嫌なら、IS01のようにSIMカードを抜いてWiFi専用機として使う（つまり携帯電話は従来のものを併用）しかしWiFi電波の無いところでは使えないのでそれはそれで不便な端末になる。
  • PDAのようなものは昔もいくつか存在した。
    • Psion->Palm(SONY CLIE)->WindowsCE->Sharp ZAURUS->NetWalker->...
  • つまり、何が言いたい？
    • PDAのカテゴリーに属する端末は、一時期は流行るけれど、いずれ廃れるものなんだ。
    • iPhoneやAndroidが流行るのももしかしたら一時的な現象かもしれない。
    • 通信料はたしかに頭の痛い問題ではあるけれど、端末としては衝動買い可能なレベルだ。

全然関係ないけど、うちには今もIBMのWorkPadとNECのMobileGear(WinCE)がある。

  • さすがにPsionは持っていない。
  • ZAURUSやNetWalkerについてはキーボードと字が小さすぎて駄目。手を出さなかった。
↑

Appleという名のガラパゴス諸島

マスコミやGIGAZINEが伝えないマジコン規制の本当の恐ろしさ

  • iTunesミュージックストアが閉じたときのことを全然考えていなかった。
  • PalmやCEが廃れたように、いずれはApple社にも落日の日が来る。（消滅したSunのことを考えるとよい。）
  • そうすると何が起きるか。
  • そうだ。今まで購入した楽曲やアプリが風化し消滅するのだ。しかもAppleにとってはなんのペナルティもなく合法的に！
  • 現在所有しているiPhone/iPodが使えているうちはいいが、故障したり使えなくなったときには購入したデジタルデータは使えなくなる。

デジタル化というのは、そういうものかもしれないが、

  • ありえない、というか許せない気持ちになる。


  • 実際のところ、iPhone/iPodのリチウム蓄電池には寿命がある。（せいぜい数年だ）
  • 現在は１〜２年でAppleは新製品を出し、皆がそれに買い換えるので蓄電池の寿命は問題視されていないが、Appleが新製品を出さなくなったらそこで終了だ。
  • もちろん、AppleがiPadビジネスをやめる可能性はいまのところ少ない。
  • しかし、新製品を出す、あるいは現行製品の供給を続けるという確約がされているわけではない。
  • 電子機器を多く製造している共産圏のとある国が崩壊した場合にはやはり安価な供給は続けられなくなるだろう。


  • iPhone/iPadの一時の繁栄は幻想に過ぎない
  • iTunesによる囲い込みは、結局のところ、Appleという名のガラパゴス諸島にすぎないのだ。

これは、いまのうちに問題提起しておくべきことなのだ

↑

MacBookがさっそくバラされている件

↑

STM8L-Discovery

↑

PlayStation Move Teardown

iFixit

ここにも解析している人が居た。




↑

STM8S-Discovery基板を用いたOpenOCDライター

  • 動いた。

read more : stm8s_blaster




↑

ちょっと良さげなキーボード

ARCHISITE