2010-07

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

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

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

↑

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

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

参考にしたＵＲＬ

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

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

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

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

↑

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

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

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の応答がワンテンポ遅かったりとかコマンドの応答に３０秒待たされたりといったLinuxのlibftdiを使った場合の問題の症状は、全く起きなかった
快適に操作できる。
というか普通これくらいが当たり前。

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

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

ターゲット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を玄箱にインストールする.

Palmは復活するのか？

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

http://jp.techcrunch.com/archives/20100428hp-palm-deal-webos/

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

http://journal.mycom.co.jp/news/2010/07/16/035/

なるほど、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)

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

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

↑

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

■元麻布春男の週刊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の現状。

もっと軽いＯＳ（Chromiumとか、Linuxでも超軽量なTinyCoreとか）なら1.5GHzでも動くし使えると思う。
しかし、それだと当然ARMでも充分動くのでAtomのメリットは何もないのだ。

↑

STM8S-Discovery:ひとおもいにERASE

STM8SのST-LINK側の解析を諦め、ひとおもいにERASEしてみた。

ついでにCQ-FRK-STM32用のdfuファームをOpenOCD経由で書き込んで、一応動いている(USBデバイスとして動作し、DFuSeが認識するところまでＯＫ)

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

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

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

↑

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

AKIBA Watch

http://akiba-pc.watch.impress.co.jp/hotline/20100724/etc_asrock.html
VIAまだ生きとったんかい。
●コアはC7系のEsther
nanoじゃないの？
パラレル、シリアルポートが健在だ！

↑

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

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

http://pc.watch.impress.co.jp/docs/column/hot/20100723_382678.html
iPadの対抗製品がいまだに出てきていないのはある意味謎だ。
やはりコンテンツ配信も含めてサービス出来る会社が名乗りをあげないからだろう。

端末自体はいずれ多くの会社が供給するようになるはずなので、
配信の相互乗り入れが出来るようにしてコンテンツ配信の寡占化を防ぐような仕組みが今後必要になってくるのではないだろうか。

そうならない場合は、全部アメリカ勢(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-STM32	STM32F103VBT6
STM8S-Discovery	STM32F103C8T6

       - 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なのかもしれない。

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

↑

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を触る可能性はあるので、正しいほうを選択するに越したことは無い。

あれれ？

っていうのは

     .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なのかな？全く意味不明だ。
型番から明快に分かるようにしてくんないかな。

↑

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

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

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

しかし、あれほどコード効率の悪いPIC18Fでさえ、ブートローダーは2kに収まっているし、AVRでもV-USBを使いながらもほぼ全部Ｃで書いて2K強なのに、ARM(Thumb2)が8kも食うのはいかがなものか。

無駄に32bitのポインタやらベクターが多いからかなぁ。
コールバックとかやると関数ポインタをたくさん消費するし。

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

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

ついでに 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即値のレジスタロードは１命令で出来るのでわざわざ関数の外側をPC相対でフェッチする必要が無い。
MIPSでは32bit即値は上位16bitと下位16bitをORするような形の２命令になる。

さらに言えば単独のアブソリュートアドレスからのフェッチも(intelでは)１命令で出来るのに対し、RISC CPU（例えばMIPS）では２命令に分解されるし、SH2やARMでは２命令とそれ以外の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)

http://strawberry-linux.com/catalog/items?code=32105
１９７４円
あーこいつも12MHzかぁ・・・

↑

STM32:GPIOポート

けっこうややこしい

GPIOA	0x4001_0800
GPIOB	0x4001_0c00
GPIOC	0x4001_1000
GPIOD	0x4001_1400
GPIOE	0x4001_1800

いまだにポートの読み書きさえ出来ない俺って・・・

例えば、GPIOAを弄りたいとすると、まず最初の２ワード（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)に相当するんだろうと予測。

最新の20件