hira のすべての投稿

R8CでLCDテスト

I2Cの前にSPI接続を試しておく予定だったのですが、前後してしまった。

で、早速、SPI接続の簡単なテストから始めてみました~

とりあえず、書き込みだけで、動作を確認できそうなので、LCDで実験してみます。
基板付きFSTN液晶モジュール(SPI) [M-G0812P7567]
このLCDモジュールは、128×32ピクセルで、LEDバックライト内臓のタイプです。

IMG_0750
※3.3Vで動作させる為、バックライトLED用の電源は、HT7750Aで昇圧しています。
※先日作ったシリアルモジュールを繋なげるようにして、フラッシュ書き込みのモードスイッチ、
リセットスイッチも設けました。

ビットマップグラフィックスでは、描画の利便性から、どうしても、解像度と同じメモリーが必要
です、R8C/M120AN の場合、RAM が1280バイトしか無いので、128×32だと512バイトの
RAMを消費します、この容量が、限界ギリギリのとこでしょうか・・・
LCDにデータを送ったら、このRAMは他の用途に使えるので、シェアリングする事も出来ると
思いますが、その場合を考えて、システムを設計しておかなければなりません・・

LCDの制御コードは、U8glib を参考にしましたが、ST7567の制御コードは無かったので、
多分近そうなST7565の初期化パターンを参考にしました。
※ST7567のデータシートはネットを探すとあるのですが、いくつかの流動的パラメーター
があり、とりあえず、どのようにするのか目安が必要です。
※Aitendoさんの商品は、安くて、魅力的なのが多いのですが、参考資料が少ないのが難点です。

カットアンドトライで、コードを変えながら、1時間くらいかかって、ようやく画面がまともに
出るとこまで来ました。
※まだ多少不安定な事があり、原因を究明中・・・

SPIでは、SCL、SDA_OUT、SDA_INPの3本が、ベースで、デバイスセレクトや、
アドレスセレクトは、別に考える必要があります、複数のSPIデバイスを繋ぐ場合、ベースの
制御信号は、シェアする為です。

spi_io クラスは、非常にシンプルで、基本、write、read のみです。(まだ write のみの実装)
※R8C/M120AN には、UARTの同期モードがあり、これを使うと良さそうですが、そうすると、
UARTが使えなくなってしまう為、ソフト制御としました。

lcd_io(ST7567の制御)では、LCD制御を含めて、SPIを制御します。

今回のLCDでは4本の制御線が必要です。
SPI(共通部分):
・SDA シリアルデータ
・SCL シリアルクロック

LCD(固有部分):
・A0  アドレスセレクト(コマンドレジスタとデータレジスタの切り替え)
・/CS チップセレクト
※RES信号は、R8Cのリセットに接続しています。

SPI制御ポートの定義

struct spi_base {
    void init() const {
        device::PD4.B2 = 1;
        device::PD4.B5 = 1;
    }
    void scl_out(bool b) const { device::P4.B2 = b; }
    void sda_out(bool b) const { device::P4.B5 = b; }
};

LCD制御ポート(A0、/CS)の定義

struct spi_ctrl {
    void init() const {
        device::PD3.B3 = 1;
        device::PD3.B7 = 1;
    }
    void a0_out(bool b) const { device::P3.B3 = b; }
    void cs_out(bool b) const { device::P3.B7 = b; }
};

IMG_0749s

GitHub R8C

R8C I2C(RTC)のテスト

「R8C M120AN/M110AN」には、I2C専用ハードは無いので、ポートを制御する事で
同等の機能を実現するしかない。

個人的には、I2Cは嫌いだ、ポートの制御が面倒で複雑だし、速度もあまり速くなく、
デバイスによっては、特別なケアが必要な場合もある。
SPIはもっと簡単で高速だ、デバイスを沢山繋げるとポートを消費するけど、少なく
とも、DI、DOは共通化できるので、デバイスセレクトのみで、I2Cのように、
ポートの入出力がこまめに変化したりしない。
2本の制御線でやりとりするなら、より良い方法が他にあると思う、しかしながら、業
界標準的な位置づけになると、規格がはびこってしまい、どれもがI2C通信となる
困った状況だ・・・
ここまで、I2Cが流通してしまうと、規格が悪いとか言ってられなくなるのも事実で、
とりあえず、ソフト制御のI2Cクラスを実装する事とした。

