「気になった事を・・・」カテゴリーアーカイブ

日常、気になった事、どうでもよい話題などをつぶやく。

WR250Xのメンテナンス

昨日、バイクで出かける用事があり、気になっていたメンテナンスを行った。

フレームが微妙に錆びていて、その部分を補修した。

色々な方法があると思うが、今回は、「サビ転換剤」を使った。

方法は簡単で、ワイヤーブラシで、赤サビの部分の汚れや、サビなどを落として、上記の液体を塗るだけ。
マフラーにも塗っておいたが、高温になるので、効果があるのかは微妙。

様子を見て、上から塗装しておこうと思う。

github のREADMEを英語ベースにする試み・・

最近、VSCodeでマークダウンを編集している。
これが、凄く快適で、画面をスプリットして、リアルタイムに描画イメージを確認しながら作業出来る。

そんな事もあって、トップページの README を英語にして、日本語はリンクにしてみた。
自分、英語が得意では無いので、翻訳は、Google 先生にほぼお任せ状態で、ネィティブな人には、かなり痛い英語かもしれない。
まぁ、無いよりはマシ程度と考えている。

まだ、全部を翻訳していないが、順次追加していこうと思う。

VSCode にはマークダウンを PDF 化する拡張機能があり、これを使う事で、ブラウザ以外でも読めるファイルが作れる事から、RXマイコン関連の事や、ブログで書いた細かい話などをまとめた。

https://github.com/hirakuni45/RX/blob/master/docs/cpp_spin_rx_story.md

これもまだまだ未完成なので、今後加筆修正していこうと思う。

Visual Studio Code を使う為の設定

自分は、マルチプラットホームにこだわりがあり、色々な異なった環境でも同じような操作性を提供できる事に注目している。

Visual Studio Code は、マイクロソフトのオープンソースによるもので、アプリケーションとしてはテキストエディターだが、単なる文書を書くだけではない、色々な拡張機能を追加でき、カスタマイズ出来る点で大きな広がりがある。
拡張機能は、emacs が先人でもあるが、emacs がスタートした時代は古く、VSC は最近の「流行」を取り入れて斬新な物になっている、emacs を現代風に作り直したアプリケーションとも言えると思う。
※emacs は Lisp だが、VSCは Json なので、より多くの人に受け入れやすい。

「創作活動のほとんどは、文書を作る動作が起点になっている。」と言う事実に改めて気がつく。

既に多くの人が、VSC を利用した拡張機能をリリースしており、自分で新規に作らなくても、インストールして利用する事が出来る。
また、VSC の設定方法や Tips など豊富にある、ただ、目的の機能を実現する方法は複数(無限)あり、VSC のバージョンとも関連するので、シンプルな方法を選んで取り込む必要がある。

自分が VSC で感激した点:
・拡張機能が豊富で、検索してインストールする事がコンビニエンス。
・Git と連携していて、git で行う操作を標準で色々行える、git 用フロントエンドアプリを使うより強力で判りやすく便利かもしれない。
・Markdown 形式を標準でサポートしており、プレビューしながら記述出来る。
※拡張機能を入れると PDF 化する事も出来る。
・Terminal 機能があり、MSYS2 の bash などを呼び出して使う事が出来る。
・C++ では非常に有能なインテリセンスが使える。
※インクルードパスの設定が重要
・プラットホーム毎の「固有」設定が出来る。
・比較的軽い。

それでも、小躍りする前に事前の調査が重要、「道具」類は、良さそうと思って使ってみても、細かいとこで気に入らない事も多い。
少し使ってみて、「何だコレ!」って思った事もあったけど、やはり「短所」より「長所」が勝っており、将来性を考えたら、コレを使わない理由が無い事に気がつく。

今まで emacs を中心に使ってきた、ただ、積極的に Lisp を使う気になれなくて、ほぼコードを書くだけで使っていた。
※知り合いは、自分で Lisp を書いて、自分の欲しい環境を色々実装している。
それを横目で観ていて、自分もやってみたいと思っていたが、もう少しハードルを下げた方法は無いのかとも思っていた。

最近の VSC では、「ワークスペース」と言う概念を使う事ができる点で、異なった環境を柔軟に切り替える事が出来る。
※以前は、フォルダーのルートを指定するシンプルな物だったが、それを少し拡張して、複数フォルダーに関連するファイル郡を一括して扱う事が出来るようになった。
「ワークスペース」では、設定が書かれた専用ファイルを開く事から始めるので、固有の設定を取り込む事が出来る。

