hira のすべての投稿

RXマイコン(組み込み向け)固定文字列クラス

RX マイコン向け http サーバーを実装する過程で、マイクロソフトのIEだ
け極めて遅い応答しかできない事が判った。

Firefox では、1秒以下で表示できるページなのに、IE(最新版)だと、
30秒、またはそれ以上の時間がかかる。

調べてみると、IEのパケット受け取りに、大きな制限があり、異常にインタ
ーバルが大きくなっているようだった、小さいパケットで、分割して送ると、
IEで許容しているサイズに満たない場合、タイムアウトするまで、html の
デコードが遅延され、結果次のパケットを受け付けない。
※何という腐った仕様だろうか・・・
※他の要因として、html のヘッダーにある「Content-Length」が無い、又は
正しくない場合に起こる挙動なのかもしれない。

当初、RXマイコン側での html 文の生成は、行単位で動的に行い、内部の行
生成のタイミングでパケットを送信していた。
※全体の長さは、最終文が来るまで判らないので、「Content-Length」は作成
していないかった。
この方法はメモリーの利用は最低限になるのだが、IEのように大きなパケット
を前提にした、腐ったブラウザでは表示速度に問題が起こる。

そこで、html 文を一旦メモリーに展開して貯めて、一気に転送する方法に変更
する事にした。
※完全に固定されたページでは無く、動的に生成している為
ここで問題なのは、「utils::format」クラスの挙動で、基本、行単位の動作を
前提にしている為、かなり大きく、柔軟に変更する必要がある事がわかり、仕様
を検討した。

そこで、固定サイズの配列で動作する文字列クラスを実装した。
メモリーが潤沢に無い場合には、「std::string」は事実上利用出来ないからで、
メモリーアロケーターが密接に関連したクラスは使う事が出来ない。
※今まで何故作らなかったのか不思議・・・
とりあえず、最低限の機能のみ実装してあり、必要になった機能を追加する。
※当然、std::string の仕様に準拠する。

以下に、ソースの一部を示す。

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  固定サイズ文字列クラス
    @param[in]  SIZE    文字列サイズ
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <uint32_t SIZE>
class fixed_string {
    char        text_[SIZE];
    uint32_t    pos_;

public:
    //-----------------------------------------------------------------//
    /*!
        @brief  コンストラクタ
        @param[in]    str     初期設定文字列
    */
    //-----------------------------------------------------------------//
    fixed_string(const char* str = nullptr) : pos_(0) {
        if(str != nullptr) {
            std::strcpy(text_, str);
            pos_ = std::strlen(text_);
        } else {
            text_[pos_] = 0;
        }
    }