とりあえず、手持ちのI2Cデバイスでテストしてみた、今回はDS1371を選んだ
DS1371は32ビットのバイナリーカウンターを内臓したRTCで、以前に、マキ
シム社にサンプルをもらって評価したデバイスの余りで、RTCの中でも構成としては
使いやすいデバイスである。(32ビットのカウンターが基本で、1.7V~5.5Vで動作)
※但し、購入するとなると、安くは無い事が判る、もっと複雑で扱いが面倒な、秒、分、
時、日、月、年などで構成されたタイプの方が安い。
degikey の場合で、377円
※1個100円くらいだと助かるのだが・・(R8Cより高いので違和感があるのか)
以前にもRXにこのデバイスを接続した時のブログで紹介したが、時間管理のデバイス
では、バイナリーカウンターがあればそれで十分で、他の構成は、使いにくいだけで、
最悪だと思う。
結局、まっとうな時間管理が必要な場合は、秒単位にシリアライズしなければならない。
※ハードを設計する人が、ソフトの都合をまるで判っていない例の一つだと思う。

さて、I2C専用ハードの場合と違って、プロトコルを細部まで理解する必要がある。
※ここで、大きなミスは、ネットにある情報が、自分の知りたい部分以外が多くて、
重要な部分を理解しないまま、「多分こうだろう」的な感じで、実装してしまい、
それが悪くて、中々通信が出来なかった事。
最終的には、DS1371の英文マニュアルの一部を読んでいて気がついた・・・
スレーブからのリード時のACKの振る舞いが判ってなかった・・・

IMG_0747

I2C関係の構成としては、以下のようになっている。

common/i2c_io.hpp  --->  I2C基本制御クラス
common/ds1371_io.hpp  --->  DS1371制御クラス
I2C_test/main.cpp  --->  SCL、SDA、ポート定義クラス

ポートの定義

// DS1371 I2C ポートの定義クラス
// P1_B7: SCL
// P4_B5: SDA
struct scl_sda {
    void init() const {  // オープン・ドレイン設定
        device::POD1.B7 = 1;
        device::POD4.B5 = 1;
    }
    void scl_dir(bool b) const { device::PD1.B7 = b; }  // SCL 方向 (0:in, 1:out)
    void scl_out(bool b) const { device::P1.B7 = b; }   // SCL 出力
    bool scl_inp() const { return device::P1.B7(); }    // SCL 入力
    void sda_dir(bool b) const { device::PD4.B5 = b; }  // SDA 方向 (0:in, 1:out)
    void sda_out(bool b) const { device::P4.B5 = b; }   // SDA 出力
    bool sda_inp() const { return device::P4.B5(); }    // SDA 入力
};

このクラス定義は、少し冗長だけど、I2CのSCL、SDAをどのポートに対応さ
せるかを実装する。
※詳細なテストはしていないが、オープンドレインポートじゃなくても動作すると思う。

デバイスの制御
「ds1371_io.hpp」はテンプレートクラスで上のポート定義を渡す。
内部的には、ポート定義は、i2c_io クラスにそのまま渡している。
デバイスの制御では
・初期化 ---> DS1371 の制御レジスターを設定する。
・リード ---> 32ビットカウンターの読み出し(time_t で受け渡しをする)
※RTC特有の部分として、確率的に読み出すタイミングでカウントアップが行われた際、
全てのカウンタ値が確定する前に不正な値を読み出してしまう場合があり、複数回読み出
して比較する事でこれを回避している。
・ライト ---> 32ビットカウンターへ書き込み(time_t で受け渡しをする)
※他のデバイスを制御するなら、このソースを参考にすれば、少しの手間で、色々なI2C
デバイスに対応できると思う。

