2010-07

2010-06← → AVR/PIC両用ライター usbシリアル変換  usbキーボード  簡易ロジアナ、赤外線リモコン信号観測

7月: 全然関係ないけどセタ七夕って、似てるよね。似てない?

  • はい、全然似てません。
  • Powerトダイ、懐かしいっすね。



先月のまとめ

  • JTAGケーブル(ライター)に挑戦。 --- ハードウェアは完成したが、ファームを1バイトも書いていない。
  • OpenOCDを使ってみる。 --- 全く使い物にならない、ということがわかった。

ところがどすこい

  • FT2232を使ってFTD2xxドライバーで使うOpenOCDはめちゃ快適。
  • この天国と地獄の差はいったいなんだったんだろう。


今月の暇つぶし目標

  • JTAGケーブル(ライター)に挑戦。(まだするのか?)






先月のできごとの続き

単なる推測でものを言ってみる。

  • OpenOCDのgitリポジトリのソースはあまり安定していないっぽい。
  • OpenOCDのaltera-usb-blasterサポートは、とても実用向けとは言えない。

なので、USB Blaster(こちらの中身はPIC18Fだが、純正品でも同じ)でARMのFlash書き換え(とかgdbデバッグ)をやろう、というのは暴挙となる可能性が高い。

  • ではどうするか?
  • (1)USB Blasterは諦めてFT2232Lでハードを作り直す。
  • (2)自前のPIC18Fファームを起こして、ARMのFlash Writerを作る。

後者のほうが、より{AVRチップでAVRライターを作るの愚}に近いような気がする。

  • でも、手っ取り早くARMのFlashを書き換えるには(1)のほうがいいのかな。






訃報: SF作家 ジェイムズ・P・ホーガン、逝去

ご冥福をお祈りいたします









Atomが組み込み分野で成功しない理由

■元麻布春男の週刊PCホットライン■

私が考える理由としては、

  • (1)Atomに適切なOSがない。
    • 以前WindowsXPというジャストフィットなOSがあったけれど今はない。
    • WindowsCE系は(超最新版でも)無論、論外。
    • ubuntu,chrome,androidいずれをとってもARMでも充分動くのでAtomを選ぶ理由がない。
  • (2)(チップセット込みの)コストが高い。
  • (3)消費電力が大きい。
  • (4)フットプリントが大きい。

組み込みに向かないというよりむしろ、AtomでiPadのようなものを作ろうとしたときのダメな点を列挙しただけか。

  • もちろんiPadよりも廉価で小型で省電力な組み込みには絶対向くはずがないよ。普通に考えて。






FT2232DでJTAG-key Cloneを作り始める。

秋月の1700円モジュールは手持ちがあった。

http://akizukidenshi.com/img/goods/L/M-02990.JPG

参考にしたURL

レベルコンバータがないので、手持ちの74HC573とATtiny2313(nRSTとかnSRSTは遅いのでゲート代わり)を使って作るつもり。

  • とりあえずレイアウトだけ作った。
  • ゲートの電圧はLEDとTrでひねり出す超いいかげんだけど内容は秘密。

あーWin32用のOpenOCDバイナリーつくるのが超面倒くさそう・・・。

  • どうしてWin32はmake一発で出来ないのかねぇ。






FT2232でOpenOCD:あっさり動いた。

この基板の配線チェック面倒くせーとか思いながらとりあえず(配線チェックもろくにしないで)

http://psp.dip.jp/web/jpg/ARM/ft2232d.jpg

  • BestTechnologyさんが公開してくださったバイナリーをWindowsXP上でそのまま動かしてみた。

動いたっ

  • 以下はログ。
D:\OpenOCD>openocd.exe -s ./tcl -f daemon.cfg -f jtagkey.cfg -c "jtag_kz 1000" -f target/stm32.cfg

なんかBestTechnologyさんのバイナリーってかなり新しいですね。

