2011年1月19日水曜日

LPC1768(Cortex-M3)のペリフェラルをレジスタ経由で制御してみる(の前に・・・)

昨日の記事でCortex-M3の導入方法について簡単に触れました。

先日の流れのまま最後のページまで到達するには途方もなく時間がかかるので、何らかのペリフェラルを例にとって実際に制御してみたいと思います。まずは「動かして楽しむ!」ですね!

今回は制御対象にUART1を選択しました。


まずはペリフェラルのクロックを確認します。
UART1のペリフェラルはPCLK_UART1というシンボルが付けられています。



そうだ。

大切な事を忘れていました。
ARM社はマイクロコントローラソフトウェアインターフェース規格を定めています。
従来、レジスタ操作などはデバイスベンダによって色々な流儀があったりして面倒でした。
簡単にいうと、これらを統一して扱いやすくするものがCMSIS(Cortex Microcontroller Software Interface Standard)です。
これは後ほど使います。
今はこんなものもあるという触りだけ・・・。

えーと、あ、そうそうUART1の話でした。
どこから始めるのかという話になるのですが、今回はレジスタによるデバイス制御に主眼を置いていますのでLPCXpressoのIDEを活用します。
また、スタートアップに関する処理はIDEが生成するものを使用します。

まずはプロジェクトの生成から。


プロジェクト名を適当に入れて下さい。


CMSISは今回使いません。(2011/01/21追記:やっぱり使いましょう!Use CMSISにチェックを入れておいて下さい!)


この辺りは初期値で良いです。


ここも。


最後にプロセッサを選択します。
今回はLPCXpresso LPC1768を使用しているのでリストからLPC1768を選択しました。
赤色になっているものは「このライセンスでは全部のROMを使う事はできないよ。」と言っていると思って頂ければ良いです。


上記の簡単な選択が終了するとプロジェクトが生成されます。
ソースディレクトリにはCランタイムスタートアップとmainが生成されています。


それでは少しだけCランタイムスタートアップを見てみましょう。
色々見るべきところはあるのですが、リセットベクタに対する関数はここで定義されています。


ここに記述されている.isr_vectorはリンカスクリプトで定義されています。
リセットベクタに書かれた関数ResetISRの実装は以下のようになっています。


dataとbssセグメントはメモリ(内蔵SRAM)上に配置されます。

初期値を持つデータはフラッシュからSRAMにここでコピーされます。
また、bssもここでゼロに初期化されます。
これら処理が終わった後でmain関数が呼び出される仕組みになっています。

また、__USE_CMSISが定義されている場合にはCMSISのSystemInit()が呼び出されるようになっています。選択したCランタイムライブラリによっては__libc_init_array()なども呼び出されます。

このようにLPCXpressoのIDEではスケルトンでここまで簡単にできてしまうようになっています。
いきなりmainから記述できてしまう。(良いやら悪いやら・・・。)

ということで、今回はペリフェラルを制御する一歩か二歩手前にお気軽に到達してみました。


2011年1月18日火曜日

恐れなくて大丈夫!Cortex-M3をLPCXpressoで十分に体験しよう!

Cortex-M3は商業的にもかなり成功しているラインナップらしく、随分と色んなマイコンからの乗り換えが多いようです。ところで、他のマイコンから乗り換える上でついつい心配になってしまうのは「制御しきれるのだろうか?」ということです。

例えば、mbedはCortex-M3の能力を体験するのに最適ですが、洗練されたライブラリのおかげでレジスタまで意識することはありません。

そんな時にEmbedded Artists社のLPCXpressoが便利。
ただ、他メーカのマイコンやmbedからCortex-M3に入った人にとっては、やっぱり突然未知の領域に放り込まれてしまいます。

そこで、この記事では「恐れなくて大丈夫!Cortex-M3をLPCXpressoで十分に体験しよう!」というテーマで、実際にどのようにレジスタ制御を習得していくのかを御紹介します。

ここではLPCXpresso LPC1768を使用します。
(秋月電子通商さんや、マルツパーツ館さんなどから購入可能です。)

まず、用意するものですが、LPCXpressoとユーザマニュアルです。

ユーザマニュアルは840ページを超えますが、概要やブロックダイアグラムなど一般的な項目から読み進めれば良いです。いきなり全部を読もうとすると・・・挫折します。(笑)