I2C制御
基本的に、初期化と、読み出し、書き込みなどの関数しか無い。
また、7ビットのデバイスアドレスしか対応していないが、10ビットのアドレスを使って
いるデバイスは少ないようなので問題無いだろう。
一応、100KBPS、400KBPS を切り替えられるようにしてあるが、ソフトウェアーループによる
クロック生成なので、あまり正確ではなく、実際より10%以上遅いと思われる。

I2Cの仕様として、スレーブデバイスが、内部動作の影響で、応答出来ない場合に、SCL
を強制的に「0」にする事で、動作を遅延させる事が出来る。
初期設定では、その「待ち時間」の最大を「200」マイクロ秒としているが、

//-----------------------------------------------------------------//
/*!
    @brief  スレーブデバイスの「待ち」時間の最大値を設定
    @param[in]	busy	待ち時間(単位マイクロ秒)
*/
//-----------------------------------------------------------------//
void set_busy(uint16_t busy) { busy_ = busy; } 

関数で、大きな待ち時間を設定できるようにしてある。
この待ち時間を越えてSCLが引き伸ばされると、各関数はストールして、falseを返す。

------
libc の時間関数はかなり巨大な為、必要最小限な実装をした関数群を用意した。
・うるう年の補正、曜日の計算など含まれている。
・time_t から tm 構造体、双方向(シリアライズ、デシリアライズ)で変換可能
・タイムゾーンは+9時間(東京)にしてあり、ハードコーディングしてある。
・time_t はグリニッチ標準時間で管理している。

common/time.h
common/time.c

GitHub R8C

R8Cライターモジュール作成

R8Cの書き込みプログラム完成を受けて、とりあえず、まともなライターを製作してみた。
今回はライターモジュール側の製作です。

売られている比較的安価なR8C用ライターは、USBシリアルモジュールが乗っている。
しかし、シリアルモジュールは単独で動作させる事も多いので、別にしたいと思う。
これは、前回のブログの通りです。

一応、ライターモジュールを KiCAD で回路を引いてみた。
6Pのスイッチを設けて、「WRITER」モードと、「RUN」モードを切り替えている。
TXD 信号の扱いが、WRITE/RUN で代わるので、その切り替えも兼ねている。
「RUN」モード時、シリアルの入出力だけが、具体的に繋がる機能だけなので、LEDや、A/D
用のボリューム、スイッチなど取り付けるつもりだが、今回は、ケースの加工が面倒なので
今後の課題とする。
今回、TEXTOOL のICソケットを使って、ライターらしく仕上げてみた。

R8C_Writer
※KiCAD の関係ファイルは、GitHub にプッシュしてある。

IMG_0742

RXD、TXD は、どちら側から見ているのかで、逆の意味となる、今回は、シリアルモジュール側から見た、
端子名をそのまま使っているので、方向に十分注意してほしい。

FTDI:RXD <--- R8C:TXD
FTDI:TXD ---> R8C:RXD

又、TXD 端子は、ライターモードでは、P1_6 に接続している、これは、R8Cの書き込みモードではそ
のようになっているもので、何故そうなのかは不明。

IMG_0744

-----
FTDI 社の FT231X だけど、Windows7 ではデバイスドライバーのインストールが必要だったが、OS-X で
は、そのまま認識して、直ぐに使えた、ちょっとビックリ・・

FTDI 社のデバイスは、中国製のコピーデバイスが安価で出回っており、それを掴むと、純正ドライバー
では、コピーチップと認識して、弾くらしいので注意が必要。

R8Cフラッシュプログラムとりあえずベータ完成

まだ、機能的に欠けている部分もあるし、あまりにヒドイ実装の部分もあり、
手直しをしたいのだがーとりあえず、書き込み、読み出し、消去など、一通り
の機能は揃っているので、この辺で、ライタープログラムは、止めて、
R8C本体のプログラムなどを充実したい感じです〜
※ヒドイ実装とは、設定ファイルのパースとか、機能が分離出来ていない
モトローラーファイルフォーマットの入出力など。