まずインストール。
MSYS2 は現状でも、ツールの中心なので、インストールする、詳しい方法は、https://github.com/hirakuni45/RX を参照の事。
※MSYS2 は MinGW とは異なったアプリケーションなので、必ずMSYS2 を使うように。

・Terminal で MSYS2 の bash が起動出来るようにする設定、「settings.json」を編集して、以下のように追加しておく。
※「settings.json」の直接編集の正しい方法は「ぐぐって」もらうとして、自分の場合は、
「設定」などで、「settings.json で編集」などのリンクがあるので、それをクリックして編集している。
※キーワードを入れると候補が表示されるので判りやすい。

{
    "git.ignoreLegacyWarning": true,
    "git.autoRepositoryDetection": "subFolders",
    "C_Cpp.default.cppStandard": "c++14",
    "C_Cpp.default.cStandard": "c99",
    "files.autoSave": "afterDelay",
    "C_Cpp.default.intelliSenseMode": "gcc-x64",
    "C_Cpp.intelliSenseEngineFallback": "Disabled",
    // MSYS2 bash のパスと、起動設定
    "terminal.integrated.shell.windows": "C:\\msys64\\usr\\bin\\bash.exe",
    "terminal.integrated.env.windows": {
        "MSYSTEM": "MINGW64",
        "CHERE_INVOKING": "1"
    },
    "terminal.integrated.shellArgs.windows": [
        "--login"
    ],
    "terminal.integrated.cursorStyle": "line",
    "editor.renderWhitespace": "all"
}

※必要な部分のみコピーする場合は、「,」に注意

・拡張機能を入れよう~
※「拡張機能」ボタンを押して、検索ボックスでキーワードを入れれば、候補がリストされ、簡単にインストール出来る。

(1) C/C++ (Microsoft)
※自分は、マイクロソフトの物を入れているが、検索すると複数の物が見つかるので、自分の嗜好に合った物を使えば良いだろう。
※現段階で、gcc などでインテリセンスを機能させる設定が判っていない。

(2) Emacs Friendly Keymap
※とりあえず、キーバインドを Emacs 風にしている、vi や他のエディター用もあるし、自分でキーバインドを設定する事も出来る。
※VSCでは、「ESC」キーは別の意味で使われており、一般的な Emacs のメタキーとして利用するには反故が多いようだ。
なので、「M-v」は「ALT+v」として機能する、今まで「ESC」を使ってきたが、矯正する必要がありそうだ・・・
まぁ確かに、ESC を押してから v を押すより、ALT+v の方が利便性が高い。

(3) Japanese Language Pack for VS Code (Microsoft)
英語のメニューでも、そんなに困らないが、日本語の対応は流石に本家だけあって良く出来ている


最後はインテリセンスの設定だが、MSYS2 上の gcc g++、clang などで運用するには、もう少し調査が必要だと思う。

思いつくインクルードパスを設定しても、思ったように、インテリセンスが機能しない・・・

色々調べたが、何故思ったように機能しないかも不明で、WEBにある「こうすればおけー」と言った情報を見て、そのように設定してみたが、やはり駄目・・

何か特殊な設定をするのか、別の拡張機能を入れるのか、謎である・・・

清涼飲料水の功罪

自分はアトピーがあるので、いわゆる「食品添加物」には敏感になっている。
原因が判らないし、薬は利かない状態なので、どうしても食べる物に関して無頓着ではいられない。

清涼飲料水の中では、得に炭酸飲料が好きで、「ドクターペッパー」ファンでもあるのだが、最近はなるべくコントロールして飲むようにしている。

ドクペに限らず、清涼飲料水は、どれも同じような組成で、しいて言えば「色」と「香り」が異なる程度の違いしかない、元々は果汁(ジュース)を人工的に作り出す研究から発達したものと思われる。

主な成分は:
(1)加糖ブドウ糖液
(2)酸味料(クエン酸、 アスコルビン酸)
(3)香料
(4)着色料
(5)水、又は炭酸水
(6)保存料

などで、大抵の清涼飲料水は以上の材料から作られている。
これは、「ジュース」に代表される物の組成を真似た物で、極めて安価に作る事が出来る。
※清涼飲料水でもっとも大きなコストを占めるのは輸送費とCM費だろう。

