以前に作成した、パルス出力テスト、エンコーダー入力、ＬＣＤ表示を組み合わせて
単独で動作するパルス出力を作成しました。

以前に作ったものを組み合わせるだけなので、簡単です。

ＬＣＤ表示はビットマップ表示なので、適当なフォントを用意しました。
ビットマップ表示は、とても柔軟な表示が行えるのですが、自分で「絵」をデザイン
する必要があります。
そこで、以前にビットマップ表示に適した画像エディターを探しました、フリーで、
非常に使いやすいエディターがありましたので紹介しておきます。
※Windows版です、Mac版は、あまり良いものを探せませんでした。
EDGE
※ソフトは２００９年が最終版ですが、機能は揃っており、不具合も無いようです。

「ドット絵エディタ」は２５６色まで対応ですが、モノクロの絵や、アイコンのよう
なグラフッックにはむしろ最適です。
グリッドを設定する機能もあり、任意サイズのグラフィックを描くのに便利です。

上のように、１つのファイルにまとめて配置して、切り出して使います。

切り出して、ソースコードに埋め込むのに、bmc も作成してあります。
※このソフトは、かなり昔に実装して、少しづつ改変しています。
※コンパイルは大変なので、実行バイナリーを用意してあります。（build/bmc.exe）
※必要な DLL を用意してあります。
※コンパイルの方法は、「MSYS2 で俺俺フレームワーク、アプリをコンパイルする」を参照して下さい。
※Mac版は、brew を入れれば、Windowsと同じようにコンパイルできます。

bmc では、以下のように、切り出す位置とサイズを指定して、テキスト形式に変換
しています。
※bitmap/Makefile

    bmc -offset 0*20,0*32 -size 18,32 -header 8 -text -c_style nmb_0 font32.png font32.h
    bmc -offset 1*20,0*32 -size 18,32 -header 8 -text -c_style nmb_1 font32.png -append font32.h
    bmc -offset 2*20,0*32 -size 18,32 -header 8 -text -c_style nmb_2 font32.png -append font32.h
    bmc -offset 3*20,0*32 -size 18,32 -header 8 -text -c_style nmb_3 font32.png -append font32.h
    bmc -offset 4*20,0*32 -size 18,32 -header 8 -text -c_style nmb_4 font32.png -append font32.h
    bmc -offset 5*20,0*32 -size 18,32 -header 8 -text -c_style nmb_5 font32.png -append font32.h
    bmc -offset 6*20,0*32 -size 18,32 -header 8 -text -c_style nmb_6 font32.png -append font32.h
    bmc -offset 7*20,0*32 -size 18,32 -header 8 -text -c_style nmb_7 font32.png -append font32.h
    bmc -offset 8*20,0*32 -size 18,32 -header 8 -text -c_style nmb_8 font32.png -append font32.h
    bmc -offset 9*20,0*32 -size 18,32 -header 8 -text -c_style nmb_9 font32.png -append font32.h
    bmc -offset 3*20,1*32 -size 19,32 -header 8 -text -c_style txt_hz font32.png -append font32.h
    bmc -offset 2*20+9,1*32 -size 9,32 -header 8 -text -c_style txt_k font32.png -append font32.h

変換された形式は、ビット単位で、状態を表現したシンプルな構造で、common/monograph.hpp、
draw_mobj で描画する事が出来ます。

このソフトでは、色々なオプションを用意してあります。
・BDF 形式のフォントの読み出し。
・ディザリング機能
・GUI で確認する機能
など

BitMap Converter
Copyright (C) 2013/2015, Hiramatsu Kunihito
Version 0.75
usage:
    bmc.exe [options] in-file [out-file]
    -preview,-pre     preview image (OpenGL)
    -header size      output header
    -text             text base output
    -c_style symbol   C style table output
    -offset x,y       offset location
    -size x,y         clipping size
    -bdf              BDF file input
    -append           append file
    -inverse          inverse mono color
    -dither           ditherring
    -verbose          verbose