※その為、バージョンは「0.72b」としている。

Renesas R8C Series Programmer Version 0.72b
Copyright (C) 2015, Hiramatsu Kunihito (hira@rvf-rc45.net)
usage:
r8c_prog[options] [mot file] ...

Options :
-d, --device=DEVICE		Specify device name
-e, --erase			Perform a device erase to a minimum
    --erase-all, --erase-chip	Perform rom and data flash erase
    --erase-rom			Perform rom flash erase
    --erase-data		Perform data flash erase
-i, --id=xx:xx:xx:xx:xx:xx:xx	Specify protect ID
-P, --port=PORT			Specify serial port
-a, --area=ORG,END		Specify read area
-r, --read			Perform data read
-s, --speed=SPEED		Specify serial speed
-v, --verify			Perform data verify
    --device-list		Display device list
-V, --verbose			Verbose output
-w, --write			Perform data write
    --progress			display Progress output
-h, --help			Display this

MacBook Pro でシリアル接続して、R8Cの書き込みや、消去、を色々試したけど、
とりあえず、何の問題も無い、十分に使えると思う。
自分としては、俺俺フレームワークでGUI版も作りたいけど、それはまた、後で
考えるとして・・

ソースコード一式は、GitHubにプッシュ済み、一応 MSYS2 でコンパイルと簡単な動作は
確認済みなので、Windows でも使えると思う、MSYS2 の clang では、シリアル制御関係の
ヘッダーが無い為、コンパイル出来ない、Makefile 内で、MSYS2 環境では gcc を使うよ
うにしてある。

ifeq ($(OS),Windows_NT)

R8C関係 GitHub

さて、R8Cは、メモリーが64K使える事が判ると、SDカードの操作も楽に出来そうだし、
色々と夢が膨らむ〜

R8C本体に行く前に、先週、買ってきたもので、ちゃんとしたライターを作っておこうと思う。
以前の書き込みハードはあまりにショボイ・・
色々考えた末、USBシリアル部分と、R8Cのライター部分を分離した構造にした。
USBシリアルは、色々な場合に使う事が多いので、分離しておけば、便利に利用できるだろう。

まず、USBシリアル変換、モジュールが比較的安く売られているので、それを使っても良いが、
小さいケースに収めて、綺麗に作りたかったので、部品をバラで買ってきた、デバイスは
FTDI の FT231XS、単品だと安くて210円だった。
SSOP20 ピンのハンダ付けが、少しだけ厳しい・・
それと、マイクロUSBコネクター、調べると、ミニUSBコネクターより、マイクロUSB
コネクターの方が、抜き差しの耐用が高いらしい。
また、スマホがマイクロUSBコネクターを採用している事が多く、ケーブルも調達がしやすい。
RTS、CTS、DTR、DSR など制御線を出しておきたいので10ピンのコネクターを出す。
それと、5V、3.3Vを切り替え出来るようにしておく。
3.3Vは、ICにレギュレーターが内蔵されているけど、取り出せる電流が少ないので、別途
三端子レギュレーターを載せる。

ケースは、「タカチ」の「TW4-2-6」を使った。

以前から、採用している構造で、非常に具合が良いのだが、L型の10ピンコネクターを横に出す
構造にして、反対側は、マイクロUSBコネクターの先端で受けるようにする事で、基板を抑える
事が出来、シンプルに収まる。

IMG_0733
IMG_0734
IMG_0735

一応KiCADで回路を引いた、この関係ファイルもGitHubにプッシュしてある。
SerialModule

IMG_0740
IMG_0741
IMG_0739

さて、これでシリアルモジュールが出来たー、次は本命のR8Cライターなんだけど、これは次回にでも~

R8C に新たなフラッシュ領域見つかる〜

100円で買えるマイコンとして、売られているR8Cですが、データシート上は、

RAM256バイト
フラッシュ2Kバイトです

