月: 2016年12月

R8C/38のタイマ機能（PWM）

マイコンカーラリーのレギュレーションで使うことになっているマイコンのR8CシリーズのPWMをコントロールするプログラムを書くのは結構大変です。

タイマ関係のレジスタがタイマごとに違っていてやたら数が多いのです。
stm32Fシリーズだと例えばTM2～TM5は同じ構造になっていて、同じルネサスでもR8Cと異なり旧日立系のH８シリーズもタイマ関係はよく整理されていて判りやすい構造になっていますがR8Cはタイマー関係のパーツを無秩序に寄せ集めたような印象です。

R8CではPWMのデューティを決めるアウトプットコンペアレジスタのバッファを設定する必要があり、設定によってはバッファなしで動作する場合もあります。
アウトプットコンペアレジスタとは次のTRGBに相当するものです。（次の図はH8の例です）

TRGBに設定する値がPWMのデューティになります。
TRGAの値が20000であればタイマのカウンタは０～20000のカウントを繰り返し、TGRBが3000 ならカウンタが3000になった時に信号TIOCAがHighになるという動作をします。
モーター制御ではこのTGRBを頻繁に書き換えますが、バッファが無い場合はTGRB新たに設定する値が2000の場合、カウンタの値が2000を超えて3000未満の時に書き換えたらTIOCAはカウンタが20000になるまでLowのままになってしまいます。
つまり１周期だけデューティ１００％の信号が出る誤動作が起きることになります。

このような事態を避けるためにTGRBに設定する値をバッファレジスタに入れておいてカウンタが０になったタイミングでTGRBに設定する機能がH８シリーズにしろstm32Fシリーズにしろ最近の制御用マイコンにのPWMには標準搭載となっています。

マイコンカーラリー事務局が提供しているサンプルプログラムではバッファが無いアウトプットコンペアレジスタの値を設定するのにPWM用タイマのカウントアップで起動した割り込み関数で値を設定するという面倒なことをやっています。
一昔前はハードウェアリソースが限られていたためこのようなことをプログラミングテクニックでカバーするのが当然でしたが、出来れば無駄なことはしなくて済む方が良いに決まっています。

マイコンカーラリーでは事務局提供のサンプルプログラムが良く出来ているのでR8C周辺機能の扱いにくさは問題になりませんが、ある程度プログラムが判ってきて自分で新しいシステムを考えられるレベルになればR8Cなど使わずにPIC、stm32FシリーズやArduino等を使う方向に流れるのは容易に予測できます。

せっかく周辺機能の扱いやすさではR8Cよりもはるかに優れたH8、SHシリーズがあったのに、一般ユーザー獲得の一環で始めたのであろうと思われるマイコンカーラリーのサポート事業向けにR8Cを押す辺りにルネサスのマイコン事業迷走の理由が見えるような気がします。

マイコンカーラリー用データロガー UART2MMC

※公式にSDカードという呼称を使うこと、及びSD書き込みプログラムをライセンス無しで提供することはSDライセンスで禁止されています。
マイコンカーラリーのプログラムが使っている書き込み方法はMMC方式でありSDライセンスの範囲外で問題ありませんし、MMC方式でもほとんどのマイクロSDカードが使えます。
以下の説明でMMCという表現が出てくるのはライセンス上の制限を明確にするためだけであり、SDカードと別規格のカードを意味するものではありません。

ＪＭＣＲ実行委員会が提供しているマイコンカーラリーのプログラムにはMMC(SD)カードへのデータ書き込み用ライブラリが用意されていて走行中のデータをSDカードに保存することが出来るようになっています。
ただ、CPU性能の制限により書き込み出来るのは10mSに一度であり、1mS毎の制御ループからすれば物足りません。

そこで最大1.25Mbpsでデータを送出可能なR8C/38上のコネクタを使って1mS毎の走行データを記録できるようにするのがこの試みの目的です。

