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

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

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

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

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
  @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)各部品を元に戻して終了。

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

純正インクに係わる陰謀説

以前から、プリンターはキャノン製を使っている、まぁ使用頻度はあまり高くは
無いが、無いと困る、スキャナーはそれなりに使っている。
印刷品質も満足していて、十分綺麗で納得だ。

使っていたのはMP950、10年は使っていたと思うが、最近故障してしまった。

しかし、故障の感じが「妙」で、液晶にインク系のエラー番号が表示され、先に進
まない。

まぁ、10年は使ったし、修理して使うのも無理そうなので、型落ちの同じような
複合機「MG7730」に買い換えた。(型落ちは、最新型に比べても、性能は申
し分無いレベルで、それでいて値段が凄く安くなっている)

今回問題と思う違和感は、何故故障したかだ・・・
最近、純正インクは高杉なので、互換インクを使っていたのだが、どうも、それが
原因ではないかと疑っている。

内部のフォームウェアーで互換インクと、純正インクを見分けていて、互換インク
の利用限度(多分設定されている)を超えると、エラー番号を表示して、本体を利
用できないようにするプログラムが仕組まれているのではと思っている。
※互換インクを数回使って同じような壊れ方をした話を知り合いから聞くことが出
来た。

写真画質でも、汎用カラー印刷でも、印刷を比べて、互換インクの品質が、純正イ
ンクより著しく劣るとは考えにくい。

昔、ブラウン管TVが主流の時代に、回路図を見ながら修理をしていて、70Vか
かる部分に耐圧限度が75Vのトランジスタを使っていた、これは、数年で壊れる
ように誘導する為の作戦で、承知の事実だった。
※たかだか数万円の製品の場合3年くらいで買い換えてもらわないと、メーカーは
やっていけないと言うのが言い分らしいが、理解はできても納得はいかない。

------
消耗品のインクを高くして、本体の価格を安くするビジネスモデルはレックスマー
クが始めたものと思うが、まぁそれを否定する事も難しい背景があるにはあると思う
が納得はいかない。
・日本の工業製品の品質は高く、本体が壊れにくくなっている。
・開発には多額の投資をしており、本体価格に乗せて売りたいが、市場には受け入れ
られない状況になっている。(他メーカーとの競争もあるし、本体価格をギリギリま
で下げる必要がある)
・本体は、一度購入すれば、買い替えが起こる頻度は少ないので、継続的に利益を
得る方法が必要となる。(消耗品のインクで儲ける、そうしないと開発チームの維持
が難しい)
・基本的な性能は、すでに十分熟成しており、性能と価格の住み分けが難しくなって
いる。

ただ、純正インクの値段が、とてつもなく高い。

互換インクはかなり安いが、本体にロックがかかる事を考えると、「純正やむなし」
と言えるかもしれない・・・

インクには、チップが内臓されており、リバースエンジニアリング(完全なリバース
エンジニアリングは難しい)されても、間欠的に通信する特殊な暗号通信を装備して
いれば、互換インクを見分ける事も可能なのだと思う。
純正品のカートリッジを利用する場合で、リセットしても、リセットの回数が記録さ
れていて、それを読み出せれば、互換インクの識別に使う事が出来る。

逆説的に、互換インクメーカーに、チップの通信プロトコルに関して、少しだけ情報
をリークしておき、ある程度互換インクを作りやすくする事で、互換インクメーカー
をコントロールしておけば、互換インクを使うユーザーは、必ず本体が故障するので、
買い替え頻度が上がり、本体の買い替え需要も見込めるものと思われるが・・・
ただ、このモデルはあくまでも、想像にすぎず、厳密な証拠は無い、これが本当かど
うかは、本体内部ファームのソースコードを精査する必要があるが、それは実現しな
いだろう。

-----
壊れた、MP750は、暇な時にでも分解して内部を見て見ようと思う。

NESエミュレーターのテスト

最近、ESP32の情報を集めていて、ESP32のプロジェクトにNESのエミュ
レーターがある事に気がついた。
※ESP32の方は、開発環境が、少し特殊なので、少し様子見ではあるのだが・・

NESのエミュレーションは前から興味があり、最終的にはRXマイコンで動かそう
と思っているのだが、その前に、十分コードを検証しておく必要があると考えていた。

そこで、glfwフレームワーク上で十分コードを精査しておこうと思い、必要そう
なコードをプロジェクトに入れてコンパイルしてみた。

GLFW、NESエミューレーター

NESエンジン部分のコンパイルが通り、OpenGLの描画部分、OpenALの
ストリーム部分、キー入力部分など繋げてみたら、とりあえず動いた!
※現状で、OS-X、Windowsで動作するが、動かないでアプリがクラッシ
ュする、ROMファイル(.NES)もかなりある・・・
音は、ストリームのキューイングがうまくいっていないが、とりあえず鳴る。
音は、Windowsは、普通に鳴るように修正をしたが、OS-Xでは、OpenALの実装が違う
ためか、途切れる・・・
バッファーを多くとれば解消するかもしれないが、遅延が多いのは問題なので、対応
を考えなければならない。

エミュレーター部分はCで書かれているのだが、かなり怪しいコード満載で、かな
り「痛い」コードと言える部類だが、力作ではある、とりあえず、明らかにおかしな
部分は修正を行なって、動作確認などしてあるが、まだまだ動作が怪しい。
※メモリーリークがあり、クラッシュしたり、アサーションを起こす・・・
奇妙な作りの部分が沢山あり、適宜修正して、なるべく多くのROMファイルを動
かそうと思う。


GALAXIAN.NES


Zombie.nes


GRADIUS.NES


Solstice_J.nes
-----
使い方:
F1:ファイラーの表示 On/Off(NESファイルを選択)
F2:制御パネル On/Off(ステートのロード/セーブ、マスターボリューム)
1:セレクト
2:スタート
Z:Aボタン
X:Bボタン
方向:十字ボタン
F4:ログ表示ターミナル(逆アセンブル、読み出し、書き込みなど)

Just another WordPress site