さて、肝心な、パルス出力ですが、出力する周波数範囲は、かなり広いので、エンコーダーだけ
では可変範囲が広すぎます、そこで単位毎に自動でレンジを切り替えて、増減する量を動的に変
えています。
２０Ｈｚ～９９Ｈｚ　１単位
１００Ｈｚ～９９９Ｈｚ　１０単位
１０００Ｈｚ～９９９９Ｈｚ　１００単位
１００００Ｈｚ～９９９９９Ｈｚ　１０００単位
１００ＫＨｚ～９９９ＫＨｚ　１０ＫＨｚ単位
１０００ＫＨｚ～１００００ＫＨｚ　１００ＫＨｚ単位

PLUSE_OUT_LCD

ロータリーエンコーダーを使った入力装置は、設定範囲が広く、厳密な値と、
広い範囲（レンジ）を網羅できる入力デバイスとして、組み込み機器では重宝
する入力デバイスです。
しかし、その入力を正しくエンコードして、読み取るには、多少の工夫が必要
です。

エンコーダー入力の前に、シンプルなスイッチ入力を考えてみます。
機械式接点では、チャタリングがあるので、それを除去する必要があります。
一つの方法として、サンプリング理論に沿ったデジタルフィルターを使って行
う方法があります。
これは、もっとも一般的な方法です。

サンプリング方式では、周期的に割り込みなどをかけて、入力信号を間欠的に
取り込みます。
サンプリング理論では、周期的に、状態を取り込む事で、ローパスフィルター
を通した信号とほぼ同じような状態となり、チャタリングの高い周波数を除去
したのと同じ効果となります。
サンプリング周期より速い（短い）信号は除去されます。
これにより、サンプリングするだけで、チャタリングを除去できます。

また、チャタリングが発生している期間は、機械的な構造による特性があり、
それにより周期を選ぶ必要があります。
通常、押しボタンスイッチのようなもので、４ｍｓ（ミリ秒）程度ですが、
接点の状態が悪いと、それより長くなったりするので、ある程度マージンを取
る必要があります。
通常のスイッチでは、一般的に、60Hz程度が良く選ばれます。

状態変化による、トリガーの生成：
サンプリングでは、別の要件を網羅できます、それは、「トリガー」入力の判断
です。
サンプリングした状態を１つ保持する事で、信号がどう変化したかを確認できま
す。
・前がＯＦＦ、今回がＯＮなら、「立ち上がりエッジ」（押した瞬間）。
・間がＯＮ、今回がＯＦＦなら、「立ち下がりエッジ」（離した瞬間）。

    uint8_t lvl = ~device::P1();  /// 状態を取得
    inp_pos_ = ~inp_lvl_ &  lvl;  /// 立ち上がりエッジ検出 
    inp_neg_ =  inp_lvl_ & ~lvl;  /// 立ち下がりエッジ検出
    inp_lvl_ = lvl;  ///< 状態を退避

・スイッチの状態表示

    if(inp_pos_ & device::P1.B0.b()) {
        sci_puts("SW0 - positive\n");
    }
    if(inp_pos_ & device::P1.B1.b()) {
        sci_puts("SW1 - positive\n");
    }

    if(inp_neg_ & device::P1.B0.b()) {
        sci_puts("SW0 - negative\n");
    }
    if(inp_neg_ & device::P1.B1.b()) {
        sci_puts("SW1 - negative\n");
    }

    if(inp_lvl_ & device::P1.B0.b()) {
        if((cnt % 10) == 0) {
	    sci_puts("SW0 - ON\n");
        }
    }
    if(inp_lvl_ & device::P1.B1.b()) {
        if((cnt % 10) == 0) {
            sci_puts("SW1 - ON\n");
        }
    }

SWITCH_test

では、次はエンコーダーのデコードです。
基本的に、エンコーダーのデコードはスイッチの入力と基本的に変わらない。
エンコードする方法は、デバイスの分解能などの物理的要因により、いくつ
かの方法があるのですが、今回１回転辺り２４ステップ（クリック付き）
のエンコーダーを使い、サンプリングによる方法を行ってみました。