ところが、実際は・・

RAM1366バイト
フラッシュ32Kバイト

まで使えると判り、小躍りしていました~

OS-Xでも、R8Cの開発環境を整える目的で、フラッシュ書き込みプログラムを開発していましたが、
その過程で、R8Cのフラッシュ領域には、まだ拡張された領域があるのでは無いかと思い、良く調べてみました。

すると・・・

0x10000~0x17FFFに、さらに32Kバイトの領域があり、実際に使える事が判明しました。

つまり、フラッシュ2キロバイトとは、見せ掛けの容量で、実際には64キロバイトの領域があります。
※市場では、容量が多く(最大16KB)値段が高いデバイスが存在しますが、基本的に中身は全て同一
なのでしょう・・

考えるに、「ATtiny2313」など100円マイコンと同じレンジのマイコンがラインナップに無いので、
それに相当するデバイスを揃える為に既存のデバイスを再利用したのだと思います、その時、本当の
RAM、ROM容量では、他のラインナップと競合してしまうので、苦肉の索として、100円に釣り
合うと思われる小さい容量で売り出したのでしょう・・

現在のところ、最強の100円マイコンだと思います(笑)

さて、領域がある事が判ったのですが、R8Cのポインターは16ビットなので、基本的には64KB以上の
領域にアクセスするには、工夫が必要です、R8Cは20ビットのアドレス空間までアクセス出来る仕組みが
あるので、アセンブラなら、下駄を履かせてアクセスする方法がありますが、 gcc ではどうでしょうか?
調べてみると、64KB以上のアドレスの関数をコールする為の仕組みがあり、それを使う事で、拡張領域を
使う事が割と簡単に出来るようです。

まず、リンカースクリプトに拡張領域を追加します。

MEMORY {
    RAM (w)  : ORIGIN = 0x00300, LENGTH = 0x00400
    ROM (r)  : ORIGIN = 0x08000, LENGTH = 0x07FD8
    EXT (r)  : ORIGIN = 0x10000, LENGTH = 0x08000
    VVEC (r) : ORIGIN = 0x0FED8, LENGTH = 256
    FVEC (r) : ORIGIN = 0x0FFD8, LENGTH = 40
}

次に、セクション領域を宣言しておきます。

  .exttext   :
  {
    *(.exttext .stub .exttext.* .gnu.linkonce.t.*)
    KEEP (*(.exttext.*personality*))
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
    *(.interp .hash .dynsym .dynstr .gnu.version*)
  } > EXT =0

これで、ソースコードで拡張領域のセクション指定すれば、通常領域から押し出す事ができます。
※ADC_testで main 関数を押し出してみました。

__attribute__ ((section (".exttext")))
int main(int argc, char *argv[])

コンパイル、リンクも普通に通り、出来上がったバイナリーをデバイスに書き込んでみましたが、普通に動きます。

Motolola Sx format load map:
  0x008000 to 0x009225 (4646 bytes)
  0x00FF00 to 0x012DB6 (11959 bytes)
  Total (16605 bytes)

R8C フラッシュプログラム

OS-X 用に R8C 用 gcc もビルド出来た事だし、フラュシュライターを実装する事にした。
これが出来れば、MacBook などで R8C の開発が全て完結する〜

R8C/M120AN、R8C/M110AN の場合、mode 端子を Low にしてリセットをかけると、ブートモードになり
シリアル通信で、コマンドとデータを送る事で、内部フラッシュメモリーをプログラミング出来る。

尚、ライターは簡単に自作出来るが、出来合いもあり、これがお勧めかも・・
R8C/M12A ライタ&LEDキット【MR8C-TRM】

通信プロトコルは、以下のリンクから資料を取得した。
R8C/1x、2xシリーズ 標準シリアル入出力モードプロトコル仕様書
R8C/Mxシリーズ、LAxAグループ 標準シリアル入出力モードプロトコル仕様書

