組み込み技術のエキスパート　ビーコン

こんにちは、ビーコン菅原です。


半年ほどまえから我流ではありますが、マインドマップを勉強して活用をしています。

マインドマップというと分析とか発想法と考えている方も多いと思いますが、色々なことに応用可能です。

私はマインドマップをソフトウェア設計に応用してみました。

これはなかなか良い。

もちろん、もともとソフトの開発ができる人は頭の中で設計ができあがっているか、図式化をしているはずです。
一番いけないのが行き当たりばったりで、しかし、よくやってしまうプログラマも多いのではないでしょうか?
ちょっと試しに作ってみて、そのまま本番ソフト制作に入ってしまうパターンですね。
私も以前は自分なりに図を描いて設計したり、EXCELを使ったりすることが多かったのですが、設計するときには使っても後から使わなかったり、見返しても何を考えていたのか思い出せないこともよくありました。でもマインドマップにしてからは、あとからよく見返して使うようになりました。
一人で行う小規模なソフトウェア開発ならば、マインドマップだけで結構いけます。


ソフトウェア開発マインドマップの作り方は簡単。
真ん中に開発する案件の名前を書き、必要な機能やスペック、使用するデバイス、思いついたアイディアやモジュール名、変数名などを思いつくままに枝にのばしていきます。
書いている途中で様々な不備、不明点が明らかになったり、こうすればよいとひらめいたりとさまざまな気づきがあります。
この調子で二三回書き直すと、完成の域に達してきます。

とくにマインドマップで優れているのは全体を俯瞰してみることができるということ。ルールが単純であるということ。
マインドマップをあらかじめ作ってからコーディングすると、頭に全体の構成がバシッと入るために、開発が進んでから行き詰まったり、悩んだりすることが少なくなりました。あと、仕様の抜けもなくなりました。
不思議とあとからみても思い出しやすいし。


最近はマインドマップのための良いアプリケーションがでてきましたが、私は今のところ手描きにこだわってます。

■私が描いたマインドマップ
ある組み込みのソフトウェア開発　最初だったので要求仕様が中心の記述。

何度か書き直した最終的なマインドマップ。この後コーディングを開始。

打ち合わせの議事録として作った例。このときはソフトウェアの追加・変更で　合計17項目あったのですが、このマインドマップのおかげで忘れたり、混乱することなく作業を完了することができました。


ただし、人に正確に伝えるにはマインドマップだと、自分ルールが多すぎるので、やりとりは難しいかもしれません。
オフィシャルなドキュメントはUML等がよいでしょうね。

最後に参考文献を

石ヶ森久恵さんのマインドマップを見るだけでもモトがとれる。


マインドマップのバイブル

■　DMA vs memcpy　(SH2 with HEW)

C言語においてメモリ内容をコピーする場合、memcpyを使用するのが一般的。

DMAコントローラーを制御できる場合はDMAでコピーするのも手。
DMAとはDirectMemoryAccessの略で、CPUを介すことなくメモリに直接アクセスして、コピー等を行うことで、
DMACとはDirectMemoryAccessControllerの略でDMAを実行するのハードウェアのこと。
組込用途だと、最近は外付けのDMAコントローラーなんて使わなくて、チップに内蔵しているものを使います。


DMAに転送する元番地、先番地、回数、ビット幅、番地をカウントアップするかどうか等の設定をするとハードウェアが勝手に転送してくれます。
その間CPUは他の処理が出来るというわけです。
といってもDMA実行中はバスマスターがDMAとなり、CPUはメモリアクセスできないのでできることは限られてきますが。

DMAとmemcpy()関数とどちらが速いかということですが、今まで私は圧倒的にDMAが速いと思っていました。
事実そういうことが多いのですが、あるとき、こんなことがありました。
ルネサスSH2で HEWコンパイラのときに少しでも転送時間を短くしたいことがあり、memcpyをやめてDMAでメモリ転送を使ったのですが、どうも早くなっていません。
おかしいと思い、memcpyとDMAで実行時間を比較しましたところ、ほとんど同じという結果が出ました。

恐るべしHEWコンパイラ。