R8C/38ボードが1.25Mbpsで通信できることは「マイコンカーラリー printfデバッグ (3) printf文を埋め込む」で確認しました。

STM32CubeMXのHALライブラリにあるFatFsを使ってMMC(SD)カードに書き込みできることも「stm32F765VGT6+STM32CubeMXでfatfsを動かしてみる」で確認出来ました。
ただ、あの記事に載せたボードはプログラム書き込み用のUSBシリアルを追加した新バージョンの基板CADによる３Dモデルで、実際はこのようなボードでテストしました。

一番上のボードがデータロガーボードでその下がR8C/38ボード、一番下はマイコンカーラリーをやっている先生のご要望に沿って作ってみたモータードライブボードです。

モータードライブボードにLCDを接続すると次のような状態になります。

後はデータロガーに書き込むコマンドを決めて、メインループや割り込み関数の中でprintf()を実行すればデータを保存できるようにする予定です。

コマンド例

“OPEN test.txt\n”     ファイルを開く
“CLOSE \n”                ファイルを閉じる
” WR 0123,3412,1333,13334,134134\n”
データを書き込む ： WR 以降のデータ（”WR “は除く）が保存される、データは数値も文字も関係なく保存される。

基本的にはこれだけのコマンドで十分だと思います、考慮すべきはファイル名が重複したときに追記にするか新たな名前でファイルを作るかくらいでしょう。

UART2MMCの新バージョン

R8C/38ボードを触っていて色々気づいたことがあったので改良することにしました。

１．デバッグのためにR8C/38ボードを使っていて感じたのが書き込み用とデータロガー用のコネクタが兼用のためコネクタの抜き差しが煩雑になるのでプログラム書き込み用にUSBコネクタを追加しました。
つまりこのボードはプログラム書き込み用USBシリアル変換基板としても使えます。
プログラム書き込みとデータロガー機能はボード上のロータリーディップSWで切り替えます。

２．標準のUSBシリアル書き込みツールでは書き込みモードにするとき、プログラムを走らせる時にUSBコネクタを抜いてボードの電源を切る必要があります。
また、USBコネクタを一度抜くとUSB接続が不安定になり複数回USBコネクタを抜き差しする必要があったのでUSBコネクタを挿したままボードの電源を切ることが出来るようにTARGET OFFスイッチを追加しました。

３．一般的にこのツールを提供する場合を考えてライセンス規約に則り
UART2SD  → USRT2MMC に名称を変更しました。

 

 

 

STM32CubeMXをGCC（JDE)で使う(1)

STM32CubeMXについて

Stm32CubeMXはベースとなるライブラリHALも動作が安定してきて既にSTM32CubeMX抜きの開発など考えられないほど便利な開発環境です。
ただ、便利になったぶん構造が複雑になって、以前のライブラリのようにフリーの開発環境で簡単にHALを使うのは難しくなりました。

統合開発環境JDEの生い立ち

私は組込開発に専ら自作の開発環境であるJDEを使っています。
現在、組込用メインCPUとしているtm32Fシリーズを使い始める前は、H8、SHシリーズを使っていて、その前はV25を組込み開発用のCPUとして使っていました。

V25はPCと同じ８６系のCPUなので、PC用のコンパイラであるBCC（Borland C Builder)とBCCが生成したPC用のオブジェクトを組込ボードで動作させるために作ったV25モニタを使ってコンパイル、転送、実行が素早くできる工夫をして自社製品にも活用しましたしV25ボードも様々な方に愛用していただきました。
そのV25がディスコンなどで使えなくなりH8,SHシリーズを使い始めた時に作ったのがGCCをベースにしたJDEです。

GCC

H8、SHシリーズを使い始めた時に開発用のコンパイラとして何を選ぶかという問題がありました。
当時はまだオープンソースのソフトをキワモノ扱いする人も多くメーカー純正コンパイラの評価が圧倒的に高い時代でしたが将来的にはGCCが優位に立つという見通しでGCCを選択しました。
他の理由としてはCPUボードや製品を愛用していただいている方に学校関係者や研究職の方が多いため「出来るだけフリーソフトで開発できるようにしたい。」ということもありました。
今ではLinuxが普及したこともあり汎用コンパイラとしてのGCCの評価は完全に固まり、組み込み用としても最適化性能を除いてはGCCが優位になりました。

