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

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

DELL U2718Q の修理(その2)

電源が豪華

このモニターの電源はかなり豪華な創りでコストをかけているように思う。


モニターの要は、液晶よりも電源なんだと実感する。

こんなに豪華な創りの電源は久々に見たー
※AppleのACアダプターを分解した時にも、使っている部品や構成など、凄く感心したが、それと同等くらいの感動がある。

AppleのACアダプターの場合は、コンパクト化で、ありとあらゆる空間を有効に活用する為、3次元的に部品を配置して、全く隙間が無かった。
この電源はスペースには余裕があるので、一見、部品の配置はスカスカだが、裏面には、かなり表面実装の部品を配置してある。

使っている部品もグレードが基本的に高いように思う。

消費電流はそんなに多く無いけど、ちゃんとPFC対策電源になっている。

制御ICの型番は、削ってあり、消されている。

最終段は 18V で、そんなに電流は流れないけど、FETによる同期整流回路を採用しているようだ。

この電源なら、簡単に故障しないだろうと思われる。
※どこぞの中華電源とは、全く別次元のグレードw


コンデンサが到着

コンデンサが到着したので、部品をハンダ付けするものの、パターンが広く、熱が拡散して、思ったようにハンダ付け出来ない。
※秋月の送料は、1万円くらいじゃないと無料にならないが、500円くらいなので、他に欲しかった部品を少し加えて、通販した。
それでも、秋葉原に行って帰ってくるだけで、2500円くらいかかり、往復6時間は電車に乗る事を考えると、2、3日かかってもかなりマシだ・・・

鉛フリーのハンダも、このような場合にはハンデとなると思うが、それにしてもかなりヘタクソ・・・
でも、一応、ちゃんと付いている事を確認した。

うっかり外した電源コネクタ近くの電解コンデンサは、頑張っても、ハンダを吸引出来なかったので、ストックしてあった物を無理やり付けた。
※220uF、25V

一部のコネクタを壊していた

最初に分解する時、この部分のフレキコネクタを壊してしまった、よく見えなかったのが原因だが、かなり気を付けていたつもりなので、自分的にかなり精神的ショックが大きい。

コネクタを交換する事も考えたが、これは、液晶パネルの温度を計っているらしいので、まぁ、無くても問題無いと判断した。
一応、ケーブルを挿して、隙間に厚い紙(名刺)を挟んで、何とかなったと思う。

このフレキコネクタと同じ物を探すのも大変そうで、通販に日数がかかると思うし、交換の手間もスキルもかなり高い。

あすか修繕堂

と呼ばれるネットショップ(YouTubeに修理の動画が沢山ある)に、

あすかリムーバー

「低温ハンダ」が紹介されている、これを使えば、取り外しは可能と思うが、3cmで600円と高価だ・・

組み立て

いつも後悔するが、分解する前に写真を撮っておくべきなのだが、今回も忘れている。

分解の様子は、その時は覚えているが、数日たつと、どうなっていたか忘れている・・・
組み立ては、パズルのようだが、そこまで難解ではなかったので、何とか元に戻せた。


一応直ったようだー

電源を入れてみるー

電源ランプが点いて、画面にロゴが表示された、どうやら直ったようだー


一応、MacBook Pro 13 に接続してみた、問題無い。

直る事が判っていれば、モニターを注文しなかったのだが・・・

折角直ったのだから、メインモニターに戻すべきなのだが、買ったばかりのモニターなので、迷うところ、一番の問題は、間違って解像度が低いモニターを買ってしまった事だ、同じ解像度なら、新品モニターを迷わず使うのだが・・・

でもまぁ、やはり解像度が高い以前のモニターを使うべきなのだろうなぁー・・・

P-LAP III のセンサーを修理

今年の「もて耐」は3時間

今年は、縮小プログラムで、3時間耐久となりました。

自分が参加している「Blue Eyes」は、今年、超有名レジェンドライダー3人がゲストとして参戦します。

世界的都合で3時間耐久になってしまったものの、お手伝いで参加出来るのは非常に光栄でもあります。
※来年は、是非ライダーとして参加したいです。

「レジェンドライダー」は、「もて耐事務局」が、正式なエントリーリストを公開するまでお待ちください。

昨日は公開練習日でした

今まで、二回あった公式練習日は、両日、天気が悪かったのですが、昨日は、晴れて、ドライで走れたようです。
Blue Eyes のメインライダー(五十嵐さん)が一番時計の15秒9を出していました、流石ですーー

