9353log @mits-whisper-blog - Tumblr Blog

Avahiを使ってBonjour

Avahi絡みで恐ろしく手間取ったことがあったのでメモしておく。

もともと自分の環境では、プリンター(EPSONのインクジェットPX-101)をApple製のNAS(と言って良いのか知らんが)であるTimeCapsuleにつないで「Bonjour(Apple製Zeroconf)」経由で、いくつかのホストPCから印刷していた。

ホストPCはMacとWindowsで、Macの場合はほとんど何もせずに、Windowsの場合は「Bonjour for windows」というApple謹製のアプリがあるので、それを使って問題なく印刷できていた。

ここに、あらたにUbuntu 14.04LTSを搭載したホストPCを追加しようとしたのが事の発端である。以下に手順をまとめておく。

プリンターの追加

TimeCapsuleのUSBポートに接続したプリンターの電源を入れておく。

Ubuntuトップメニュー右端の歯車メニューから「システム設定...」を選択。

「ハードウェア」内にある「プリンター」をクリック。

表示されたウィンドウで「追加」ボタンをクリック。

「ネットワークプリンター」の行を展開し、しばらく待つとTimeCapsuleに接続したプリンタ名が表示される(例: Epson PX-101...など)。ここで表示されなければ、TimeCapsuleとの接続が疑わしい。もしくはプリンターの電源が入ってないとか。

表示されたプリンター名をクリックして「進む」ボタンをクリック。

「ドライバーを検索中」ダイアログが表示されて、ドライバのインストールが開始する。余程マイナーなプリンタでない限り、ここで見つかるだろう。

「プリンターの説明」ウィンドウが表示されるので、適当に入力して「適用」をクリック。

「テストページを印刷しますか？」というダイアログが表示されるので「テストページの印刷」をクリック。「送信しました」というダイアログが表示される。この時にプリンターでテストページの印刷が始まればお目出度う。この後の設定は不要です。

スタティックルートの設定

プリンターのプロパティダイアログの「プリンターの状態」で「処理中 - プリンターが応答していません。」と出ていた場合は、私が被った問題と同じことが起きていると思われる。

TimeCapsule自体には当然IPアドレスがあるが、そのUSBポートにつながっているプリンターにも「それとは別の」IPアドレスが割り当てられる。ただし、このIPアドレスは一般的なローカルIPアドレス(例: 192.168.*.*など)ではなく、リンクローカルアドレス(169.254.*.*/16)が使われている。

「プリンターが応答していません」と出た場合は、ubuntuから送信されたリンクローカルアドレスが、ちゃんとTimeCapsuleに届いていない可能性が考えられる。

自分のネットワーク環境では、TimeCapsuleをブリッジとして使用しており、WANにはBuffalo製のルーターを使っている。UbuntuをインストールしたホストPCは、このプリンター宛リンクローカルアドレス(169.254.*.*)へのデータ送信をBuffaloルーターへ投げていた。 Buffaloルーターにとっては、こんなアドレスを知る由もなく、データは無視され、結局先の現象となっていた。

とりあえず、リンクローカルアドレスへの送信は、すべてTimeCapsuleに投げる事にする。この静的ルーティングの設定は/etc/network/if-up.d/へstatic-routesを作り(既にあれば追記)、以下のような行を追加すれば良い。忘れずに実行属性(chmod +x)を付けておくこと。

#!/bin/sh /sbin/route add -net 169.254.0.0 gw <TimeCapsuleのIPアドレス又はAvahi名> netmask 255.255.0.0 dev <eth0などのIF名>

自分のように、TimeCapsuleをブリッジとして使っている場合は、IPアドレスをDHCPで割り当てると思うので、Avahi名を使った方が良いと思う。 Avahi名は、ベースステーション名(AirMacユーティリティを起動した時に表示される名前)に「.local」を付けたものだ。自分は「TimeCapsule」と名づけたので「TimeCapsule.local」がAvahi名になる。

また、インターフェース(IF)名は、無線LANの場合はwlan0あたりになるだろう。この点はifconfigで調べれば良い。

#avahi #bonjour

Ｃプログラマのためのdoxygen

doxygenとは、ソースコード内に含まれる規定の形式のコメント(doxygenコメント)から、ドキュメントを自動生成してくれるシステムである。 doxygenでは各種プログラム言語がサポートされているが、ここではＣプログラム中心に話しを進めている。

自分は普段Ｃでプログラムを書いているが、doxygenコメントについて備忘録的なものが欲しいと思いまとめてみた。そういった経緯があるので、このまとめは少し情報に片寄りがあると思う。

このまとめでは doxygen 1.8.9.1 をベースにしており、自分の環境(Mac OS X)での表示をサンプルとして挙げている。出力結果の文言が変わったりするだろうが、他の環境でもそれほど大きな違いはないだろう。

doxygenは数多くの設定を持つが、自分はほとんどデフォルトのままで使用している。しかし、使うに当たって調整した方が良いものもある。そのような設定に関しては、[7] インストール時に設定したものとしてまとめておいた。

[1] 単なるＣプログラムをdoxygenにかける

[2] doxygenコメント

[3] 改行

[4] 箇条書きと連番リスト

[5] Markdown記法

[6] doxygenコマンド

[6-1] 総合概要(メインページ)と諸情報

@mainpage, @page, @section, @subsection, @par

[6-2] ファイルヘッダと変更履歴

@file, @brief, @author, @date, @version, @copyright, @par

[6-3] 関数ヘッダ

@brief, @param, @retval, @return

[6-4] 関数の事前条件と事後条件

@pre, @post

[6-5] 関数などの自動リンク

@sa

[6-6] 注意、警告、バグ、todo

@remarks, @attension, @warning, @bug, @note, @todo

[7] インストール時に設定したもの

参考URL

本家(英語): http://www.doxygen.org/

日本語版: http://www.doxygen.jp/

日本語で非常に助かるが、残念ながら対象バージョンが古い。

Graphviz: http://graphviz.org/

図形描画パッケージ。doxygenから使う。

[1] 単なるＣプログラムをdoxygenにかける

doxygenは、ソースプログラムに含まれている特殊な形式のコメント(doxygenコメント)をもとに、ドキュメントを自動生成してくれるシステムだが、doxygen形式のコメントが入ってない普通のＣのプログラムを入力しても、それなりの出力をしてくれる。

以下のようなファイル(hello.c)の先頭に/** @file 〜 **/の行だけを入れてみてdoxygenにかけてみる。

/** @file hello.c **/ #include <stdio.h> const char greeting[] = "Hello, World"; int main(int argc, char **argv) { puts(greeting); return 0; }

先頭ページで「ファイル」というタブをクリックすると以下のような表示になる。「hello.c」がリンクになっている。

出力例：

「hello.c」をクリックすると以下のような表示になる。

出力例：

このように、includeファイルの依存関係や、定義されている関数、変数などの一覧をちゃんと解析して出力してくれる。(ここには無いが、マクロ、構造体、列挙型もあれば解析して出力してくれる。)

残念ながら、それ以上の情報は出てこないが、それでもただのＣプログラムから、これだけの情報を抽出してくれる。

この出力に肉付けしていくのがdoxygenコメントとなる。

ちなみに、Ｃプログラムでは、ここで示した/** @file 〜 **/の行は必須である。また、ファイル名も必ず一致してなければならない。これを間違うと何も有用な出力が成されない。

☞目次へ戻る。

[2] doxygenコメント

doxygenコメントは以下の四つの形式がある。

① /** ～ */ ② /*! ～ */ ③ /// ～ ④ //! ～

原則的に、これらは書き方が異なるだけで大きな違いはない(微妙な違いについては、あとで触れる)。例えば①の形式ならば、/**の部分がキーとなるようで、以下のように色々な記述の仕方ができる。

/** バッファの説明 */ unsigned char Buf[1024];

/** バッファの説明 **/ /*** これはdoxygenコメントではないでの無視される ***/ unsigned char Buf[1024];

/** * バッファの説明 */ unsigned char Buf[1024];

/** バッファの説明 */ unsigned char Buf[1024];

/*************************************//** * バッファの説明 ******************************************/ unsigned char Buf[1024];

最後の例は、通常のコメント/*****...*/の後ろから①のコメントが始まっている形式だ。これらは、すべて同じ出力になる。

出力例：

さらに、①〜④のコメントの左端に<を付けることにより、行の後ろにdoxygenコメントを置くことができる。

①' /**< ～ */ ②' /*!< ～ */ ③' ///< ～ ④' //!< ～

先の例を使って示すと、以下のようになる。これも同じものが出力される。

unsigned char Buf[1024]; /**< バッファの説明 */