基本的にUM10360は重要な項目から読み進められるようなページ構成になっています。
プロセッサの概要に触れ、ブロック図を示し、メモリマップへと進みます。


他メーカの独自コアマイコンから乗り換える方の中には「プロセッサの中にペリフェラルのバスが!」なんて引き気味になってしまう方もいるかもしれませんが、御安心を。
先ほどのブロック図と共に「APB peripheral addresses」を参照すれば、だいたいどのような構成になっているのか理解できると思います。


APB0とAPB1で使用できるペリフェラルが異なりますので、その辺りをここで確認しておくと良いでしょう。

「Chapter 3: LPC17xx System control」からはリセット、電圧降下検出、外部割り込み入力、その他のシステム制御とステータスに関する記述があります。これらに関連するピンの情報もここに示されています。リセットブロックダイアグラムも示されていますので確認しておきましょう。


スタートアップについては以下のような図が載っています。
起動タイミングにシビアな性能を要求する場合には確認しておきます。


「Chapter 4: LPC17xx Clocking and power control」からはクロックと電源制御について書かれています。

ここで重要なのは「パワーアップ時やチップリセット時には、クロックに内蔵RCオシレータが選択されている。」ということ。この内蔵RCオシレータはウォッチドックタイマやPLL0の駆動クロックなどに使用されます。ただ、このクロックはUSBや100kbit/sを超えるCAN1/2には使用できません。

そこで、起動後にクロック選択レジスタでクロックを選択してあげることになります。

もう突然嫌になりましたか?
大丈夫です。

これを設定すれば高速マイコン動作。
やらずにいられません。


ドキュメントに「Clock Source Select register」というのがありますね?
CLKSRCSELがそうです。

ドキュメントには、CLKSRCSELを00にするとPLL0クロック源が内蔵RCオシレータになり、01にするとメインオシレータが選択され、10にするとリアルタイムクロック用オシレータが選択されると書いてあります。

こんな調子で、各ファンクションブロックについて見ていくとあーら不思議、安くて高性能なコンパクト組み込み機器の完成となるわけです。

と言っても840ページありますからね。
大変ですけど。

次回はこの続きでSPIを使った液晶制御などを行うかもしれません。

2011年1月15日土曜日

EAGLE上で部品のVALUEを全部カラにするULP

EAGLEは直感的にサクサク図面が作成できるので非常に便利です。
他のCADでは数ステップ必要な動作もどんどんできてしまいます。

図面を書く上でよくあるのは、ヒョイヒョイと隣にある部品をコピーする事。
便利なのですが・・・


時にはこんな事になってしまいます。
これはおそらくプルアップ抵抗をコピーしたのでしょう。

こんな図面を見せようものなら電気技術者として穴を掘って入りたくなる状況に追い込まれます。
そんな時に便利な「EAGLE上で部品のVALUEを全部カラにするULP」を作ってみました。

電気設計の画面で実行すると、全ての部品の値をカラにします。
ユーザ定義可能な値を持たない部品の場合には確認画面が出ます。
好みに合わせてYesかNoを選択して下さい。

BOMを見るとこの通り。



回路定数の決定は設計でも重要な要素の1つです。
ざっと電気設計を終わらせたい時についつい後回しにしてしまいがちですが、このスクリプトを図面完成時に走らせて、定数決定フローに入れば間違いなく回路も見直せて一石二鳥というわけです。

以下のリンクからダウンロードして御利用頂けます。

なお、使用した結果について、当方は一切責任を持ちません。
この点御理解頂いた上で御使用下さい。
ダウンロードはこちらから

2011年1月9日日曜日

電気設計と基板設計の検証方法

今回は電気設計と基板設計の検証方法に関するトピックです。


最近の設計業務では画面上で設計を入力して、そのまま出図というケースも珍しくありません。
が、実際に基板が上がってくると、「うわっ!何ここのパターン!」とか、「これじゃあダメだよね。」ということが珍しくありません。

How to use Eagle3DEagle 3Dを用いた基板設計改善の効果(基板の完成予想図を使って失敗を最小限にする)ではEagle3Dを使った簡単な事前確認を取り上げましたが、今回は少し異なるアプローチを御紹介します。

使用するのはトレーシングペーパーとプリンターです。
私はKOKUYOのセ-T49Nを使用しています。