Open On-Chip Debugger 0.5.0-dev-00616-g0672a64 (2010-07-14-09:46)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : device: 4 "2232C"
Info : deviceID: 67330064
Info : SerialNumber: FTTDJ3SYA
Info : Description: JTAGkey A
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba
0, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x641
, ver: 0x1)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
>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
>halt
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x41000003 pc: 0x08000e58 msp: 0x20001e90
>reg
===== arm v7m registers
(0) r0 (/32): 0x00000000
(1) r1 (/32): 0x00000005
(2) r2 (/32): 0x200016D6
(3) r3 (/32): 0x20000240
(4) r4 (/32): 0x20000E84
(5) r5 (/32): 0x20000E85
(6) r6 (/32): 0x20000E8C
(7) r7 (/32): 0x20000E94
(8) r8 (/32): 0xFFFEF7DD
(9) r9 (/32): 0xF7FBFFB4
(10) r10 (/32): 0xA37732C4
(11) r11 (/32): 0x96520B5D
(12) r12 (/32): 0xE000E410
(13) sp (/32): 0x20001E90
(14) lr (/32): 0xFFFFFFF1
(15) pc (/32): 0x08000E58
(16) xPSR (/32): 0x41000003
(17) msp (/32): 0x20001E90
(18) psp (/32): 0x84324460
(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)
  • FTDIのD2XXドライバーを入れるのが面倒くさかったので、USBを挿して追加されたCOMポートをデバイスマネージャーのプロパティで選んで、WindowsUpdateに繋いでドライバー更新を行っただけ。
  • その前に、MProg (今はFT_Progになっていた )を起動してProduct Stringを適当な文字列"JTAGkey" にして、VID、PIDはFTDIのデフォルトのまま。Channel AをD2XXモードにしてEEPROMに書き込んだ。
  • EEPROMは壊れたNICから外した93C46を実装してある。
  • EEPROMを実装していない場合は、デバイス認識をどうするのか不明。


で、結論

  • Windows上でFT2232(D2XXドライバーベース)インターフェースのOpenOCDを使う場合は、telnetの応答がワンテンポ遅かったりとかコマンドの応答に30秒待たされたりといったLinuxのlibftdiを使った場合の問題の症状は、全く起きなかった
  • 快適に操作できる。
  • というか普通これくらいが当たり前。

  • ターゲット(STM8S-Discovery付録のST-Link基板)と接続したところ(上記ログはST_Link基板にもUSBケーブルを繋いで記録)

http://psp.dip.jp/web/jpg/ARM/ft2232jtag.jpg

ちなみに配線状況などは こちら

  • ターゲットVDD検出Trなどは未配線。
  • nTRSET や nSRSET 用のゲートは手持ちが無かったのでATtiny2313にファームを焼いて代用してみた。

こんなやつ

**********************************************************************
*	メイン
**********************************************************************
 PD5 ----|>---------- PB5
           |
 PD4 -----/
 PD3 ----|>---------- PB3
           ゜
 PD2 -----/
 PD1 ----|>---------- PB1
           ゜
 PD0 -----/
*/
int	main(void)
{
	uchar c;
	DDRD=0xc0;		// PORTD 0-5 入力.
	PORTD=0x3f;		// PORTD 0=5 PullUp.
	DDRA=0x00;		// PORTA 0-1 入力.
	PORTA=0x03;		// PORTA 0-1 pullup.
	
	while(1) {
		c=PIND;
		PORTB=c;
		c=c<<1;
		c^=0x0f;
		DDRB=c;
	}
	return 0;
}






寄り道:EUC/SJISが使えるjedを玄箱にインストールする.

read more: 玄箱でjed-ja

懐古趣味な人(==UTF-8がダメな人)向けの話題です。

  • VineLinux-4.2に標準装備されている日本語版jed-ja(EUC/SJIS おっけー)をDebianで動かします。
  • 普通にubuntuなどでもOK.






Palmは復活するのか?

HP、Palmを12億ドルで買収、「全力でWebOSを盛り立ていく」

米HP、Androidタブレットの開発計画を中止 - webOS一本化へ

  • なるほど、iPhoneの二匹目のドジョウを地でいくわけか。
  • しかしカーネルがLinuxでブラウザがWebkitだったら、オリジナリティってウィンドウマネージャーだけ?
  • アプリは何で書くのかな?Java?それともNative-C?
  • 過去のPalmの特許が物を言うわけか。場合によってはAppleをギャフンと・・・。
  • これで、携帯ブラウザは全部Webkitベースになっちゃったなぁ・・・(Microsoft?そんなもん知らん)
  • 日本発ブラウザー(NetFrontとか)はほんとに文字通りガラパゴス諸島。






FT2232でOpenOCD:これは良く出来ている。

まずtelnet接続したら、

> reset halt 
> reg                  // レジスタを見る.
> mdw 0x20000100 0x40  // RAMをメモリーダンプする.
> load_image main.hex  // 自作hexファイルを(RAMに)ロードする.
> reg pc 0x20000250    // 自作hexのエントリーアドレスをpcに入れる.
> step
> step
> reg 
 ・・・気がすむまで・・・