最初のハードルは、OS−Xって、どうやって「シリアル通信」すんの?
だった、でも、ちょっと調べたら、どうやらPOSIX準拠のシリアル通信APIをサポートしており、要はLinuxと同じ
コードで、大丈夫のようだったー、これは、MinGWでもサポートしているようなので、簡単にマルチプラットホーム
に出来るおまけ付きだ!
※ただ、デバイスファイル名は、OS依存なのだと思う。

とりあえず、FTDIのシリアルUSBブリッジを接続したら、/dev/tty*にそれらしいデバイスが認識される。

crw-rw-rw-  1 root  wheel   18,   6  5  7 21:18 /dev/tty.usbserial-A600e0xq

これを使って、簡単な通信を行いテストすると、普通に動作する〜
「rs232c_io.hpp」に必要な機能を盛り込んだ〜

それではと、色々ガリガリプログラムを作成して、とりあえず、出来上がった〜
まだ機能追加中で、中途半端な状態ではあるけれども、一応動作しているようだ。
GitHubで公開している。

仕様的には、千秋ゼミで公開されているr8cprogを元にしている。
※このプログラムをダウンロードするには、登録が必要。

ただ、C++ でスクラッチから組んだものなので、動作は、オリジナルとは違うので注意。
俺俺フレームワークとして、「file_io、string_utils、sjis2_utf16」など同梱している。

r8c_prog -d R5F2M120 -s 57600 -e -w -v uart_test.mot

現在は、デバイス名は無視されています。
ポートは、何も指定しないと、上記のデバイスパスが使われるようにしてあります。
また、コンパイルには boost が必要です。

Windows 環境では、テストされていません。
Msys2環境でコンパイル、実行を試しました。
※select の挙動が、OS−Xと違っていて、少し悩みましたが、とりあえず、問題無く動作するようになりました。

R8Cコンパレーターのテスト

R8Cの機能を一通り実装、テストしている。

今回は、コンパレータークラス。

テストプログラムでは、ICOMP3、IVREF3 を電圧比較をして、その結果、LEDの点滅速度が変わると言うもの。
※実験では、REF側に、VCCを1/2に分圧し、COMP側にボリュームを接続、確認した。

R8Cには2チャネルのコンパレーターがある、機能的には、単純な物だが、割り込みを使った時に、実行する
処理をどのような構成にするか、考えてみた。
以前にタイマークラスを実装した時に、タイマー割り込みから、何らかの処理を実行できるように、

void (*task_)(void);

実行ポインターを用意した、ところが、こんな事をすると、コンパイラは、「task_」で何が実行されるか不明
な為、メイン側で利用しているライブラリーのワークを全てスタックに積むようコードを生成する。
※タスク内で、メイン側と同じライブラリーを使った場合に備える為で、強引な方法だが、動作は正しい。
しかし、これでは、スタックが直ぐに限界を超え深くなるのは容易に想像出来る、その為、「実行ポインター」
でのタスク管理は不採用とした。

そこで、コンパイル時に静的な関数が実行できるような仕組みを追加した。
関数オブジェクトを使い。

class task {
    public:
    void operator() () {

    .....

    }
};

()オペレーター内に、実行したい手続きを実装して、それをテンプレートの引数とする。
関数オブジェクト内の手続きが何も無い場合、コンパイラは、その部分一切を削除する。

template <class TASK1, class TASK2>
class comp_io {

    static TASK1 task1_;
    static TASK2 task2_;

    public:
        static INTERRUPT_FUNC void itask1() {
            task1_();
            WCB1INTR.WCB1F = 0;
    }

    .....

};

これなら、コンパイラが、テンプレートクラスを展開する時に、割り込み内手続きを考慮するので、ライブラリー
で使われる変数の退避も最小限となる。

COMP_test ソースコード

-----
そして、R8CのI/O定義は、ほぼ全てを網羅した。

立川から茂木に行くルート

依然から良く茂木に行きますが、「有料道路を一切使わない」とか、色々「縛り」を設けて、
冗長な車の運転に少しでも面白みを見出してますwww

その過程で見つけた色々な事を記しておきます。