最近のプロセッサは高速に動作するようになってきていますので、「あー、このクロックラインはダメでしょ。」とか「ちょっと!グランドなんでそんなに細いの!」なんて事になると致命的です。
クロックがおかしければプロセッサはなんともなりませんし、電源が発振したら動くものも動きません。色んな部品がきちんと動作しない状態でデバッグしようものなら、一体何を見ているのかわからなくなってしまいます。

そこで登場するのがこれ。


非常に古典的な手法ですが、私はトレーシングペーパを使っています。
メリットはやはり実際に見て、感じて、書き込めるというところでしょうか。



画面上で確認した後で、実際にトレーシングペーパに印刷して重ねて見てみると意外なミスを発見したりすることがあります。特に層間の問題を発見するには都合が良いです。
「アナログのあの部分とデジタルのあの部分が近くないか?」とか、そういったケースです。


ちなみに、トレーシングペーパーに印刷する時には濃度設定を行ってから印刷して下さい。
最近のプリンタはインクをたっぷり使って綺麗に印刷するのですが、トレーシングペーパにはインクの量が多すぎます。

濃度設定は最小濃度で丁度良いくらいです。

印刷して持ち歩けばカフェで息抜きがてらに赤入れをしたりできるので便利。
気分転換にもなります。

こういった事前検証は全網羅する為のものではなく、あくまで「よりよい結果を生むための取り組みの1つ」と捉えるのが良いと思います。

ネットに対する最小線幅の設定自体が間違っていたり、ネットに適切なアトリビュートが割り当てられていない事もあるでしょう。DRCで逃してしまうミスを最終的にキャッチする手段として有効です。

また、製造時に起きそうな無用な不具合を避ける事にも使用できます。
例えば、このパッドとビアをもう少し話すと良さそうだなぁとかそんな具合。

画面上の作業ではどうしても単調になりがちです。
上記のようなアプローチを設計フローに盛り込む事で、いつもと違った視点を持つ事ができるようになります。

2010年12月12日日曜日

LPCXpresso LPC1768にJTAGKey2Pを接続してOpenOCDで楽しむ

先の記事ではLPCXpresso LPC1768のデバッガとターゲットを切り離しました。
ターゲットを独立させたのはJTAGKey2Pを接続して使いたいためです。
ここでは実際にLPCXpresso LPC1768にJTAGKey2Pを接続してみました。
OpenOCDはgitリポジトリから2010/12/12現在のものを取り出して使用しました。
まずはOpenOCDのビルドです。

JTAGKey2Pではlibftd2xxを使用します。
http://www.ftdichip.com/Drivers/D2XX.htm
2010/12/12現在のバージョンはlibftd2xx1.0.0.tar.gzです。
ダウンロードして展開しておきます。

tar xvfz libftd2xx1.0.0.tar.gz

次にOpenOCDのソースコードです。

git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
cd openocd
./bootstrap
./configure --enable-ft2232_libftdi --with-ftd2xx-linux-tardir=/path/to/libftd2xx1.0.0
make

ビルドにはautomakeも必要です。
予めビルド環境に入れておいてください。

ビルドできたらmake installして出来上がりです。

ここで試しにsuikanさんがポーティングされたTOPPSER/ASP for LPCのバイナリをOpenOCD経由でフラッシュに書き込んでみましょう。
まずはOpenOCDを起動します。

その前に・・・OpenOCDの設定ファイルを確認します。

openocd.cfgは以下のようにしました。

source [find /usr/local/share/openocd/tcl/interface/jtagkey2p.cfg]
source [find /usr/local/share/openocd/tcl/target/lpc1768.cfg]

jtagkey2p.cfgはgitリポジトリに入っている物と同じです。
lpc1768.cfgについてはSWDを使う設定になっていました。
これについては以下のように修正して使用しました。