(1)加糖ブドウ糖液は、「甘み」で、とうもろこしデンプン(コーンスターチ)から酵素反応で「ブドウ糖」を作り、さらにそれをもう一度酵素反応させて(加糖)作るもので(二度行うのは、一度では甘さが足りない為)、砂糖とほぼ同じ糖度でありながら、非常に安価に作る事が出来る。
※「砂糖」はコストが高いのと、嗜好的に「重い」ので使われる事が少ないが、エナジードリンクのような単価が高い飲料には使われる事があるようだ。
※また、ゼロカロリーにする為、「 スクラロース、アセスルファムカリウム、アスパルテーム」などの人口甘味料が使われる場合もあるようだが、コストの関係と、大量に取ると腹を下す事などから主流では無いようだ。

(2)一般に、果物には「酸味」が含まれているので、この酸味を人工的に添加する事でジュースと同等の飲み応えを提供する、通常クエン酸が使われるが、ビタミンCとして「アスコルビン酸」を補助的に使う場合もある、アスコルビン酸を100mg添加するとレモン50個分のビタミンCと言う事が出来る(レモン1個に2mg入っている)。

また、人間の舌は、酸味が含まれると、糖分を感じにくい性質があり、糖分だけで見ると、極めて高い糖度が含まれる事になる。
※「酸味」を加えない「さとう水」の状態では、甘すぎて飲めない程の「甘さ」となっている。(手に着くと凄くベタつくので判ると思う)
※糖度を少なくして、酸味も少なくすると、「パンチ」が無く、「うす味」と感じるので、セールスに結びつかない事から、そのような試みのほとんどは失敗しているようだ。(甘くないりんごやみかんが売れない現実を考えれば良くわかる話ではある)

※100%ジュースは天然なので体に良いと勘違いしている人がいるが、「酸味料」の説明通り、ジュースの場合も糖度は非常に高い、500ccのオレンジジュースで何個オレンジを食べたのと同等なのかを考えれば判ると思うが、ジュースを多く摂取するのは同じように糖分過多となる。
それでも、清涼飲料水よりはマシなのかもしれない。

(3)(1)だけでは甘すぎて飲めないが、(2)を添加する事で美味しく飲める(サイダーの状態)ようになるのだが、色々な香料を添加する事で、嗜好的な飲み物になる。
香料は一般に揮発性の科学物質で、主な成分はエステル系と思われる、最近では、分析の精度と、合成の精度が向上して、殆どの物は人工的に作り出せるようになった。
たとえば、オレンジ香料を使って人工的に作ったオレンジジュースもどきと、100%オレンジジュースでブラインドテストをしたら、「本物」を飲み分ける事が出来る人は殆どいないと思われる。
※エンジンオイルでエステルを添加したものがあるが、フルーティな匂いがするw

(4)最近「無色透明」の清涼飲料水が売られるようになったが、これは販促のネタ切れで、何かのキッカケ作りで新しい事を始めただけで、本流になるとは思えない、オレンジ風味の飲み物ならそれらしい色が着いている方が「説得力」がある、着色料は、合成と天然があり、よく知られている天然着色料は、「カイガラ虫」(赤色)の物か、「カラメル色素」(茶色)だろうか。
合成(?号と表記されている物)は、主に石油精製の過程で出てくる副産物を利用しているようだ。
合成の方が、設計した色彩を作りやすいのと、鮮やかな方がセールスに結びつくので、合成がより多く使われる。
また、「合成着色料」を本気で敬遠する人は全体の2%程度と言われているのと、仮にそれが引き金となって病気になったとしても、メーカーの責任として立証する事はほとんど不可能なので、販売側もほとんど気にしていないようだ。
※動物実験で安全を確認していても、人間に安全なのかは微妙だ。
※「見た目」はセールスに非常に大きく影響する。

(5)水だが、通常、水道の水をさらに精製して不純物を取り除いた「純水」が使われる。
「天然水」が使われる事もあるが、合有するミネラル分と何かが反応して不都合な事が起こる場合を考慮して、限定的に使われる。
炭酸水は、ジュースには無い嗜好的要素があり、好んで使われる、糖分があると、炭酸が抜けにくい効果もある。

清涼飲料水は、たまに飲むのなら問題無いと思うが、「糖分」が非常に多いので、飲みすぎには注意が必要と思う、特に子供には・・
100%ジュースもその性質は同等なので、やはり飲みすぎには注意がいる、一番妥当なのはミネラルウオーターという事になる。
※100%ジュースより、果物を丸ごと食べた方が食物繊維を同時に取れて量も少なくて済むので都合が良い。
※昨今、お茶もかなり怪しくなりつつあり、避けている。