最適化性能をどれだけ問題にするかは立場によって異なります。
民生機器のように数円のコストが問題になる場合はギリギリの性能と最小限のROM/RAMを持つCPUを使うためにコストや汎用性等他の点を犠牲にしても最適化性能に優れたコンパイラを使う必要があります。
一方私たちのようにFA分野の仕事を手掛ける場合や研究職、教育関係者の方々にとっては最適化性能より汎用性、コストパーフォーマンスに優れたコンパイラを使う方が有利です。
何故なら、組込分野では使えるCPUの性能は様々であり多少のコストアップで最適化性能の差を埋めるCPUを使うことが出来るからです。

具体的な例をみると、マイコンカーラリーのレギュレーションで決まっているR8Cボードに搭載されているR8C/38Aという16ビットCPUは秋月価格450円でROM128KB,RAM20KB、クロック20MHｚですが、マイコンカーラリー用のデータロガーボードの試作に使ったDigiKeyで入手できる価格1517円のSTM765VGT6は32ビットでクロック216MHｚ、ROM１MB、RAM512KBと一桁以上の性能を有しています。
このくらいのROM/RAMがあればリアルタイムOSも楽に動くので制御ループと同時にモニタプログラムを走らせておくことも出来ますし浮動小数形式が使える普通のprintfを使っても全く問題がありません。

つまり最新の高性能組込用CPUを使えば最適化性能を気にする必要は無く、オープンソースのGCCを問題なく使えるということになります。

JDEの履歴

JDEを作った当初の目的はGCCを使うこと以外にV25モニタの思想を引き継いだH8用モニタを使ってコンパイラから転送、実行までの流れを自動化するということにありました。
私が開発を効率化するために最も重視するのはボード上の情報可視化とターンアラウンドタイムの短縮です。
H8はボード上のCPUにシリアルケーブルだけでプログラムを書き込み出来るオンボードプログラミング方式の先駆けとなったCPUでしたがCPUに書き込むために「電源を切る → ブートモードSW ON → 書き込み → 電源を切る → ブートモードSW OFF → 電源投入」という手順を踏む必要がありました。（今のR38C/38Aボードも同じです）
H8モニタを使えば書き込むために一度ボードのリセットボタンを押す必要はありますがボード上のスイッチを操作しなくても転送から実行が出来ますし、モニタモードでボードのメモリ情報を見ることが出来るようになっています。
僅かな差ですが、スイッチ操作の削減とモニタモードでの情報があることで、開発が効率的になるものです。

H8、SHシリーズに見切りをつけたのはルネサスの大手メーカーだけを向いた営業姿勢により突然デバイスの供給が数か月中断するといった事態が起こり始めたのがきっかけでした。（具体的には自動車メーカーの都合で一般へのデバイス供給が中断した件）

JDEはGCCがサポートしているCPUなら何でも使えますから、GCCが組サポートしているアーキテクチャの中で最も前途有望と思われるARM系のCPUにターゲットを絞って検討を開始し、最初はATMEL社のCPUを暫く使ってみてその後、周辺機能が充実したstm32シリーズを使い始めて今に至っています。

JDEにSTM32CubeMXが生成したプロジェクトのインポート機能追加

STM32CubeMXが出てくるまではJDEをプロジェクト管理ツール＋OopenOCD仕様の書き込みアダプタを使った書き込みツールとして便利に使ってきました。
それだけならば特にJDEにこだわる必要もありませんでしたが、STM32CubeMXが生成したプロジェクトをインポートする機能を追加出来たことで自分が好きなように改造できるツールJDEを使っていて良かったと、改めて思っているところです。