# NXP LPC1768 Cortex-M3 with 512kB Flash and 32kB+32kB Local On-Chip SRAM,
# # LPC17xx chips support both JTAG and SWD transports.
# # Adapt based on what transport is active.
# source [find target/swj-dp.tcl]
if { [info exists CHIPNAME] } {
        set  _CHIPNAME $CHIPNAME
} else {
        set  _CHIPNAME lpc1768
}
# After reset the chip is clocked by the ~4MHz internal RC oscillator.
# When board-specific code (reset-init handler or device firmware)
# configures another oscillator and/or PLL0, set CCLK to match; if
# you don't, then flash erase and write operations may misbehave.
# (The ROM code doing those updates cares about core clock speed...)
#
# CCLK is the core clock frequency in KHz
if { [info exists CCLK ] } {
        set _CCLK $CCLK
} else {
        set _CCLK 4000
}
if { [info exists CPUTAPID ] } {
        set _CPUTAPID $CPUTAPID
} else {
        set _CPUTAPID 0x4ba00477
}
#delays on reset lines
adapter_nsrst_delay 200
jtag_ntrst_delay 200
# LPC2000 & LPC1700 -> SRST causes TRST
reset_config srst_pulls_trst
jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
#swj_newdap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_m3 -chain-position $_TARGETNAME
# LPC1768 has 32kB of SRAM In the ARMv7-M "Code" area (at 0x10000000)
# and 32K more on AHB, in the ARMv7-M "SRAM" area, (at 0x2007c000).
$_TARGETNAME configure -work-area-phys 0x10000000 -work-area-size 0x8000
# LPC1768 has 512kB of flash memory, managed by ROM code (including a
# boot loader which verifies the flash exception table's checksum).
# flash bank (name) lpc2000 (base) (size) 0 0 (target#) (variant) (clock) [calc checksum]
set _FLASHNAME $_CHIPNAME.flash
# flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME lpc1700 $_CCLK calc_checksum
flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME lpc1700 120000
# Run with *real slow* clock by default since the
# boot rom could have been playing with the PLL, so
# we have no idea what clock the target is running at.
jtag_khz 500
$_TARGETNAME configure -event reset-init {
        # Do not remap 0x0000-0x0020 to anything but the flash (i.e. select
        # "User Flash Mode" where interrupt vectors are _not_ remapped,
        # and reside in flash instead).
        #
        # See Table 612. Memory Mapping Control register (MEMMAP - 0x400F C040) bit description
        # Bit Symbol Value Description Reset
        # value
        # 0 MAP Memory map control. 0
        # 0 Boot mode. A portion of the Boot ROM is mapped to address 0.
        # 1 User mode. The on-chip Flash memory is mapped to address 0.
        # 31:1 - Reserved. The value read from a reserved bit is not defined. NA
        #
        # http://ics.nxp.com/support/documents/microcontrollers/?scope=LPC1768&type=user
        mww 0x400FC040 0x01
}
init
reset init

次にOpenOCDを起動します。

shinta@greenpad:~/Projects/ledblink_lpcxpresso_1768$ sudo openocd 
[sudo] password for shinta: 
Open On-Chip Debugger 0.5.0-dev-00651-gc6e0705 (2010-12-11-21:58)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
none srst_pulls_trst
500 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : lpc1768.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Warn : Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals


無事に起動したらtelnet localhost 4444でOpenOCDと接続します。
halt, flash probe 0, flash write_image erase (バイナリファイル名), resetでLPCXpresso LPC1768上にあるLEDがチカチカする事を確認してみましょう。

shinta@greenpad:~$ telnet localhost 4444
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> halt
> flash probe 0
flash 'lpc2000' found at 0x00000000
> flash write_image erase /home/shinta/Projects/ledblink_lpcxpresso_1768/asp.bin
auto erase enabled
wrote 32768 bytes from file /home/shinta/Projects/ledblink_lpcxpresso_1768/asp.bin in 5.705619s (5.609 KiB/s)
> reset
JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals

OpenOCD側の端末ではクライアントから受けたコマンドの動作が記されていると思います。

target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
Info : accepting 'telnet' connection from 4444
flash 'lpc2000' found at 0x00000000
auto erase enabled
wrote 32768 bytes from file /home/shinta/Projects/ledblink_lpcxpresso_1768/asp.bin in 5.705619s (5.609 KiB/s)
Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Warn : Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals

この文書ではLPCXpresso LPC1768をJTAGKey2Pで使用するための狭い範囲のドキュメントとして作成しました。
TOPPERS/ASP for LPCに関するドキュメントはsuikanさんがお書きになった以下のドキュメントも参照してください。

LPCXpresso LPC1768のデバッガとターゲットを切り離して使う