普通考えればハードウェアで実行している処理とソフトウェアで実行している処理と同じというのはちょっと考えられません。
というのもソフトウェアで処理する場合(memcpyの場合)、データをコピーする時間に加えて、回数を計算する処理が必要だからです。

memcpyのライブラリがどのようになっているかは知りませんが、おそらくマシン語でカリカリにチューニングしてあるのでしょう。


■DMAのmemcpy的ではない使い方

で、SH2始めとする多くの組込MPUはDMAはmemcpyの代わりだけに使うのではなくて、例えばシリアルなどの割り込みと連動して使用できます。
元番地をSIOの受信データレジスタ
先番地を受信バッファのアドレス、
DMAのトリガをSIOの受信割り込みと絡ませてやるわけです。

こうすることによって割り込み処理を使わなくても取りこぼしがない受信ができます。
当然送信もできるし、タイマの割り込みフラグと絡ませると時間キッチリでDAにデータを連続出力して、アナログ波形を出すなどという芸当も出来ます。

割り込みのオーバーヘッド(つまり、レジスタ退避などの時間)がないので、割り込み処理を使うよりも高速に処理できます。
しかもデータの取り込みにCPUのパワーを使わないところもイイデスネ。


■DMA サイクルスチールモードとバーストモード

DMAの転送にはサイクルスチールモードとバーストモード二つのモードがあります。
サイクルスチールはCPUとDMACがバス権を渡しあって処理をします。
CPUが1回データを動かしたらDMACにバス権を渡し、
DMAが1回転送をしたらCPUにバス権を渡します。

バーストは設定した転送回数が終了するまでバス権を渡しません。

当然バーストの方が転送時間が短いのですが、転送終了までバス権が渡されないので、割り込みも転送終了まで待つことになります。
転送速度の要求でやむないときもありますが、転送時間がどの程度になるかキッチリ計算・測定する必要があります。
大量のデータをバーストモードでコピーすると割り込みに対する応答が待ちあわないなんてことも発生します。

サイクルスチールモードの場合はCPUもバス権があるタイミングがあるのでDMAが働いていないときよりは遅いものの割り込みを受け付けます。

シリアル通信の受信などの場合は、転送に要するタイミングがほんのちょっとであとは待ち時間となります。したがってバーストモードにするとDMAが終るまでCPUが止まっているようになってしまうので、サイクルスチールモードにします。

小マイコンでsmalight(マルチタスクOS)を使うときの注意。

smalightで開発始めて一週間。

マニュアルはあっさりしています。もうちょっと親切でもよいのにと思いますが・・
しかし、意外とあっさり動きました。


開発する上での注意点を少々。

◆タスクの増えすぎに注意。

マルチタスクの便利さに気付き、使い慣れてくるとたくさんのシンプルなタスクを作りたくなります。
各タスクには必ずスタックが必要なので、RAMが数百〜数Kbyteの小マイコンの場合、あっという間にRAMがなくなります。
ちょっと前までNORTiで40個ぐらいタスクが走るシステムの開発をしていたので、その感覚で小さなタスクを量産していたら、RAMが足りなくなってしまった。

◆タスク、割り込みのスタック量に注意。
タスクの定義は smalight configuratorというユーティリティソフトウェアを使います。
ユーティリティで設定するタスクのスタックはデフォルトのが 128バイト。
128バイト程度だと、浮動小数点演算をするとオーバーすることがあります。
自分がローカル変数をたくさん取っている場合には気付きやすいのですが、
例えば・・
float f,v;
v = f*3.1415 -15.0;
のような単純な計算だったとしても、コンパイラがひそかに浮動小数点計算のライブラリ関数をコールしてスタックを消費していることがあります。
printf系もスタックをたくさん消費します。このような関数も注意が必要です。
再帰関数も最大何回再帰するか確認します。

RAMに余裕があるシステムでは余裕を持って、スタックに何Kbyteもとっておくことができますが、小マイコンでは不可能。
こういったスタック関係のトラブルはいきなり暴走してしまうので、デバッグに骨が折れます。

HEWだと call walker(スタック計量ソフト)が付属しているのでこれで各タスク、割り込み処理が何バイトスタックを消費しているか確認します。