gdb要らないじゃん(笑)

本日の結論

  • 意地でも0x800_0000のFlashは読めないようになっている、ということが分かった。
  • ひとおもいにERASEしてしまえばいいだけのことだが・・・。(何か悔しい)
  • gdbを立ち上げなくても普通にhexファイルを読んで実行するとか簡単にできる
  • (おまけにブレークポイントとかステップ実行とかreg dumpとか全部出来る)ということが分かった。






STM8S-Discovery:ST-Linkはマスストレージ?

H:\>dir /w

ドライブ H のボリューム ラベルがありません。
STM32 (CORTEX M3) - 32-bit Microcontrollers.url
STM8S - 8-bit Microcontrollers.url
STMicroelectronics - Microcontrollers - 8-bit microcontrollers, 16-bit microcontrollers and 32-bit 
ARM micro controllers.url
              3 個のファイル                 729 バイト
              0 個のディレクトリ      32,474,112 バイトの空き領域
H:\>

デバイスマネージャーからは

ディスクドライブ
 + STM32
    USBSTOR\DISK&VEN_STM32\7&1BFB811A&0&8_N_0S59W8_C&0

に見える。

  • 複合デバイスではなさそうだ。
  • 普通にUSBメモリーだけのようだ。
    USB\VID_0483&PID_3744\6&16B697D&0&3
  • USBメモリーとしては今時珍しい、たったの32MByte(FAT16)で、書き込み禁止になっていた。(つまりダミー)
  • ということはDeviceIoControlで通信するのだろう。おそらく。

参考になる?

  • もうすこし調べたいが、ファームが読めないとどうにもならないかも。


一応Beagleでログだけ取ったら、ひとおもいにERASEする予定。

Product       = STM32 STLink
Manufacturer  = <not available>

Vid=0x0483 Pid=0x3744 Rev=1.00 USB=2.00
Class=0x00 SubClass=0x00 Protocol=0x00
NumConfig=1 MaxPacketSize(EP0)=64

[BOS] None.

[Config 1] NumInterfaces=1 Power=bus MaxPower=100mA
 [Interface 0 (alt 0)] NumEPs=2 Class=0x08 SubClass=0x06 Prot=0x50
   [Endpoint IN  0x81] Type=Bulk MaxPacketSize=64 Interval=(FS:0ms HS:0.0ms)
   [Endpoint OUT 0x02] Type=Bulk MaxPacketSize=64 Interval=(FS:0ms HS:0.0ms)

エンドポイントは1組だけ。

マスストレージ系は良く分からないや。






ネットブック人気はもう復活しない。永久に

■元麻布春男の週刊PCホットライン■ ネットブックの再生を目指す試作機「Canoe Lake」

  • http://pc.watch.impress.co.jp/docs/column/hot/20100720_381849.html
  • Windows7のベンチマーク、エクスペリエンス指数がいくら上回ろうとも、クロックわずか1.5GHzのN550なんてクズだ。
  • Windows7をまともに使いたいなら最低でも2GHz以上のCore2ベースに2GB以上のRAMは必須だと思う。
  • Atomクロック(等クロックだとcore2の半分しかパフォーマンスが出ない)に換算すると、4GHzのデュアルコアが必要だ。
  • 何年先になるのか?


大まけにまけても2GHzオーバーのデュアルコアがWindows7を使う最低ラインだろう。

  • しかし2GHz駆動にすると電池が持たない、というのが現行Atomの現状。
  • もっと軽いOS(Chromiumとか、Linuxでも超軽量なTinyCoreとか)なら1.5GHzでも動くし使えると思う。
  • しかし、それだと当然ARMでも充分動くのでAtomのメリットは何もないのだ。






STM8S-Discovery:ひとおもいにERASE

  • STM8SのST-LINK側の解析を諦め、ひとおもいにERASEしてみた。
  • ついでにCQ-FRK-STM32用のdfuファームをOpenOCD経由で書き込んで、一応動いている(USBデバイスとして動作し、DFuSeが認識するところまでOK)

read more: stm32f103

  • だけど、どうもDFUは馴染めない。
  • コマンドラインツールが存在しないことと、elfからdfuフォーマットへの変換にもGUIツールしか存在しないというのがユーザーを舐めているとしか思えない。
  • DFUプロトコルに何のメリットも感じないので、結局HIDブートローダーに移行する予定。