LPCXpressoはそれ自身でデバッガとターゲットの用が足りてしまうので、デバイスを試すという意味で言えば普通それ以上考えません。

でも、「じゃあ製品に組み込む時どうすんの?」とかそういう話になってくると「いやー、LPC-LINK使うかなぁ?(←使わないでしょ。)」とか、「本当に動くのかなー。(←そりゃ動くだろうよ。)」みたいな話になってきます。

そこで、今回はLPCXpressoのターゲットだけを切り離して、JTAGデバッガと接続するお話です。

ユーザとしては「使い慣れた」、あるいは「既に投資してしまった」デバッガや環境を使いたいわけです。
ここでは手始めにデバッガ(LPC-LINK)とターゲットを切り離して使うことを考えます。


まずは回路図を確認します。
LPCXpressoは以下のようなデザインになっています。


LPC-LINK側から+3.3[V]を給電してもらってターゲットが動作するようになっています。
「じゃあ、USBに接続しないで動作させるにはどうするの?」という話ですが、これは図にある通り、「Expansion connector」から外部電源電圧(+5.0[V])をもらい、それがそのままLPC-LINKに入って、先ほどの+3.3[V]を生成するという設計です。

ちょっと考えてみましょう。
LPC-LINKとターゲットを切り離してみてください。
そして、整理してみます。

  • LPC-LINKは+5.0[V]から+3.3[V]を生成する。
  • ターゲットは+3.3[V]を給電されて動作する。
  • ターゲットは+5.0[V]を給電されても、LPC-LINKにそのまま渡すだけ。(要するにターゲットと+5.0[V]は一切関係ない。)
何が言いたいのかというと、「LPC-LINKとターゲットを切り離すと+3.3[V]を何らかの方法で給電しなければ動作しないボードになってしまう。」ということなんです。

また、図面には「Superset of mbed connector」と書かれていますが、これは大嘘。
なぜなら、mbedの40ピン目は+3.3[V]の出力です。


LPCXpressoのターゲットはLPC-LINKを接続している限り「+3.3[V]を出力」しますが、切断した途端にここから+3.3[V]を入れるという前提になっています。これでは当該ピンから+3.3[V]が供給される前提で設計されているベースボードは動作しないことになります。
これは明らかにスーパーセットではありません。
この時点で「superset of mbed pinning」は信用しないことにしました。
この設計はLPC-LINKを使わせる前提なのでしょう。

以下は図面の最後のページのピンアサインです。
初めは「self powered」の意味がわかりませんでしたが、「デバッガ+ターゲット=セルフ」ということみたいです。


そうなると「じゃあどうするの?」という現実的な問題になってきます。

  • LPCXpressoのターゲットの問題は単に+3.3[V]のみ。
  • 手軽に取り出せるのは、例えばUSBの+5.0[V]。
  • パソコンとターゲットとデバッガI/Fだけで開発したい。

私はこうしました。
  • LPCXpressoのターゲット上で+3.3[V]を+5.0[V]から生成するようにしよう。
  • LPCXpressoのデバッガは+3.3[V]の出力にダイオードを突き当ててるから大丈夫。
  • ターゲット用の+5.0[V]はUSBから頂こう。
結果としてできたのがこれ。

LPCXpresso上の配線は以下のようになっています。
EXT_POWXから+5.0[V]をもらい、+3.3[V]に降圧してからVIO_3V3Xに給電です。
コンデンサは後で。

こうすれば(※J6-29にUSBの+5.0[V]を渡す必要もある。)電源面から見ると「mbedとほぼsuperset」と言えます。また、パソコンさえあればデバッグが開始できます。

通常、デバッガはターゲットのI/O電源電圧をリファレンスとしてもらってI/Oを駆動する形をとります。
LPC-LINKは積極的にターゲットに電源を供給する前提で設計されています。
そういう意味で「切り離して使えます」と言われてはいるものの、LPCXpresso LPC1768にかなりフォーカスしたデバッガと考えていた方が良いかもしれません。

この次にJTAGKey2Pによる動作確認です。

2010年12月1日水曜日

Time elapse image using mbed NXP LPC1768



The components
* mbed NXP LPC1768
* microSD card
* LinkSprite JPEG Color Camera LS-Y201

The content is UNIQLOCK.
http://www.uniqlo.jp/uniqlock/