(6)保存料は、流通の過程(温度変化や、製造日数などによる劣化を防ぐ)で、品質を保つ為に添加されている、通常「 安息香酸Na 」などが使われるよいだが、人体にどのような影響があるのかは不明。
以前に、「 安息香酸Na 」と「 アスコルビン酸 」が反応して有毒な「ベンゼン」が生成されている事が判り、製品が回収された事があったようだ。
「ビタミンC」は、それ自体「保存料」として使われている場合がある。

アスコルビン酸はビタミンCとして使われるが、それは「ビタミンC郡」の中の一つで、天然のビタミンCとも異なっている、たとえば、オレンジに含まれるビタミンCとりんごに含まれるビタミンCの組成は異なっており(郡としては同類)、科学的効果も異なるものと思われるが、その微妙な違いが身体的にどのような影響をもたらすのかは判っていないようだが、大雑把に、「色々なビタミンCを取る必要があるだろう」と言う事だと思う。
※人間が自身で合成できないもので、身体の維持に必要な成分。

「食物繊維」として、ポリデキストロース を添加している物もあり「レタス○個分の食物繊維」と言っているが、水溶性の部分のみなので、効果はかなり怪しい。
※みかんを薄皮ごと1個分食べれば、それだけで、かなり便秘には効果がある。

スポーツ飲料も、糖分はかなり多く含まれるので、飲む量に応じて希釈して飲む方が良さそうだが、他の選択枠もある。
※糖分を少なくすると「売れない」現実がある。

スポーツ時の汗で出て行くミネラルを補給するもっとも強力なスポーツドリンクは「あま酒」(さけ粕に砂糖を入れた物はNG)で、米を麹で分解した時にブドウ糖の他、各種ビタミン等、副産物が豊富に含まれる、そのままではやはり糖分が多いので、希釈して飲む事になるが、点滴より効果的と言う人もいるくらい栄養豊富な飲み物で、直ぐに吸収されるので即効性が高い、米の粕が残り、口当たりが良くないのが欠点と言える。
※しょうがを入れて飲むと、甘みが抑えられるのは、経験的に得た知恵なのだろう、酸味料と同等な効果があるのは想像しやすい。

RXマイコン関係ソースコードを整理する

RX66T関係を追加する過程で、RX関連ソースコードを整理した。

今まで、RX24Tに始まり、RX64M、RX71M、RX65Nとサポートデバイスを広げてきたが、RX66Tを加えるにあたり、重複しているファイルや、醜い部分を整理した。
基本はRX64Mとなっている。
・RX64M、RX71Mはほぼ同じ
・RX651/RX65Nは、微妙に異なる
・RX24Tは別品種(割り込み関係が異なる)
・RX66Tは、RX24TとRX64M系の中間的
こんな感じだが、デバイスのレジスター関係は、全てにおいて共通部分が多く、共有出来る。
異なるのは、デバイス(自分のフレームワークでは、ペリフェラルと呼んでいる)の有無。
RX64M、RX71Mは非常に沢山のペリフェラルを持っているが、RX24Tなどは、それに比べて少ないが、中でも「割り込み」ベクターが大きく異なる。
これをどのように表現するかが大きな課題となっていたが、とりあえず、テンプレートにしておけば何とでもなる事が判った。
また、今までは、似ているけど少し異なるような場合は、「#if」などで、分けて凌いでいたが、基本的に各デバイスで、ファイルを分けて対応する事にした。
懸念事項としては、同じコードを全てのデバイス専用ファイルにコピーする必要があり、この場合、一つの修正が、他のデバイスのソースも同じように修正する必要が出てくる・・
一つのファイルで共有して「#if」で細かく分ける書き方だと、かなりトリッキーで読みにくくなる、どちらが良いかは、ケースバイケースで何とも言えないが、保守より読みやすさを優先した。

ペリフェラル:
各デバイスには、「peripheral.hpp」があり、このファイル内で、「enum class」により、「peripheral」型で、利用できるペリフェラルが列挙してある。
この「列挙型」の違いにより、ポートの設定、消費電力設定、割り込み制御など、大まかな動作を分けている、ペリフェラルを直接叩くドライバーは、たとえば割り込みベクター型の違いを考慮する必要が無いように実装してある。

RX24Tのペリフェラルでは、割り込みベクターは、通常ベクターに全て割り当てられているが、RX64Mなどペリフェラルが多いデバイスでは、通常ベクターの数が足りずに、グループベクター、選択型ベクターを新規に設け、それらに割り当てるように工夫されている為、そのままでは同じように扱う事が出来ない。
この違いを吸収して、デバイスドライバーを共通化する為、考えた結果、以下のような実装を行う事でかなりスマートに解決出来た。