某日産のECU納期遅れは・・・

  • STマイクロが犯人らしい。
  • るねさす使ってやれよ。ってゆーかるねさすがARM作れば良いじゃん。

そもそもARMってARMチップ作ってないし。






VIAの新CPU「PV530」搭載マザーが発売に

AKIBA Watch






シャープ、次世代XMDFソリューションで電子書籍事業に参入

〜年内にサービス開始。タブレット端末2製品も同時投入

  • 端末自体はいずれ多くの会社が供給するようになるはずなので、
  • 配信の相互乗り入れが出来るようにしてコンテンツ配信の寡占化を防ぐような仕組みが今後必要になってくるのではないだろうか。
  • そうならない場合は、全部アメリカ勢(Apple,Amazon)に持ってかれて終了だ。






STM8S-Discovery:中途半端に互換性の無い奴ら

  • ST-Link側を動かそうとした。 結果
  • dfuのみなんとなく動いている気がする。但し、書き込んだプログラムが動くのを確かめたわけではない。
  • HIDなモニターはHIDデバイスとしては正常に認識しているけれど、意図したエコーバックを返さない。
  • CDCなvcomもCDCデバイスとしては正しいし、COMxx:に割り当てられてCOMポートもオープンできるが、エコーバックがない。
  • 割り込みベクターは一応0x0800_0000,0x0にしたつもり。
  • 一応モデルはCQ-FRK-STM32と同じMDなはずなんだけれど・・・
    # NOTE:
    # - Low-density devices are STM32F101xx and STM32F103xx microcontrollers where
    #   the Flash memory density ranges between 16 and 32 Kbytes.
    # - Medium-density devices are STM32F101xx and STM32F103xx microcontrollers where
    #   the Flash memory density ranges between 32 and 128 Kbytes.
    # - High-density devices are STM32F101xx and STM32F103xx microcontrollers where
    #   the Flash memory density ranges between 256 and 512 Kbytes.
    # - Connectivity-Line devices are STM32F105xx and STM32F107xx microcontrollers.
    #
    # ---> STM32F103VB 128KFlash=MD?
    
    # Place -D or -U options for C here
    CDEFS =  -D$(RUN_MODE) -DUSE_STDPERIPH_DRIVER -DSTM32F10X_MD 
  • よくわかんないや。
  • もしかして、これ:
    #ifndef STM32F10X_CL
  • CQ-FRK-STM32ではSTM32F10X_CLは定義しないけれど、こっちのほうでは必要だったとしたら、変更箇所はやばいくらい多いことになる。
CQ-FRK-STM32STM32F103VBT6
STM8S-DiscoverySTM32F103C8T6
       - under STM32F10B_EVAL directory: to select the project for STM32 Medium-density devices.
       - under STM32F10C_EVAL directory: to select the project for STM32 Connectivity-Line devices.
       - under STM32F10E_EVAL directory: to select the project for STM32 High-density devices
  • C8T6のマニュアルによると、どうもMedium-densityではなくてPerformance Lineのようだ。
  • Connectivity Line (STM32F10X_CL) ではなさそうだ。
    • Connectivity Line を有効にするとUSB_OTGが付いてくるので多分違う。
  • Flash容量で見る限りだとMedium-Densityなんだけど・・・。
  • しかし、STM32F103VBT6もPerfoemance Lineのマニュアルに含まれていたので、両方ともPerfoemance Lineなのかもしれない。

このあたり、品番とヘッダーが1対1対応しているPICのほうがはるかに分かりやすい。