まず、一般的な標準ルートは・・

立川
大泉インター
外観
三郷
常磐道
水戸北スマート
茂木北ゲート、又は南ゲート

良い点:
・空いていれば時間が意外とかからない(2.5時間~3時間弱)
問題点:
・距離が長い
・帰りは、三郷の手前とかで渋滞する
・高速料金
・大泉から立川間の一般道(新青梅街道の流れの悪さ)
・レストラン倉井に寄れない

全て下道で行くと、どうなるか?
過去に、色々なルートを試してみました。
そこで、淘汰され残ったルートで、最も合理的で最短時間なのが以下のルートです。

立川
川越(国道16号)川越市内を適当に・・
県道12号
県道370号
県道151号
県道370号
県道346号
県道60号
県道46号
国道354号(川越市内からここまで、ほぼ道なりです)
県道9号
県道11号
国道50号
新4号バイパス
県道47号(真岡市内へ)
国道408号バイパス
国道121号
県道163方面へ(ファミマがある交差点を道なり)
星の宮交差点
北中交差点
大沢橋東交差点
木幡交差点
国道123号
県道51号
茂木南ゲート

※川越から国道354号までも多少複雑なようですが、ほぼ道なりです。
※国道121号から、茂木までは、複雑のようですが、ほぼ道なりで(「はがグリーンコリドール」と呼ばれる広域農道です)
良い点:
・高速料金0
・休憩ポイント、コンビニなど多く、ゆったりまったり行ける
・ほぼ直線なので、距離が短く、ガソリンも少なくて済む
問題点:
・それなりに時間がかかる(深夜帯で3.5時間~4時間弱)
・祭日の昼間など多少混む場所がある。(裏道で逃げ切る)

そこで、圏央道を有効に使い、少しだけ短縮すると・・

立川
国道16号
圏央道入間インター
桶川北本インター
県道12号(後同じ)

これだと、3時間弱~3時間強
標準ルートとあまり変らない!
高速料金1230円!

圏央道が繋がり(今年中に繋がるらしい)、4号バイパスまで延びれば、さらなる短縮になります~

-----
下道でお勧めポイント
レストラン倉井:
※ここは、上のルートから少し離れていますが、帰りには是非寄りたいスポットです。
※夜9時がラストオーダーなので、9時までに店に入ればセーフです。
※水曜定休
・安い!
・ホルモン定食がクセになる!
※注意:
調子にのって、ニンニクのゴマ油漬けを沢山入れると、次の日に響くかもwww
食べた夜は、ニオイが厳しく、奥さん、子供の不評を買う場合もあるようです・・
(リア充の人は、彼女と一緒に食べれば問題無し)
※倉井から国道50号に出るのは、農道を通るのがお勧め、信号無く、渋滞一切無し!
※4号線を通るのは最悪で、昼間は凄く渋滞します。

R8C PWM出力(タイマーC)

R8C関係のリソースもかなり色々揃って来ました。

組み込みマイコンでは、外せないPWM機能の実装です。

一般的に、組み込みマイコンのハードウェアータイマーの機能は、多機能で、複雑です。
R8C/M120の、タイマーCでも、PWMは二通りのモードがあり、その他に、インプットキャプチャなど
色々な機能があります。

今回は、3チャネルの出力が可能な、PWMモードの実装を行いました。
※今後必要になったら、PWMモード2や、インプットキャプチャーなど、他の設定も組み込む予定です。

PWMの場合、デューティ可変範囲を切りのよい2のn乗にしたい場合と、あくまでも周波数(周期)で設定
したい場合がありますので、引数の違う2つの設定を用意してあります。

今回、必要無かったので、割り込みを使っていません。