    //-----------------------------------------------------------------//
    /*!
        @brief  格納可能な最大サイズを返す(終端の数を除外)
        @return 格納可能な最大サイズ
    */
    //-----------------------------------------------------------------//
    uint32_t capacity() const noexcept { return SIZE - 1; }
...

完全なソースコード

RXマイコン、C++、FTPサーバーの実装

RX マイコン C++ で、FTPサーバーを実装した。
※動作検査は、GR-KAEDE で行っている。

車輪の再発明的要素は高いが、学習的要素もあるしで、取り組んでみた。
※Arduino の FtpServer プログラムとネットの情報を参考とした。
Arduino 系の C++ ソースは、自分的には気に入らない部分が多い、なので応答メ
ッセージや、全体の流れなど参考とした。

・Arduino の構成は、最新の C++ からは乖離しており、あまり使う気にならない。
・必要の無い継承関係(継承は便利な機能ではあるが、結びつきが強すぎるので、
最近はあまり使わない、どうしても使う必要がある場合だけ使う)
・テンプレートを使わないスタイル(テンプレートを使う事で、柔軟性と拡張性
が導入できると思うので、最近は良く使うようになっている)
・ヘッダーとソースに分かれている。(C++ では、定義と実装を分離する必要が
無く、1つのソース(ヘッダー)のみで管理できる)
・他、細かい部分で色々・・

-----
ある程度実装して、クライアントを接続してみた。

最初、何とか、FFFTP のみ使える状態になった。
※データ転送は PASV モードで行った。

次に FileZilla を試したが、正常に動作しない・・・

MSYS2 上のコンソールから、ftp コマンドで接続してみたが、やはり駄目・・・

原因を調査すると、「SYST」コマンドのタイミングのようだった。
・FFFTP では、SYST は使っていないようだったのでサポートしていなかった。
・コンソールの ftp コマンドでは、SYST のリクエストが来るタイミングが、USER
認証の前だった。
FileZilla では、PASS 認証の後だった。
これを改修したら、接続は出来るようになった。

次に問題になったのは、データ転送のやり方だった。
・FFFTP では、PASV モードで転送を行っていたので、PORT コマンドに対応してい
なかった、そこで、PORT コマンドの対応も行った。
※PORT コマンドでは、FTP サーバーのデータ転送は、クライアント接続となる。
そこで、関連するデータ転送部分で、PASV モードと、PORT モードで、サーバー
動作か、クライアント動作を分けた。

これを行ってから、PORT モードでの転送も行えるようになり、ftp コマンド、
FileZilla での接続等、出来るようになった。

各種クライアントによる接続状況:

FFFTP:
・PASV 有効 ---> OK
・PASV 無効 ---> NG
※PASV 無効 では PORT モードで接続するが、ネットワークが複数(WiFiや
セカンダリーネットワーク)ある機種では、利用している IP アドレスを正しく
取得しない為、正常に接続できないようだ、これは、FFFTP のバグ(仕様)と
思える。

FileZilla:
・既定値(PORT モード)---> OK
・アクティブ(PASV モード) ---> NG
・パッシブ(PASV モード)---> OK
※「アクティブ」の仕様が不明

ftp:(MSYS2 上のコマンド、Windows の ftp コマンドでは無い)
たぶん PORT モード ---> OK

-----
まだ、現在、ネットスタックが調整中であり、中途な状態ではあるが・・

ftp_server.hpp

に、ftp_server のソースコードがある。

サポートコマンド一覧:(※一部、実装中)

    // RFC 959
    ABOR,   ///< ファイルの転送を中止する。
    ACCT,   ///< アカウント情報。引数はユーザアカウントを示す文字列。
    ALLO,   ///< ファイルを受け取るために十分なディスクスペースを割り当てる。引数は予約するサイズ。
    APPE,   ///< 引数に示したファイルに対して追記する。
    CDUP,   ///< 親ディレクトリに移動する。
    CWD,    ///< 作業ディレクトリの変更。引数は移動するディレクトリ。
    DELE,   ///< ファイルを削除する。引数は削除するファイル。
    HELP,   ///< コマンドの一覧。引数を指定するとより詳しいコマンド情報を返す。
    LIST,   ///< 引数に指定したファイルの情報やディレクトリの一覧。
            //   指定しない場合、現在のディレクトリの情報を一覧。
    MKD,    ///< 引数に指定した名前のディレクトリを作成する。
    NLST,   ///< 引数に指定したディレクトリのファイル一覧を返す。
    NOOP,   ///< 何もしない。接続維持のためダミーパケットとして使われることがほとんど。
    MODE,   ///< 転送モードの設定(ストリーム、ブロック、圧縮)。
    PASS,   ///< 認証パスワード。
    PASV,   ///< パッシブモードに移行する。
    PORT,   ///< サーバが接続すべきポートとアドレスを指定する。
    PWD,    ///< 作業ディレクトリを取得する。
    XPWD,   ///< 作業ディレクトリを取得する。(拡張)
    QUIT,   ///< 接続を終了する。
    REIN,   ///< 接続を再初期化する。
    REST,   ///< ファイルの転送を指定した箇所から再開する。
    RETR,   ///< リモートファイルをダウンロード(Retrieve)する。
    RMD,    ///< 引数に指定したディレクトリを削除する。
    RNFR,   ///< 引数に指定した名前のファイル(ディレクトリ)をリネームする。
    RNTO,   ///< 引数に指定した名前のファイル(ディレクトリ)にリネームする。
    SITE,   ///< RFCで定義されていないようなリモートサーバ特有のコマンドを送信する。
    SMNT,   ///< ファイル構造をマウントする
    STAT,   ///< 現在の状態を取得する。
    STOR,   ///< ファイルをアップロード(Stor)する。
    STOU,   ///< ファイル名が重複しないようにファイルをアップロードする。
    STRU,   ///< 転送するファイルの構造を設定する。
    SYST,   ///< システムの種別を返す。
    TYPE,   ///< 転送モードを設定する(アスキーモード、バイナリモード)。
    USER,   ///< 認証するユーザー名