MDとLDの違い。

  • 差分を取ってみたが、有意な差はあまり無かった。
    3c3
    <   * @file      startup_stm32f10x_ld.s
    ---
    >   * @file      startup_stm32f10x_md.s
    7c7
    <   * @brief     STM32F10x Low Density Devices vector table for RIDE7 toolchain.
    ---
    >   * @brief     STM32F10x Medium Density Devices vector table for RIDE7 toolchain.
    11c11
    <   *                - Set the vector table entries with the exceptions ISR address.
    ---
    >   *                - Set the vector table entries with the exceptions ISR address
    16c16
    <   ******************************************************************************
    ---
    >   *******************************************************************************
    168c168
    <   0
    ---
    >   .word  TIM4_IRQHandler
    171,172c171,172
    <   0
    <   0
    ---
    >   .word  I2C2_EV_IRQHandler
    >   .word  I2C2_ER_IRQHandler
    174c174
    <   0
    ---
    >   .word  SPI2_IRQHandler
    177c177
    <   0
    ---
    >   .word  USART3_IRQHandler
    189c189
    <                           STM32F10x Low Density devices.*/
    ---
    >                             STM32F10x Medium Density devices. */
    315a316,318
    >   .weak  TIM4_IRQHandler
    >   .thumb_set TIM4_IRQHandler,Default_Handler
    > 
    321a325,330
    >   .weak  I2C2_EV_IRQHandler
    >   .thumb_set I2C2_EV_IRQHandler,Default_Handler
    > 
    >   .weak  I2C2_ER_IRQHandler
    >   .thumb_set I2C2_ER_IRQHandler,Default_Handler
    > 
    324a334,336
    >   .weak  SPI2_IRQHandler
    >   .thumb_set SPI2_IRQHandler,Default_Handler
    > 
    330a343,345
    >   .weak  USART3_IRQHandler
    >   .thumb_set USART3_IRQHandler,Default_Handler
    > 
    338a354
    >  
  • ほぼ全てにおいて、追加されたPeripheralの定義が増えているだけで、それらを使わない限りはMDだろうがLDだろうが 関係なさそうだった。
  • 割り込みベクターも、追加された要因の定義が増えているだけで、共通するものについては番号がずれていないので、どっちでコンパイルしても支障ないように見える。
    • もちろん、間違えて、存在しないPeripheralを触る可能性はあるので、正しいほうを選択するに越したことは無い。

あれれ?

     0

っていうのは

     .word  0

であるべきだと思うけど・・・まあいいか、CMSISなんてどうせつくりかけみたいなやつだし。

とりあえず気を取り直して

  • STM32用のarmon.zipをちゃんと取得し、
  • startupを*_ld.s がリンクされるように変更。
  • Makefileのdefineを *_MDから *_LDに変更。
  • main.cの割り込みベクター設定を(0x0800_0000,0x3000)から(0x0800_0000,0x0)に変更。
  • リンカースクリプトのROM領域を0x0800_3000から0x0800_0000に変更。
  • OpenOCDで焼いたらちゃんと動いたので、ま、いっかー。

750円のST-LinkのUSBはちゃんと動くよっ!

  • だけど、あとでマニュアルを読み返したら、USART3まであるしI2Cも2本あるし、
  • Performance Lineだけど、Medium Densityなのかな?全く意味不明だ。
  • 型番から明快に分かるようにしてくんないかな。

http://psp.dip.jp/web/jpg/ARM/stmfamily.png






STM8S-Discovery:armonが動いたので、今後の展望

  • armon(HIDな簡易モニタ)がFlashを12kも消費しているのは、
    • ADC関係が無駄にリンクされていた(呼んでいた)こと。
    • EVAL Board周りの無駄な関数と、無駄にメモリーを食うテーブルが定義されていたこと。

なので、8kに収める目処は付いた。

  • しかし、あれほどコード効率の悪いPIC18Fでさえ、ブートローダーは2kに収まっているし、AVRでもV-USBを使いながらもほぼ全部Cで書いて2K強なのに、ARM(Thumb2)が8kも食うのはいかがなものか。
  • 無駄に32bitのポインタやらベクターが多いからかなぁ。
  • コールバックとかやると関数ポインタをたくさん消費するし。

まあいいか、STM32のFlashは64Kある。

  • とりあえず、armonのソースをまとめてみた。

read more: stm32f103

ついでに FLASHの erase と write を仮実装してみた。

  • 消去は1Page=1kB単位で消してくれた。
  • 書き込みはまだうまくいってない。というか何を書こう。もうまくいった。

問題が一つ。FLASH_* 系の関数を呼び出すようにしたら、8kBを128byteくらいオーバーしてしまった。

  • システム側のmemcpy()が無駄に長かったので、短いヤツに差し替えたら8kに納まった。
  • それから、最初全然FLASHの消去が出来なかったのだが、どうやら
    FLASH_unlock();
    の呼び出しが必要らしい。
  • dfuのソースを見ると起動時のセットアップでunlockしていて、lockには戻していないようだ。ぃぃのかい?
  • 普通Flash書き込み直前にunlockして、終わったらlockしといたほうが良くないか?
  • (電源がBrownOutしたときの誤書き込みを防げる)
  • 消去に限って言えば0x800_3000以前の番地も消せるようだ。問題なし