機械式接点による、ロータリーエンコーダーの場合は、かなり短い周期でパルス
が発生する為、製品のスペックに合わせたサンプリング周期を設定する必要があ
ります。
エンコーダーの回転軸を速く回した場合にも追従出来るようにするには、ギリ
ギリまでサンプリング周波数を高くする必要があります。
このエンコーダーのチャタリングは3.5ms以下のようなので、２４０Ｈｚを採用
しました。

光学式や磁気式のエンコーダーで、より高分解の場合は、チャタリングが無いの
と、周波数が高いので、サンプリングとは別の方法が用いられますが、それは、
又、別の機会とします。

static uint8_t enc_lvl_ = 0;
static uint8_t enc_pos_ = 0;
static uint8_t enc_neg_ = 0;
static uint16_t enc_count_ = 0;

static void encoder_service_()
{
    uint8_t lvl = ~device::P1();  /// 状態の取得
    enc_pos_ = ~enc_lvl_ &  lvl;  /// 立ち上がりエッジ検出
    enc_neg_ =  enc_lvl_ & ~lvl;  /// 立ち下がりエッジ検出
    enc_lvl_ = lvl;  /// 状態のセーブ

    if(enc_pos_ & device::P1.B0.b()) {
        if(enc_lvl_ & device::P1.B1.b()) {
            --enc_count_;
        } else {
            ++enc_count_;
        }
    }
    if(enc_neg_ & device::P1.B0.b()) {
        if(enc_lvl_ & device::P1.B1.b()) {
            ++enc_count_;
        } else {
            --enc_count_;
        }
    }
    if(enc_pos_ & device::P1.B1.b()) {
        if(enc_lvl_ & device::P1.B0.b()) {
            ++enc_count_;
        } else {
            --enc_count_;
        }
    }
    if(enc_neg_ & device::P1.B1.b()) {
        if(enc_lvl_ & device::P1.B0.b()) {
            --enc_count_;
        } else {
            ++enc_count_;
        }
    }
}

Ａ相、Ｂ相、の立ち上がり、立ち下がりを検出して、対になる「相」の
レベルにより、時計周り（ＣＷ）、反時計周り（ＣＣＷ）を検出します。

ENCODER_test

Ｒ８Ｃもかなり、色々なクラスが充実してきた、内臓デバイスの規模
が大きいと、デバイスドライバー的なクラスを十分用意するのは、大
変だけど、Ｍ１ｘ系だと、適度な周辺デバイスなので、見通しも良く、
シンプルに作れるのが良いところだと感じている。
※RXマイコンとかだと、周辺機器が充実しすぎていて、しかも高機能
なので、実装するのもかなりボリュームが大きくなってしまう。

ルネサスの場合、この手のタイマーは、非常に構成が細かく、広い応用
範囲を網羅している。
ハードウェアマニュアルには、全体の構成が記されており、全体の構成
や設定要領を掴むのに便利です。

R8C 20MHz の場合、出力可能な周波数は、おおよそ、20Hz～10MHzくらい
になる、タイマーのダウンカウントで発生する「アンダーフロー」を
トリガーにして、フリップフロップでトグルする仕様なので、出力は、必
ずデューティ５０％となり、最大クロックの１／２の周波数が最大となる。
設定レジスターは、周波数の逆数なので、高い周波数ほど、荒い設定しか
出来なくなる。
※実際には、低い周波数領域は、小数点以下の設定が可能なのだけど、
その仕様は割愛してある。

１ＫＨｚを出力した場合

R8C/PLUSE_OUT_test

さて、ＬＣＤも何とか動くようになったので、避けては通れないＳＤカードのアクセス
をやってみたいと思います。

先日 Flash が６４Ｋある事が判ったので、ＲＡＭ容量は心細いですが、
ＳＤカードアクセスに不安はありません。
組み込みでＳＤカードと言ったら ChaN さんでしょうー、えるむさんが実装して、ソース
を公開しているＳＤカードのソリューションは非常に柔軟性があり、細部まで良く考えら
れており、組み込みマイコンにおけるＳＤカードスタンダードだと思います。
少ないリソースでも動作するように、プチ fatfs もあり、今回のＲ８Ｃに最適な
ソリューションです。（感激！感謝です！）