    // RFC 2389
    FEAT,   ///< サーバに実装されている拡張コマンドのリストを取得する。 
    OPTS,   ///< 拡張機能の設定。 

    // RFC 3659
    MDTM,   ///< 引数に指定したファイルの最終更新時間の詳細を返す。
    MLSD,   ///< 引数に指定したディレクトリのファイル一覧を詳細な最終更新時間をつけて返す。
    MLST,   ///< 引数に指定したディレクトリの詳細な情報を返す。
    SIZE,   ///< ファイルサイズを返す

ftp_server クラスは、ファイルアクセスクラスを参照する為、以下のように
SDC(ファイルアクセスクラス「utils::sdc_io」)を typedef しておく。

typedef net::ftp_server<SDC> FTP;
    FTP     ftp_;

コンストラクターで、SDC の実態、及び、Ethernet クラス(net スタッククラス)
を渡す。

    ftp_(ethernet_, sdc_io_)

開始時、ユーザー名、パスワードを引数とする。

    ftp_.start("user", "pass");

実行時、1/100秒間隔でサービスを呼び出す。

    ftp_.service();

-----
ネットスタックは、GR-KAEDE の WEB コンパイラ用ソースを元にしているが、
かろうじて動いている状態なので、回収中。
※あまりにも、酷いソースコードなので、前面的に修正中・・・

サーミスタの温度計算テンプレート

サーミスタの温度計算テンプレートを実装してみた。

このような簡単なテンプレートクラスを書くのは、程よい難しさもあり、パズル的
要素があって意外に楽しい。

クラスのプロトタイプは以下のようになっている。

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
  @brief  NTCTH テンプレートクラス
  @param[in]  ADNUM A/D 変換値の量子化最大値
  @param[in]  THM   サーミスタの型
  @param[in]  REFR  分圧抵抗値
  @param[in]  thup  サーミスタが VCC 側の場合「true」、GND 側の場合「false」
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <uint32_t ADNUM, thermistor THM, uint32_t REFR, bool thup>
class NTCTH {

使い方:

#include "chip/NTCTH.hpp"

・・・

// A/D: 12 bits, NT103, 分圧抵抗: 10K オーム、サーミスタ: VCC側
typedef chip::NTCTH<4095, chip::thermistor::HX103_3380, 10000, true> THERMISTOR;
THERMISTOR thermistor_;

・「NTCTH.hpp」をインクルードする。
・テンプレートパラメーターを typedef しておく。
※A/D 変換の分解能(この場合は12ビット)
※NT103 型サーミスタ(B定数などの定義は、「NTCTH.hpp」にある)
※分圧抵抗の値(10000オーム)
※サーミスタが、VCC側か、GND側にあるのか定義

auto v = get_adc(6);  // CH6
utils::format("温度: %5.2f [度]") % thermistor_(v);

クラスに、A/D変換値を入れて、呼ぶと温度が返ってくる。
※サーミスタの抵抗値が「0」になる場合は抵抗計算が成立しなくなるが、実際には、
そのようねケースは起こらないので、「良し」としとく。

テンプレート化している事で、不必要な比較的要素(サーミスタがVCC側かGND側)
かで別れる計算過程などがコンパイル時に決定されるので、条件分岐は無くなり、最適化
も十分行われる。

※対数計算があるので、数学ライブラリ「libm」をインクルードする必要がある。

※サーミスタは種類が多く特性が違うので、新たなサーミスタを使う場合は、テンプレー
トに定義を追加する必要がある。
・「thermistor」型の定義

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  サーミスタ型
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
enum class thermistor {
    NT103_34G,  ///< THB:3435, TR25:10K
    NT103_41G,  ///< THB:4126, TR25:10K
    HX103_3380, ///< THB:3380, TR25:10K (25C to 50C)
};

・「パラメーターの取得関数」

static void get_para_(float& THB, float& TR25)
{
    switch(THM) {
    case thermistor::NT103_34G:
        THB  = 3435.0f;  ///< サーミスタB定数
        TR25 = 10e3;     ///< R25 サーミスタ25℃基準抵抗値
        break;
    case thermistor::NT103_41G:
        THB  = 4126.0f;  ///< サーミスタB定数
        TR25 = 10e3;     ///< R25 サーミスタ25℃基準抵抗値
        break;
    case thermistor::HX103_3380:
        THB  = 3380.0f;  ///< サーミスタB定数
        TR25 = 10e3;     ///< R25 サーミスタ25℃基準抵抗値
        break;
    default:
        break;
}

R8C/M120AN サーミスター・サンプル

-----
100円マイコン、R8Cでも、問題なく動作した。
・NTCサーミスタ(NCP18XH103F03RB)

※将来的にR8Cで温度制御に使う予定。

サーミスタの温度表示サンプル、R8Cでのバイナリーサイズ:
※log 計算や float の計算が含まれるので、確認

m32c-elf-size thm_sample.elf
   text    data     bss     dec     hex filename
  24580     296      76   24952    6178 thm_sample.elf

R8C/M120AN でのバイナリーサイズ

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

以前にRX24T用に、実装した事があるので、まぁ、同じようなものだろうと思った
が、全く違う仕様で、マニュアルを見ながら、チクチクと実装したので、それなりに時
間がかかった。
※「RX64Mグループ、RX71Mグループフラッシュメモリユーザーズマニュアル ハードウェア インタフェース編」
※リンクを開くには、ルネサスのアカウントが必要

RX64M、RX71Mは共通のようだが、基本的に、RX64Mは、フラッシュメモ
リーはEEPROM系では無い感じだ。

通常、EEPROMでは、イレースすると、データが「FF」になるが、RX64Mは
以前に書かれた値が維持されるようだ、しかしながら、イレースを発行したバンクには
新規に新しい値に変更ができるようになる。

なので、以前とは少し違った管理方法を考える必要がある。

それでも、R8C、RX24T、などと共通の仕様にしておく事は有益なので、そのよ
うな見た目を提供できるように実装を行った。
※単純にデータを保持する目的なら、I2Cで外部に接続したEEPROMの方が簡単
で汎用性が高いと思われる。
前から疑問なのだが、なぜ、こんなにも、面倒な操作が必要なのか理解に苦しむ。
※単純にメモリーが「主」のEEPROMをウェアハ上に作る場合と、一般的なロジッ
クが「主」のマイコンでは、製造過程におけるプロセスが随分違う為、マイコン内臓の
EEPROMの場合は、そう単純ではないのかもしれないが、単にデータフラッシュに
読み書きするだけなのに、毎回、仕様を見ながらシーケンスを作る手間は勘弁してほし
い、かと言って、「ル◎サ◎」が提供するソースコードの品質は極めて低いので使う気
にならないしで・・・

RX64Mのフラッシュが特殊な点は、フラッシュメモリーの操作は、内臓されたシー
ケンサーが行い、このシーケンサーにコマンドを送る事で二次的な操作で行う点だ。

初期化では、このシーケンサーにファームを転送して、起動する必要がある。
ファームは、RX64M内に置かれているので、単にデータの転送を行うだけなのだが、
特殊だと感じる。
※確かに、シーケンサーを動かすファームを書き換える事で、色々な仕様を網羅できる
のは後々便利なのだが・・

RX64Mのフラッシュで、とりあえず、駄目なところは、書き込みが4バイト単位で
しか行えない点だろう。
※当然書き込み先アドレスも4の倍数となる。
一度、データを書いたブロックは、イレースするまで更新ができない訳だから、バイト
単位でオーバラップするような操作は行えない事になる・・・
フラッシュの書き込みは、必ず4バイト(32ビット)単位で行うようにしなければな
らない。

とりあえず、「できた」レベルで、あまり詳細に検討していないがソースコードを、
Git に上げた。

flash_io.hpp

RX64M、GR-KAEDEのSPI、SDカードインターフェースの罠

GR-KAEDEにはRSPIを使った、SDカードインターフェースがある。

ところが、非常に不安定で、動作しない事が多かった。
実装はRX24Tでも実績のあるコードで、RX24Tでは何の問題も無く動作
しているものだった・・・

MMC/SDCの使い方
SDカードをSPIモードにするには、「DAT0」端子をプルアップしておく
必要があるのだが、回路図を観ると、GR-KAEDEには、プルアップが無い
ようだ、そこで、10Kでプルアップした。
しかし、全く効果は無かった。

電源ノイズによるものなのかとも思い、10uFをマイクロSDソケットの端子
に接続したが効果は無かった。

ソフト的に色々考えられる事を試したが、成果は無かった・・・

症状としては、初期化の段階で、SDカードをSPIモードに切り替える段階で
エラーになり、SPIモードにならないものだった。

SDカードの相性問題があるのかもしれず、試したが違うようだ(マイクロSD
を二種類しか持っていない)
※そもそも電気回路に「相性」のような不確定性があるハズも無い。
※ごく稀に動作する事もあるが、何かの拍子にすぐに不良になる。

約2日悩んだが、どうやら原因が判った。

RX64Mのデータシートを観ていて、気が付いた、何と、GR-KAEDEで
は、DAT0はPC7に接続している、しかも、この端子はリセット時にブート
モードを切り替えるMD端子でもある。
よくよく回路図を見ると、モード切替のDIP-SW付近で、4.7Kオームで
プルダウンされている。

あーーー、これだ・・・・・


そこで、1Kオーム位ででプルアップしたいが、それだと、ブート出来ない。
そこで、1KオームでPC3と接続しておき、SDカードの初期化時にPC3を
出力にして「H」を出力する事で、プルアップした状態を作る事にした。

この改修を行い、PC3の制御を足したら、当たり前だが、SDカードがSPI
接続出来るようになった。

-----
また、DAT0のプルアップは、必要無いカードもあり、状況を複雑にしている。

GR-KAEDEでSDカードを使っている人はどのように回避しているのだろ
うか?

追記:
ネットを調べたら、普通に情報があった(良く調べるべきだった・・・)
GR-KAEDEでSDカードにアクセスする場合について

RX64M、GR-KAEDEを試用してみた

GR-KAEDEを試用する機会があったので、少し内容に触れてみたい。

同時に、「RENESAS E1」も借りたので、それについても述べておく。

ルネサス関係のマイコンを集中して扱っているが、E1エミュレーターは、持って
いない。
理由として:
・値段が高い
・基本的に普段は詳細なデバッグを必要としない事が多い
※この理由が大きい、ターミナルデバッグで通常は十分
・ルネサスのIDEを使わない(購入するには高価すぎる)
・KPIT はフリーで使えるが、やはり、IDE が好きでは無いし、自分的には刺さらな

など、色々な理由がある、今回は、デバッガーとしてではなく、FlashROM
の書き換え時に、「Renesas Flash Programmer」でのみ利用した。
通常は、シリアルポートを使って書き込んでいるので、それに比較すると、書き込
み速度が速く、重宝した。

GR-KAEDEは、ハードとしては悪くは無いが、高すぎるので興味は無い。
※サポートや、色々考えると、まぁしょうがないのは理解できるが納得はできない。
※バッテリーバックアップ用の電池フォルダーくらいは付けて欲しかった。
・初期からSDRAMが載っているのは好印象。

GR-KAEDEに用意されているプロジェクトに関して:
とりあえず、WEBコンパイラで、簡単なコードを動かしてみて、動作確認し、自分
のシステムに、必要な部分を移植(主にイーサーネット関係のスタック)する為、
プロジェクト一式のソースコードを取得した。
※何故か、ビルドして出来た、mot ファイルをフラッシュに直接書いても動作しない。
スケッチとしてロードすると機能した、「まぁ、そういうものなのだろう」として
詳細な理由は調べなかった。

今まで、GR系のソースコードには触れていなかったのだが、開発期間が短いので、
色々調べたが、やはり既にある程度枯れているソースを再利用する事にした。

第一印象:
・CとC++のコードがあるが、どれも、品質がとても低い。
※ボードの価格に値しない、ソースコードの品質
・コーディング規約はほとんど守られていない。
※多分、会社内でコードレビューを行った事が無いのだろうな・・・
・関数名、クラス名、変数名のつけ方に一貫性がないのでわかり難い。
・C++のクラスがいくつかあるが、これはC++とは言えない(C+-だろうな)
※典型的な、C++を少しだけかじったCのプログラマーのコード
・色々なところに細かく罠とも思える実装依存が含まれている
※動作させるまでに、時間がかかった・・・
・設計が悪すぎで、典型的なスパゲッティーコードになっている。

そんなこんなで、動作させるまでに非常に時間がかかってしまったが、色々改修し
ながらコツコツを進めている・・・

R8C(M120AN)を使ったUSB、電流、電圧チェッカー(その2)

液晶のDPIが高い為、いつも使っている12×6ピクセルのフォントでは
小さすぎて見にくい(最近、視力が極端に落ちてる事も影響・・・)

とりあえず、24ピクセルのフォントを用意するまでの繋ぎで、縦横二倍
にして表示する事で、解像度を生かせないが、それなりの大きさになった。

※余ったスペースで、電力変化をグラフ表示した。

ケースに液晶の穴を開けたが、液晶への配線が邪魔で、蓋が閉まらないが、
何とか工夫すれば、閉まる感じではある。

単独で、電力のグラフ表示も追加した。

マイコンのアナログ入力はまだ余っているので、USBの差動信号電圧を測
定する機能も追加した。

まだ、ソフトを見直す余地はあるが、とりあえず完成とする。

-----
今後の改修予定:
・電力のグラフ表示のインターバル設定
・電圧、電流変化時のフィルター

などなど

R8C(M120AN)を使ったUSB、電流、電圧チェッカー(その1)

R8C(100円マイコン)では、多分始めてとなる実用的なサンプルだ。
※液晶の事故により、第二段となった・・

マイコンは100円だけど、ハイサイトの電流検出に210円のICを使っているのが
痛い・・・
まぁそれはそれとして、多少豪華な仕様(128×32グラフィックス液晶)にしてあ
る。

また見た目も重要なので、タカチ電機工業のケース(CS75N)に収まるように
製作した。

表示切替などを行う、スイッチも設けた。

問題となったのは、「クイックチャージ」をどうするかだ、この仕様では、最大20V
の電圧に対応する必要がある。
電源電圧が5~20Vも変化するとなると、部品の選定や回路設計が難しくなる。
自分は、そのようなデバイスを持っていないが、折角だから「対応」を視野に入れて製
作した。

・マイコンは3.3Vで動作させる。
※グラフィックス液晶が3.3V動作なのと、M120ANのA/D変換の基準電圧は
VCCと同等なので、電源電圧が正確である必要がある。
※5V~20Vから3.3Vを出力する事ができるレギュレーターを入れる。
・ハイサイト電流検出のIC、「LT6106CS5」は、都合の良い事に、最大36
VまでOKなので、これをそのまま使う。

-----

さて、製作してる過程で、配線を修正したり、オペアンプを追加したりしてたら、液晶
に余計な力がかかり、フレキが「ポロリ」ととれてしまいご臨終となった。

しばらくの間、その衝撃で、製作意欲が吹き飛んでいたのだが、秋月で、新たな液晶を
購入、入れ替えた・・・

この液晶、以前のより解像度が高いのだけど、表示面積は少し小さい、またバックライ
トも無いが、コントラストは良好なようだ。
解像度は、128×48ピクセルあり、フレームバッファを用意すると、768バイト
必要となる為、少ないRAMしかないM120ANでは、半分のフレームバッファを
用意して、二回に分けてレンダリングし、半分づつLCDに転送する事で、何とかやり
くりしている。

-----

ケースは、少し小さすぎで、色々削って、何とか入る余地を設けたが、もう少し大きい
方が良さそうだった・・・

基板に、フラッシュプログラムの切り替えや、シリアルコネクターを設ける余裕が無か
ったので、インライン6ピンの専用ラインを設けて、外部でフラッシュプログラム時の
切り替えやリセットなどを行うようにした。

※この段階では液晶の窓は、開けていない・・・

表示に使うフォントなど作り直す必要もあり、色々修正中ではあるけど、とりあえず、
電圧表示と、電流表示、経過時間表示などできたので、回路図を含めて、Gitに上げた。

USB チェッカー

R8C(M110AN)を使ったRCサーボテスター

100円マイコンR8Cには、14ピンの小型パッケージ(M110AN)が
ある。

今まで、ほぼ、20ピンの120ANを多用してきた為、あまり使う理由が無
かったので、今回、RCサーボテスターを作成し、小さいケースに収める事で、
14ピンパッケージの利便性を役立てた。

以前に、サンプルとして、2チャネルのRCサーボを制御する為のコードを実
装したが、これは、それを少しだけ修正して、シングルチャネルで動作させる
だけのものだ。
※ボリュームの角度により点滅速度を変化させるLEDインジケーターを追加
した。

タカチのケースに収める為、余分なスペースが無いので、6ピンのフラッシュ・
プログラム用コネクターを設けている。

インジケーターは、ケースに穴を開けて、グルーガンで塞ぎ、硬化したら、表
面の凸部分をカッターで削って平面にする。
最近良く使う手法で、こうする事で、かなり自由にLEDを基板に取り付けら
れる。
また、グルーガンのスティックが半透明なので、淡い発光で見栄えも良い。

RCサーボテスター回路図:

現状では、サーボのPWMパルスの仕様は、JRサーボ用にしてある。
※ソースコードの先頭で、フタバ用に切り替える事ができる。

// どちらか片方を有効にする
#define JR_TYPE_SERVO
// #define FUTABA_TYPE_SERVO

ソースコードと、KiCADのプロジェクトは、GitHub にプッシュ済み。

M705マウスの修理

最近、どうもボタンの調子が悪い、いわゆる「チャタリング」を起こす感じで、具合が
悪い。

このマウス、保障期間は3年と長いのだが、保障期間は過ぎている。
かと言って、買いなおすのももったいない。

ネットで調べると、同じような症状に悩んでいる人も多いようで、スイッチに使ってい
るマイクロスイッチを単体で入手する事が出来るので、自分も修理する事にした。

分解する場合に、この+ドライバーが、ピッタリだった。

ある程度値段のするマウスは、分解する事を前提に作られているためか、比較的容易に
分解できる構造になっている。

(1)まず、5箇所のネジを外して、上ケースを分離する、側面にあるスイッチ用のコ
ネクターを抜く(そこそこ硬いので注意)
※パッドの下に2本隠れているので、パッドを剥がす(両面テープで貼ってある)

(2)スクロールホイールを固定してあるピンを抜く。

(3)スクロールホイールを外して、ネジを4箇所外すと基板が取れる。
※電源コネクターを抜く(そこそこ硬いので注意)
※スクロールホイールボタン用の小さいバネがあるので、無くさないように!

(4)問題のスイッチを取り除く。

※十分溶かして、吸引機で吸い取る、ピンを左右に揺らした感触で、フリーになってい
るか、まだハンダが残っているか判断できる。
※サーマルリリーフがあってもパターンの面積が広いと、熱が拡散されて、ハンダが十
分に溶けないので、大きな容量のコテが必要。(自分は、アンテックスの60Wを使っ
た)
※80Wの温度調整機能付のコテでは、最大温度でもハンダがうまく溶けなかった。

(5)新品のスイッチを取り付けて完了。
・購入したスイッチと、古いスイッチ

・GNDはサーマルリリーフになっているので、コテの熱量が足りないとハンダ付けしにくい。

・右ボタン、左ボタンで向きが違うので注意

(6)各部品を元に戻して終了。

当たり前だが、チャタリングも収まって、調子が戻った~