So-net無料ブログ作成
検索選択

メモ [SH]

SH マイコン使い始めて一週間程度が経過した。基本デバイスコントロールだけを試行錯誤している状態だけれど、なんとなく使い方に慣れてきた感じ。ちょっとこのあたりで、デバイスを弄るためのメモを残しておこうと思う。まだ、それほど長い時間弄っているわけではないので勘違いも多いかもしれない。

  • スタンバイ
    SH マイコンに内蔵されている多くのデバイスは、電源が供給された時点でスタンバイ状態になっている。デフォルトで使えるのは ROM、RAM と DTC/DMAC くらい。あとはデバッガ関連の機能が有効になっているようだけど、当分使うこともないので放っていく。
    スタンバイ状態になっているデバイスを使いたいときはスタンバイ解除してやらないとならないのだけど、チャネルごとに解除するものと、デバイス単位で解除するものがあるようだ。
  • 割り込みレベル
    システム全体の割り込み受付可能レベルが用意されている。デフォルトで 15 ということになっているんだけど、このままだと NMI しか受け付けられない。基本 0 にしてしまえばいいのじゃないかと思っているのだけど、そうじゃない方がいいのかもしれない。この件についてはもう少し考察してみる。
  • 割り込み優先順位
    デバイス毎に割り込みの優先順位が決められている。デフォルトで優先順位が 0 になっているので割り振ってやらないと割り込みハンドラが一切起動されない。
  • 割り込みハンドラー
    デフォルトの割り込みハンドラは何もしないようになっている。自分で作ったメソッドを登録してやらないとウンスンになっちゃうので注意。
  • ステータス
    割り込みハンドラの中では、割り込み要因となるデバイスのステータスを読み上げ、更に書き戻してやらないと次からの割り込みが受けられなくなる。
  • マクロ
    SH マイコンの I/O ポートの定義が非常に使いづらい。始めた当初は関数でも作ってみようと思ったんだけど、関数よりはマクロ (#define) のほうが使いやすいかもしれない。

今のところ提供されているランタイムを使用しているけれど、いずれフルスクラッチに書き換えたいと思っている。そしたら、プログラミングに関する要件ももう少し見えてくるかもしれない。少なくとも、早いところ malloc/free あたりは書き換えてしまいたいと思ってる。

 


タイマー [SH]

Windowsタイマーを使いたいときにいつも悩むのがその精度。何をやっても殆ど無駄なあがきになるので、最近はもう諦めの境地。いいところ秒単位くらいなら何とか使えるかなぁという程度にしか期待しないようになってきている。

ハードウェアを繋いで制御するような場合、直接割り込みを受ける様なものが多いので、タイマー使って一定周期でポートをスキャンするような事はあまりないのだけれど、LED を点滅させておくなどして、ハートビートを制御するような用途がたまにある。

最近のマイコンと呼ばれるチップには、タイマーの機能を提供しているものが多い。そして、その機能もチャネル数も結構豪華仕様だったりする。中には説明を読んでも何に使うのか理解できないものも結構多い。

タイマーの機能でオーソドックスなものは、定周期タイマー。一定時間ごとに割り込みを発生させて、それに同期させてプログラムを操作するもの。SH マイコンでは コンペアマッチ という名称になっている。

取り合えず、1 秒周期で LED を点滅させるだけのものを作ってみようと思ったんだけど、、、ハマッタ!!予想に反して 1 日がかりになっちゃった。

手元にある SH-2 が載ったマイコンボードは 12.5MHz のクロックで動作している。システムクロックはこれを 4 倍に、ペリフェラルクロックは 2 倍にしたもので動作するモード 3 という設定がデフォルト。なのでタイマーに使用されるクロックは 25MHz という事になる。

SH のコンペアマッチカウンタはこのクロックのパルスをカウントし、それが設定した値と一致したら割り込みを発生させるというもの。今回は 1 秒周期で LED を点滅させたかったので、500ms 毎に割り込みが受けられれば、点灯時間が 500ms、消灯時間が 500ms という感じでよいと思ったのだけど、残念ながらそこまで単純じゃなかった。

コンペアマッチで使用出来るカウンタは 16bit しか使えないので、範囲が 1 ~ 65535 の値しか設定できない。さらに、プリスケーラの設定が 1/8、1/32、1/128、1/512 の何れかを選ばなければならないので直接 500ms のタイマーを間隔を設定しようとするとどうしても誤差が出ちゃう。まあ、お遊びで作っているだけなので、精度を追及しても仕方がないとは思うのだけど、気になったら放っておけないたちなので、、、。

結局 1/8 のプリスケーラを使い、10ms 毎のタイマー割り込みを発生することにして、プログラムで 1/50 に分周して 500ms を作り出した。

今回のタイマーは左記に挙げたハートビートの代用品。まともなデバッガーが使えないので、裏でこれを走らせておいて、メインのプログラムがおかしなことになったら LED の点滅が止まることを期待している。今のところ、殆ど割り込み処理だけを記述しているので、結構に役に立っている。とは言っても、原因を突き止める役には立たないけどねぇ。

 


送信完了 [SH]

かなりの手抜きではあるけど RS-232C を使ってデータを送ることはできた。対向するのは Windows PC で動作させた Tera Term。一応、115,200bps の設定で動作させて問題ないようだけど、本当にそこまでのスループットが出ているかは図っていない。送信側が多少もたついても通信できてしまうのが調歩同期の数少ないメリットのひとつだから。

SH マイコンでは SCI (Serial Communication Interface) と DMA (Direct Memory Access) を同期させることができるので、データサイズさえ分かっていれば殆ど設定を行うだけで通信できてしまう。なので、データ送信だけを行うようなプログラムは全体で 150 行程度。そのうち 120 行くらいが define 文だったりする。

 Renesas の方針(オリジナルは日立かな?) なのか解らないけれど、ポートの定義が共用体とビットフィールドのオンパレードになっている。(そのうち合わせることになるかもしれないけれど)勉強がてらデータシートからポート定義を起こしてみた。まだ、すべてが出来上がった訳ではないのだけれど、今回のプログラムが動く程度のものが、上の 120 行ということ。

今のところ、一応は使える様になったかなと思えるのは以下の機能。

  • SCI の送信機能
  • DMA と SCI の連携
  • 割り込みハンドラの定義 (DMA の割り込みを受けている)
  • ポートの操作

次は SCI の受信動作に挑戦。受信に DMA を使うのは難しそうなので SCI の受信割り込みを直接操作することになると思うのだけど、送信と違って取りこぼしが起きないかちょっと心配。

ちなみに、115,200bps というのは多くの PC に乗っている (RS-232C 用の) シリアルコントローラーの制限。USB - Serial Converter を使うともう少し上が狙えるかもしれないのだけど、今回はまだ試していない。

 


Hello, World. [SH]

マイコンボードを入手して、先日からチョコチョコと弄ってる。仕事が終わってから夜中に弄るだけなんで今一つ進捗が思わしく無いのだけど、それでも全てが揃った環境でモノを作るのとはチョット違った楽しみがある。さらに言えば、仕様も設計も超いい加減な状態で、純粋にプログラミングだけを楽しんでいる。

ちなみに、今回入手したマイコンボードはコレ。 半田付け済みって所と金額で採用決定。PC と繋げて遊ぶには、別売の電源と RS-232C のストレートケーブルが必要になる。USB - Serial Converter が付いてくるのでPC に RS-232C のポートがなくても使えそうと思ったのだけど、コネクタについてるネジが邪魔してこのままじゃ上手く刺さらない。ネジを外してしまうか、間にストレートケーブルをかますかの何れかを選ぶ必要がある。

開発環境は High-performance Embebbed Workshop なる Renesas 謹製のモノ(評価版)が付いてくる。ランタイムも提供されているので、ハードルは若干低めにはなるけど、「全部自分で作ってみよう」と思ってただけにチョット拍子抜け。多少慣れたら再度チャレンジしてみようかと思う。

慣れない環境で初めて書くプログラムって言ったらやっぱり Hello, World. かな?とは言っても、このボードにはモニタなんか繋がっていないし、すぐに使える I/O と言えば 2 つの LED と 1 つのスイッチだけ。付属していたサンプルプログラムに LED をチカチカと点滅させるものが付いていたので、別のものを作ってみたいし。

ということで、マイコンボードと PC を (RS-232C で) 繋いで、Hello, World. のメッセージを流し続けるのを最初の課題にしようと思う。

むかーしむかしのマイコンボードのようなものでシリアル通信を試したことがある。そこで使用していたのはクロックがおよそ 4MHz の 8bit マイコン。UART 以外の特別なハードウェアなしに 9,600 bps の通信が達成できていた。今回のマイコンボードはクロックが 10 倍以上になった 32 bit CPU の上に DMA が標準で使える様になっている。当然、当時の転送速度を凌駕するようなものにできるはず!! なので、取り敢えずはハードウェアの確認も兼ねて 115,200bps (12倍) 程度を目標に進めていこうと思う。

 


マイコン [SH]

最近、ちょっとマイコンのプログラミングにハマってる。仕事で(かなりの部分で趣味も被っているんだけど)やってるプログラミングは、OS やフレームワーク、ライブラリ等が出来上がっていて、自分でやらなければいけないのはアプリケーションの仕様に合わせた外見の作り方に特化してしまったようなものが多いのに対して、マイコンのプログラミングは全てを自分で作り上げないと何もできないという違いがある。

マイコンという単語は(殆ど死語?) Micro Computer の略で、そのまま訳したら超小型のコンピュータ(計算機)ということになる。マイコンが出始めた頃のものと現行のマイコンを比べたら、殆どスーパーコンピューターじゃないかと思うほど進化しているのだけれど、それでもデータシート(ハードウェアの仕様や特性とかが記述されているマニュアル)とにらめっこしながらプログラミングするといったスタイルは以前と変わっていない。

Windows や .NET Famework に依存するプログラミングとマイコンのプログラミング、殆ど別のことを指しているのじゃないかと思えるほど中身が違う。

  • パフォーマンス
    先ず、CPU (Central Prosessing Unit) の性能が違う。現行の PC に採用されている CPU は 3GHz 前後のクロックで動作していて、さらには複数のコアが存在していたりすることが多い。更には普段は使いきれないほどのメモリを搭載していて、余程間抜けな設計をしていなければメモリが足らないなんてことは起こり得ない。
    対して、マイコンと呼ばれるようなものでは、クロックが 2 桁違う(当然少ない)なんてのは普通にあるし、メモリは数KB程度ということが多い。
  • 開発環境
    PC の開発環境といえば Visual Studio のような IDE (Integrated Devalopment Environment) は普通に使えるし、プログラミング言語も C# や Java のようなオブジェクト指向が取り入れられた言語を使うことが多い。
    マイコンの開発環境は、、、コンパイラとリンカーがあれば御の字かなぁ。デバッガーのようなものが存在しない訳ではないけど、今一つメジャーではない感じ。勘と経験が開発環境というような前時代的な環境が多いかもしれない。プログラミング言語は C 言語がメジャー、C++ が使えない訳ではないけど、それは C 言語を使いやすくしたものとして扱っているようだ。前項に挙げたようにメモリ容量に制限があるために、オブジェクト指向全開のような使い方は破たんしてしまう。そして、いざとなったらインライン アセンブラに手を出さないとならないことがあるのが面白いところ?互換性よりも性能を求める必要がある、、、というよりも、ハードウェアを直接操作する必要があるからといった方が近い。共通のライブラリとして提供されているものにもインライン アセンブラが駆使されているものがあり、自分でアセンブラを使うかかどうかは別にして、コンパイラの出力だけでは制御しきれないものが多々あるということ。
  • ライブラリ
    PC のプログラミングではライブラリの助けを借りないと何もできない。よく例題に出される Hello World だって、ランタイム ルーチンという名のライブラリがなければなにもできないし。逆に言えば、あまり細かいことに拘らなくてもいいようにライブラリ群が提供されている。
    マイコンのライブラリ、、、それって美味しいの?実際問題として、電源投入時に main 関数を呼び出してくれる程度のランタイムは装備されているけれど、それ以外のところは CPU 毎にサポート体制が違っているいる。私が経験したもので割りに多いのは、「とりあえず printf から作ろうか」というもの。そもそも標準出力さえないので、これをどうにかしないといけないというパターンも結構多い。
  • ハードウェア
    前項のライブラリとも絡むのだけれども、PC のアプリケーション プログラミングでハードウェアのことを考える必要は先ずない。ハードウェアの詳細はライブラリに(あるいはフレームワーク)よって完全に隠蔽されてしまっているので手を出そうとしても出せない。どうしても、という場合はデバイス ドライバーを構築する必要があるかもしれないけど、それが必要になるのは極々限られた人たちだろう。
    マイコンのプログラミングではハードウェアのことを考えないと何もできない。同じハードウェアという単語を使ったけれど、その粒度は大きく違う。マイコンのプログラミングでは、割り込みコントローラーや DMA (Direct Memory Access) といった、一般的なアプリケーション プログラマでは何を言っているのか理解できないようなものを制御しないとならない。そういった細かいことを自分でやる楽しさがあるということもできるけど。

データシートを眺めながら、PC とマイコンボードでなにができるか考えているところ。何か成果が出たら公開するかもしれない。


シリアル [SH]

最近の PC には殆ど載っていないものにに RS-232C というシリアルデバイスがある。PS/2 や FDD とともにレガシーデバイスという括りにされ駆逐されてしまったようなデバイス。今では正式名称も ANSI/TIA/EIA-232-F-1997 と変わってしまったようだけど、それこそ誰も知らないような存在。

PC は 5 年も経てば世代も大きく変わってしまうのだけど、PC に繋いで動作をするようなデバイスはそこまで変化が激しくない。そういったデバイスは PC 相手に情報の授受をするために RS-232C を備えていることが多い。PC 側は RS-232C の代わりに USB-Serial コンバータといったものを利用して、相手をすることが多くなってきているように思う。

IBM PC/AT 互換と言われる PC に装備されていた(過去形) RS-232C のインターフェースは D-SUB 9 ピン オス型というもの。本来の RS-232C の規格とは異なるのだけど、今となってはこれがデファクトスタンダード。必要最低限の信号に絞って形状を小さくした設計になっている。

RS-232C はもともと端末とモデムを繋ぐものとして利用されていた。信号の意味も端末側の意味合いから命名されたものが多い。例えば端末から送信するデータは TxD (SD) を使い、端末が受信するデータは RxD (RD) を使う。モデム側から見ると信号の意味合いが逆になってしまうのだけど、これが仕様。なので、RS-232C で端末同士を繋ぐというのは仕様から外れた使い方と言える。実際には(仕様通りの)ストレートケーブルではなく、クロスケーブルというものを繋ぐことで端末同士の接続を可能にしているケースが多いのだけれど、万能なクロスケーブルというのはなかなか難しいようだ。

実際、RS-232C を使った通信というのは、常に受信可能な状態にしておくことが多い。送信するべき情報ができたら、相手の都合など考えずにとりあえず送る。それで問題があるようなら RS-232C 以外の方法にすべき、、、みたいなところがある。

クロスケーブルの種類は結構多様で、これ以上の要求を満たせない場合がある。 

仕事で RS-232C を使う羽目になって、そばにハード屋さんがいてくれればいいのだけど、自分ひとりでいるときに困ることがある。RS-232C のケーブルを一目見て、それがストレートケーブルなのかクロスケーブルなのか、なかなか見分けがつかない。PC 同士を繋いでみて通信ができなければストレートケーブルなんていう解釈も可能かもしれないけど、それじゃ接待が悪くて通信できないのかどうかの判断ができないし、、、。

ケーブルの両端が D-SUB 9 ピンなら、共ににメス型コネクタがついている場合はクロスケーブルの場合が多いようだけれど確実とは言い切れない。1本1本導通を確かめていけばいずれ解答は出ると思うけど、慣れない人がやると結構大変。

以前、ハード屋さんに教えてもらった小ネタ、「D-SUB 9 ピンの、5 本並んでる列の真ん中同士をテスターで繋いで反応があればストレートケーブル」というのが重宝している。

ピン配置を確認してみると解るのだけど、このピンは TxD ということになっている。ストレートケーブルであればお互いの TxD が繋がっている(導通する)だろうし、クロスケーブルであれば TxD と RxD が繋がっているはずというのが根拠らしい。信号名もピン番号の数え方もうろ覚えだとうまく探せないけど「真ん中」なら間違えないと思う。もう一方の列は 4 ピンしかないから真ん中はあり得ないので。

と、ちょっと変わりダネでした。最近、マイコンボードを入手して、Flash にプログラムを書き込むのに RS-232C が必要だと解ってバタバタした時のメモを見ながら書いてみました。