そして、恐るべきレジェンドライダー、実線を離れて30年、ほぼバイクに乗っていなかったのに、初めてのコース、初めてのマシンで、数十分乗っただけで・・・(69歳)
40秒くらいから始まり、周回毎に少しづつタイムを削っていきますー

ですがー、今回はフルグリッドで、台数が多く、クリアラップはほぼ取れない状況、そして、スキルの差が大きく、極端に遅いライダーもいます。
その中で、ほぼ毎周同じくらいの割合でタイムを削っていく・・・
確か、全体で8周くらいしたと思いますが、ベストを更新しなかったのは、2周くらいだったと思います。
そんな事が出来るものなのか、魔法のようで、非常に感銘を受けました。
車載カメラの映像を見ると、レコードラインにレールがあるかのように、綺麗にトレースしています。

1、2コーナーで観ていた人が、あまりにリラックスしていて、全く無理をしている感じがしないと言ってました。

流石、世界戦で優勝した実績は伊達ではありません・・


他のレジェンドライダーも凄くて、ここでは書ききれません、別の機会に・・・(濃いライダー三人もーー)



CBR-250RR レースベース車は、モノブロックと、JB-MAGTAN で武装!
そして、多分、「初」のヨシムラマフラー

P-LAP のセンサーが壊れてる

ライダーには気の毒でしたが、P-LAPのセンサーが壊れていて、走行タイムは、サインボードでした・・・

直るかどうか判らなかったけど、預かってきました。

センサー基板が腐食している

サーキットには、マグネットバーが埋設してあり、それを通過する事で、ラップタイムを計測する仕組みがあります。
※これは、レースで使うトランスポンダー(ループコイルゲート式)とは異なるもので、どこのサーキットでも大抵はあるようです。

センサーは、磁気を感知して、ラップタイムを計測します。


センサー部はシリコンが充填されており防水加工されていますが、不完全で、水が浸入して、腐食したようです。

よくよく観察しましたが、基板のパーターンは生きていたので、クリーニングして、「追いハンダ」してみました。

直ったようです。

センサー部にマグネットを通過させると、ラップタイムを計測します。

P-LAP III は区間タイムを計測可能

昨日知ったのですが、このラップタイマーは区間タイムを計測できるとの事。

えーーー、どのような原理なのか?

聞いた話では、
「区間タイム計測モードでは、4回計測で、1周とする」
と聞いたのですが、そんなハズはありません。
自分は、P-LAP I の壊れたセンサーをもらい、直して、自作の計測器で使っていますが、普通に1周で1カウントでした。

そこで考えられる事は、P-LAP III のセンサーはアナログ式で、センスした、磁気の強さを観ているものと思います。
区間タイム計測用のマグネットバーは、ラップタイム用より、磁力を下げているのだろうと思いました。
それなら、ラップタイムと区間タイムを分離計測できるものと思います、そして古いラップタイマーでも今まで通り計測できるものと思います。

山歩き始めたー

最近体重ヤバイ

大月に越して、自宅で、作業するのが続き、外にあまり出ない事が続いたら、体重(腹)がヤバイ事になっていた。
以前は、出向とかしていたので、週の半分くらいは、電車に乗り通勤している事もあったけど、ここ最近、自宅で全て完結するので、外に全く出ない日が殆ど。

体重を計ったら、8キロくらいは増えている・・・
これはヤバイなぁーとゆー事で、少し運動して燃費の悪い体作りをする事にした。
※食事を減らすのは良くない。
※山歩き用のシューズを買っておいた。

灯台下暗し

良く利用する駅「鳥沢」では、登山する感じの服装な人を良く見かけて、へー「登山するような処が近くにあるんだー」って思った、興味無かったのでスルーしていた。

調べると、自宅の前には、百蔵山、扇山といった1000m台の山がある。
この位の標高だと(鳥沢駅が既に300mくらいの標高)、スキルに関係なく、散歩感覚で山歩きでき、天気が良ければ頂上から、富士山も見えて中々のスポットだと知った。

  • 晴れていても、富士山方向は、雲がかかって見えない事が多い。
  • 適度な斜度があり、登り、下り共、足腰を鍛えるのに丁度良い。
  • 小学生くらいの女の子や、年配の人なども見かける。