//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
        @brief  CMT I/O クラス
        @param[in]  CMT チャネルクラス
        @param[in]  TASK    タイマー動作クラス
*/    //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <class CMT, class TASK = utils::null_task>
class cmt_io {

...

};

上記はCMTの制御クラスの型だが、「CMT」は、CMTペリフェラルクラスで、CMTの制御レジスターを定義したものになっている、通常CMTは0~3まで4チャネルある。
RX64M、RX71M、RX65Nでは、CMT0、CMT1の割り込みは「通常」ベクターだが、CMT2、CMT3は「選択型」ベクターとなっていて、割り込みの設定手順が異なる。

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  CMT 定義基底クラス
    @param[in]  base    ベース・アドレス
    @param[in]  per     ペリフェラル
    @param[in]  INT     割り込みベクター型
    @param[in]  ivec    割り込みベクター
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <uint32_t base, peripheral per, typename INT, INT ivec>
struct cmt_t {

...

};
#if defined(SIG_RX24T) || defined(SIG_RX66T)
    typedef cmt_t<0x00088002, peripheral::CMT0, ICU::VECTOR, ICU::VECTOR::CMI0> CMT0;
    typedef cmt_t<0x00088008, peripheral::CMT1, ICU::VECTOR, ICU::VECTOR::CMI1> CMT1;
    typedef cmt_t<0x00088012, peripheral::CMT2, ICU::VECTOR, ICU::VECTOR::CMI2> CMT2;
    typedef cmt_t<0x00088018, peripheral::CMT3, ICU::VECTOR, ICU::VECTOR::CMI3> CMT3;
#elif defined(SIG_RX64M) || defined(SIG_RX71M) || defined(SIG_RX65N)
    typedef cmt_t<0x00088002, peripheral::CMT0, ICU::VECTOR, ICU::VECTOR::CMI0> CMT0;
    typedef cmt_t<0x00088008, peripheral::CMT1, ICU::VECTOR, ICU::VECTOR::CMI1> CMT1;
    typedef cmt_t<0x00088012, peripheral::CMT2, ICU::VECTOR_SELB, ICU::VECTOR_SELB::CMI2> CMT2;
    typedef cmt_t<0x00088018, peripheral::CMT3, ICU::VECTOR_SELB, ICU::VECTOR_SELB::CMI3> CMT3;
#endif

上記のように、テンプレートパラメータで「INT」(割り込みベクター型)を設ける事で、cmt_t クラスは、どの型のベクターなのかを意識しなくて済むようになっていて、「typedef」だけで対応できる。

cmt_io クラスでは、ベクターの型を元に、割り込み設定の方法を分ける事ができ、面倒な「#if文」から開放される。
また、C++ では、ベクター型の違いによる分岐は、コンパイル時に決定できるので、最適化により、余分の分岐一切が無くなるので、速度の面もリソースの面も好都合となる。
このような仕組みは、C言語だと、スマートに実現する事は難しい、C++ が組み込みマイコンのプログラムに向いた言語である事の一例であると思う。
※C言語プログラマは、#define で実現可能と思うかもしれないが、#define では、正確で厳密な「型」チェックは行われないし、構造的や論理的に誤ったコードをエラー無くコンパイルしてしまう可能性があり、テンプレートとは雲泥の差がある。

C++ のテンプレートでは、構造的や論理的に誤った構造は、「ほぼ」エラーになるので、最初の設計が必要十分な要素を詰め込んであれば、自ずと正しい方向に誘導してくれる感じがある。
大雑把に言うと、コンパイルエラーが無くなったら、プログラムも正しく動く事が多いとも言える。

自分が実装したソースでは、「#define」でマクロ的な定義を行う事は一切していない。

CPが最高に高いRX24T

100円マイコンのR8Cは別格としても、安くても十分機能があり、それでいてパフォーマンス(馬力)があるマイコンが必要な場合がある。
ルネサス社が発表しているマイコンで、どれが、コスト、パフォーマンス、機能が優れているか、検討してみた。
※実際は、かなり前に検討したものだが、未だにCPの高さトップに君臨している。

ちょっとした物を作る場合でも、昔には戻れない・・
※ファミコンやゲームボーイの時代はROMが高かったので、より多くのリソースを積み込む為、データ圧縮や、手動による最適化を行ったものだ、ハードウェアーがアップグレードして、記憶媒体がROMから、RAMになってCD-ROMなどの光学媒体になってから、もう容量の事で悩むような事は少なくなり、開発環境もアセンブラから高級言語に移っていった。
※PS2、EEのようにアセンブラでチューニングしなければ性能が出なかった例外的なハードもあるのだけど・・