ＳＤカードですが、FlashAir を使えるように、標準ＳＤカードソケットを使います。
標準ＳＤカードソケットなら、直接ユニバーサル基板にハンダ付けできますが、スイッチ
関係のパッドが狭く、その部分は、絶縁テープで保護して、直接配線します。
ＳＤカードソケットは、ヒロセ製（ＤＭ１Ｂ－ＤＳＦ－ＰＥＪ）を使いました。
このソケットは、価格は高いですが、機能と品質が非常に優れています。

事前に考えておかなければならない点として、ポートにどのように、各信号を割り当てる
かです。
まず・・
・「/RESET(3)」は、ポートにも割り当てが出来るけど、一応キープ。
・「MODE(8)」端子は当然のようにキープ。
・「TXD(16)、RXD(15)」もシリアル通信で必須なのでキープ
・「AN0(20)、AN1(19)、AN2(18)、AN3(17)」は、とりあえずキープ
・「XIN(6)」は、高精度なクロックを入れて使う場合があるのでキープ
・「TRJIO(13)」は、周期測定用としてキープ

// P4_2(1):   LCD_SCK  ,SD_CLK(5)
// P3_7(2):   LCD_/CS
// /RES(3):  (System reset)
// P4_7(4):            ,SD_DO/DAT0(7)
// VSS:(5)   (Power GND)
// P4_6(6):   XIN (高精度なクロック用)
// VCC(7):   (Power +V)
// MODE(8):  (System mode)
// P3_5(9):   I2C_SDA
// P3_4(10):           ,SD_/CS(1)
// P1_0(20):  AN0 (keep)
// P1_1(19):  AN1 (keep)
// P1_2(18):  AN2 (keep)
// P1_3(17):  AN3 (keep)
// P1_4(16):  TXD0
// P1_5(15):  RXD0
// P1_6(14):  LCD_A0 (share)
// P1_7(13):  TRJIO (keep)
// P4_5(12):  LCD_SDA  ,SD_DI/CMD(2)
// P3_3(11):  I2C_SCL

こんな感じになりました、これで、ほぼ全てのポートが埋まりました。
「P1_6(16)」は、Flash 書き込み時に使うので注意が必要です。
※無難な、LCD_A0（コマンド／データ切り替え信号）にしています。
※AN0、AN1、AN2、AN3 はアプリによって自由に使えるポートとしています。

※電源は３．３Ｖで動かします！
Ｒ８Ｃは３．３Ｖで動かしても、２０ＭＨｚで動作します、フラッシュプログラムも問題なくできます。

ぷち FatFsはソースコードを展開して、pffconf.h で基本的な設定を行います。

/*---------------------------------------------------------------------------/
/ Function Configurations
/---------------------------------------------------------------------------*/

#define	_USE_READ	1	/* Enable pf_read() function */
#define	_USE_DIR	1	/* Enable pf_opendir() and pf_readdir() function */
#define	_USE_LSEEK	1	/* Enable pf_lseek() function */
#define	_USE_WRITE	1	/* Enable pf_write() function */

#define _FS_FAT12	1	/* Enable FAT12 */
#define _FS_FAT16	1	/* Enable FAT16 */
#define _FS_FAT32	1	/* Enable FAT32 */

とりあえず、全て「１」で良いでしょう。
FAT12、FAT16 は「０」でも問題は少ないですが、古いＳＤカードは「FAT12」や「FAT16」
でフォーマットされており、それらを使う必要があるなら「１」にする必要があります、
但し、実行バイナリーは多少大きくなります。（おおよそ１Ｋバイト増加）
※FAT32でフォーマットをやり直せば、使える物もあるかと思います。

/*---------------------------------------------------------------------------/
/ Locale and Namespace Configurations
/---------------------------------------------------------------------------*/

#define _USE_LCC	1	/* Allow lower case characters for path name */

#define	_CODE_PAGE	932

「_USE_LCC」を「1」にして
コードページは９３２にしておきます。