一回目:百蔵山(1003m)アタック

  • google マップでは、登山道は表示しないので、国土地理院の地図で、登山道を一応確認した。
  • 宮谷地区から、山頂に至る登山道がある事が判り、とりあえず、そのルートで登ってみた。
  • 頂上では、時間が遅かったので、富士山は見えたが、それなり。
  • 頂上では、まだ元気は残っていた。
  • 下りは、同じルートを通るのはシャクなので、猿橋駅方面に抜けるルートを通った。
  • 1時過ぎくらいに家を出て、戻ったのは7時前くらい、今の季節真っ暗だった。


登り3時間強、下り2時間半くらいで、トータルで6時間くらいかかり自宅に戻ってきた・・
最近こんなに歩いたのは久々で、ヘロヘロになったー、下りは、足全体が筋肉痛でガクガクして痛くてそろそろ歩いてた・・

  • もっと楽な工程と思っていたが、意外にキツイ。
  • 普段、バイクや車ばかりで、すっかり足腰が衰えているようだー・・・

二回目:扇山(1138m)アタック・・失敗

今回は、距離的には百蔵山より長いので、午前10時過ぎくらいに家を出た。

うる覚えで、適当に登山道らしき道に入ったら途中で、小川の横を登り、宮谷地区の水の取水場らしき場所に出る。
コンクリートで出来た水槽のような物があり、トタンで塞がれ、上に重石が置いてある、管理されているようだー。

大した距離では無いけど、戻るのは何となくイヤだったし、小川の脇に登れそうなとこがあったので、そこを登れば、登山道に合流するだろうと進んだ。
※この判断が散々な目に合う・・・

それなりの斜面を、登っていくと、「これは登れないな」とゆーよーな崖に行き着く、仕方なく、回り込みさらに進んで行く。
意外と、行けるので楽しくなってガンガン進む。
※かなり「山」を舐めてた・・・

そんな事を繰り返していると「稜線」のような場所に出て、これを登れば、登山道に出るんだろうなぁーと登って行くと、断崖だった・・
これはヤバイと思い、何となく獣道らしいとこがあるとこに回って進んでいったが、途中でそんな道も無くなり、谷で、進むことも戻る事も出来ない状態に・・
かろうじて、下る事は出来そうなので、仕方なく下って行った。
「落ちたら死ぬかも」くらいの場所に遭遇するも、冷静に、ルートを判断して、下っていった。

降りて行くと、谷になっているので、水が沸いて集まって小さな川になっているが、流量は僅か。
岩がゴロゴロしていて、非常にあるきづらいが、安全な方法でどんどん下る。

下って行くと「砂防ダム」が現れた、このまま下れば戻れると思ったが、高さがあり降りれないようなとこもあるので、一旦避け、谷から森に回って、歩けそうな場所を下っていった。

森の中は歩きやすいが、小川の流れている谷から離れだしたので、修正しながら下っていった。

最初の登山道に入ってから休みながら3時間以上、ウロウロしている。

小川から、大分離れてしまったので、一旦小川の方向に戻ってみたら、登山口の近くまで戻ってきていた。

教訓:
自然の山は複雑で、高低差が激しく、一筋縄ではいかない、ハイキング気分でどうにかなるような場所ではない。
これに懲りて、「探検」は程々にしないと・・・

三回目:扇山(1138m)アタック

二回目の失敗で、ジーンズを破いてしまい、手も岩で切った。
それで、山歩きに適したパンツを Amazon で買っておいた。

今回は、登山道を普通に登って、変な冒険をしないと誓った。

事前に、地図を見て、登山道の場所を十分確認しておいた。

今日は天気が良く、暖かくなりそうなので、7時20分くらいに家を出た。

ただ、宮谷方面から、登る登山者はほとんどいない(鳥沢駅と猿橋駅の中間くらいなので)ようで、登山道は荒れていて、整備されていない。
倒木が多く、迂回したり、道が複数あり、どっちに進んだら良いか判らない場所もある。
登山道には、要所にそれらしい目印(ピンクのテープが木に巻いてある)があるので、間違う事は少ない。

かなり急な斜面もあったが、何とか、百蔵山と、扇山を結ぶ登山道にちゃんと出た。
方向感覚が狂っていたのと、「扇山」標識の矢印が無かったので、百蔵山方面に歩いてしまい、途中で気が付いて、引き返した。
※これで40分くらい損をした。

扇山へのルートは、稜線と言えども、幾つか山を越え、かなり急な斜面もあり、既にかなり体力を減らしているので、休み休みで中々進まない。
この日は土曜日だったので、何人かの登山者に抜かれていった。