今は、時代が違う、それでも、組み込みマイコンの場合、容量は有限だし、価格の安いデバイスはRAMも少ない、それゆえ、小さな工夫はしないとならない。
「数」を沢山作るような製品とは異なり、DIYでは機能を実現できれば、コストは度外視しても良いが、開発がやりやすいとか、リソースの再利用とか、便利で短時間で完成させる事が出来る方が良い。
C++ のテンプレートライブラリを多様したペリフェラルフレームワークは、Arduino のスケッチを書くより簡潔で判りやすく、最適化されたコードを作る事が出来る。

8/16ビットマイコンは、CPが高いと思うかもしれないが、実際はそうでは無い(ルネサス社のラインナップでは・・)、また、個人で数個単位で扱う場合と、大手が数百個、数千個、数万などスケールが異なる場合は、全く異なる価格帯になると思われるが、実際、数個のオーダーで個人が買う場合には、状況が異なる。
また、8/16ビットマイコンは、通常ポインターが16ビットで、大きな容量にアクセスする場合は、その都度、「方法」を選択してトリッキーなコードを実装しなければならない。
意外な盲点として、RXのような32ビットマイコンに比べて、同じプログラムでも、コードサイズが大きくなってしまうケースは良くある、又、内部レジスターは16ビットなので32ビットの演算では、さらに遅くなるので、場合により汎用のクラスは改修する必要もある。
32ビットマイコンは、プログラミングにおける基本的な制限はほぼ無いので、開発のしやすさや、リソースの再利用性から、少々コストが高くなっても選択したい理由となる、それでも@1000くらいだと、少し考えてしまう・・

マイコンの選択は、単純に、フラッシュの容量と内臓RAMサイズ、動作周波数などだが、マイコンの販売価格を見るに、非常にCPの高い製品がある事に気がつく。
※ARMやPIC32の価格には到底太刀打ち出来ないのだが、自分は、RXマイコンのソフトウェアー資産が豊富にあるので、ARMやPIC32よりも、RXマイコンを選択する事は十分メリットがある。
※まぁ、AVR、ARM、など各社マイコンは使った事もあるにはあるが、ルネサス社のマイコンだけにフォーカスしている人は少ないかもしれない。

RX24Tは、ブラシレスモーターのベクトル制御に特化した製品のようで、多分、エアコンや冷蔵庫などに使う目的でデザインされラインナップされた物と思う、イーサーネットやUSBは内臓していないが、他のペリフェラルが豊富で高機能なマイコンだ、そしてそれなりに安い。
※コード256K、RAM16K、データフラッシュ8K、LQFP100(10個購入時@594)
chip1stop「R5F524TAADFP#30」
※10個購入時だけど、DIY用でも10個くらいは使うだろって事で勘弁してほしい~
※RL78の256K版(@400)と比較しても、馬力を考えるとお得感がある。
※32MHzでFPU無しのRX220より安い。
※RXマイコンは、意外と命令効率が高いので、128KBの製品でも十分かもしれないが、価格差が僅かなので、256Kの製品リンクを張った。
※最近、Bバージョンが発売され、CANが使えて、RAM容量が2倍の32Kになった製品もある。(自動車向けか?)
#コード256K、RAM32K、データフラッシュ8K、LQFP100(10個購入時@657)
chip1stop「R5F524TBADFP#31」

  • RXv2コア
  • 80MHz動作(80MHz動作では、プログラムフラッシュにはウェイトが入る)
  • DSP命令(有効に使うには、アセンブラで実装する必要がある・・)
  • FPU(各種32ビットの浮動小数点命令)
  • ベクトルの正規化に威力を発揮するFSQRT(平方根)命令
  • 2.7V ~ 5.5V の単一電源動作
  • 普通に低消費電力
  • 12ビットA/D(最大1uS、3ユニット)
  • RSPI(1チャネル)※SDカードもかなり高速にアクセス可能
  • SCI(3チャネル、簡易SPI、I2Cが使える)
  • I2C(1チャネル)
  • DTC(データトランスファーコントローラー)
  • 高速で、豊富なタイマー郡(最大80MHz動作)
  • コンパレーター(4チャネル)
  • 必要十分なI/Oポート数
  • BバージョンのみCANインターフェースを備える
  • コードフラッシュの書き換え回数(1000回と少し少ない・・)