ARM(Thumb)のメモリー馬鹿食いの原因が少し分かったような気がした。

  • こいつ(Thumbのこと)はSH2病だ。32bit即値をレジスタにロードする命令がないので、グローバルな変数とかポインタとか構造体などを参照する場合は、常にPC相対で32bit定数を取りに行くようだ。
    RESULT CustomHID_SetProtocol(void)
    {
     uint8_t wValue0 = pInformation->USBwValue0;
     ProtocolValue = wValue0;
    80005ce:	78d2      	ldrb	r2, [r2, #3]
    80005d0:	4b02      	ldr	r3, [pc, #8]	(80005dc <CustomHID_NoData_Setup+0x30>)
    80005d2:	2000      	movs	r0, #0
    80005d4:	601a      	str	r2, [r3, #0]
    
     else
     {
       return USB_UNSUPPORT;
     }
    }
    80005d6:	4770      	bx	lr
    80005d8:	20000304 	.word	0x20000304  <===こんなやつとか
    80005dc:	200002c8 	.word	0x200002c8  <===こんなやつ。
  • つまり、アドレス定数列がメモリー食い(と、速度低下)の原因だ。
  • intelアーキテクチャーでは32bit即値のレジスタロードは1命令で出来るのでわざわざ関数の外側をPC相対でフェッチする必要が無い。
  • MIPSでは32bit即値は上位16bitと下位16bitをORするような形の2命令になる。
  • さらに言えば単独のアブソリュートアドレスからのフェッチも(intelでは)1命令で出来るのに対し、RISC CPU(例えばMIPS)では2命令に分解されるし、SH2やARMでは2命令とそれ以外のPC相対に書かれた32bitアドレス定数が必要になる。






MicrosoftへのARMのライセンスは何を意味するのか

■元麻布春男の週刊PCホットライン■

  • http://pc.watch.impress.co.jp/docs/column/hot/20100726_383354.html
  • http://japanese.engadget.com/2010/07/26/msarm/
  • なんだろうね?
  • やっぱりWindows7Phone用の最適化?
  • Appleへの対抗上、高性能なARMチップが要るんだろうね。
  • iPadってJavaScriptがJITコンパイラじゃないんだ。
  • むしろ、そのほうが勝手アプリを増やされずに済むという魂胆なのかもしれない。
  • どうせiPadのアプリはObjective-CのARMネイティブなので、iTunesStoreに囲い込むにはJavaScriptが遅いほうが好都合だ。






STM8S-Discovery:このまま挫折したままかも。

現状

  • ファームは8kBにおさまっている。
  • HIDデバイスとして動作している。
  • HEXファイルを読み込んでFLASHの書き換えも可能になった。

けれど、問題点として、

  • USBのdisconnectをサポートするハードウェア(PULLUP抵抗の開放)がないので、 アプリケーションを起動させてもUSBの再認識を行えない。(PICですら簡単に出来るのに)
    • 裏技としては、Windowsのデバイス一覧でデバイス切断する方法はあるが・・・。
  • GPIOの操作が面倒そうなので、半ば諦めムード。
    • もちろんGPIO_*関数を呼べば出来るのは知っている。
  • PORTの操作には、どうもwordアクセスなメモリーの読み書きが必要そうだ。(面倒・・・)

他にも、

  • 配線が微細なので、線の引き出しが面倒だなーとかも。






苺:■STM32マイコンボード 『STBee Mini』(72MHz, 128K+20K)






STM32:GPIOポート

  • けっこうややこしい
GPIOA0x4001_0800
GPIOB0x4001_0c00
GPIOC0x4001_1000
GPIOD0x4001_1400
GPIOE0x4001_1800
  • いまだにポートの読み書きさえ出来ない俺って・・・
  • 例えば、GPIOAを弄りたいとすると、まず最初の2ワード(8byte)はCRL,CRH になっていて、たいていは 0x4444_4444 , 0x4444_4444 みたいになっている。
  • 4bit x 16Portだ。
  • 4bit(1 digit)の意味は0x4のとき、オープンドレインのInputモードで、 0x3のときはPush-PullのOutputモード、といった具合。
    • AVRで言うところのDDR設定が(1pinあたり4bit)×16pin分あるわけ。
  • ただし、RCCなんちゃらの初期化をやっていないと、まったく無反応っぽいぞ。
  • たぶんGPIO_IDR,GPIO_ODRというのが、16bit分のPINA,PORTA (もしくはLATCH_A)に相当するんだろうと予測。

http://psp.dip.jp/web/jpg/ARM/stm32gpio.png