それでもマルチタスクだと、複数の同時進行の処理をしなければならないときにも開発効率がよいし、すっきりとしたコードになります。
一度マルチタスクの快適さに慣れてしまうと、マルチタスク無のシステムがつらく感じます。


◆割り込みレベルについて
今のところR8Cのsmalightしか使っていないので、このマイコンに限っての話ですが、割り込みの応答時間でシビアな要求がなければディスパッチ有、無にかかわらず割り込み優先レベル選択は全部「レベル6」、多重割り込み無にしておくのが無難。



コンパイラ
M16C/60,30,20,10,Tiny,R8C/Tinyシリーズ用
Ｃコンパイラパッケージ V.5.43

HEW4
Version 4.03.00.001

Smalight OS V3.00
for R8C/Tiny

smalight configurator v1.00.07

PC
Windows 2000
Service Pack 4




-----------------------
マイコンシステムの開発は
----------------ビーコン
-----------------------

smalightが納品されてきました。

Smalightとはルネサスが出しているuITRONライクなリアルタイムマルチタスクOSです。
小さいマイコンにも搭載できるように資源の消費が最小限になっています。

マルチタスクOSってタスク切替の考え方を理解してしまえば、自作もできます。
要は戻ってこない割り込み処理みたいなものなのですが、仕様を決めるのと、デバッグが大変です。
また、速度が速く、メモリがたくさんあるマイコンシステムはいいですが、小さいマイコンでは荷が重くなります。
このような理由から、今回は購入しました。
評判がよいこともあるし。


厳しい?審査を経て、
待つこと一ヶ月。

やっと来ました。


値段の割には簡易包装すぎる気がしますが、購入したのはライセンスですからね。

ライセンス形態はシステム用途限定ライセンスです。
別の製品を開発する場合にはもう一つsmalightを購入します。(と思う)

サポートしているデバイスは
H8,R8C,M16C,SH-2といったところ。
願わくばメーカーの壁を超えて他社のCPUにも移植されてほしいところです。

プログラムをしていると、真と偽の二つの値をとる型が欲しいときがあります。

真と偽は普通 TRUEとFALSEで表現します。

TRUE 真
FALSE 偽

真と偽のニ値しか取らないタイプの型です。

C言語にはそのような型はありませんので、みな勝手に作るわけです。
多くの場合 BOOL とか BOOLEAN という型名となります。
この定義もプログラマーの考え方などによりちょっと違ってくるのです。

定義例
#define TRUE (1==1)
#define FALSE (!TRUE)

定義例2
#define TRUE 1
#define FALSE 0

定義例3
#define FALSE 0
#define TRUE (!FALSE)

BOOLのtypedef も
int の人がいたり char (一番小さい型)だったりと様々。

このあたりのいいかげんさが、複数の人で開発したり、移植したりする際にバグの原因となったりするわけです。
特に条件判断をするところではよく間違いが起きます。


IPA　独立行政法人　情報技術処理推進機構　ソフトウェアエンジニアリングセンターで出している
組み込みソフトウェア　開発向けコーディング作法ガイド[C言語板]でも
R2.2.1　真偽を求める式の中で、真として定義した値と比較しない。
としています。


例として func1の戻り値が真であれば括弧内のコードを実行するソースコードの場合は

○
if(func1() != FALSE ){
;
}

○
if(func1() ){
;
}

× if(func1() != TRUE){
;
}

　※func1()の真と TRUE　が必ずしも一致するとは限らないため




私は最近　0,1を直接表現する方法に戻っています。
格納変数は　isXXXXX と言う名前にします。
これはプログラミング作法という本から影響されました。



例えば以下のような関数があるとすると
int isCommandA( void );

関数の実行結果が OKであれば 1 ,NGであれば　0　となります。

これだと TRUE/FALSE　よりも分かりやすいと思います。

C言語の標準関数に isdigit()等の is系の関数があるので、特に説明しなくてもC言語プログラマには直感で理解していただけるのではないかと思います。

もっとも is系の関数は　真であれば 0以外の数が戻り値となるとあるので、
×
if( 1 == isCommandA()){

}
という書き方は禁止です。


◆◆　参考書籍　◆◆






◆組み込み技術のエキスパート　ビーコン