これだけの特異な特徴があり、他のRXマイコンと基本的にペリフェラルは共通。
ちょっとした用途ならこれで十分と思う、また、フラッシュROMの書き込みはシリアルで行うが(J-TAGはサポートしないが、エミュレーター専用端子FINEを持っているので、対応したE1でも当然書き込めるしデバッグもできる)、何故か、RX64Mなどと異なり、かなり高速に書き込めるので、シリアル書き込みでも開発ではあまり不自由しない。
※自分の開発スタイルでは、コードのブレークは必要としない。
※Apple、Linux、Windowsで開発出来る。
この価格帯にしては、浮動小数点がかなり強力なので、ジャイロや加速度センサーを使った姿勢制御(ロボットなど)にも、かなりマッチすると思う。
タイマーも非常に多く使えるので、RCサーボを沢山動かすのにも向いている。
多少残念なのは、コードフラッシュの書き換え回数が1000回と少し少ない。
それでも、ちょっとしたDIYボードに最適と思う。

おなじみ、レイトレーサーを走らせてみたが、約1.2秒くらいでレンダリングする。
これは、160MHz動作のESP32の10倍以上高速となっている、FPU内臓は伊達では無い。
※ピクセルの描画コストを5マイクロ秒としている。
※ESP32でのレイトレーサー速度は、ネットでの記事を参考にしており、RXマイコンに比べてあまりに遅い、ESP32はFPUを内臓しているので、ベンチマークの方法に問題があるかもしれず、単純に比較するのはフェアではないかもしれない事を付け加えておく。
200MHz動作のARMでは0.6秒との事なので、妥当なスピードと思う。

デバイスは以前に10個ほど買った(Aバージョン)ので、自分用にでも汎用ボードを作ろうと思っている。
又、折角のDSP命令も使わないのは勿体無いので、gcc 向けアセンブラ・ライブラリを実装しようと思っている、これはRXマイコン全般で使えると思う。

GitHub の「主要言語」

GitHub のホームを開くと、各プロジェクトに主要言語が表示されるー

自分の場合、以前は「C」、「C++」などで、どのようなロジックで表示されてるのか疑問だった。
調べると、コミットしてあるファイルの拡張子などから、集計を取り、一番多い「言語」を表示している事が判った。
「主要言語」が「C++」でも、「C」のライブラリなどがプロジェクトにコミットされていて、単純にCのソース数がC++ソース数を上回ると、「C」と表示されてしまう・・
※自分のプロジェクトでは、C++はヘッダーのみの場合がほとんどで、ソースは必要無いので、ソースの数は1/2で、評価が意図と異なる。
githubの検索などでは「言語」をキーに検索する事もできるので、これは、意図と違う結果になってしまう。
そこで、調べると、「.gitattribute」ファイルをプロジェクトのルートに置いて、このファイルで、集計を除外する事で、「主要言語」の評価を変えられる事が判った。