Sample プロジェクトの generic を参考に、「diskio.c」シリアル／パラレル変換の部分を書き換えます。
自分のシステムでは、I/O ポートの制御部分は C++ のクラスで構成されているので、
「diskio.cpp」として、メインのポート定義「port_def.hpp」を使って、実装します。
※port_def で宣言しているポートクラスの実体は、「diskio.cpp」で宣言していますが、
このクラスは、最適化されインラインで組み込まれるものと思います。
他に、「マイクロ秒」単位の時間待ちルーチンが必要で、「common/delay.hpp」に該当する
関数があるので、それを使います。
※「utils::delay::micro_second(n);」

// マイクロ秒単位の、「時間待ち」
static void dly_us(unsigned int n)

/*-----------------------------------------------------------------------*/
/* Transmit a byte to the MMC (bitbanging)                               */
/*-----------------------------------------------------------------------*/
static void xmit_mmc(BYTE d)

/*-----------------------------------------------------------------------*/
/* Receive a byte from the MMC (bitbanging)                              */
/*-----------------------------------------------------------------------*/
static BYTE rcvr_mmc(void)

/*-----------------------------------------------------------------------*/
/* Receive a byte from the MMC (bitbanging)                              */
/*-----------------------------------------------------------------------*/
static BYTE rcvr_mmc()

基本的に以上の４つの関数を実装すれば良く、他に、元のソースでは、コマンド
の定義を、「#define」で行っていたので、「static const BYTE」に換えました、C++
では、この定数は、コンパイル時にのみ使われ、メモリー上に置かれる事はありません。