鳥沢駅から扇山の登山ルートの分岐手前の急な斜面で、霜があった、最近昼間は暖かいが、昨日は氷点下まで下がったのだろう。

やっとの思いで、山頂に付いた頃には11時40分くらいで、頂上には、数組の登山者が休憩していた。
今日は、天気は良いが、富士山方面には雲があり、富士山は見えないのが残念だった。
※大月に住んで判ったが、朝は富士山が見えても、昼に見えない事は多い。

自分は、500ミリの水二本とタオルくらいしか持っていないが、一般の登山者は、充実した装備と服装で固めている。
頂上でお湯を沸かして弁当を食べているグループがいて、次来る時は、弁当くらい持ってこようと思った。

既に足がガクガクで、厳しい状態だが、お腹も減っていて、何か食べたい、しばし休んで、下山する事にした。

下山ルートは、「鳥沢駅方面」こちらの方が距離が短く、楽だと思う。

登りと下りでは、使う筋肉が違うが、半分も下ったら、「下り用筋力」も限界気味で、休み休みゆっくり降りていった。
でも、登るより早く楽だった。
※登りの半分くらいの時間で下る感じ。

途中、小学生くらいの女の子を含んだ家族連れとすれ違い、軽々と登っていく様を見て、自分の体力の無さを実感した。

1時30分くらいに、登山道の入り口くらいまで降りてきた(大月カントリークラブの入り口)。
自宅は宮谷なので、鳥沢駅には行かないで、掛川ウェルネスパーク方面に下っていった。
ここには、うどんなどの食事をする場所がある。
30分くらいで、食堂までたどり着いて、やっと食事にありついた。
しばらく休憩して、自宅に戻ったのが3時くらい、自宅で甘い物を食べて、5時前くらいまで寝てしまった・・

山歩きに便利なアプリ

国土地理院の地図には、登山道が破線で示されている。

google マップでは、車が通らないような道は、詳細な情報はほぼ無い。
※人気の登山道などは、ストリートビューで確認出来る場合があるようだ。

ネットでは、当然ながら、接続しないと地図を見る事が出来ない。

しかしながら、探すと、山歩きに適したアプリが色々見つかる。

今回は、「ジオグラフィカ」を紹介する。
※開発者自ら、テストを行っているようで、どのような機能が必要で、利便性などに関して、非常に良く研究され、開発されている感じがする。

この手のアプリは、事前にネット接続して、該当する地図を一時的に貯めておく事で、ネット接続が出来ない状況でも、地図の確認が出来る。
また、携帯の GPS と連携して、地図上に自分の位置を示す事が出来る。
ただ、バッテリーの消費は、それなりにあると思うので、モバイルバッテリーなどの用意は必要なのかなと思う。
基本は無料だが、保存できる容量は100メガバイトに制限される、機能制限を外す場合、960円の課金が必要だが、アプリの完成度を考えると「安い!」と思う。
※100メガでどのくらいの範囲を保存しておく事が出来るか、判らないが、数時間で往復出来る範囲はカバー出来るものと思う。

※扇山の山頂では、ギリギリアンテナが立つ(4G、KDDI)状態だった。

RXマイコン・マスストレージドライバー

USB メモリーのアクセスが出来た

細かい内容は、Qiita に投稿、参照して欲しい。

RXマイコンで実現するUSBホスト(USBメモリー編)

USB メモリーのR/W速度を一応簡単に計測した。
記事にあるように、250KB/秒くらい出ている。

これなら、オーディオ再生にも使えそうだ。

SDカードと同時に使えるようにしなければならないので、FatFs 関係は色々改修する部分が出てきそうだ。
ルートにドライブレター的なパスがあれば十分と思う・・

また、USB ハブ経由の場合や、複数の USB メモリを繋いだ場合など、色々と複雑な感じ。

RX64M や RX71M には、USB チャネルが二系統あり、片方は、ハイスピード対応(480MBPS)なので、どのくらい速度が出るのか興味があるところ。
※そう考えると、RX72M の場合、ハイスピード対応では無いのが残念。

ワードプレスでマークダウン記法対応のプラグイン導入

今回の記事とは関係無いが、ワードプレスもマークダウン記法で記事が書けるようにプラグインを導入した。

最近、GitHub が開発のキーになっているので、ドキュメントは、マークダウンで書く事が多くなり、慣れもあり、マークダウンで統一出来るのはありがたい。

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マイコン全般で使えると思う。