RTK5_NESEMU/emu/* linguist-vendored
ff12b/src/* linguist-vendored
zlib/* linguist-vendored
libmad/* linguist-vendored
jpeg-6b/* linguist-vendored
RX65x/drw_2d_ver1.02/* linguist-vendored

たとえば、「RX」プロジェクトは↑のように、ライブラリを除外してある。

これで、「主要言語」の評価を「C++」に出来た。

※上記の「バー」をクリックすると、ファイルと言語のプロパティが表示される。

さらに、「言語」をクリックすると、どのファイルがその言語と認識されているか詳細が表示できるので、「意図」と合わないファイルは、「.gitattribute」で、細かく指定できる。

中華製VFDで問題発生(CNC6040)

CNCの要と言えるスピンドルモーター、80mm直径、ER16、水冷式を購入、それに合わせてVFD(インバーター)も購入(HY01D511B)、物が届いたので、早速火入れをしてみた。

ところが、超低速では回るものの、周波数を上げると10Hzくらいで停止してエラーコードらしきものが表示され強制停止する。
「E.oL.A」
このエラー、マニュアルを見ても載っていない・・・
設定が悪いのかと思い、色々変更してみたが、同じようにエラー表示で停止する。
不具合の問題を切り分ける為、別のVFDに接続して回してみた(やはり中華製)、こちらでは、ギュンギュン回る、やはりVFDの初期不良のようだ、VFDの横にテクニカルサポートのメールアドレスが印刷してあるので、メールで不具合を聞いてみたら、モーターの型番を教えて欲しいとの事で、写真を撮って、メールを返した。
※英語の文書を作るのは翻訳エンジン頼みなので、イマイチだ・・・
今、ココ・・・
初期不良だとしても、送り返す手間や送料など、かなり面倒な事になる・・
まぁ仕方無い、それが中華品質だ・・・

そもそも、日本製のインバーターだと、100Vで使えるものが少ないうえに割高だし、少し調べた限りでは、100V、1.5KWはラインナップしていない。
かと言って200V用を買って、屋内配線を200V対応にするとか、かなりハードルが高い、昇圧トランスを買うにもコストが高い・・・
どうしたもんか・・・
まぁ、対応がアレな場合、修理するしか無いと思える。
それか、インバーターを自作するしか無いかも・・・

エラー表示のVFD
問題無く動作するVFD、非常に概観が似ているが、違うメーカーのようだ・・・

動作するVFDは、RS485で制御する事が出来ないようなので、追加で買ったのだが「ハズレ」を引いたようだ・・・

「RX65N Envision Kit」の紹介

Arduino や ARM には、よそ見をしないで、ルネサス製マイコンのみを扱ってきたが、
最近、ようやく、面白そうなガジェットが出てきたー

ARM界隈では、コスト度外視、メーカーでなければ出来ないような評価ボードを色々
出していて、そんなのが出る度に、ARMerたちがそこに注力するとゆー構図があった。

自分は日本人なので、「日本製マイコン使え!」と言ってはいたが、中々胸を張って、
「これはイイですよと言えない」状況が続いていた。

そんな折、マルツさんのメールニュースで、「Renesas Synergy Target Board Kit」
のアナウンスがあり、ARMベースのルネサスマイコンで、興味は無いのだけど、
リンクを観に行った。
そこで、見つけてしまい、思わず購入してした。
※自分の好きなRXマイコン、120MHz動作、液晶付、など目一杯盛り込んでいて
5000円!、しかも、何かガジェットを作った場合に、コンパクトにまとめられる
ように配慮された基板サイズ。

このボード2017年11月頃に発表されていたボードのようだが、丁度仕事が忙しく
情報を漏らしていた。

このボード、海外のソフトウェアーベンダーが音頭を取り、製作したようだが、この価格
でこの内容は、コストパフォーマンスが良すぎる。
しかも、インサーネットやSDカードを後から付けられるようにもなっているし、かなり
練られた設計となっていて好感が持てる。

ボードの特徴など気がついた部分を列挙する。
・RX65Nマイコン120MHz動作
・2MBの内臓フラッシュ
・256KB+320KBのRAM
※このメモリー空間は別なので、液晶のフレームバッファで、320KBは利用不可と思う。
・インサーネット対応「N」バージョン
※物理層PHYは乗っていないが、後から乗せられるようにパターンがある!
※25MHzのクリスタルは乗っているので、PHY(LAN8720A)、パルストランス
付コネクタ(表面実装タイプ)を取り付けるだけと思う。
・エミュレーター(簡易バージョン)内蔵なので、フラッシュの書き換えや開発が容易。
・480×272ピクセル、タッチ機能付液晶付
・RX65N内に、液晶の制御と、描画エンジンなど内臓(パフォーマンスは現在不明)
・拡張コネクターや、未使用端子の取り出しランドなど多数。
・SDカード接続用パターン有り
・マイコン用3.3V電源用に、同期整流式のDC/DCコンバーター
※5Vから降圧で動作し、効率が高い(安易なシリーズレギュレーターでは無いのが凄い!)
※液晶用バックライトもDC/DCコンバーターを内臓
・USBコネクター装備(RXマイコン用と、エミュレーター用)
・モード切替用、DIPスイッチ4ビット分(1ビットはユーザー利用可能)

今は、仕事が忙しいのだが、これをベースに色々な物を作りたいと思う。

BOSCH(ボッシュ) 高圧洗浄機 AQT33-11 ホースジョイントの改造

以前に、ボッシュの高圧洗浄機を買ったのだけど、賃貸の水道は勝手に使えないと判り、
放置してあったが、一軒家に引っ越したので、水道を自由に使えるようになった。

ただ、この高圧洗浄機のホースジョイントは、ニップルが特殊な形状になっており、専
用の物で一般的な「タカギ」製と互換性が無い、それでは、不便なので、改造してみた。

良く調べるとニップルの先端が、数ミリ余分に出っ張っているだけで、これを削ると、
タカギのジョイントが使えると考えた。


※赤いジョイントが、ボッシュ専用、透明(ポリカーボネイト)なのが、高圧洗浄機の
「ニップル」。
※先端を切断、削った後。

そこで、先端を削ってみたら、無事フィットするようになった、これで、タカギ製の、
色々なアタッチメントも使える~