これで完了です。
簡単なテストとして、カードをマウントして、ディレクトリーをリストしてみます。

    FATFS fatfs;
    bool mount = false;
    // pfatfs を開始
    {
        if(pf_mount(&fatfs) != FR_OK) {
            sci_puts("SD mount error\n");
        } else {
            sci_puts("SD mount OK!\n");
            mount = true;
        }
    }

    if(mount) {
        DIR dir;
        if(pf_opendir(&dir, "") != FR_OK) {
            sci_puts("Can't open dir\n");
        } else {
            for(;;) {
                FILINFO fno;
                // Read a directory item
                if(pf_readdir(&dir, &fno) != FR_OK) {
                    sci_puts("Can't read dir\n");
                    break;
                }
                if(!fno.fname[0]) break;

                if(fno.fattrib & AM_DIR) {
                    utils::format("          /%s\n") % fno.fname;
                } else {
                    utils::format("%8d  %s\n") % static_cast<uint32_t>(fno.fsize) % fno.fname;
                }
            }
        }

GitHub R8C

先日、Ｉ２Ｃ接続のＲＴＣが動いたのだが、対象のデバイスがローカルすぎて、
誰も追試できるような状況ではなかったです。

それで、Ｉ２Ｃとしては、もっと汎用的なデバイスでも試してみたかったので、
ＥＥＰＲＯＭ用の入出力を実装してみたが、どうも、動作しない。
読み込みは出来てるようだけど、書き込みが出来ない・・・

どうも、I2C の STOP コンディションが、正しく機能していないようで、
調査したら、ACK を受け取った後に、SDA を「０」レベルに保つ必要があっ
たのに、抜けてたようだった。
※SDA を「０」に戻さないと、STOP コンディションが正しく機能しない。
それで、これを修正したら、無事書き込みが出来るようになった。

EEPROM は、STOP コンディションをトリガーにして、実際に書き込む為
動作しなかったようだー。

i2c_io クラスでは、なるべくシンプルにした方が良いだろうと思って、単純に
データを転送する関数と、受け取る関数のみ用意していたけど・・

//-----------------------------------------------------------------//
/*!
    @brief  受信（リード）
    @param[in] address スレーブアドレス（７ビット）
    @param[out]	dst    先
    @param[in]  num    数
    @return 失敗なら「false」が返る
*/
//-----------------------------------------------------------------//
bool recv(uint8_t address, uint8_t* dst, uint8_t num) const;

//-----------------------------------------------------------------//
/*!
    @brief  送信（ライト）
    @param[in] address スレーブアドレス（７ビット）
    @param[in] src      元
    @param[in] num      数
    @return 失敗なら「false」が返る
*/
//-----------------------------------------------------------------//
bool send(uint8_t address, const uint8_t* src, uint8_t num) const;

内部動作では、ＥＥＰＲＯＭにデータを書き込む場合は、データアクセスのアドレス
を、指定する必要がある。
通常の実装だと、テンポラリーを用意して、アドレスとデータをコピーしてから、
送らないとならない。
しかし、それでは、効率が悪いので、冗長ではあるけど、関数を追加する事にした。
アドレス指定は、１バイトと２バイト用に二種類がある。

//-----------------------------------------------------------------//
/*!
    @brief  送信（ライト）
    @param[in] address スレーブアドレス（７ビット）
    @param[in] first    ファーストデータ
    @param[in] src      元
    @param[in] num      数
    @return 失敗なら「false」が返る
*/
//-----------------------------------------------------------------//
bool send(uint8_t address, uint8_t first, const uint8_t* src, uint8_t num) const;

//-----------------------------------------------------------------//
/*!
    @brief  送信（ライト）
    @param[in] address スレーブアドレス（７ビット）
    @param[in] first   ファースト・データ
    @param[in] second  セカンド・データ
    @param[in] src     元
    @param[in] num     数
    @return 失敗なら「false」が返る
*/
//-----------------------------------------------------------------//
bool send(uint8_t address, uint8_t first, uint8_t second, const uint8_t* src, uint8_t num) const;

内部で行っている事は単純だけど、ＥＥＰＲＯＭへの書き込みはシンプルとなった。
又、ＥＥＰＲＯＭの書き込みでは、最後のＳＴＯＰコンディションがトリガーとなり、
ページバッファにあるデータを実際に書き込む、書き込み時間は比較的長く、５ミリ
秒とかかかる、その為、書き込みが終了するまで、待機する必要があり、今回はポー
リングで待つ事にした。
ポーリングは、比較的簡単で、書き込んだアドレスを読み出しに行けば、書き込み中
なら、正規のＡＣＫが返らないので、読み出しが失敗する、それを利用している。
もし、規定時間以上、ＡＣＫが返らない場合は、「書き込みが失敗した」として、
ストールさせる。
ポーリングで待つ場合だと、ＥＥＰＲＯＭの持っている性能を最大限生かせて、
スループットは最大となる。

あと、重要なのは、ページ境界をまたがった書き込みの場合で、start 関数で指定した
ページサイズを超えた書き込みが発生した場合は、２回に分けて書き込むように配慮
した。

さらに、もう一つの仕様として、ページサイズ以内で、ページを超えない書き込みの
場合は、書き込み終了を待たずに、関数は、直ぐに終了する。
アプリ側で、ページサイズ以内で、書き込み待ちが起こらないような間隔で書き込むよ
うに配慮してあれば、「待ち」の為にポーリングしなくて済むので、ＣＰＵ時間を有効
に利用できる。
この場合、書き込みの発行を分けて、複数回行うようなコードを書くと、二回目の
書き込みで「失敗」してストールする。
※これは、回避する事も出来るけど、余分なワークを消費するので、仕様とした。
一応、書き込み中か、判定する関数も用意してある。

//-----------------------------------------------------------------//
/*!
    @brief    書き込み状態の検査
    @param[in]  adr    検査アドレス
    @return 「false」なら、書き込み中
 */
//-----------------------------------------------------------------//
bool get_write_state(uint32_t adr) const;

先日、実験したＬＣＤ基板で、実験中～

I2C_EEPROM_test
実際のテストでは、ターミナルとの対話形式で、書き込み、読み出しのテストを行えるようにした。
ボーレートは１９２００、８ビット、１ストップビット

Start R8C EEPROM monitor
# help
speed KBPS (KBPS: 10 to 1000 [Kbps])
read ADRESS [LENGTH]
write ADRESS DATA ...
fill ADDRESS LENGTH DATA ...

EX:

# speed 1000

1000Mbps (1M bps) の指定

# read 1000

1000 番地から１６バイト表示

# read 1000 10ff

1000 番地から、10ff 番地までダンプ

# write 127e fc ba 95 67 8e

127E 番地より、「FC BA 95 67 8E」を書き込み
※最大８バイトまで

# fill 0 1ff 1 23 45 6 78 9a b

00000 ～ 001FF 番地までを、「01 23 45 06 78 9A 0B」で埋める。
※最大８バイトまで

Ｒ８Ｃ GitHub

Ｉ２Ｃの前にＳＰＩ接続を試しておく予定だったのですが、前後してしまった。

で、早速、ＳＰＩ接続の簡単なテストから始めてみました～

とりあえず、書き込みだけで、動作を確認できそうなので、ＬＣＤで実験してみます。
基板付きFSTN液晶モジュール（SPI） [M-G0812P7567]
このＬＣＤモジュールは、１２８×３２ピクセルで、ＬＥＤバックライト内臓のタイプです。

※３．３Ｖで動作させる為、バックライトＬＥＤ用の電源は、ＨＴ７７５０Ａで昇圧しています。
※先日作ったシリアルモジュールを繋なげるようにして、フラッシュ書き込みのモードスイッチ、
リセットスイッチも設けました。

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

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

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

ＳＰＩでは、ＳＣＬ、ＳＤＡ＿ＯＵＴ、ＳＤＡ＿ＩＮＰの３本が、ベースで、デバイスセレクトや、
アドレスセレクトは、別に考える必要があります、複数のＳＰＩデバイスを繋ぐ場合、ベースの
制御信号は、シェアする為です。

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

lcd_io（ＳＴ７５６７の制御）では、ＬＣＤ制御を含めて、ＳＰＩを制御します。

今回のＬＣＤでは４本の制御線が必要です。
ＳＰＩ（共通部分）：
・ＳＤＡ　シリアルデータ
・ＳＣＬ　シリアルクロック

ＬＣＤ（固有部分）：
・Ａ０　　アドレスセレクト（コマンドレジスタとデータレジスタの切り替え）
・／ＣＳ　チップセレクト
※ＲＥＳ信号は、Ｒ８Ｃのリセットに接続しています。

ＳＰＩ制御ポートの定義

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; }
};