ちなみに、①と②(/*で始まる)、③と④(//で始まる)は、お互いに同じ出力となるが、①、②系と③、④系の出力は微妙に異なるようだ。

unsigned char Buf1[1024]; /**< ①、②系バッファの説明 */ unsigned char Buf2[1024]; ///< ③、④系バッファの説明

出力例：

①、②系は変数詳解が別に設けられて表示されるようであり、「変数」欄の「Buf1」がリンクになっており、「変数詳解」欄に飛ぶようになっている。 ③、④系は変数欄にまとまって出力される。これらは、好みに応じて使い分ければ良いだろう。

ちなみに①'～④'の形式は、どちらかというと構造体のメンバ説明や、列挙型の項目説明で使うのが本来の用途なのだろう。

/** 解析の状態値 **/ enum CommandSta { IDLE, /**< アイドル **/ ACT, /**< 稼働 **/ SLEEP, /**< 停止中 **/ };

出力例：

/** 解析の状態値 **/は①形式のdoxygenコメントであるので、「列挙型詳解」欄に出力されている。これを/*** 解析の状態値 ***/などとしては出力されなくなる。

☞目次へ戻る

[3] 改行

doxygenコメント内の文章は、実際の改行位置とは無関係に、詰めるだけ詰めて表示される。明示的に改行したい場合は、何も無い空のコメント行を挟む必要がある。以下に例を示す。

/** * 単純な改行は * 詰めるだけ詰めて表示される。 * 明示的に改行したい場合は、以下のように * * 空のコメント行を挟む。 */ void dummy(void) { /* 何もしない */ }

出力例：

コメントブロック内の各行を*で始めているので、この文字列だけの行(スペースやタブは無視されるようだ)があれば、そこが段落の区切りとなり、改行されて出力される。以降、このような空のコメント行のことを、単に「空行」と呼ぶ。

doxygenは最終的にHTMLに翻訳されるため、HTMLでおなじみの タグでも改行できる。また、doxygenコマンド自体に「改行」を意味する\nや@nといったコマンドがあるので、これらを入力しても改行できる。

以下の例では、この他にHTMLタグであるタグを使用している。

/** * タイトル * ・最初の説明 * ・ニ番目の説明\n * ・三番目の説明@n * ・四番目の説明 */ void dummy(void) { /* 何もしない */ }

出力例：

なお、上のようなケースでは「[4] 箇条書きと連番リスト」で説明する「箇条書き」を使った方が、もっとスマートに記述できる。

/** * タイトル * * - 最初の説明 * - ニ番目の説明 * - 三番目の説明 * - 四番目の説明 */ void dummy(void) { /* 何もしない */ }

出力例：

ところで、MacOS Xでバックスラッシュ「＼」を入力する時には注意が必要である。 Mac OS Xでは、半角の円記号「￥(0xa5)」と半角のバックスラッシュ「＼(0x5c)」が明確に区別されており、キーボードの「￥」キーを押した時にどちらが入力されるかは「システム環境設定」に依存する。

試しに「￥」キーを押した時に「￥」が表示されたら、それは円記号「￥(0xa5)」でありバックスラッシュ「＼(0x5c)」ではない。だから「￥ｎ」と入力しても改行されない。この場合は、Optionキーを押しながら「￥」キーを押すと良い。デフォルトでバックスラッシュを入力したいと思ったら「システム環境設定」での変更が必要だ。

日本語版Windowsでは、この点がうまく隠されており、「￥」キーを押した時は「＼(0x5c)」が入力される。さらに、日本語フォントの場合はバックスラッシュ「＼(0x5c)」を「￥」と表示する。だから「￥ｎ」と表示されていても、ちゃんと改行されるのだ。

ちなみに、上記の例のように、コメントの中にやたらや などのHTMLタグが入っているコードを見ることがあるが、あれは何だろう。ひどいものになると、偏執狂的に各行、各行に が付いていたり、お飾りのためのHTMLタグも入っていたりする。

そのHTMLタグはdoxygenの整形プログラムを通らないとまともに見られないわけで、普通にソースコードリーディングしている分には目障りで見苦しいばかりなのに。 doxygenコメントに凝るのも良いが、普段は普通に読めて、doxygenに通せば、より綺麗に読めるコメントの書き方をするのが本筋だと思うのだが。

何か途中から全然doxygenの説明になってませんね。

☞目次へ戻る

[4] 箇条書きと連番リスト

doxygenコメント内に、-や-#で始まる行を記述すると、箇条書きや連番リストとして出力される。

-とスペースで「箇条書き」となる。タブやスペースで段付けすると、より低いレベルの箇条書きを示すことができる。また、.のみの行は、そのレベルの箇条書きを終了させる。

/** * タイトル * * - 箇条書き1 * - 箇条書き2 * - 箇条書き2-1 * この行は上の行に詰めさせられる。 * - 箇条書き2-1-1 * . * 箇条書き2-1の追加説明 * - 箇条書き2-2 * - 箇条書き3 */ void dummy(void) { /* 何もしない */ }

出力例：

上の例の通り、隣接する行は詰めるだけ詰めて出力されるので、これが嫌な場合は、同じレベルにドット(.)だけを置くことにより、その前の箇条書きを終わらせることができる(箇条書き2-1-1の後の.のみのコメント行がそれだ)。

先頭を-#で始めると連番リストになる。

/** * タイトル * * -# 連番リスト1 * -# 連番リスト2 * -# 連番リスト2-1 * -# 連番リスト2-2 * - さらに箇条書きを含めることも可能。 * このように別の行に書いても詰めさせられる。 * . * . * 同じレベルにドットをおくことで該当のレベルを強制的に * 終わらせる。 * -# 連番リスト3 * . * -# 連番リスト(新しい1) */ void dummy(void) { /* 何もしない */ }

出力例：

「連番リスト3」の後に.だけの行がある。これで次からは新しい連番リストとなる。

普通にソースコードリーディングしている場合は、-はまだしも、-#は単なる変な記号にしか見えない。doxygen 1.8.0からは、Markdownと同じく1.や2.という連番リストが振れるようになった。 Markdownサポートに関しては次の項で説明する。

☞目次へ戻る

[5] Markdown記法

doxygen 1.8.0 からはMarkdown記法もサポートされるようになった。

Markdownのような箇条書き、連番リスト、表、水平線、その他の記述ができるようになった。以下に例を示す。

/** * ### タイトル * * この関数の機能 * _ _ _ * 1. メイン機能 * * 説明1 * * 説明2 * 2. サブ機能 * 1. サブ機能1 * 2. サブ機能2 * * | 左詰め | 中央揃え | 右詰め | * |:------ |:--------:| ------:| * | 1-1 | 1-2 | 1-3 | * | 2-1 | 2-2 | 2-3 | */ void dummy(void) { /* 何もしない */ }

出力例：

「###」はMarkdownのタイトル指定(H3を使用)、「_ _ _」は水平線だ。

オリジナルのMarkdown記法の他に、いくつかの有名な拡張機能もサポートされているようなので、参考までに以下にURLを貼り付けておく。

Doxygen Markdown support

URL: http://www.stack.nl/~dimitri/doxygen/manual/markdown.html

なお、残念ながら「行末にスペースを二つ以上入れての改行」での「強制改行」はサポートされていないようだ。やっぱり互換性とかに問題があるのだろうか。

☞目次へ戻る

[6] doxygenコマンド

doxygenコメントの中に、\や@で始まる特殊コマンドを挟み込むことにより、色々な情報を付加して出力することが可能となる。これ以降は、そのような特殊コマンドについて、目的別に説明して行こう。

なお、ここでは特殊コマンドを@形式で記述するが、これは単純に自分の好みである。例えば、@briefは\briefと記述しても良いので、好みの方を選べば良いだろう。

☞目次へ戻る

[6-1] 総合概要(メインページ)と諸情報

doxygenで作ったドキュメントで一番最初に表示されるページ(「総合概要」、又は「メインページ」)があるが、そのままだと、ここには何も表示されず、ちょっと格好悪い。

このページに載せたい文書はdoxygenコマンドの@mainpageコマンドで作ることができる。また、@pageコマンドを使えば、他のページを作ることもできる。以下にこれらの例を示す。

/** * @mainpage メインタイトル * いろいろな説明 * * @section main_sec 大項目 * 大項目の説明 * * @subsection main_subsec 中項目 * 中項目の説明 * * @par 小項目 * 詳しくは @ref more_info も参照のこと。 */ /** * @page more_info 補足説明 * 色々な補足の説明。 * 大本の @ref main_sec も参照のこと。 */ /** * @page more_info2 さらなる補足説明 * さらに色々な補足の説明。 */

これらのコメントは、同じファイルに記述しても良いし、別々のファイルに記述しても良い。 @mainpageに記述したコメントが最初のページ(「総合概要」、又は「メインページ」)に表示される。

出力例：最初のページ(総合概要、又はメインページ)

上記例の「小項目」中にある補足説明はリンクになっている。これは@refコマンドの結果だ。

@pageに記述したコメントが「諸情報」ページに表示される。

出力例：@pageで作ったページ(諸情報)

この例での補足説明と、さらなる補足説明は全てリンクになっている。クリックすると以下のようなページが表示される。

出力例：補足説明

出力例：さらなる補足説明

「補足説明」のページの大項目の部分も@refコマンドで作ったリンクになっている。

@section、@subsection、@page各コマンドの左のmain_sec、main_subsec、more_info、more_info2は、全て@refコマンドでのリンク先に使う。クリックすると、それぞれ該当のページを表示する。

なお、@refコマンドでリンクを張る場合は、上記例のように、名前の前後にスペースが必要である。スペース無しで前後に詰めて書いてしまうとリンクとして認識されなくなる。

☞目次へ戻る

[6-2] ファイルヘッダと変更履歴

プログラムファイルの先頭には、そのファイル自体の説明や変更履歴などを記述すると思う。

それらの情報を見栄えよく出力してくれるdoxygenコマンドがある。以下にその例を示す。

/** * @file RingBuf.c * @brief リングバッファライブラリ * * 一般的なリングバッファ制御のためのAPIをまとめたライブラリ。 * * @author mits * @date 2015.01.20 * @version 1.0 * @copyright 2015 Mits Corp. All rights reserved. * * @par 変更履歴: * - 2015.01.15: mits: 新規作成 * - 2015.01.20: mits: 以下の通り * 1. 空きバッファサイズの計算方法がおかしかったので直す。 * 2. 関数名のリファクタリングを行った。 * - Command* → Cm_* * - Driver* → D_* */

まず、「ファイル」ページにファイルの一覧が表示される。

出力例：

ファイル名の脇に表示されているメッセージは@briefコマンドで記述したものである。このファイル名(例ではRingBuf.c)はリンクになっている。

ファイル名をクリックすると、doxygenコメントで書いた情報が表示される。

出力例：

項目コマンド説明ファイル名 @file ファイル名を示す。必須項目であり、これが無いとＣプログラムでは、まともにページを作ってくれない。また、ここで記述するファイル名は、実際のファイル名と一致してなければならない。概要 @brief 本ファイルの概要説明。ファイル一覧ページでは、この概要説明が使われる。なお、上記例のように、@briefのあとに空行を一行挟んだ後、詳しい説明を書くのが一般的だ。作者、日付け、バージョン、著作権 @author, @date, @version, @copyright いつもの記述。お好みでどうぞ。段落 @par @parコマンドは、別に変更履歴用のコマンドではないが、このようにまとまった文章を書くために重宝するので使っている。この例で示したように、複数の情報を列挙するには「箇条書き」や「連番リスト」が非常に重宝する。わざわざ見苦しく を乱発しなくても済む。

☞目次へ戻る

[6-3] 関数ヘッダ

関数定義の前に、その関数の処理内容や引数、戻り値などの説明を書いたりするが、それらを見栄えよく出力してくれるdoxygenコマンドについて説明する。以下に例を示す。

/** * @brief 概要説明 * * その簡単な説明。 * * @param[out] op 出力パラメータ * @param[in] ip 入力パラメータ * @param[in,out] iop 入出力パラメータ * @retval true 処理成功。 * @retval false 処理失敗。 */ bool dummy(char *op, int ip, int *iop) { /* 略 */ }

出力例：

関数の戻り値を示すdoxygenコマンドとしては、他に@returnもある。

/** 〜略〜 * @return 0～MAX_BUFの範囲値を返す。〜略〜 */

出力例：

項目コマンド説明概要 @brief ファイルヘッダでも使った@briefコマンドだ。関数一覧には、ここで記述した文章が出力される。ファイルヘッダ同様に、空行を一行挟んだ後、説明を書くのが一般的だ。引数 @param 関数の引数は、このコマンドで指定する。この例のように、各引数には出力・入力・入出力の情報を付加することも可能である(付けなくても良い)。戻り値 @retval, @return 戻り値を示すためのコマンドとしては二種類ある。列挙型やブール値など、いくつかの項目に分類して説明したい時は@retval、ひとまとまりの文章で説明したい場合は@returnを使う。

説明したいことがたくさんある場合は、先に示した@parなどを使うのも良いだろう。お好みで、先に示した@authorや@dateなどを使っても良いが、まず間違いなくメンテナンスされなくなると思うが…

☞目次へ戻る

[6-4] 関数の事前条件と事後条件

関数の中でassert()を使った場合、その表明内容を説明するのに適したdoxygenコマンドもある。 @pre、@postがそれで、以下に例を示す。

/** * @brief 簡易メモり割り当て * @param sz 割り当てサイズ * @return 割り当てたメモリ * @pre szは1〜MAXBUFの範囲内にあること。 * @post メモリ割り当ては常に成功する。 */ void *alloc(int sz) { void *p; assert(0 < sz && sz <= MAXBUF); /* 〜 */ assert(p != NULL); return p; }

出力例：

ちなみに、これらのコマンドはコードの中に直接書いても構わない。出力結果は、先の例と同じで、関数説明としてすべてまとめて表示してくれる。

void *alloc(int sz) { void *p; /** @pre szは1〜MAXBUFの範囲内にあること。**/ assert(0 < sz && sz <= MAXBUF); /* 〜 */ /** @post メモリ割り当ては常に成功する。**/ assert(p != NULL); return p; }

☞目次へ戻る

[6-5] 関数などの自動リンク

doxygenコメント内で、関数名などにリンクを付けることができる。以下のように、関数名に続けて()を記述し、前後の文章とスペースで間を空けておく。

/** * @mainpage * リングバッファライブラリ * * @section main_api API一覧 * | API名 | 機能 | * |:-------------- |:-------------------------------- | * | Rbuf_ini() | リングバッファの初期化 | * | Rbuf_putChr() | リングバッファへ1文字出力 | * | Rbuf_getChr() | リングバッファからの1文字入力 | * | Rbuf_isEmpty() | リングバッファが空かどうかの判断 | * * @section main_usage 使用方法 * - あらかじめ Rbuf_ctl 型の変数を定義しておく。 * - その変数で Rbuf_ini() を呼び出す。 */

出力例：

関数ヘッダで@briefで記述したコメントがポイントした時に表示される。クリックすると該当の関数定義のページが表示される。また、この例の「使用方法」欄のRbuf_ctlは構造体タグ名であるが、この前後にもスペースで間を空けているので、自動リンクが付いている。

このように、関数名以外にもいくつか自動リンクされるものがある。参考までに、以下に自動リンクの説明ページを貼っておく。

Automatic link generation

URL: http://www.stack.nl/~dimitri/doxygen/manual/autolink.html

当然のことながら、リンク先の関数にdoxygenコメントが付いてないと自動リンクされない。

なお、関数参照としては「参照」セクション内に書く流儀もあるだろう。そのような場合は@saコマンドが使用できる。

/** * @brief 一人じゃ何もできない関数 * @sa mama() と papa() */ void baby(void) { /* ... */ }

出力例：

☞目次へ戻る

[6-6] 注意、警告、バグ、todo

何らかの注意を喚起するために、doxygenコメントの中に以下の六種類の記述が可能である。状況に応じて使い分ければ良いだろう。

/** * @brief 制御構造体 * * 非常に重要な構造体 * * @remarks 単なる情報を書きたいとき。 * @attention 注意を喚起したいとき。 * @warning 何らかの警告をしておきたいとき。 * @bug バグが存在するとき。 * (別ページで一覧がリスト化される。) * * @note 何らかのメモ書き。 * @todo やるべきことを書いておく。 * (これも別ページで一覧がリスト化される。) */ typedef struct Control { int member1; ///< 最初のメンバ int member2; ///< 次のメンバ int member3; ///< 三番目のメンバ } Control;

出力例：

@bugと@todoに関しては、@pageコマンドでも使われる「諸情報」ページ内に一覧がリスト化される(上の例でも「バグ」と「todo」には、該当ページへのリンクが付いている)。「諸情報」ページのtodo一覧、バグ一覧は、それぞれリンクになっており、クリックするとそれぞれ該当のページが表示される。

各リンクをクリックした時に表示される画面。それぞれ、doxygenコメントで書いたものが出力される。

出力例：

☞目次へ戻る

[7] インストール時に設定したもの

doxygen設定ファイルのDoxyfile内の設定で、必須なもの、調整が必要だったものなどを挙げておく。

Project

PROJECT_NAME

プロジェクトの名称。出力ドキュメントのページのタイトルとして使われる。デフォルトはMy Projectなので、好みの名称に変えておいた方が良いだろう。

OUTPUT_DIRECTORY

ファイルの出力先。適当な場所を設定しておく。

OUTPUT_LANGUAGE

日本語のドキュメントで出力して欲しいのでJapaneaseとしている。

TAB_SIZE

ソースコードのタブ幅を何文字としているかをdoxygenに教える。デフォルトは4で、1～16の範囲で指定できる。自分はプログラムを4タブで使用しているのでデフォルトのままだ。

OPTIMIZE_OUTPUT_FOR_C

デフォルトは無効(NO)だが、有効(YES)にするとCプログラムに適した最適化をしてくれる。原則的に自分はCでしか使わないので有効(YES)にしている。

MARKDOWN_SUPPORT

doxygen ver.1.8.0からはコメント内でのMarkdown記法がサポートされている。この設定で、doxygenでMarkdown記法を使うかどうかを選択できる。デフォルトで有効(YES)なので、Markdown記法がうっとうしい場合は無効(NO)にすれば良い。

Build

EXTRACT_STATIC

static定義された関数や変数をドキュメントに出力するかどうかを指定する。デフォルトのままだと出力されない(NO)ため、自分はYESにしている。

EXTRACT_PRIVATE

Ｃ＋＋の場合privateメンバをドキュメントに出力するかどうかを本設定で選択する。デフォルトのままだと出力されない(NO)ため、それが嫌ならばYESにすれば良い。Ｃプログラマにとってはどうでも良いことだが。

GENERATE_TODOLIST

@todoコマンドのリストを別ページに作るかどうかを指定する。デフォルトで有効(YES)である。特に必要ない場合は無効(NO)にする。

GENERATE_BUGLIST

@bugコマンドのリストを別ページに作るかどうかを指定する。デフォルトで有効(YES)である。特に必要ない場合は無効(NO)にする。

Input

INPUT_ENCODING

入力プログラムの文字エンコーディング。デフォルトがUTF-8であり、変える必要はないと思うが、恐ろしく古いプログラム(SHIFT_JISやEUC-JPファイル)などをそのまま読み込ませる場合には変える必要がある。

RECURSIVE

入力プログラムをサブディレクトリからも取り込む場合は有効(YES)とする。デフォルトは無効(NO)なので、プログラムコードをサブディレクトリに分けている場合は有効(YES)にする必要あり。

USE_MDFILE_AS_MAINPAGE

この設定で総合概要(メインページ)を作るために任意のMarkdownファイルを指定できるようだ。 GitHubで用意したReadMe.mdを、そのまま使うこともできる。関数名の自動リンクもやってくれるようだが、微妙にMarkdownの解釈が異なるようで、使うならば出力結果を確認してからの方が良い。

HTML

GENERATE_TREEVIEW

有効(YES)にすると、サイドパネルにツリー状の目次を付けてくれる。良かったら、どうぞ。

Dot

HAVE_DOT

図形描画でGraphvizのdotコマンドを使う場合は有効(YES)とする。

DOT_PATH

図形描画用のGraphvizのdotコマンドのあるパスを設定する。ブランクにしておけば勝手にコマンドパスから探してくれるということだったのに、Mac OS Xでは見つけてくれなかった。なぜ？しようがないので、dotのインストールされている/usr/local/binを設定してやる必要があった。

☞目次へ戻る

#doxygen #reference

tumblrでのmarkdown

tumblrで使えるマークダウン(markdown)記法について少しまとめてみた。

markdownの参考ページとしてはMarkdownや、PHP Markdown Extraや、GitHub Flavored Markdownがあるけれども、tumblrではサポートしていたり、してなかったりらしい。

[1] 改行 [2] 斜体、太字、等幅、その他の修飾 [3] 表 [4] 水平線 [5] タイトル、アンカー [6] リンク [7] 画像 [8] 箇条書きと連番リスト [9] コードブロック [10] 引用文 [11] 脚注

[1] 改行

単純な改行は詰めるだけ詰めて表示される。明示的に改行したい場合は、行末にスペースを二つ(→) で改行。明示的な空行でも段落分け

表示例：

☞目次へ戻る

[2] 斜体、太字、等幅、その他の修飾

文字修飾は、*や_を使う。また、HTMLタグを直接記述することで修飾することもできる。

アスタリスク`*`による文字の*斜体化(Emphasize)*と**太字化(Strong)**。アンダースコア`_`による文字の_斜体化(Emphasize)_と__太字化(Strong)__。文字の上付き、下付き、Copy right ©マークなど。バッククォート`` ` ``による`等幅(monospace)`かつ、文字そのまま`**__`の表示。

表示例：

☞目次へ戻る

[3] 表

表は|と:と-で記述する。:の書き方で左・中央・右寄せが可能。

| タイトル1 | タイトル2 | タイトル3 | |:--------- |:---------:| ---------:| | 左寄せ | 中央 | 右寄せ | | ●　　　 | ▲ | ■ | | ○　　　 | △ | □ |

表示例：

☞目次へ戻る

[4] 水平線

水平線は-、*、_を三つ以上連続することで記述できる。

ハイフン`-`による水平線 - - - アスタリスク`*`を使った場合 * * * アンダースコア`_`を使った場合 _ _ _ 三つ以上つなげればOK ___

表示例：

☞目次へ戻る

[5] タイトル、アンカー

タイトルは、文字の下に=か-を引くか、先頭に#を付けることで書くことができる。

タイトル1 ========= タイトル2 --------- # タイトル1 ## タイトル2 ### タイトル3 #### タイトル4 ##### タイトル5 ###### タイトル6

表示例：

タイトルにはアンカーを付けることもできる。このページの目次は、このアンカー記法を使って記述している。

# アンカー付きタイトル {#my_funny_valentine} ～たくさんの文章～～たくさんの文章～～たくさんの文章～ [元の場所](#my_funny_valentine)へ戻る

表示例：

☞目次へ戻る

[6] リンク

<>でURLかメールアドレスを囲むか、以下のような表記方法でリンクを記述できる。

リンク<http://example.com/>とメールアドレス<[email protected]>。もう一つの[リンク](http://example.com/ "ホームページ")の表し方。さらにもう一つの[リンク][link]の表し方。 [link]: http://example.com/ "ホームページ"

表示例：

☞目次へ戻る

[7] 画像

画像(http://example.com/jiro.jpg)の挿入方法は以下の通り。

![画像1](http://example.com/jiro.jpg "ジロの勇姿")

表示例： ※マウスをポイントすると""の文字列が表示される

ローカルファイルならば、URLでなくファイルパスの指定でも可能。また、以下のようにURLを分ける書き方もある。

![画像2][jiro] [jiro]: http://example.com/jiro2.gif "威風堂々"

表示例：

☞目次へ戻る

[8] 箇条書きと連番リスト

箇条書きは-、*、+のどれかで始める。段付けもしてくれる。

- 箇条書き1 * 箇条書き2 + 箇条書き3 * 箇条書き3-1 - 箇条書き3-1-1 箇条書きの後には、このような通常文が無いと表示が乱れる模様。

表示例：

連番リストは数字と.とスペースで始める。段付けも可能。数字はバラバラでも揃えてくれる。

1. 連番リスト1 1. 連番リスト2 1. 連番リスト3 1. 連番リスト3-1 1. 連番リスト3-2 1. 連番リスト3-2-1 1. 連番リスト3-2-2 連番リストも同様。

表示例：

☞目次へ戻る

[9] コードブロック

文全体をタブで段付けするとコードブロックの表示となる。

/* コードブロック */ #include <stdio.h> int main(int argc, char **argv) { printf("Hello, World\n"); return 0; }

表示例：

☞目次へ戻る

[10] 引用文

引用文は>とスペースで始める。

> 引用文1。引用文の続き(分けるには明示的な空行が必要)。

表示例：

☞目次へ戻る

[11] 脚注

脚注の入れ方は以下の通り。

脚注[^darjeeling]を使った説明[^assam]。～たくさんの文章～～たくさんの文章～～たくさんの文章～ [^darjeeling]: このようにページ最後に説明がまとまって表示される。 [^assam]: こちらも同様。

表示例：

☞目次へ戻る

#markdown #reference

梅＊＊

去年紫陽花を見に行った公園で、梅が花開いてきたらしいので見に行ってきた。

自分は鈍感なせいか、鼻を近づけても全然匂わなかったが、紫陽花の頃には、自分でも分かるぐらいの良い匂いの梅の実になるのだろう。

春には梅・桃・桜の順番で花開き、梅の花が一番最初に咲く、と聞いたふうな知ったかぶりの知識でひとり悦に入っていたら、これも咲く、と梅を見に来ていた爺さんに言われてしまった。

「先ず咲く」満作だそうです（最後の写真）。

#梅 #風物詩 #japanese apricot #diary

LPC810(17) 〜 ISPモードをバイパスする

LPC810はタダでさえピン数が少ないため、各ピンにどのような機能を割り当てるかが悩みどころとなるが、特に5番ピンを使う場合は注意が必要である。

LPC810の5番ピンは、内蔵フラッシュROMの書き換えを行うためのピンとして、マイコン固定で機能が割り当てられており、リセット時にこのピンがLowになっていると、強制的に「ISPモード」と呼ばれる特別のメンテナンスモードとして起動してしまう。

なお、ISPモードに関しては「ISPモードでのプログラム書き込み」で説明した。

別に5番ピンをGPIOとして使ってなくても、また、入力ポートとしてさえ使ってなくても、リセット時にLowが読める回路構成になっていると、強制的にISPモードに移ってしまう。

自分は、ついうっかりと、5番ピンがGNDにつながるような回路構成を作ってしまい、一度ハマってしまったことがあった。

一旦ISPモードになってしまうと、これを抜けるには5番ピンをオープン、又は電源につなぎ直してマイコンをリセットするか、ISPモード内からUART経由でISPコマンドで指示するかしか手段が無い。要するに、ハタから見るとロックアップしているようにしか見えなくなってしまうのだ。

これは、わずらわしい事この上なく、だからといって5番ピンを使わずに済ませるのはピン数が少ない故に難しいため、リセット時にGNDを見ないような回路構成にしておく工夫が必要である。

ところが調べてみると、このISPモードでの起動をバイパスすることができるようなのだ。今回はその点に関してまとめておこうと思う。

ただし、ある意味取り返しのつかなくなる恐れのある手順でもあるので、その点は十分に注意のうえお試し頂きたい。

(1) NO_ISPモード

ISPモードをバイパスするには、LPC800シリーズマイコンで持つCRP(Code Read Protection)機能を使う。

これは、どちらかと言うとセキュリティのための機能であり、フラッシュROMに書き込まれているプログラムへの外部からのアクセス(読み出し、書き込みなど)を保護する機能のことである。

CRP機能には全部で4段階のレベルがあり、最高位レベルではデバッガも接続できなくなる。ここでは、その中の一番低いレベルであるNO_ISPモードを使用する。

NO_ISPモードとは、ISPモードでの起動を禁止するモードであり、一度このモードにしてしまうと、5番ピンがどのような状態になろうとも、もう該当のマイコンはISPモードで起動しなくなる。

これは、言い換えてみるとFlash Magicと接続できなくなると言うことでもあり、当然ながらFlash Magic経由でのプログラムの書き換えはできなくなる。

では、どうやってNO_ISPモードでのプログラムの書き換えを行うのかと言うと、SWDインターフェースを使ったデバッガ(LPCXpresso)経由で行うのだ。だから、これから説明するISPモードのバイパス手順は、LPC-Link 2やトラ技2014年3月号付録のデバッガ基板など、SWDインターフェースによるデバッガ接続環境が整っている場合にのみお試し頂きたい。

この環境が整ってないと、バイパスしたは良いが二度とプログラムを書き換えられなくなる。この点には十分に注意して頂きたい。

まぁ、ぶち明けた話し、LPC810自体80円ぐらいで買えるものだから、最悪の場合は捨てるつもりで試してみても良いとは思うが、この点は個人の責任でお願いしたい。

(2) CRP機能を有効にする

プロジェクトを新規に作る場合は、以下のダイアログでCRP機能のチェックを入れたままにしておくだけで良い。

新規プロジェクトの詳しい作成手順に関しては「LPCXpressoを使う(3)」を参照して頂きたい。

新規プロジェクトでなく、既にあるプロジェクトで、改めてCRP機能を有効にする場合は、Quickstartパネルの“project settings”で行う。

Propertiesダイアログが表示されたら“C/C++ Build”内にある“Settings”をクリックする。 Configurationのドロップダウンリストから“[All configurations]”を選ぶ。

“Tool Settings”タブを選択し“MCU Linker”中の“Target”をクリックする。ここで表示された項目のうち“Enable Code Read Protect”にチェックを入れる。入れた後は“OK”をクリックして終了する。

CRP機能を有効にしてプロジェクトをビルドすれば、CRP用の設定が組み込まれる。プロジェクトのmapファイル(プロジェクト名がSampleの場合は“Sample¥Debug”、又は“Sample¥Release”の内の拡張子.mapのファイル)に、以下のような記述が追加されていればOKだ(CRP_WORDで検索すれば良い)。

*(.crp) .crp 0x000002fc 0x4 ./src/crp.o 0x000002fc CRP_WORD 0x00000300 PROVIDE (__CRP_WORD_END__, .)

少し説明すると、アドレス0x2FC番地からの4バイトの値により、各種CRPモードでの起動となる。 NO_ISPモードの場合は、0x4E697370という4バイトの数値(ASCIIコードで示すと“Nisp”)を設定すれば良い。この方法は簡単だ。次の項で説明する。

(3) NO_ISPモードの選択

プロジェクトを作った時に、srcフォルダ内にcrp.cというファイルが自動生成されているはずだ。 NO_ISPモードの選択では、このファイルを変更することで行う。

このファイルの中身は、以下のようになっていると思う。

#if defined (__CODE_RED) #include <NXP/crp.h> // Variable to store CRP value in. Will be placed automatically // by the linker when "Enable Code Read Protect" selected. // See crp.h header for more information __CRP const unsigned int CRP_WORD = CRP_NO_CRP ; #endif

CRP_WORDという変数が、アドレス0x2FC番地に配置される4バイトの変数であり、初期状態ではCRP_NO_CRPを代入していると思う。これは、システムヘッダcrp.h内で0xFFFFFFFFに定義されている。同じくcrp.h内には以下のシンボルも定義されている。

#define CRP_NO_CRP 0xFFFFFFFF // Disables UART and USB In System Programming (reads and writes) // Leaves SWD debugging, with reads and writes, enabled #define CRP_NO_ISP 0x4E697370

要するにCRP_WORDにCRP_NO_ISPを設定してやれば良い(以下)。

// __CRP const unsigned int CRP_WORD = CRP_NO_CRP ; __CRP const unsigned int CRP_WORD = CRP_NO_ISP ;

変更後、プロジェクトをビルドし直す。できあがったHEXファイルをマイコンに書き込んでやれば良い。

まだ、この段階ではFlash Magicが使えるので、Flash Magicを接続し、試しに0x2FC番地の内容を見てみよう。恐らく以下のように0xFFFFFFFFとなっているはずだ。

先程ビルドし直したHEXファイルを書き込み、USBケーブルを接続したまま、改めてフラッシュROMの内容を読み出すと、以下のようにNO_ISPモードの選択コードが読めるはずだ。(リトルエンディアンなのでバイト毎の逆順に入っている。)

USBケーブルを外し、再度接続し直し、Flash Magicで接続をかけようとしても、以下のようなエラーダイアログが表示されて、もう二度とFlash Magicで接続できなくなる。

もう、このマイコンはISPモードでは起動しない。今後、プログラムの書き換えはLPCXpressoの“Debug”メニューで行う。

“Debug”メニューにより、SWDインターフェース経由でフラッシュROMの書き換えが行われる。この手順は、従来のLPCXpressoを使ったデバッグと同じだ。

再びISPモードを使いたくなった場合は、CRP_WORDの設定値を元(CRP_NO_CRP)に戻してビルドし、“Debug”メニューでデバッガ接続すれば、この時にSWDインターフェース経由での書き換えが行われるので、再びFlash Magicが使用可能になる。

なお、マイコンに書き込んだプログラム自体に0x2FC番地を書き換えるコードを入れておけばISPモードでの起動も可能になる。この手順はIAPプログラミングと呼ぶ。機会があれば試してみようと思う。

(4) NO_ISPモードの動作

実際のNO_ISPモードの動作を試してみた。以下のような簡単な回路構成とした。マイコン内部のプルアップ抵抗をそのまま使うつもりなので、スイッチはマイコンに直結している。

ピン機能説明 1 RESET リセット入力 2 PIO0_4 (未使用) 3 SWCLK SWDインターフェース用 4 SWDIO SWDインターフェース用 5 PIO0_1 ISPバイパステスト用にスイッチを接続 6 VDD 電源(3.3V) 7 VSS GND 8 PIO0_0 動作確認用LEDを接続する。マイコン動作中は点滅表示させる。

3、4番ピンに割り当てたSWDインターフェースは必須だ。これが無いとプログラムを書き換えられなくなる。

以下はブレッドボードで組み立てたものだ。

最初に「ISPモードあり」のケースを示す。 SW1を押しながらリセットSWを押すとLEDの点滅が止まってしまう。これはマイコンがISPモードで起動してしまったからだ。この状態から抜けるには、SW1を離した状態でリセットSWを押す必要がある。

同じプログラムをNO_ISPモードにして動作させてみた。今度はSW1を押したままリセットSWを押しても、すぐにLED表示を行う。ISPモードをバイパスしているのが分かる。

これで、5番ピンを心置きなく自由に使える。

#LPC810 #nxp #arm #ISP

梅雨の晴れ間、近くの公園まで紫陽花を見てきた。

近くに梅の木も植えてあるのだが、実がすっかり黄色く熟して、紫陽花の周りに落ちていた。拾って鼻に近づけると、甘酸っぱい杏の香りがする。思わず齧ってしまいそうだが、止めた方が良いとのこと。恐ろしく酸っぱいと、近くの小学生が言っていた。

#風物詩 #紫陽花 #diary

LPC810(16) 〜 CMSISライブラリを取り込む

LPCXpresso付属の二つのライブラリ(CMSIS_CORE_LPC8xx、及びlpc800_driver_lib)は、便利は便利なのだが、いくつが問題があることは、以前「ライブラリ使用上の注意点」で触れた。

良くない部分は使わずに済ませたいが、CMSIS_CORE_LPC8xxライブラリにはLPC8xxマイコンのレジスタ定義やCMSIS関連の便利なマクロも含まれているので、これらは使いたい。

そこで、これら便利な定義のみをプロジェクトへ取り込み、問題含みの不用なライブラリ(libCMSIS_CORE_LPC8xx.aなど)を使わないプロジェクトの作成方法についてまとめておく。

コアライブラリCMSIS_CORE_LPC8xxから、いくつかファイルをコピーする必要があるため、プロジェクト作成の段階では、コアライブラリCMSIS_CORE_LPC8xxをワークスペース内に用意しておく必要がある。この手順に関しては「LPCXpressoを使う(2)」を参照のこと。

続いて新規プロジェクトを作成する。ここでは便宜的にプロジェクト名を“SysLib”とした。

プロジェクト作成の手順は「LPCXpressoを使う(3)」と同じであるが、ライブラリの選択は全て無し(None)にしておく(以下)。

SysLibプロジェクトを作成したら、CMSIS関連の便利な定義ファイルを手動で取り込む。 “Project Explorer”タブでCMSIS_CORE_LPC8xxを選び、incフォルダを右クリックしてコピー(Copy)する。

次に、SysLibプロジェクト(今回新規作成したプロジェクト)を選び、incフォルダを右クリックしてペースト(Paste)する。

SysLibプロジェクトのincフォルダ内にCMSIS_CORE_LPC8xxのincフォルダがコピーされるので、そのフォルダを選択して右クリックし名称変更(Rename)を選ぶ。表示されたダイアログで“CMSIS”と入力し“OK”をクリックする。

この追加したヘッダファイルをビルド時のインクルードパスに追加するため、“Quickstart Panel”タブの“Edit 'SysLib' project settings”をクリックする。

表示されたPropertiesウィンドウの“‣C/C++ Build”中にある“Settings”をクリックし、“Configuration:”のドロップダウンリストから“[All configurations]”を選択する。

“Tool Settings”タブをクリックし、“‣MCU C Compiler”中にある“Includes”をクリックする。さらに“Include paths”欄にあるAddボタンをクリックする。

表示された“Add directory path”ダイアログの“Workspace...”ボタンをクリック(①)。“Folder selection”ダイアログでSysLib(間違えないように)下のinc内にあるCMSISをクリックして選択(②)、その後“OK”(③)、最初のダイアログに戻るので、こちらも“OK”をクリックする(④)。

最後に“Properties”ウィンドウの“OK”をクリックして終了する。

これで、コピーして持ってきたコアライブラリの便利な定義(レジスタ定義やレジスタアクセスマクロなど)が使用できる。使用するにはソースファイル先頭で以下のインクルード文を入れること。

#include "LPC8xx.h"

なお、今作ったSysLibプロジェクトのmain.c先頭は、以下のようなコードとなっている。

#ifdef __USE_CMSIS #include "LPC8xx.h" #endif

試しに、この条件コンパイルを外し、インクルード文のみにしてビルドしてみて欲しい。

// #ifdef __USE_CMSIS #include "LPC8xx.h" // #endif

インクルードパスの設定が正しくできていれば、エラー無くビルドできるはずだ。

CMSISライブラリをプロジェクト内に完全に取り込んでしまったので、もうワークスペース内にCMSIS_CORE_LPC8xxは必要ない。本プロジェクト単独でCMSIS関連の便利な定義が使える。

スタートアップルーチンは相変わらずcr_startup_lpc8xx.c内のResetISRである。以前と異なるのは、スタートアップルーチンからは、もはやSystemInitは呼び出されない。その他の処理に違いはない。

システムクロックを変えたい場合は、自前のSystemInitを用意する必要があるが、内蔵オシレータ(12MHz)で動かすつもりであれば、そういったものは必要はない。このままでも内蔵オシレータ(12MHz)で動作する。

自前のSystemInitを用意したい場合は、CMSIS_CORE_LPC8xx内のsrcフォルダ内にあるsystem_LPC8xx.cを参考にすれば良いだろう。ただし、ここに含まれる関数には「ライブラリ使用上の注意点」で触れた問題があるので、この点を注意する必要がある。

なお、lpc800_driver_libライブラリから取り込みたい関数などがあれば、lpc800_driver_libフォルダ内に含まれる該当のソースファイル(*.cや.h)を自プロジェクト内にコピーすれば良い。

ただし、プロジェクトに新たにファイルを追加した場合は、プロジェクト内の依存関係を更新するため、Clean Projectを実行する必要がある。これは、“Quickstart Panel”タブの“Clean 'SysLib'(SysLibプロジェクトの場合)”をクリックすれば良い。

この操作により“Project Explorer”タブ内に、追加したファイルが現れてくるはずだ。

参考までに、既存のSystemInitを置き換える改善版のシステム初期化処理を作ってみた。プログラムでは、全てのコードをウォッチドッグタイマ(WDT)で保護している。 GitHubで公開(https://github.com/mitsware/lpc8xxBasic)しておいたので、興味のある方は参考にして頂きたい。

#LPC810 #arm #nxp

春には桜の名所だった近くの公園に行ってきた。公園いっぱいの緑が眩しい。

#diary #小金井公園

LPC810(15) 〜 Mac OS Xでシリアル通信

組み込みの世界ではデバッグやフラッシュROMの書き込み、そしてデバッグ用のログ出力などでシリアル通信が良く使われる。そのシリアル通信をMac OS X上でできるか試してみた。

Windows同様にMacでもRS232-Cを直結することはできないが、USBの仮想COMポート経由ならば可能である。ただし、Macへの対応を明記しているUSB・シリアル変換のケーブルは余り無いし、あっても高い。また、RS232-CレベルのD-SUB9ピンへの変換なので、そのままマイコンのUART端子へは接続できないため、使い勝手が非常に悪い。

TTLレベルの出力を、そのままUSBの仮想COMポートに変換するモジュールならば、秋月電子やマルツパーツ館から色々と出ているので、それらのモジュールを使いたい。そのモジュールで使用している変換チップメーカーが、Macに対応したドライバを提供してくれていればMacでも使えるはずである。

FTDI社のUSB・シリアル変換チップならばMacにもドライバが提供されており、このチップを搭載している製品ならばMacでもシリアル通信できるはずである。「ISPモードでのプログラム書き込み」でも触れた、秋月電子のUSBシリアル変換モジュールAE-UM232Rは、このFTDI社の変換チップを搭載しているのでMac OS Xでも使えるはずだ。今回はこの基板で試してみようと思う。

ドライバのインストール

FTDI社のホームページhttp://www.ftdichip.com/にアクセスし、左側のメニューからDriversを選択する。ドライバーには“VCP Drivers”、“D2XX Drivers”、“Win RT Driver”があるが、USBを使用した仮想COMポートを使う場合はVCP(Virtual COM Port)のDriverを選択する。

表示されたページを見てみると、ちゃんとMac OS Xもサポートされている。自分が見た時は2012-08-10リリースのVer.2.2.18だった。

Virtual COM Port Drivers http://www.ftdichip.com/Drivers/VCP.htm

とりあえず今回は64-bit版を選んだが、32-bit版やPPC版もリンク先は全て一緒のようなので、インストーラ側で判断してくれるのだろう。 dmgファイルがダウンロードされるので、それを開くと二つのパッケージが入っているのが分かる。

10.3(Panter)以前と10.4(Tiger)以降は別のパッケージとなっている。FTDI社のページを見ても10.8(Mountain Lion)以降の最新版でも使えるのかどうかが良く分からない。ここいら辺は自己責任で試してみることにする。

手元には10.9(Mavericks)がインストールされているMacbook airがあったので、これにドライバをインストールしてみる。インストールは簡単で、FTDIUSBSerialDriver_10_4_10_5_10_6_10_7.mpkgの方を開いて、あとはインストーラのガイダンスに従って進めば良いだけだ。

インストールが終わったら、早速Macbook airのUSBポートにUSBケーブルをつないでAE-UM232Rを接続してみる。

Windowsの場合は、この後マイコンピュータのプロパティからCOMポートを確認できるのだが、Macの場合はそうはいかない。“アプリケーション”の“ユーティリティ”フォルダに入っている“ターミナル”アプリを使う必要がある。

ターミナルを開いてlsコマンドを使い、ちゃんと“/dev”下にUSB仮想COMポートができているかどうかを確認しておく。(以下の>はコマンドプロンプトである。)

> ls /dev/*usb* /dev/cu.usbserial-A400FA34 /dev/tty.usbserial-A400FA34 >

ドライバがちゃんとインストールされていれば“/dev/cu.usbserial-*”と“/dev/tty.usbserial-*”の二つの形式で仮想COMポート(usbserial)ができていると思う。自分は、この“cu”と“tty”の違いが良く分かっていないのだが、色々と調べてみるとTx/Rx送受の他にDTRの制御なども行いたい場合がttyで、そのような制御を要せず単純な垂れ流しの場合はcuの方を使えば良いらしい(ここいら辺は、もうちょっと調べた方が良いと思うが...)。

とりあえず、今回はDTRの制御などは全く必要ないので、cuポートの方を使おうと思う。

Flash Magicのインストール

「ISPモードでのプログラム書き込み」でも触れたFlash MagicはMac OS X版も提供されている。今回は、このアプリを使ってLPC810マイコンにプログラムを書き込んでみようと思う。

Flash MagicはFlash Magic社のホームページ(http://www.flashmagictool.com/)からダウンロードできる。自分が見た時はVer.7.50だった。ちゃんとWindows版のダウンロードボタンの下にMac OS X版も用意されている。10.6(Snow Leopard)以降に対応しているらしい。

dmg形式でダウンロードされるので開いてみると、インストーラなどは存在せず、Flash Magicアプリのみが入っている。インストールはこれを単に“アプリケーション”フォルダにコピーすれば良いだけだ。

ただし、App Store経由でインストールしてないアプリは、最近のMac OS Xでは起動できなくなってしまった。起動しようとしても以下のようなメッセージが表示されてしまうはずだ。

この場合は“アプリケーション”フォルダを開いてFlash Magicをクリックして選択し、controlキーを押しながら開く必要がある。

そうすると今度はお伺いのメッセージが表示されるのでFlash Magicを起動することができる。

これ以降はcontrolキーを押さなくとも、普通のアプリ同様に単に開くだけで起動できるようになる。

とりあえず起動してしまったが、実はこのままではFlash Magicから仮想COMポートにアクセスすることができない。そのためFlash Magicはいったん終了する。

Flash Magicで仮想COMポートを使えるようにする

このFlash Magicは「Mac OS X版」を謳っているがネイティブなMacアプリではない。Wineskinというラッパーアプリをまとった「Mac OS Xでも使えるようにしたWindowsアプリ」なのだ。参考としてWineskinのページへのリンクを貼っておこう。

Wineskin http://wineskin.urgesoftware.com/tiki-index.php

言わば、Mac OS XアプリのフリをしたWindowsアプリである。だから、USB接続した仮想COMポートには、Windowsではおなじみの“COM1〜”のCOMポート経由でアクセスする必要がある。しかし当然のことながらMacではCOM1なんか存在しない。この辻褄合わせをしてやる必要がある。

Flash Magicの化けの皮をはがすために、アプリケーションフォルダにあるFlash Magicを選択して“パッケージの内容を表示”してみる。

見易いようにカラム表示にした。ここにあるdosdevicesフォルダ内に、Flash Magicから見ることができるデバイスの数々が存在する。既にCOM4〜が定義されているが、すべてエイリアス(実際はシンボリックリンク)であり、それぞれ/devフォルダ内のデバイスにシンボリックリンクされている(実体は存在してないが)。

> cd /Applications/FlashMagic.app/Contents/Resources/dosdevices > ls -l total 104 lrwxrwxrwx 1 mits staff 23 7 5 2013 COM4 -> /dev/cu.Bluetooth-Modem lrwxrwxrwx 1 mits staff 26 7 5 2013 COM5 -> /dev/cu.Bluetooth-PDA-Sync lrwxrwxrwx 1 mits staff 26 7 5 2013 COM6 -> /dev/cu.usbserial-FTFK21HZ lrwxrwxrwx 1 mits staff 24 7 5 2013 COM7 -> /dev/tty.Bluetooth-Modem lrwxrwxrwx 1 mits staff 27 7 5 2013 COM8 -> /dev/tty.Bluetooth-PDA-Sync lrwxrwxrwx 1 mits staff 27 7 5 2013 COM9 -> /dev/tty.usbserial-FTFK21HZ lrwxrwxrwx 1 mits staff 10 7 5 2013 c: -> ../drive_c lrwxrwxrwx 1 mits staff 21 7 5 2013 d: -> /Volumes/FlashMagic 1 lrwxrwxrwx 1 mits staff 13 7 5 2013 d:: -> /dev/rdisk2s1 lrwxrwxrwx 1 mits staff 21 7 5 2013 e: -> /Volumes/FlashMagic 2 lrwxrwxrwx 1 mits staff 13 7 5 2013 e:: -> /dev/rdisk1s1 lrwxrwxrwx 1 mits staff 13 7 5 2013 f:: -> /dev/rdisk1s2 lrwxrwxrwx 1 mits staff 1 7 5 2013 z: -> /

先に調べた/dev下のcuポートをCOM1として割り当てる。

> ls /dev/*usb* /dev/cu.usbserial-A400FA34 /dev/tty.usbserial-A400FA34 > cd /Applications/FlashMagic.app/Contents/Resources/dosdevices > ln -s /dev/cu.usbserial-A400FA34 COM1 > ls -l COM1 lrwxr-xr-x 1 mits staff 26 5 25 13:56 COM1 -> /dev/cu.usbserial-A400FA34

後はWindowsで書き込みをした時と同じ要領で行えば良い。 Flash Magicを起動したらCOM Portとして先に割り当てを行ったCOM1を選択する。

その他のFlash Magicのパラメータ設定は「ISPモードでのプログラム書き込み」と同じである。同じようにブレッドボードを用意してLPC810を設置後、虫眼鏡のアイコンをクリックして、ちゃんとマイコンの中身が読み出せるか試してみる。

以下のように、Windowsで試した時と同様に、ちゃんとベクタアドレスなどが読めれば成功だ。ここまで動作していれば、ちゃんと書き込みもできるはずだ。

プログラムの書き込み

書き込みたいhexファイルだが、これはWindowsのLPCXpressoで作ったhexファイルを、そのまま書き込むことができる。このhexファイルをMac OS Xの“書類フォルダ”に入れておけば、Windowsのような“My Documens”経由でアクセスできる。ファイル指定はFlash Magic画面中央右の“Browse...”ボタンをクリックした時に表示されるダイアログで行う。

ユーザー名がmitsだった場合、書類フォルダの対応は以下のようになる。

Mac OS X Flash Magic /Users/mits/Documents C:\users\mits\My Documents

ここいら辺は、ラッパーアプリであるWineskinが辻褄合わせをしてくれているようだ。

あとはWindowsの時と同様に“Start”ボタンのクリックで書き込みを行う。

Flash Magicターミナル

Flash Magicは簡易的なコンソール機能を持っており、シンプルながらマイコンとのUART通信を試すことができる。この点をざっと触れておく。

Toolsメニューから“Terminal..”を選択する。

続いて設定ウィンドウで、COM Port、Baud Rate、通信時の改行コードを設定。今回は115,200bpsでUART通信するプログラムをマイコンに書き込んだので、そのように設定した。

問題なければ以下のような画面が表示される。

二分割した上画面がUART受信したもの、下画面がUART送信したものになる。今回はUARTテスト用としてエコーバックするプログラムを書き込んでみた。ちゃんと入力がエコーバック表示されており、Mac OS Xでも問題なくUART通信できている。

以前も書いたが、LPCXpressoにもMac OS X版が提供されている。折を見てこちらも試してみたいと思う。

#LPC810 #arm #nxp #mac osx

我孫子駅構内にある弥生軒という立ち食いそば屋で、唐揚げ蕎麦という大きな唐揚げの入った蕎麦が食べられるというので、食べてきた。

お弁当に唐揚げを持ち帰りにして貰い、せっかく我孫子まで来たので、手賀沼から高野山桃山公園までぐるっと回ってみたんだけど、季節的に藤棚は終わっていた。残念です。

#手賀沼 #diary

LPC810(14) 〜ウォッチドッグタイマ

ウォッチドッグタイマ(WDT)は組み込みプログラムならば必須の機能で、一定時間内にクリアし続けないとシステムリセットするタイマである。プログラムが暴走してしまい、わけの分からない所を走り続けたり、無限ループに陥ってしまったり、いわゆるロックアップ状態になってしまった時に、すべてをご破算にして最初からやり直す機会を与えてくれる心強い味方である。

WDTは例えてみるならば止めることのできない時限爆弾であり、時間切れになる前にタイマをクリアしてやらないと爆発(システムリセット)する。だから時間切れになる前に定期的にクリアし続けてやる必要があり、この行為によりプログラムが暴走やロックアップしてないことを間接的に証明している訳だ。

ちなみに、LPC810のユーザーズマニュアル(UM10601)では、このWDTのクリアのことをfeedと言う単語で表している。ペットにエサをやったり、機械に燃料を供給するという意味である。英語圏ではそう表すのが一般的なのだろうか。しかしここでは「クリア」という言い方を使う。

それから、最近のマイコンは皆そうなのかもしれないが、LPC810のWDTはウィンドウ形式のウォッチドッグタイマ(WWDT)である。これは、WDTのクリア期間に制限を設ける機能であり、詳しくは後で説明する。

LPC810のWDTだが、操作してみて想像以上にトラブってしまった。ここでは、その紆余曲折も踏まえてLPC810でのWDTの使用方法について、まとめておきたいと思う。

1.WDTの使い方

WDTの初期化処理をWdt_ini()、クリア処理をWdt_clr()とすると、以下のような感じになると思う。

int main(void) { Wdt_ini(); /* WDT初期化：ここからロックアップ監視 */ setup(); /* その他の初期化処理 */ for (;;) { loop(); /* メイン処理 */ Wdt_clr(); /* WDTクリア：ここまで来たらOK　*/ } return 0; }

setup()はWDT以外の初期化全般を行う関数を示す。setup内にWDTの初期化処理を入れても良いと思うが、まず最初にWDTを動作させることを強調したかったのでこのように示した。まず最初にWDTを有効にした理由は、特にマイコンの初期化処理では、外部信号やハードウェアの状態待ち(安定待ち)で待機し続ける状況が多く、ある程度待ち続けても安定しない場合は、システムリセットしてもう一度最初からやり直したいと思ったからだ。

WDTの満了時間(時間切れと見なしシステムリセットする時間)にもよるが、必要ならばsetup内部でもWDTをクリアしても良いだろう。必要なのは「これ以上時間がかかったらシステム異常と見なす」時間を最初にしっかりと決めておくことだ。MHzのオーダーで動くマイコンなのだから、満了時間は2秒〜ぐらいで十分だろう。

loop()は、本プログラムのメイン処理関数を示す。この中でロックアップしていたり、暴走してあらぬ所を走り続けて、このメインループに戻って来れなくなったらクリアできずシステムリセットする。

2.WDTライブラリについて

本来ならばLPCXpresso付属のWDTライブラリについて説明したいところだが、はっきり言ってお勧めできない。自分が見ているライブラリはLPCXpresso Ver.6.1.0のものであり、これ以外の版では状況が違っているのかもしれないが、少なくともこの版のWDTライブラリは使えない。

lpc800_driver_libで用意されているWDTライブラリは、lpc8xx_clkconfig.c内のWDT_CLK_Setupと、lpc8xx_wdt.cで定義されている関数群である。

はっきり言うが、これらの関数はLPCXpressoで提供されているサンプルコードNXP_LPC8xx_SampleCodeBundle用のものであり、参考にはなるが、わざわざライブラリとして使う必要は無い。

以下にこれら関数の内容を説明する。

ファイル名関数名説明 lpc8xx_clkconfig.c WDT_CLK_Setup WDT用オシレータの周波数を最小値(9.375kHz)に設定し、WWDTユニットにクロックの供給を開始する。周波数の選択ができないため、使い勝手が非常に悪い。 lpc8xx_wdt.c WDT_IRQHandler WDT警告割り込みハンドラだが、はっきり言ってサンプルコードである。使う必要ない。警告割り込みについては後で説明する。 lpc8xx_wdt.c WDTInit WDTユニットの初期化関数という位置付けだが、はっきり言ってサンプルコードの初期化関数である。使う必要ない。 lpc8xx_wdt.c WDTFeed WDTクリア関数。このファイル内では唯一使える関数だが、単純な関数だし、この関数のためだけに本WDTライブラリを使う必要は無い。

はっきり言って現ライブラリ(LPCXpresso Ver.6.1.0付属)を全否定してしまったが、汎用性無く使えないのだから仕方がない。ライブラリに頼らないで、自分なりの代替関数を用意した方が良いと思う。以下、この点を踏まえてLPC810のWDT機能について説明していく。

3.WDT用パラメータの設定

まずは、ウィンドウウォッチドッグタイマ(WWDT)ユニットに供給するソースクロックの設定を行う必要がある。

システムクロックの項でも説明したが、LPC810は12MHzの内蔵オシレータとは独立したWDT用のオシレータも持っている。

WDT用オシレータは動作クロックを9.375kHz〜2.3MHzの範囲で指定可能であり、このソースクロックの1クロック毎にウォッチドッグ「タイマ」のカウントをカウントダウンしていくのだ。そしてカウントアップした時に爆発(システムリセット)する。

WDT用として機能に応じたカウンタが全部で四つ用意されている。これらはLPC810のレジスタであり、LPC8xx.hをインクルードすることによりアクセス可能になる。

それぞれの意味と関係を以下に示す。このうち、実際にカウントダウンするカウンタはLPC_WWDT->TVのみであり、その他のものは指標を示すリファレンスカウンタである。

レジスタ設定範囲初期値説明 LPC_WWDT->TV ー 0xFF WDTカウンタ。ダウンカウンタであり、カウンタが負になるとWDT満了である。読み出し専用のため、直接設定することはできない。 LPC_WWDT->TC 0xFF〜0xFFFFFF 0xFF 満了時間(リセットするまでの時間)カウンタ LPC_WWDT->WINDOW 0〜0xFFFFFF 0xFFFFFF ウィンドウ(クリア可能時間)カウンタ LPC_WWDT->WARNINT 0〜0x3FF 0 WDT警告割り込みの発生時間カウンタ

各カウンタはWDT用オシレータの周波数をベースとした値を設定する必要がある。ただし、図のようにWWDTユニット内で、プリスケーラがソースクロックをさらに四分周している点に注意が必要である。耳慣れない言葉もあると思うので、以下説明しておこう。

‣ WDTクリア

TVの値を直接設定することはできず、WDTクリアすることによりTCの値がTVへロードされる。 TVはダウンカウンタであり、四分周された1クロック毎に-1減分される。カウンタが負になった時(より厳密に言うと0からさらに-1した時)が時間切れとなる。

クリアはWWDTユニットのFEEDレジスタを使う。言葉で説明するよりも実際にプログラムを示した方が早いだろう。

/* WDTのクリア */ LPC_WWDT->FEED = 0xAA; LPC_WWDT->FEED = 0x55;

このようにFEEDレジスタに、0xAA・0x55をこの順に書くことで、WDTカウンタTVにTCの値がロードされて、もう一度最初からカウントダウンし始める。

‣ WDTウィンドウ

最近のマイコンには良くついている機能だが、LPC810のWDTもウィンドウ付きである。ウィンドウとは、クリア期間にも制限を設けたい時に使用する。すなわち、クリア後に一定時間経過してから次のクリアを受け付けるようにしたい場合である。

WDTカウンタTVが、ウィンドウカウンタWINDOW以下になっていた時のみWDTクリアを受け付け、もし上回っていたら満了と同じ扱いをさせる。だから、以下のような悪意のある無限ループでもシステムリセットさせることが可能なのだ。

for (;;) { /* クリアしながらロックアップ */ LPC_WWDT->FEED = 0xAA; LPC_WWDT->FEED = 0x55; }

WINDOWカウンタは初期値として最大値0xFFFFFFが設定されており、常にクリア可能となっている。例えば、この値が0x2FFFだった場合は、TVが0x3000以上の時にWDTクリアするとシステムリセットする。

なお、これは個人的見解なのだが、このウィンドウ機能というのはどうなのだろうか。今までの経験上、あまりこのウィンドウ機能が必要になったケースに出会ったことがなく、逆にウィンドウ設定したために、後々煩わしくなることが、ままあった。

「全然クリアできない」状況に比較して「早すぎるクリア」をシステム異常と見なすのは、やり過ぎの様な気もする。恐らく、余程時間的にカッチリとシステムを動かしたいようなケースでしか、使う機会は無いだろう。

‣ 警告割り込み

暴走検出してシステムリセットするのは良いが、システムリセットする前に何らかの終息処理をしておきたいケースも考えられる。

例えば、外部リソースを解放しておきたいとか、デバッグのためにスタックダンプを取っておきたいような場合だ。警告割り込みは、そのような用途で使用できる。いわば死ぬ前の遺言のようなものだ。

WDTカウンタTVが警告割り込みカウンタWARNINTと一致すると、警告割り込みが発生し、警告割り込みハンドラWDT_IRQHandlerが呼び出される。終息処理は、このハンドラの中で行うことになる。

しかし、何かおかしな状況に陥ってしまったためにハンドラが呼び出されたのだから、まともなシステムサービスが使用できるとは考えられず、ハンドラの中でできることは非常に限られているだろう。

また、警告ハンドラが呼び出されたとしても、その後システムが持ち直すようなケースも考えられるので、外部リソースを解放するようなケースでは注意が必要である。その場合は、ハンドラ内部で無限ループして強制的にWDTリセットを生じさせてしまった方が良いかもしれない。

警告割り込み内での処理に関しては、より深く掘り下げて述べたいこともあるのだが、話しがWDTから外れてしまうので、別のトピックで説明したいと思う。

なお、WARNINTに現在のTVより小さい値を設定すると、いきなり警告割り込みが発生してしまうようだ。TVの初期値は0xFFであるため、WARNINTにこれ以下の値を設定する場合は注意が必要である。この点を踏まえたWARNINTへの設定方法については、この後で説明しよう。

‣ WDT用オシレータの設定

WDT用オシレータの周波数はLPC810のSYSCON(System configuration)ユニットのWDTOSCCTRLレジスタへの設定値で決まる。既にシステムクロックの項でも説明しているが、見返す手間を省き、ここでも触れておこう。 WDTOSCCTRLレジスタのビット構成を以下に示す。DIVSEL、及びFREQSELの設定値に基づいた周波数となる。

SYSCON - WDTOSCCTRLレジスタ ※ユーザーズマニュアル(UM10601) - 4.6.6 Watchdog oscillator control registerより

ビット記号説明 b4〜0 DIVSEL 出力時の分周値を指定する。分周値は以下の式で示される。　分周値 = (DIVSEL + 1) × 2 以下に実際の値を示す。 00000: 2 = (0 + 1) × 2 00001: 4 = (1 + 1) × 2 〜 11111: 64 = (31 + 1) × 2 b8〜5 FREQSEL WDT用オシレータの周波数を指定する。 0000(0x0)〜1111(0xF)の16種類の周波数が選択可能である(別表)。 b9〜 — 0以外設定してはならない。

FREQSEL 周波数 FREQSEL 周波数 FREQSEL 周波数 FREQSEL 周波数 0x0 0 0x4 1.75MHz 0x8 3.00MHz 0xC 4.00MHz 0x1 600KHz 0x5 2.10MHz 0x9 3.25MHz 0xD 4.20MHz 0x2 1.05MHz 0x6 2.40MHz 0xA 3.50MHz 0xE 4.40MHz 0x3 1.40MHz 0x7 2.70MHz 0xB 3.75MHz 0xF 4.60MHz

なお、システムクロックとしてWDT用オシレータを選択していた場合は、既に指定の周波数で動作しているのであらためて設定する必要はない。それ以外の場合は、WDT用オシレータも設定する必要がある。

enum { WWDT_OSCVAL = 0x03F, /* オシレータを9.375kHzで動作 */ SYS_WDTOSC_PD = 0x1<<6, /* WDT用オシレータ電源供給ビット */ SYS_AHB_CLK_WWDT = 0x1<<17 /* WWDTユニットクロック供給ビット */ }; LPC_SYSCON->WDTOSCCTRL = WWDT_OSCVAL; LPC_SYSCON->PDRUNCFG &= ~SYS_WDTOSC_PD; LPC_SYSCON->SYSAHBCLKCTRL |= SYS_AHB_CLK_WWDT;

リセット直後はWWDTユニットにクロックも電源も供給されてないので、それをしてやる必要がある。PDRUNCFGは1の設定でパワーダウンとなるので、0を書いてやる必要がある。

先にも述べたが、WWDTユニット内では、このクロックをさらに四分周したものを使用している。TCなどの各カウンタには、その周波数をベースにしたカウンタ値を設定する必要がある。

WDT用オシレータでいくつかの周波数を選択し、その時に各カウンタで最大値を設定した時の時間を表にまとめた(TCに関しては最小値も示している)。

1カウント時間は四分周後の時間を示している。これはカウントダウンする間隔になる。例えば、ソースクロックを最小値の9.375kHzとした場合、約430μs毎にカウントダウンされる。この場合、TCに5,000を設定すると約2秒でカウントアップする。

なお、カウンタに1,023(=0x3FF)を設定した場合、1,024回目にカウントアップするので、カウンタ値に対応する時間を式で示すと以下のようになる。

(カウンタ値＋１) ÷ (WDT用オシレータの周波数 ÷ 4)

4.動作モードの選択

動作モードの選択はWWDTユニットのMODレジスタで行う(LPC_WWDT->MOD)。本レジスタはビット単位で意味を持ち、ユーザーズマニュアルに基づいた各ビットの機能を以下にまとめる。特に、ユーザーズマニュアルに書いてない重要な点や、恐らくマニュアルが間違っていると思われる点についてもまとめておこう。

これらのビットの初期値は全て0である。「変更不可」なビットは、一度1を設定すると動作中は0にできなくなるビットだ。

WWDT - MODレジスタ ※ユーザーズマニュアル(UM10601:Rev.1.5 - 6 March 2014) - 12.6.1 Watchdog mode register

ビット記号変更不可説明 b0 WDEN ◎ WDT機能のマスタービット。本ビットを1にすることでWDT機能が有効となる。ただし、ここを1にしただけではWDTカウンタは動作開始しない。この後に明示的なWDTクリアが必要。 b1 WDRESET ◎ タイマ満了時の動作選択ビット。タイマ満了時にシステムリセットする(=1)か、割り込み発生(=0)にするか選択できる。割り込みハンドラは警告割り込みハンドラが使われる。 b2 WDTOF タイマ満了通知ビット。WDTタイマが満了した場合に1がセットされる。0を書いて明示的にクリアする必要あり。 b3 WDINT 警告割り込み発生ビット。警告割り込み発生時に1にセットされる。こちらも明示的にクリアする必要あり。ユーザーズマニュアルの記述とは異なりクリアするためには1を書く必要あり。 b4 WDPROTECT ◎ TCカウンタのプロテクトビット。1を書くことで、TVの値がWARNINT、及びWINDOWの値を下回っている時のみTCが変更可能となる。が、動かない。 b5 LOCK ◎ WDT機能のロックビット。1を書くことでWDT用オシレータを停止しWDT機能自体を止める。が、ビット位置が間違っている。 b6〜ー (予約)

WDRESET、WDTOFに関してはウィンドウ期間外のWDTクリアでもWDT満了と同じ扱いになる。

なお、WDTの動作を開始するにはWDENに1を設定する必要があるが、それだけでは動作開始しない。その後に明示的なWDTクリア(ユーザーズマニュアルの言い方に則ればfeed操作)が必要なのだ。

enum { WWDT_TC_CNT = 0x2FFF, WWDT_WARN_CNT = 0xFF } enum { WWDT_WDEN = 0x1<<0, WWDT_WDRESET = 0x1<<1 }; LPC_WWDT->TC = WWDT_TC_CNT; LPC_WWDT->MOD = WWDT_WDEN | WWDT_WDRESET; /* 有効にした後に明示的なクリア動作が必要 */ LPC_WWDT->FEED = 0xAA; LPC_WWDT->FEED = 0x55; /* WDTカウンタ(TV)ロード後にWARNINTを設定しないと割り込み発生の危険あり */ LPC_WWDT->WARNINT = WWDT_WARN_CNT;

この場合のクリア動作はウィンドウ期間外とは扱われないようなので、いきなりリセットしてしまう恐れはない。

それから、上ではWDTクリア後にWARNINTの設定を行っているが、これはTVの初期値が0xFFであるため、クリア前にWARNINTの設定を行うと、いきなり警告割り込みが発生してしまうからだ。 WDTクリアを行うことによりTCの設定値がTVにロードされるので、その後にWARNINTの設定を行えば、そのような予期せぬ割り込みに見舞われることはない。

なお、上記のようにWDENを1にしてデバッグする時には注意が必要である。デバッガはWDT用オシレータの動作までは制御できないようであり、プログラムをブレークすることでWDTカウンタが満了してしまう場合がある。これは非常に煩わしいので、デバッグ版と製品版とでMODレジスタの設定を以下のように切り替える必要があるだろう。

/*** WDT動作モードの指定 ***/ enum { // WWDT_MODE = WWDT_WDRESET WWDT_MODE = WWDT_WDEN | WWDT_WDRESET } LPC_WWDT->MOD = WWDT_MODE;

ちなみにWDRESETを0にすることで、暴走検出時にリセットせず単なる割り込みにすることも可能である。警告割り込みを使わず、こちらを使用して重要な終息処理を行ったあとに自らリセットする(もしくは不具合発生時の状態を温存するため、そのままロックアップしておく)といった手段も取れるだろう。

なお、割り込み要因のWDTOFとWDINTであるが、それぞれクリアする手順が異なる。ユーザーズマニュアルでは両ビットとも0書きでクリアできる記述があるが、WDINTをクリアするには1を書く必要がある。

よくよく調べてみると、WWDTのサンプルプログラム(lpc8xx_wdt.c)でもそのようなコードになっている。

/* LPCXpresso付属のサンプルプログラムから抜粋 */ #define WDTOF (0x1<<2) #define WDINT (0x1<<3) void WDT_IRQHandler(void) { /* 〜略 */ LPC_WWDT->MOD |= (WDINT | WDTOF); /* clear the interrupt flag */ LPC_WWDT->MOD &= ~(WDINT | WDTOF); /* clear the time-out flag */ }

どうやらマニュアルの方が間違っているように思うのだが、Rev.1.5でも直ってないようである。(以下引用。下線は筆者。)

UM10601(Rev.1.5) - p.176

WDINT The Watchdog interrupt flag is set when the Watchdog counter reaches the value specified by WARNINT. This flag is cleared when any reset occurs, and is cleared by software by writing a 0 to this bit.

それから、WDPROTECTビットとLOCKビットだが、これははっきり言ってユーザーズマニュアルもおかしいし、実際の動作もおかしい。以下のようなサンプルプログラムを作って動作確認してみた。なお、WDT_CLK_Setupはライブラリ内のクロック設定関数である。

WDT_CLK_Setup(); /* 一番遅い9.375kHzで初期化 */ LPC_WWDT->TC = 0x2FFF; /* 約5秒 */ LPC_WWDT->WINDOW = LPC_WWDT->TC; /* 常にクリア可 */ LPC_WWDT->WARNINT = 0; NVIC_EnableIRQ(WDT_IRQn); /* ユーザーズマニュアル(UM10601)によるとb4はプロテクトのはず */ LPC_WWDT->MOD = (0x1 << 0) | (0x1 << 4); LPC_WWDT->FEED = 0xAA; LPC_WWDT->FEED = 0x55; LPC_WWDT->TC = 0x3FFF; /* WARNINTが0なので変更は不可のはず */ for (;;) { ; }

ユーザーズマニュアルによればTCを変更可能なのは、WDTカウンタがWINDOW、及びWARNINTよりも下回っている時のみのはずだ。(以下引用。下線は筆者。)

UM10601 - 12.5.3.2 Changing the WWDT reload value(p.174)

If bit 4 is set in the WWDT MOD register, the watchdog time-out value(TC) can be changed only after the counter is below the value of WDWARNINT and WDWINDOW.

WARNINTを0にしているので、この値を下回ることは有り得ないため、TCの書き換えはできないはずである。デバッガでこのプログラムを動作させ、一分ぐらい放置してからブレークした時の様子が以下の通りである。

TCは16,383(0x3FFF)に書き替わっており、MODは17(0x11)なのでb0とb4のみが1で、WDTOF(b2)もWDTINT(b3)も1になってない。 WDT用オシレータとして9.375kHzを選択したので、四分周後の周波数は約2.344kHz、TCが0x2FFFの場合は約5秒、0x3FFFでも約7秒で満了である。一分以上放置したにも関わらず何も動作してない。そもそもTVが初期値255(0xFF)のままである。WDTが動いてないのだろう。これは、どちらかというと隣のLOCKビット(b5)の動きだ。

試しにb5の方をオンしてみる。

7秒ほど放置すると、以下のようにWDTOFとWDTINTが1になった状態で割り込み(WDT_IRQHandler)が発生する。

TCが16,383(0x3FFF)の場合は約7秒後ぐらいに満了となるため、書き替わった後のTCに基づいた動作であることが分かる。(TVがTCと同じ値になっているのは、カウンタが満了しTCの値が自動的にリロードされたのだろう。)

すなわち、

実動作ではb4の方がLOCKビットのように動いている。

実動作ではb4にもb5にもWDPROTECTの動作を認められなかった。

うーん、使い方が悪かったのだろうか。しかしLOCKビットの位置がずれているのは間違いないだろう。どちらにしろ、これらのビット機能は使わないのが正解だ。実際、使わなくともWDT機能としては十分だ。

なお、ここまでの内容をベースにWDT機能を使ったサンプルプログラムを作ってみた。 GitHubで公開(https://github.com/mitsware/lpc8xxBasic)しておいたので、興味のある方は参考にして頂きたい。このサンプルプログラムでは、以前「ライブラリ使用上の注意点」でも触れた問題についても対応している。

#LPC810 #arm #nxp #ウォッチドッグタイマ

LPC810(13) 〜ライブラリ使用上の注意点

LPCXpressoで添付のライブラリ(CMSIS_CORE_LPC8xx、lpc800_driver_lib)を使って色々とやっているが、その時に気づいた点について今回はまとめておこうと思う。ただし、どちらかというと自分自身の個人的見解(単なる文句)の羅列になっていると思うので、今回は余り技術的な情報は無いかもしれない。

なお、自分が使用しているライブラリはLPCXpresso Ver.6.1.0付属のライブラリであるため、新しい版では改善されているかもしれない(だったら良いが)。その点はご了承願いたい。

1.ライブラリlpc800_driver_libについて

一応“ライブラリ”という位置付けであるし、使っていて便利な関数がいくつか用意されているが、本当にライブラリなのだろうか。どちらかというと“サンプルコード”集の意味合いが強く、使う場合に注意が必要である。

GPIO関連の設定を行うGPIOInitやGPIOSetBitValueを使った時に、使用ROM容量が想像以上に大きくなった。これらの関数自体は非常に小さいし、何がそんなに肥大したのか生成されたmapファイルを調べてみたところ、勝手にGPIO関連の割り込みハンドラが登録されてしまっていることに気づいた(以下、mapファイルから一部抜粋)。

.bss 0x00000000 0x0 C:\...\liblpc800_driver_lib.a(lpc8xx_gpio.o) .bss.gint0_counter 0x00000000 0x4 C:\...\liblpc800_driver_lib.a(lpc8xx_gpio.o) 〜略 .text.PININT_Handler 0x0000049c 0x1e4 C:\...\liblpc800_driver_lib.a(lpc8xx_gpio.o) .text.PININT0_IRQHandler 0x00000680 0x10 C:\...\liblpc800_driver_lib.a(lpc8xx_gpio.o) .text.PININT1_IRQHandler 0x00000690 0x10 C:\...\liblpc800_driver_lib.a(lpc8xx_gpio.o) 〜略

勝手にbssセクションに変な変数も取られているし、そもそも自分はGPIOの割り込みを使った覚えはない。これはlpc800_driver_lib内のファイルlpc8xx_gpio.cで、これら変数や割り込みハンドラが勝手に定義されていることに原因がある。

よくよく調べてみると、定義されていた割り込みハンドラはサンプルコードNXP_LPC8xx_SampleCodeBundleに含まれるサンプルプログラムと対応するものであり、要するに割り込みハンドラの使い方を示した単なるサンプルコードなのだ。

ただでさえROM/RAM容量の少ないLPC810に、このような贅肉が勝手についてしまうのは非常に困る。

lpc800_driver_libのソースコードは、該当のフォルダ中のsrcフォルダに入っており、これらのファイルをあらためて調べてみたところ“勝手ハンドラ”は以下のようになった。

ファイル名勝手ハンドラ説明 lpc8xx_bod.c BOD_IRQHandler BOD(Brown-Out Detect)ユニット、すなわち電源喪失監視ユニットで、電源が落ちそうになった時に発生する割り込みハンドラ。明らかにサンプルコード。 lpc8xx_clkconfig.c (なし) ウォッチドッグタイマ(WDT)用のクロック設定と、CLKOUT端子用のクロック設定関数が含まれる。WDTの方は使わない方が良い(WDTについては別項で説明する)。 lpc8xx_comp.c CMP_IRQHandler アナログコンパレータ用の割り込みハンドラが勝手に入っている。 lpc8xx_crc.c (なし) LPC810組み込みのCRCユニットを使うための関数群。 lpc8xx_gpio.c PININT0_IRQHandler 〜PININT7_IRQHandler GPIOピン割り込みのハンドラが勝手に入っている。上で述べた通り、いらない。 lpc8xx_i2c.c I2C_IRQHandler I2C関連の関数が定義されている。このハンドラもサンプルコードだ。 lpc8xx_mrt.c MRT_IRQHandler MRT(Multi-rate timer)ユニット。このハンドラも単なるサンプルコード。 lpc8xx_nmi.c NMI_Handler NMI_Initを使うと、勝手ハンドラがもれなく付いてくる。 lpc8xx_pmu.c (なし) PMU(Power Management Unit)、すなわち電源管理ユニットの関数群が含まれる。 lpc8xx_spi.c SPI0_IRQHandler 〜SPI1_IRQHandler ピン数の少ないLPC810ではSPIは使わないと思うが、I2C同様に、こちらも勝手ハンドラがもれなく付いてくる。 lpc8xx_uart.c UART0_IRQHandler 〜UART2_IRQHandler UART関連の関数群が含まれる。勝手ハンドラは完全なサンプルコードであり、いらない。 lpc8xx_wdt.c WDT_IRQHandler ウィンドウウォッチドッグタイマ(WWDT)の関数群なのだが、はっきり言ってこのファイル内の関数は全て使えない。WDTに関しては項を分けて詳しく述べるつもり。 lpc8xx_wkt.c WKT_IRQHandler WKT(Wake Timer)ユニット、すなわちスリープ中の定期起床タイマの関数群が含まれる。このまま使えそうな唯一のハンドラなのだが、自分独自の実装に置き換えた方が良いと思う。

これらのファイルに含まれるライブラリ関数を使う場合は、これら“勝手ハンドラ”をコメントアウトなど完全に削除してから使わないと、ROM容量を逼迫したり、いらぬ混乱を招く結果になるだろう。

なお、各ファイル内に定義されている(ムダな)変数は、使用している関数を削除さえしておけばリンカに無視されるので、面倒ならばわざわざ消す必要はない。

あらためて見てみると、各ファイルの先頭にあるヘッダコメントでもexampleと書いてあるから、これはライブラリでなく本当にサンプルコードであり、必要な関数のみコピペして使ってね、ということなのだろうか。何か釈然としないが。

2.ライブラリCMSIS_CORE_LPC8xxについて

システムクロックの項でも詳しく述べたが、このライブラリにはシステムクロック関係の以下の二つの関数が含まれている。

名称説明 SystemInit システムクロックの設定を行う。 SystemCoreClockUpdate 現在のシステムクロックの周波数を取得し、外部変数SystemCoreClockに設定する。

ウォッチドッグタイマ用オシレータの周波数がユーザーズマニュアルと異なっている点については、既にシステムクロックの項で説明した。ここでは、それ以外の点について言っておきたいことを以下にまとめておく。

(1) SystemInitはロックアップする恐れを孕んでいる。

いきなり酷い言い回しだが、このリスクは十分承知しておいた方が良い。

SystemInitはmain前のスタートアップルーチン(ResetISR)から呼び出される関数であり、内部でシステムクロックの設定を行っている。システムクロックの設定なので、ところどころに非常にセンシティブな設定があるのは致し方ないと思うが、その中で例えば以下のようなコードがある。目立たないが、一番右のカッコ脇にセミコロンがある点に注意。

while (!(LPC_SYSCON->MAINCLKUEN & 0x01)); /* Wait Until Updated */

これは、メインクロックの入力がマイコン内で安定するまで待機しているループである。メインクロックとはシステムクロックのソースクロックであり、各種設定後、LPC_SYSCON->MAINCLKUENレジスタのb0が1になることで、安定したことが示される。

SystemInit内には、このようないわゆるビジーウェイトで状態変化を待っている箇所が他にも二カ所ある(条件コンパイルの内容により変わる場合もあるが。)

このようなハードウェアに依存する終了条件のみのループは、全てロックアップする恐れを孕んでいる。必ず終わることが論理的に証明できないからだ。上記例では、LPC_SYSCON->MAINCLKUENがいつまでたっても0のままであれば、永久にここで待ち続けることになり、それはすなわちロックアップ状態そのものである。

このようなことを言うと、メインクロックの状態が変なのだから、他にどうしようもないのであり、手段として待ち続ける以外なく、結果としてロックアップしてしまってもしようがないのでは、という意見が出てくると思うが、そういった人に私は問いたい。

例えば、あなたが使用しているPCなりスマートフォンなり、何でも良いが、そのような普段使っている機器が無反応になった場合、あなたはボケーと待ち続けますか？恐らく10人中10人が、リセットボタンがあればそれを押すか、無ければ電源を入れ直すかするだろう。当然、それで動き出すかどうかは分からないが、まずは試してみて、何回か電源を入れ直してもダメだったら、あらためて修理に出すなりするはずだ。

今回のケースもそうであり、ある程度待ってみて、ダメそうだったらリセットして最初からやり直してみてらどうですか、と言いたいのだ。それでダメなら、その時こそマイコンの故障を疑うべきであり、ただ単に待ち続けるのは余りに能がない。

先に示したような状態待ちループは、本来ならばウォッチドッグタイマ(WDT)の監視下で行うべきであり、そもそも、このような時のためにWDTがあるのではないだろうか。まぁ、シンプルに作っておきたかったから、SystemInitはこのようなコードになったのかもしれない。それでも、組み込みプログラミングにWDTは必須の機能だし、サンプルコードであれば、なおのことその点を示しても良かったと思うのだが...

この改善については、WDTの項で説明したいと思う。

(2) SystemCoreClockは分周された値を示す。

現在のシステムクロックは、SystemCoreClockUpdateを呼び出すことにより、外部変数SystemCoreClockに設定される。例えば、SysTickタイマなどでは、この外部変数SystemCoreClockをもとに初期化すれば、システムクロックが変更された時も連動して設定し直されるので、可搬性の高いプログラムを作ることができる。

しかし、UARTのボーレート設定やIOCON(I/O Configuration)ユニットのデジタルグリッチ機能でクロック設定する時には注意が必要である。(デジタルグリッチ機能についてはGPIOについて説明した時に触れたいと思う。)

LPC8xxシリーズマイコンではクロックとして“メインクロック”と“システムクロック”の二種類のクロックがあり、マイコン自体の動作クロック数に相当する“システムクロック”は“メインクロック”を分周したものが使われている。この分周値はSYSAHBCLKDIVレジスタの値が使用される。

SystemCoreClockは“システムクロック”を示し、この分周後の値が格納されているのだ。しかし、UARTのボーレートジェネレータやIOCONユニットは分周前の“メインクロック”をソースクロックとしている。

SYSAHBCLKDIVレジスタはSystemInitで初期化されており、何も操作しなければ1で初期化される。そのため、通常はメインクロックとシステムクロックは同じ値となるが、この分周値を1より大きくした場合(〜255まで可能)は、SystemCoreClockはメインクロックの値と異なってくる。

だから、例えばUARTのボーレート設定を以下のようにSystemCoreClockから直接求めるのは正しくない(UARTCLKDIVはUART側の分周値)。

UARTSysClk = SystemCoreClock / LPC_SYSCON->UARTCLKDIV; /* ? */

本来ならばメインクロックの周波数から求めるべきだ。この点について、先のSystemInitのロックアップと合わせて改善したものを、WDTの項で触れるつもりだ。

(3) SystemInit内の条件コンパイルについて

これは、はっきり言って自分のいちゃもんに近いが、とりあえず触れておこう。

SystemInit内では条件コンパイルでプログラムが分かれている。このぐらいのサイズならば、まだ追跡して内容を把握することは可能だが、ちょっと気を許すと、いつのまにか条件コンパイルと通常の制御文が入り乱れた、追跡するのも理解するのも困難で面倒なプログラムになってしまう恐れがある。

何を言いたいのかと言うと、条件コンパイルなど使わなくとも、通常の制御文だけで条件コンパイルと同様の作用を及ぼすことが可能だ、ということが言いたいのだ。

ご存知の方は今更感が大きいと思うが、一応念のために触れておく。例えば、条件コンパイルで以下のようなプログラムの“場合分け”をしたとする。

int main(void) { int i; #if SELECTOR == 0 for (i = 0; i < 200; i++) { ; } sample1(); #elif SELECTOR == 1 sample2(); #endif return 0 ; }

SELECTORを0、1、それ以外とし、生成されるコードを選択するつもりだ。このままだと、オリジナルのSystemInit同様にSELECTORが0以外の時にウォーニング(iが使われてない)が出る。

実は、このプログラムでは条件コンパイルを使う必要がない。以下のようにコーディング可能である。

int main(void) { int i; if (SELECTOR == 0) { for (i = 0; i < 200; i++) { ; } sample1(); } else if (SELECTOR == 1) { sample2(); } else { ; /* 何もしない */ } return 0 ; }

これだとSELECTORの値に関わらず余分なコードが作られてしまい、ROM容量がもったいないのでは、と思われる人がいるかもしれないが、今どきのコンパイラは、そこまで愚かではない。 SELECTORを2にしてビルド(LPCXpresso Ver.6.1.0)した場合、上記プログラムで以下のようなアセンブラコードが生成された。

main: push {r7, lr} add r7, sp, #0 mov r3, #0 mov r0, r3 mov sp, r7 pop {r7, pc}

sample1もsample2も出てこないし、forループも出てこない。単に戻り値として0を返しているだけだ。念のために言っておくが、これはオプティマイズなし(-O0)でコンパイルしている。今どきのコンパイラは、この程度の操作は頼まれなくてもやってくれるのだ。ちなみにiが使われてないというウォーニングも出ない。

SELECTORを1にすると以下のようになる。

main: push {r7, lr} add r7, sp, #0 bl sample2 ; call sample2 mov r3, #0 mov r0, r3 mov sp, r7 pop {r7, pc}

この通り、無駄なコードは一切生成されない。

このプログラムの優れている点は、条件コンパイルだった部分が、ちゃんと制御の一部としてプログラムに組み込まれているため、条件コンパイルとCプログラムという、それぞれ異なる制御を追う必要がなくなる点にある。

条件コンパイルの話題について触れたが、ついでと言っては何だがdefineシンボルについても、自分の見解を述べておこうと思う。

このブログで自分のオリジナルプログラムを載せるときはdefineシンボルを使わずにenumを使っている。これには理由がある。 defineシンボルは単なる文字列置換に過ぎず、文脈によって解釈が変わってしまう恐れがあるからだ。

既にご存知の方も多いと思うが説明しておく。以下のようにdefineシンボルとenumで値を定義したとする。

#define define_BIT2 1<<2 enum { enum_BIT2 = 1<<2 };

この二つの値は全く異なる。enum_BIT2は間違いなく4と解釈されるが、define_BIT2はそうならない。以下に例を示す。

param1 = 1 + define_BIT2; /* (1) */ param2 = 1 + enum_BIT2; /* (2) */

上記のようなプログラムをコンパイルした場合、恐らく(1)に対して次のようなウォーニングが出ると思う。

warning: suggest parentheses around '+' inside '<<'

先のプログラムをプリプロセッサだけを通すと、以下のように変換される。

param1 = 1 + 1<<2; param2 = 1 + enum_BIT2;

ウォーニングの指摘通り、<<よりも+の優先順位が高いため、(1)は(1 + 1) << 2と解釈されparam1には8が入る。 param2には望んだ通り5が入る。

このような事態を避けるため、defineシンボルでの定義では必ずカッコでくくって定義するよう言われているが、それでも最終的にどのように解釈されるかは、そのdefineシンボルの使用されている文脈に依存してしまう。しかし最初からenumを使っていれば、このようないらぬ混乱とは無縁だ。

#LPC810 #arm #nxp #lpcxpresso #プログラミング

#蒲公英 #風物詩 #diary

LPC810(12) 〜システムクロック(3)

ここでは、LPC810のシステムクロックにウォッチドッグタイマ(WDT)用オシレータを選択した場合の動作を見てみた。なお、ここでの情報はLPCXpresso Ver.6.1.0(2013-10-21リリース)を元にしており、これ以外の版では違ってしまっているかもしれない。その点はご了承頂きたい。

先の項でも触れた通り、WDTオシレータの周波数がユーザーズマニュアル(UM10601.pdf: Rev.1.5 〜 2014.3.6版)とコアライブラリのソースコード(system_LPC8xx.c)とで食い違っている。

以下に、その問題の箇所、すなわち、現在のシステムクロックの周波数を取得する関数SystemCoreClockUpdateで、レジスタWDTOSCCTRLの値に基づき周波数を取得する部分を示す(一部のみ抜粋)。 WDTOSCCTRLレジスタのb5〜8の4ビットで周波数を選択する。プログラムではwdt_oscに周波数(単位はHz)を格納している。

/* Determine clock frequency according to clock register values */ switch ((LPC_SYSCON->WDTOSCCTRL >> 5) & 0x0F) { case 0: wdt_osc = 0; break; case 1: wdt_osc = 500000; break; case 2: wdt_osc = 800000; break; case 3: wdt_osc = 1100000; break; 〜略

少し長くなるが、以下にユーザーズマニュアルの値と併記して示す。

FREQSEL ユーザーズマニュアル system_LPC8xx.c 0x0 0 0 0x1 600KHz 500KHz 0x2 1.05MHz 800KHz 0x3 1.40MHz 1.10MHz 0x4 1.75MHz 1.40MHz 0x5 2.10MHz 1.60MHz 0x6 2.40MHz 1.80MHz 0x7 2.70MHz 2.00MHz 0x8 3.00MHz 2.20MHz 0x9 3.25MHz 2.40MHz 0xA 3.50MHz 2.60MHz 0xB 3.75MHz 2.70MHz 0xC 4.00MHz 2.90MHz 0xD 4.20MHz 3.10MHz 0xE 4.40MHz 3.20MHz 0xF 4.60MHz 3.40MHz

FREQSELが0の時以外、全く一致しない。そこで、WDTOSCCTRLレジスタへの設定値を変えた時に、実際にどのようなクロックが生成されるかを調べてみた。

WDT用オシレータをシステムクロックとするには、コアライブラリCMSIS_CORE_LPC8xx内のsystem_LPC8xx.c内で定義されている以下のシンボルを変えてビルドすれば良い。これ以外のシンボルは無関係なので無視して構わない。

シンボル設定値説明 CLOCK_SETUP 1 初期定義値のまま変える必要なし。 MAINCLKSEL_Val 0x00000002 WDT用オシレータをシステムクロックとする。 WDTOSCCTRL_Val いろいろここを色々と変えてみた。 SYSAHBCLKDIV_Val 0x00000001 初期定義値のまま変える必要なし。

前項の「システムクロック(2)」で使用したブレッドボードのシステムを使い、CLKOUT端子からの出力クロックを手持ちのオシロスコープで計測することで検証を行った。

最終的に生成されるクロック周波数は以下の式で示される。

WDTオシレータのクロック周波数 = (FREQSELで選択された周波数) / ((DIVSEL + 1) × 2)

最小値(ユーザーズマニュアル)： 9.375KHz 〜 FREQSEL:0001(0x1), DIVSEL:11111(0x1F)

最大値(ユーザーズマニュアル)： 2.3MHz 〜 FREQSEL:1111(0xF), DIVSEL:00000(0x00)

調査した結果を以下に示す。“実測値”が実際にCLKOUT端子から出力された計測値である。念のためにDIVSELを変えたケースも一部見てみた。

WDTOSCCTRL_Val FREQSEL DIVSEL 実測値ユーザーズマニュアルでの計算値 system_LPC8xx.cでの計算値備考 0x03F 0001 11111 9.639KHz 9.375KHz 7.812KHz 最小値 0x1FF 1111 11111 73.758KHz 71.875KHz 53.125KHz 0x020 0001 00000 308.4KHz 300.0KHz 250.0KHz 0x040 0010 00000 546.3KHz 525.0KHz 400.0KHz 0x060 0011 00000 743.4KHz 700.0KHz 550.0KHz 0x080 0100 00000 930.3KHz 875.0KHz 700.0KHz 0x0A0 0101 00000 1.09MHz 1.05MHz 0.80MHz 0x0C0 0110 00000 1.25MHz 1.20MHz 0.90MHz 0x0E0 0111 00000 1.40MHz 1.35MHz 1.00MHz 0x100 1000 00000 1.53MHz 1.50MHz 1.10MHz 0x120 1001 00000 1.66MHz 1.63MHz 1.20MHz 0x140 1010 00000 1.79MHz 1.75MHz 1.30MHz 0x160 1011 00000 1.91MHz 1.88MHz 1.35MHz 0x180 1100 00000 2.03MHz 2.00MHz 1.45MHz 0x1A0 1101 00000 2.14MHz 2.10MHz 1.55MHz 0x1C0 1110 00000 2.26MHz 2.20MHz 1.60MHz 0x1E0 1111 00000 2.36MHz 2.30MHz 1.70MHz 最大値

それぞれの周波数をプロットしてグラフ化してみたのが以下だ。

多少の誤差はあるが、ユーザーズマニュアルの方が正しいのだろう。

ユーザーズマニュアルの値に基づき、現在のWDTオシレータの周波数を取得するプログラムを作ってみた。

#include <stdint.h> #include "LPC8xx.h" /* LPC810内蔵のWDTオシレータ出力周波数(Hz) UM10601参考 */ /* ※FREQSEL(LPC_SYSCON->WDTOSCCTRL[8:5])で指定 */ const uint32_t Wdt_OscClk[] = { 0, /* FREQSEL = 0000b */ 600000, /* FREQSEL = 0001b */ 1050000, /* FREQSEL = 0010b */ 1400000, /* FREQSEL = 0011b */ 1750000, /* FREQSEL = 0100b */ 2100000, /* FREQSEL = 0101b */ 2400000, /* FREQSEL = 0110b */ 2700000, /* FREQSEL = 0111b */ 3000000, /* FREQSEL = 1000b */ 3250000, /* FREQSEL = 1001b */ 3500000, /* FREQSEL = 1010b */ 3750000, /* FREQSEL = 1011b */ 4000000, /* FREQSEL = 1100b */ 4200000, /* FREQSEL = 1101b */ 4400000, /* FREQSEL = 1110b */ 4600000 /* FREQSEL = 1111b */ }; uint32_t Wdt_getOscClk(void) { uint32_t clk; clk = Wdt_OscClk[(LPC_SYSCON->WDTOSCCTRL >> 5) & 0x0F]; clk /= ((LPC_SYSCON->WDTOSCCTRL & 0x1F) + 1) * 2; return clk; }

現在のWDTOSCCTRLレジスタ設定値からユーザーズマニュアルに基づいたクロック周波数を求め、関数値(Hz)として返す。 9.375KHzの場合は9,375、2.3MHzの場合は2,300,000を返す。

LPCXpresso Ver.6.1.0付属のsystem_LPC8xx.cのSystemCoreClockUpdateを、ユーザーズマニュアルの値に基づいて修正するには、この関数を同ファイル内に定義し、ローカル変数wdt_oscへクロック周波数を設定している箇所で、以下のように修正すれば良いだろう。

void SystemCoreClockUpdate (void) { uint32_t wdt_osc = 0; // 〜省略 // wdt_osc /= ((LPC_SYSCON->WDTOSCCTRL & 0x1F) << 1) + 2; wdt_osc = Wdt_getOscClk(); // 追加

Wdt_getOscClkは、ウォッチドッグタイマ機能で、暴走検出するまでの待ち時間を設定するときにも使えるので、SystemCoreClockUpdate同様にsystem_LPC8xx.h内にプロトタイプを定義しておくと良い。

#LPC810 #arm #nxp #クロック

LPC810(11) 〜システムクロック(2)

前項までの内容をもとに、PLLを使って内蔵オシレータ12MHzをクロックアップしてみた。なお、ここでの情報はLPCXpresso Ver.6.1.0(2013-10-21リリース)を元にしており、これ以外の版では違ってしまっているかもしれない。その点はご了承頂きたい。

クロック設定のためのシンボル値は以下の通りである。これらは、コアライブラリCMSIS_CORE_LPC8xx内のsystem_LPC8xx.c内で定義されている。これ以外のシンボルは無関係なので無視して構わない。

シンボル設定値説明 CLOCK_SETUP 1 初期定義値のまま変える必要なし。 MAINCLKSEL_Val 0x00000003 PLL出力をシステムクロックとする。 SYSPLLCLKSEL_Val 0x00000000 PLL入力を内蔵オシレータ(12MHz)とする。 SYSPLLCTRL_Val いろいろここを色々と変えてみた。 SYSAHBCLKDIV_Val 0x00000001 初期定義値のまま変える必要なし。

クロックアップ時の動作を確認するにあたって、LPC810の各ピンを以下のように割り当てた。

ピンNo. 名称説明 1 PIO0_5 黄色LEDをつなげて、処理スピードを見る。 2 CLKOUT 動作クロックの確認用としてクロック出力端子にする。なお、CLKIN端子と異なり、CLKOUTはどのピンへも割り当て可能なようである。 3 SWCLK デバッガ接続用 4 SWDIO デバッガ接続用 5 PIO0_1 未使用。ちなみにCLKIN端子は、このピンにしか割り当てできない。 6 VDD 3.3V電源 7 VSS GND 8 PIO0_0 赤LEDをつなげて、SysTickタイマを試してみる。

ブレッドボードで以下のように組み立てた。CLKOUT端子からの出力をオシロスコープで見るつもりだ。

なお、現在のクロック周波数は、コアライブラリCMSIS_CORE_LPC8xxに含まれる以下の関数を使うことにより知ることができる。

#include "LPC8xx.h" void SystemCoreClockUpdate(void); uint32_t SystemCoreClock;

SystemCoreClockUpdateを呼び出すことにより、外部変数SystemCoreClockの内容が、現在のクロック周波数に設定される。例えば、デフォルトの内蔵オシレータ(12MHz)で動作させていれば、SystemCoreClockには12,000,000が設定される。

せっかくだから、この値を使ったSysTickタイマも試してみる。汎用システムタイマ(SysTick)の操作は非常に簡単で、以下の関数を呼び出すだけで動作開始する。

#include "LPC8xx.h" uint32_t SysTick_Config(uint32_t ticks);

項目説明 ticks 指定ticks毎にシステムタイマ割り込みを優先度3で発生させるよう初期化する。割り込みは本関数を呼び出すと有効になる。 ticksはシステムクロックを単位としたクロック数で指定する。 ticksには1〜0x1000000(16,777,216)の範囲の値を指定する。戻り値常に0

すなわち、システムクロックが12MHzの場合、ticksを12,000,000とすれば1秒毎にSysTickタイマ割り込みが発生する。1ms毎に発生させたければ1/1000である12,000を指定すれば良い。システムクロックの周波数はSystemCoreClockで手に入るので、ms(ms)毎にタイマ割り込みを発生させる関数SysTick_startを作ると以下のようになる。

/*** SysTickカウンタの最大値 ***/ enum { SYSTICK_MAX = 0x1000000UL }; /*** SysTick_start: 引数ms(ms)毎にSysTick割り込みを発生 ***/ void SysTick_start(uint32_t ms) { uint32_t ticks = (SystemCoreClock / 1000) * ms; if (ticks > SYSTICK_MAX) { ticks = SYSTICK_MAX; } SysTick_Config(ticks); }

ms単位なので1000で割っているが、秒単位ならば割る必要はない。しかしその場合、すぐにticksが上限値を超えてしまうだろう。割り込み周期を200msとすると、上記関数は以下のように使用する。

/*** SysTick割り込みの起動間隔(ms) ***/ enum { SYSTICK_MS = 200 /* ms */ }; SystemCoreClockUpdate(); /* クロック数変数SystemCoreClockを初期化 */ SysTick_start(SYSTICK_MS);

SysTick割り込みハンドラは“void SysTick_Handler(void)”という関数を、自分のファイル(main.cなど)に定義すれば良い。今回は割り込み内部でPIO0_0の赤いLEDを点滅表示するようにした。

/* 各GPIO毎の機能割り当て */ enum { LED_PORT = 0, /* LPC810のGPIOポート番号は0のみ */ SYSTICK_LED = 0, /* P0_0をSysTick点滅で使う */ LOOP_LED = 5 /* P0_5を定常処理の点滅で使う */ }; void SysTick_Handler(void) { static uint32_t led = 0; GPIOSetBitValue(LED_PORT, SYSTICK_LED, led); /* SysTickでのLED点滅 */ led = !led; }

mainルーチンでは、処理のスピードを目視するため、一定時間の待機ループ毎にP0_5の黄色いLEDを点滅表示するようにした。クロック数を上げることにより、この待機ループの処理時間が変わってくるだろう。

int main(void) { volatile uint32_t i = 0; uint32_t led = 0; /* SysTickやCLKOUTなどの初期化(省略) */ for (;;) { GPIOSetBitValue(LED_PORT, LOOP_LED, led); /* 定常処理でのLED点滅 */ led = !led; for (i = 0; i < 0xfffff; i++) { ; /* 処理待ち */ } } return 0 ; }

割り込み側と同じリソース(GPIO)にアクセスしているが競合の心配はない。この点についてはGPIOの項で改めて触れたいと思う。

SYSPLLCTRL_Valの内容を色々と変えて動作確認した結果を以下に示す。 MSEL、PSELに関しては「システムクロック(1)」を参照のこと。表中の“論理値”とはPSELも含めて計算した周波数である。実際はPSELの設定値は無視されているようなので、MSELのみを見れば良いだろう。ある程度の周波数まで、CLKOUTからの出力をオシロスコープで確認した。なお、参考としてGIFで動作も示したが、あくまで目安程度に見て欲しい。

SYSPLLCTRL_Val MSEL PSEL 論理値 CLKOUT 0x00 0(等倍) 0(÷2) 6MHz 12MHz

PSELは全く動作してない。ちゃんと内蔵オシレータ12MHzがそのままCLKOUTに出力された。さすがに100万カウント超(0xfffff)の時間待ちループだと12MHzでも以下のようなゆっくりとした点滅(黄色)になるようだ。

SYSPLLCTRL_Val MSEL PSEL 論理値 CLKOUT 0x01 1(×2) 0 12MHz 24MHz 0x21 1 1(÷4) 6MHz 24MHz 0x41 1 2(÷8) 3MHz 24MHz

MSELを倍速にし、PSELを色々と変えてみたが、CLKOUTに変化はなかった。やはりPSELは無効なようだ。以下はPSEL=0の動作だが、動作は見た目どれも同じである。

SYSPLLCTRL_Val MSEL PSEL 論理値 CLKOUT 0x02 2(×3) 0 18MHz 36MHz

ユーザーズマニュアルではMax 30MHzとあるが、6MHzオーバーの36MHzでも動作している。ちゃんとCLKOUTからも36MHzが出力されていた。

SYSPLLCTRL_Val MSEL PSEL 論理値 CLKOUT 0x03 3(×4) 0 24MHz (48MHz?)

残念ながら手持ちのオシロスコープの帯域幅の限界を超えているため、CLKOUTの確認はできなかった。LEDの点滅動作も速くなっているような、いないような…

SYSPLLCTRL_Val MSEL PSEL 論理値 CLKOUT 0x04 4(×5) 0 30MHz (60MHz?)

一応最高スペックの2倍の速度だが、うーん、どうなんだろう。

SYSPLLCTRL_Val MSEL PSEL 論理値 CLKOUT 0x05 5(×6) 0 36MHz (72MHz?)

まさか、ここまでイケるとは思わなかった。60MHzと比較すると良く分からないが、36MHzと比較すれば倍ぐらいで動いてそうに見える。

SYSPLLCTRL_Val MSEL PSEL 論理値 CLKOUT 0x06 6(×7) 0 42MHz —

動かした瞬間にハードフォールトが発生して動作しなかった。

ユーザーズマニュアルでは30MHzが最大値と記述されているので、SYSPLLCTRL_Valに0x01を設定した24MHzが仕様に則った最高速になるのだろう。

72MHzで動作したのは驚きだが、これはたまたま自分の持っているLPC810だけがそうで、個体差があるかもしれない。残念ながら手持ちのオシロではスペックを遥かに凌駕しているため、本当に72MHzで動作しているのかは確認できなかったが、LEDの点滅速度を見てみると信用できるかもしれない。

なお、デバッガ接続でなく、単三電池(二本)でも以下のようにちゃんと動いていた(72MHz)。

クロック周波数の変化に関わらず赤LEDの点滅周期は変わっていない。これは、SystemCoreClockをベースにSysTickタイマ割り込みを設定したからだ。

#LPC810 #arm #nxp #クロック

LPC810(10) 〜システムクロック(1)

LPC810のシステムクロックは以下の四種類より選べる。

12MHzの内蔵オシレータ(デフォルト)

新規プロジェクトを作ってシステムクロックについて何も操作しないと、このオシレータで動き出す。

外部クロック

クロック入力端子(CLKIN)からの入力を使う。CLKIN端子は5番ピン固定。

上記1.又は2.を内蔵PLLで逓倍したもの

ユーザーズマニュアル(UM10601.pdf)によると最大30MHzまで。

ウォッチドッグタイマ(WDT)用の低速オシレータ(9.375kHz〜2.3MHz)

WDT用のオシレータをシステムクロックとすることも可能なようだ。

LPC811やLPC812などのLPC8xxシリーズの上位マイコンの場合は、この他に外付けの水晶発振子(1MHz〜25MHz)でも動作可能なようだが、LPC810ではできない。

12MHzの内蔵オシレータは、データシート(LPC81XM.pdf)やユーザーズマニュアル(UM10601.pdf)ではIRC(Internal RC) oscillatorと記述されている。ここでは単に「内蔵オシレータ」と呼ぶことにする。内蔵オシレータは12MHz固定である。ここでは、システムクロックをデフォルトの12MHz以外で動作させる方法についてまとめる(上記の3.と4.)。

なお、これらの情報はLPCXpresso Ver.6.1.0(2013-10-21リリース)を元にしており、これ以外の版では違ってしまっているかもしれない。その点はご了承頂きたい。

システムクロックの設定は、コアライブラリCMSIS_CORE_LPC8xxに含まれる以下の関数で行っている。この関数はsystem_LPC8xx.c内で定義されている。system_LPC8xx.cはコアライブラリCMSIS_CORE_LPC8xxのsrcフォルダに入っている唯一のソースファイルである。

#include "LPC8xx.h" void SystemInit(void);

SystemInitはスタートアップルーチン(ResetISR)で呼び出しているので、ユーザーが明示的に呼び出す必要はない。この関数の中では、LPC810のSYSCON(System configuration)レジスタを操作し、システムクロックを決定している。システムクロックは、このSYSCONへの設定値で決まる。

SYSCONにどのような値が設定されるかは、いくつかのdefineシンボルの値に依存している。これらシンボルの値を変えることで、システムクロックを好みのものに切り替えることができるのだ。

以下に、これらシンボルと、それぞれ対応するSYSCONレジスタ名、及び各シンボルの意味についてまとめておく。なお、表だけでは分かりづらいと思うのでブロック図も示す。これらのシンボルは、全てsystem_LPC8xx.cの先頭で定義されている。

No. シンボル初期定義値レジスタ説明 1 CLOCK_SETUP 1 — クロック設定の有無を選択できる。0にするとクロック設定のコードが無効になる。 2 SYSOSCCTRL_Val 0x00000000 SYSOSCCTRL 外付け水晶発振子の周波数を設定するのだが、LPC810ではこの機能は搭載してないので、本シンボルは無視して構わない。 3 WDTOSCCTRL_Val 0x00000000 WDTOSCCTRL クロックソースにWDT用オシレータを選択した場合に、そのクロック周波数を指定する。詳細は後で説明する。 4 SYSPLLCTRL_Val 0x00000041 SYSPLLCTL クロックソースに内蔵PLLの出力を選択した場合に、そのPLLへの設定値を指定する。詳細は後で説明する。 5 SYSPLLCLKSEL_Val 0x00000000 SYSPLLCLKSEL 内蔵PLLへの入力選択。 0: 内蔵オシレータ(12MHz) 1: 外付け水晶発振子(LPC810では不可) 2: 予約(設定不可) 3: 外部クロック(CLKIN端子からの入力) ※これ以外の値は設定不可 6 MAINCLKSEL_Val 0x00000000 MAINCLKSEL 【重要】システムクロックの選択。 0: 内蔵オシレータ(12MHz) 1: 内蔵PLLへの入力クロック 2: WDT用オシレータ 3: 内蔵PLLからの出力クロック ※これ以外の値は設定不可 7 SYSAHBCLKDIV_Val 0x00000001 SYSAHBCLKDIV システムクロックの分周値。 1〜255の範囲で指定する。0だとシステムクロックの停止となる。

IOCONに関してはGPIOで色々と試すときに説明しようと思う。

LPC810の場合は以下の選択となるだろう。表中の“ー”は、該当のクロックソースを選んだ場合、設定の必要のないシンボルである。

シンボル ①内蔵オシレータ (12MHz) ②外部クロック (CLKIN) ①を逓倍したもの ②を逓倍したもの WDT用オシレータ MAINCLKSEL_Val 0 1 3 3 2 SYSPLLCLKSEL_Val — 3 0 3 — SYSPLLCTRL_Val — — (※1) (※1) — WDTOSCCTRL_Val — — — — (※2)

※1：ビット構成が以下のようになっており、フィードバック部分であるMSELと出力後のPSELを指定するのだが、MSELはまだしもLPC810ではPSELが動作しない。

ビット記号説明 b4〜0 MSEL フィードバック部分の分周値(Feedback Divider)を指定する。 00000(0x00)〜11111(0x1f)で、それぞれ1〜32の値になる。すなわち、MSELの値で1倍(等倍)〜32倍になる。ユーザーズマニュアルでは、PLLの出力クロックとしては100MHzが最大と記述されているが、そもそもLPC810ではこんなクロックで動作しない。 b6〜5 PSEL 出力後の分周値(Post Divider)だが設定しても機能しない。ユーザーズマニュアルによると00(0x0)〜11(0x3)で、それぞれ2, 4, 8, 16の分周値の意味になるようだが、動作しない。常に1/1と考えて良さそう。 b7〜 — 0以外設定してはならない。

PSELが動作しないのは事実のようであり、system_LPC8xx.c内のプログラムでもMSELのみ使用し、PSELの内容を見てない。「システムクロック(2)」で説明するが、PSELの値を変えても生成されるクロック周波数に変化はなかった。

※2：WDT用オシレータは任意の周波数を本レジスタの設定値で選択することができる。ビット構成は以下の通り。

コアライブラリのソースファイルsystem_LPC8xx.cを既に見た方は、FREQSELの値がソースコードと異なっていることに気付かれたかもしれない。結論から言うと、コアライブラリのソースコードの方が間違っているのだ。これについては「システムクロック(3)」で検証する。

まずは、内蔵オシレータ(12MHz)をPLLでクロックアップしてみた結果を、次の「システムクロック(2)」で説明しよう。

#LPC810 #arm #nxp #クロック

自宅近くの河川敷に、申し訳程度に菜の花が咲いている。管理されているようで、されてないようで、ポツポツと咲き出している。

#風物詩 #菜の花 #diary

Trending Blogs

Recently Viewed Blogs

9353log