mbedクラウドで作るプログラムのデバッグ


 ■はじめに

mbedのクラウド環境は便利で、コンパイラのインストールも必要ありません。
反面、コンパイラがローカルPCに無い=生成するプログラムの製造過程はローカルで把握できない=ローカルでCPU動作を管理するプログラムが無い事になります。
これがオンラインコンパイラの泣き所かも知れません。
しかし、プログラムは思った通りに動かないものです。
このため、自分の考えと実際の動作が異なっていないか調べるのがデバッグです。
通常のデバッグはコンパイラと1:1に結合した、デバッガソフトが行います。
このために専用装置が必要な場合もあります。
このような装置もなく、ローカルにコンパイラも無い状況でデバッグを行うには、ある程度の工夫が必要になります。
 


 ■LEDを利用する

mbedで最初に作るプログラムとして、LEDを点滅させるものがありました。
LEDをチカチカ点滅させるので、一般にLチカと呼ばれるものです。
このプログラムは、最初の動作確認用として存在するイメージですが、LEDを自由に点けたり消したりする操作はデバッグに利用する事ができます。
プログラムの量が増えてくると、作成したブロックや関数が実行されたのか、はたまた、自分の希望部分を実行しているのか判断できない場合があります。
このような場合は、プログラムが通過する部分にLEDを点灯(あるいは消灯)させるコードをあらかじめ追加してコードを作成します。
実際に動作を行い、LED点灯状況からプログラムの通過、不通過を判断します。
この方法の利点は、実行時間に殆ど影響を与えない事です。

下の例はforループを途中抜け出しの可能性がある場合に、最後まで実行したのかを調べています。

搭載しているLEDは出力に0を書き込むと点灯、1だと消灯するので、この書き方だと、可読性が良くありません。
LEDは左右で二個付いていますので、若干の定義を加えて見やすくします。
LEDに付ける名前ですが、LED1、LED2は既に使われていますので、記号を加えてLED_1、LED_2としました。


何をしているのかが判りやすくなりました。
LEDの左右を表す、RとLの文字を含めても良いと思います。

**ちなみに、上記プログラムには間違いがあります(文法上は合っている)
チェックのために、LEDを点灯させる部分には到達しません
for(i=0;i>10;i++)
と繰り返し条件が、実行前から不成立になっています。
正しくはi<10です。


 ■printfデバッグ
MC11U35 CPUボードでは、この手法を利用する前に準備(と機材)が必要です。
printfデバッグは正式名称ではありませんが、デバッグで内容を知りたい際にprintfを利用するため、付いた名前のようです。
MC11U35 CPUボードでprintfを行うには、CPUからのシリアル出力を、PC(またはターミナル)に接続しなければなりません。
信号の形式は一般にTTLとよばれ、PCの232Cシリアルポート(COMポート)に直接接続する事はできません。
SP3232のような、TTLレベルの信号を232Cレベルの信号に変換するICを通しての接続になります。
しかし、昨今のPCには232Cコネクタ(COMポート)は装備されなくなりました。
その場合の接続は、USBに接続する方法をとります。
市販品のUSBシリアルコンバータを入手しての接続となるのですが、二種類市販されています。
(1)232Cコネクタを増設するコンバータ
(2)TTL形式のシリアル信号を直接USBに接続するコンバータ
1のコンバータはシリアルコネクタ(COMポートで一般に9pinのD-SUBコネクタ)をPCに追加するものです。
こちらは、232C信号をインタフェースするため、MC11U35 CPUボードのTTLシリアル信号では、もう一段変換が必要になります。

信号順に表すと、
MC11U35 CPUボード -> TTLと232Cのレベル変換 -> USB、232Cコンバータ -> PC

一方、2の方式は、TTL信号をそのまま扱いますので、
MC11U35 CPUボード -> USB、シリアルコンバータ -> PC

と余分な回路が不要になります。
ただし、注意点があります。このコンバータには、接続する相手の電圧に合わせて、5V系と3.3V系(または切り替え式で両方の電圧に対応)が販売されています。
MC11U35 CPUボードのシリアル出力は3.3Vの信号ですので、3.3V系に対応するコンバータを入手します。
スイッチサイエンスで探すと、
ケーブル型の物ユニット型の物が売られています。
どちらを使用しても、機能を満足しますが、ちょっとした選択が必要です。
ケーブル型は、信号線の先端がピンに直接ささる形になっていますので、MC11U35のヘッダーピンに直接接続できます。しかし、使用環境がwindows7までとなっています。
一方、ユニット型の物は、windows8にも対応しますが、コネクタ間の接続が必要です。
環境に合わせて選択してください。
接続は下図のように、コンバータのTX線CPUのRXDへ、RX線をCPUのTXDへ、最後にGND間を接続するだけです。

 printfデバッグを行う
MC11U35 CPUボードでprintfを行うためには、UARTの機能を使います。
LPC11U35のCPUには、UARTの機構が1set実装されています。
通常は、UARTの初期化と送受信の管理が必要ですが、mbedのクラウドで作成する際に組み込まれるmbedユーティリティーには、この部分が既に含まれています。

プログラムの作成、編集の画面で、左のMy Programsの中にある[+mbed]の+をクリックして展開します(下の画面左側)
さらに[Classes]の頭の+をクリックしてClassesを展開します(画面右)

 mbedを展開  Classesを展開
 
今展開して表示されたのは、クラスと呼ばれ、利用可能な機能の固まりのようなものです(詳細を知りたい方はC++で検索するか、参考書をご利用ください)
展開表示したクラスの中で[RawSerial]と[Serial]が今回利用したいUARTの関係です。

Serialの箇所をクリックしてください。
新しいページが開き、使える関数(クラスのメンバー)が表示されます。
Serialは便利な関数が使えますが、メモリを多く消費します。
printf関数(命令)はSerialで利用可能です。

下のプログラムは8行目にSerialの使用を追加しています。
名前はmbedで良く使われるpcとしましたが、特に意味はありません。
付けた名前.printfで利用でき、下の例では21行目と22行目で使用しています。


pc.printf("sum=%d\r\n",sum); で、sumの値をシリアル出力して確認しています。

実行した結果です。


間違ったプログラムなので、sumの内容が0のままになっている事が確認できます。

for文の中を修正し、実行させます。
for(i=0;i<10;i++){


希望した合計の値になっている事が確認できます。
(LEDも点灯します)

変数のチェックやメッセージを配置してデバッグを行います。

hint!
・Srialはメモリを多く消費する以外に、printfは割り込みルーチンの中では使用しないのが原則となっています。
一方、RawSerialは便利な関数が無く(printfはありません)一文字毎の入出力になりますが、メモリの消費が少なく、割り込み内でも使用できる事になっています。
・シリアルの伝送速度とフォーマットは既定値のままとして、設定せずに使用しました。
何も設定しない場合は9600bps、8bit、パリティー無しです。
伝送速度を変える場合はbaudを使用します。先の例を38400bpsに変更する文を追加するには、
pc.baud(38400);
をmainに記述します。
・シリアル伝送ですので、ある程度の時間がかかります。
9600bpsですと、1文字伝送するのに、約1ms必要となります。
先のsumを表示させている部分は19文字(見えない文字が4文字分あります)
ですので、19mSの時間がかかる事になります。
この間、プログラムの実行が制限される可能性がありますので、出力する文字数は短いほど有利です。
また伝送レートは速いほど、時間が短縮できます。
 
取り扱い説明書に戻る