ＬＣＤ制御ポート（Ａ０、／ＣＳ）の定義

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; }
};

GitHub R8C

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

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

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

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

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

common/i2c_io.hpp  --->  Ｉ２Ｃ基本制御クラス
common/ds1371_io.hpp  --->  ＤＳ１３７１制御クラス
I2C_test/main.cpp  --->  ＳＣＬ、ＳＤＡ、ポート定義クラス

ポートの定義

// 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 入力
};

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

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

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

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

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

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

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

common/time.h
common/time.c

GitHub R8C

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

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

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

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

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

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

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

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

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

※その為、バージョンは「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 でシリアル接続して、Ｒ８Ｃの書き込みや、消去、を色々試したけど、
とりあえず、何の問題も無い、十分に使えると思う。
自分としては、俺俺フレームワークでＧＵＩ版も作りたいけど、それはまた、後で
考えるとして・・

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

ifeq ($(OS),Windows_NT)

Ｒ８Ｃ関係 GitHub

さて、Ｒ８Ｃは、メモリーが６４Ｋ使える事が判ると、ＳＤカードの操作も楽に出来そうだし、
色々と夢が膨らむ〜

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

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

ケースは、「タカチ」の「ＴＷ４－２－６」を使った。

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

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

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

１００円で買えるマイコンとして、売られているＲ８Ｃですが、データシート上は、

ＲＡＭ２５６バイト
フラッシュ２Ｋバイトです

ところが、実際は・・

ＲＡＭ１３６６バイト
フラッシュ３２Ｋバイト

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

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

すると・・・

０ｘ１００００～０ｘ１７ＦＦＦに、さらに３２Ｋバイトの領域があり、実際に使える事が判明しました。

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

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

現在のところ、最強の１００円マイコンだと思います（笑）

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

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

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)