このタイマーCのPWM出力は、設定値とカウンターの一致を利用しているので、設定値を書き換えるタイミングに注意
する必要がありますが、現状の実装では考慮されていません。

    // PWMモード設定
    {
        PML1.P12SEL = pml1_t::P12TYPE::TRCIOB;
        PML1.P13SEL = pml1_t::P13TYPE::TRCIOC;
        PML1.P10SEL = pml1_t::P10TYPE::TRCIOD;
        bool pfl = 0;  // 0->1
        timer_c_.start_pwm(10000, pfl);
        uint16_t n = timer_c_.get_pwm_limit();
        timer_c_.set_pwm_b(n >> 2);  // 25%
        timer_c_.set_pwm_c(n - (n >> 2));  // 75%
    }

↑の例では、PWM周波数を10KHzとしています。
B出力には25%、C出力には75%のデューティで出力します。

    if(adc_.get_state()) {
        uint32_t v = adc_.get_value(1);
        v *= timer_c_.get_pwm_limit();
        timer_c_.set_pwm_d(v >> 10);
	adc_.start();
    }

又、C出力にはLEDが接続してあるので、AN1入力にボリュームを繋げて、0~100%まで
デューティを変化させられますのでLEDの明るさが変化します。

-----
I/Oポートの定義を見直し、ポートのマッピングに「固有の型」を導入しています。
その為、設定が判りやすく、誤設定も減ると思います。

        PML1.P12SEL = pml1_t::P12TYPE::TRCIOB;
        PML1.P13SEL = pml1_t::P13TYPE::TRCIOC;
        PML1.P10SEL = pml1_t::P10TYPE::TRCIOD;

※この型には「enum class」を使っている為、C++11対応コンパイラでコンパイルする必要があります。
現在 gcc-4.7.4 なので、「-std=c++0x」オプションを使っています。

PWM_test

GitHubにソースをプッシュしました。

R8Cデータフラッシュの操作

さて、今回はデータフラッシュメモリーを扱います。

R8Cには、プログラムフラッシュとは別に、データの記録用の小規模なフラッシュメモリーが別にあります。

3000番地から始まり、容量2048バイトです。
※1024バイト毎にバンク0、バンク1と分かれています。
フラッシュメモリーは、「1」のビットを「0」にする事は出来ますが、「0」のビットを「1」にする場合は、バンク毎に
イレースコマンドを発行して、全て「1」の状態に戻します。

この辺りのマネージメントが、多少難しいのですが、電源を切っても、記録を残す事が出来るので、非常に有益なメモリーと言えます。

テストプログラムでは、バイト単位での読み出し、書き込み、イレースなどが対話形式で行えるようにしてあります。
※シリアルポートにターミナルを接続します。

Start R8C FLASH monitor
# ?
erase bank[01]
r xxxx
write xxxx yy
# r 3
FF
# write 3 56
# r 3
56

操作説明:
? ---> 簡単な説明
r xxx ---> xxx のデータをリード
write xxx yy ---> xxx へ yy を書き込み
erase bank0 ---> バンク0を消去(0x3000 to 0x33ff)
erase bank1 ---> バンク1を消去(0x3400 to 0x37ff)

※xxx アドレスは、0 から 7ff までの領域です
※値は全て16進数で行います

本来は、プログラム領域の操作関数も含めたいところですが、それは、また次の機会(必要になったら)とします。

-----
R8Cへのプログラム書き込みには、ルネサスのFDTを使っていましたが、コマンドラインから気軽にプログラム出来れば便利です。
又、FDTは Windows 環境にしか対応しておらず、Linuxや、OS-X での開発には不向きでしたが、先日、AVR関係でお世話になっている
YCITのsenshuさん
の掲示板で、コマンドラインで使える、R8C 用プログラムコマンドが公開されました。
元々は、ゆきさん開発の r8cprog を元にしていて、M120AN 32K Flash に対応した
ものですが、使いやすいように、その他の小規模な改造も行っており、安定性も増しています。
私は、コマンドラインから使えるのが便利ですが、GUI 版も用意されており、シンプルで良く精査されたシンプルな設計により、予備知識が無く
ても直ぐに使えるようになっています。
Linux にも対応している事から、OS-X にも対応可能と思います、こちらは、時間が出来たら挑戦してみるつもりです。