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)で、米を麹で分解した時にブドウ糖の他、各種ビタミン等、副産物が豊富に含まれる、そのままではやはり糖分が多いので、希釈して飲む事になるが、点滴より効果的と言う人もいるくらい栄養豊富な飲み物で、直ぐに吸収されるので即効性が高い、米の粕が残り、口当たりが良くないのが欠点と言える。
※しょうがを入れて飲むと、甘みが抑えられるのは、経験的に得た知恵なのだろう、酸味料と同等な効果があるのは想像しやすい。

RX65Nボードの設計(その1)

RX66Tが発表になり、デバイスが入手出来るのを待っていたが、なかなかデバイス単体で購入できる状態にならないので、RX65Nのボードを先に作ろうかと思い作業を始めた。
※169ピンのRX65Nを5個購入した(@1560)
※ついでにPFCコンバーター専用ICなども購入、こちらは、CNC用インバーターなどの前段に使う予定でいる。

RX65N Envision Kit はまぁ良いのだが、惜しい部分がある。
・バッテリーバックアップがない
・RTCのクリスタルが接続されていない
・付属LCD(480×272)の視野角が狭く、表示品質がイマイチ
・無線LANがない
・SDRAMがない
・オーディオ出力がない
・バッテリー駆動系の部品などが無い
・後載せ部品など基本的な仕様
などで、本当は 最高速で動作する 240MHz の RX71M の方も捨てがたいが、DRW2Dコントローラーが魅力なので、とりあえずRX65Nで進める。
ピンアサインは RX71M、RX64M とほぼ同一なので、少し工夫すれば乗せかえる事も出来そうだが、RX71M用は、また基板を作れば良いだろう。

無線LANは、コストで有利な ESP8266 や ESP32 を繋げておけば良さそうだが、天邪鬼なので、マイクロチップ社の WiFi モジュール ATWINC1500 を乗せられるようにしておく予定でいる。
※スピードを評価したい事もあるし(ESP8266より高速に通信できると思う)、SPI 接続の代表的な物を使いたい、ただ、コストは ESP に比べると3倍くらい高い。(個数を沢山買えば、1.5倍くらいにはなりそう・・)

EDA ツールは KiCAD を使っているのだが、最新バージョン(5.02)をインストールしたら、非常に機能が追加されており、シンプルで使いやすくなっていて驚いたー(素晴らしいとしか言い様がない!)
※ただ、4.x系とファイルの互換で問題がありそうで、4.x用ファイルを読み込めない場合があるようだ・・

ボードのコストは、Wifi、SDカードインターフェース、100BaseEthernet、256Mbit SDRAM、LCD などなど乗せても、部品代だけなら Envision Kit と同等くらいで収まる。

ただ、問題もある。
実際に設計を始めて問題になったのはピン定義だ、SDRAM(16ビットバス)、SDHI(SDカード)、Ethernet、LCDなど、169ピンデバイスで、これらを全部使うピン定義を考えたが、信号が被って、同時利用は出来ないようだ・・・

LCD のバスを「8ビットシリアル」にする事で何とかアサイン出来る事が判った、ポートは余っているのに、そこにアサイン出来ない(定義が無い)のは「何で」ってなる・・
※8ビットシリアルを通常の RGB バスに変換するのに8ビットラッチを2個は用意する必要があると思う。

将来的にはマイクロコントローラのピン定義は、全てのピンで全てのペリフェラルを自由に割り当て出来るような構成になるものと思うが、LSIの設計段階で、それが大きなハードルになる場合もあるのだろう、現状では、そのような柔軟な設定が出来るマイクロコントローラは少ない。
そこまでの柔軟性は必要無くても、最低限、主要な機能を使う為の標準的定義が仕様として出来ないのは如何なものか・・・

KiCADのシンボルや footprint は、ネットを探すと自分の欲しい物はほとんど入手できる場合が多いが、部分的に気に入らない場合や、ライセンスなどの問題があったりして、一つや二つなら自分で作っても大した手間ではない。
また、5.x系の為、4.x系のライブラリが読めない事があるようだ。
※秋月電子とかで、そのような物を集めて、またはサービスとして作成して公開して欲しいと思う。
自分が使う部品は、GitHub に上げてある。
https://github.com/hirakuni45/RX/tree/master/KiCAD_lib

パルストランス内臓イーサーネットモジュラージャック RJ-45

回路設計と言っても、ルネサス社が出しているサンプルボードの回路図で必要な部分を流用すれば良い、最近は基板を作るハードルが下がっているので、失敗しても気軽に作り直しが出来る、ただ、やはり4層基板で作りたいので、それほど安くは出来ないかもしれないが、日本国内の基板屋に比べて1/4~1/10程度だろうと思う。

MicroChip ATWINC1500-MR210PB WiFiモジュール

LCD は秋月で売っているものの、タッチパネルが付いていないので、AliiExpress でタッチパネル付きの物を購入した、送料入れて22ドル程度だったが、表示品質は高そうだ、秋月で売っているものとバックライトLEDの仕様が異なるが、「CAT4238」を使えば、流れる電流値の設定変更だけで対応出来そうではある、LCDのピンアサインは共通のようだ。

SDRAM は、秋月で128メガビット品を@300で入手出来るが、256メガビット品「IS42S16160-7TL」を購入、@423だった。(16ビットバス)
RX65Nは内臓RAMはそこそこあるものの、グラフィックスなど、容量の大きいオブジェクトを扱う場合、SDRAMは必須と言える。
※外部に接続されたSDRAMの速度は、内臓RAMに比べてかなりスローダウンすると思えるのだが、実メモリが数十メガバイトあるのは、本当に有利だ、C++ の標準ライブラリや boost も気兼ねなく使え、PC 環境と遜色無く、プログラムを実装できると思える。
また、Minix のような実行環境も揃えられるだろう。
※ gcc を動かしたいが、完全な POSIX 環境を作るのは簡単では無いだろうな・・

中古住宅リホーム(物置)その4

残ってた「根」をほぼ抜き取った
抜きとった状態
さらに、周辺に残ってた「根」などを除去
これで、ほぼ完了だが、折角なのでもう少し広げる為に作業を続行

以前の物置をゴミ処理場(まるたの森クリーンセンター)に運んだら、これは、鉄屑なので、ここでは受け取れないとの事、それで、「綿半Jマート都留店」そばの金属回収業者「田村リサイクル」を紹介してもらった、丁度お昼どきで責任者が食事に出かけていないとの事、このくらいの鉄屑だと数百円になると言われたが、そのまま置いてきた。

次の日、残っていた「根」を取り除く為作業をした。
根の周辺をある程度掘って、鉄棒を差込み、色々な方向から「こじった」ら、あれだけ頑丈でビクともしなかった根が、部分的に折れて、何とか抜き取る事が出来た、多分、深い所にまだ残っているようだが、それは放置する事にした。

根のあった所に土を埋め戻して、固めているが、沈下しないように強く固めておかないと後々問題が起こると思うので、少し慎重に作業している。

木製の大きなハンマーとかあると良いのだが、以前にホームセンターで見た時は、それなりの値段だったので、花壇を囲っていたレンガを使って、地ならしをしている。

これだけ苦労して抜いたが、30センチくらいしか広がっていない感じで、それだと不十分なので、もう少し邪魔な植木を抜いて、広げたい。

中古住宅リホーム(物置)その3

切り株の除去に難儀してる。
とにかく「硬い」!

最初、5~6センチだけ削ろうと思ったが、ここまできたら、とことん除こうと思った、どんなふうに「根」が伸びているのかも気になった。(何でこんなに強力なんだとは思ったが、考えてみれば、この切り株の木が上に数メートルあるのなら、かなり頑丈に根を生やしていないと簡単に倒れてしまう。)

2時間だけ作業・・、手が痛い・・
天気が悪く、2日おいて作業、腕が限界でここまで・・
壊した木屑w

ある程度壊してしまうと、土台が緩くなって、木が硬い事もあり、ノミが入っていかない、横から叩いたり、方向を色々工夫すると、入って行きやすい角度があり何とかなる感じ・・

土を掘っていたら何故か、鉄の棒が出てきたので、それを使ってテコで根を掘り出したり、折っている。
木の生命力は凄い!、複雑に入り組んで、強靭な根を伸ばしてる。

何故か地中に埋まっていた「鉄棒」
残すは右側の切り株(この状態ではビクともしない・・)
左側から掘り出した「根」

あと、もう少しだ・・・
今回はここまでー

中古住宅リホーム(物置)その2

最初、切り株はそのままにして、ギリギリまで寄せるつもりだったが、最近天気が良い日が続いていて、時間もある事から、切り株を取り除こうと思い作業を開始した。
まず、切り株の周りを掘ってみたー、それなりに掘ったら、末広がりで、頑丈な根があり、とても全体を取り除く事は出来ない事が判った。

また、この「木」は何の木か知らないけど、目が詰まって、非常に堅い。
とりあえず、ノコギリを買ってきて、切ってみようとしたが、硬くて、手動では到底無理で断念したー、次に電動ドライバーに木工ドリルを付けて穴を開けてみたが、硬くて、崩せる程穴あけするには無理がある、次に丸ノコで切れそうな部分を切ってみたが、丸ノコでは、中心部まで刃が届かないので、これも駄目、本来ならチェーンソーが必要なとこだが、切り株を一つ処理するだけなのにチェーンソーを買うのも気がひける・・

最後は、地道にノミとトンカチで少しづつ切り崩してみた。
どうやらこれが「正解」のようで、時間と手間がかかるが、そこそこの労力で何とかなる事が判った。

切り株の周りを少し掘った状態

ノコギリで根を少し分解する過程で、「石」を噛んだ根をノコで引いてしまい、一瞬で刃が鈍ってしまったようだー(切れ味が一瞬で悪くなった・・・)

とりあえず、地道ではあるが少しづつ崩して(30センチ弱は崩した)、ここまでになったが、あと7センチくらいは崩さないと・・・
トンカチを振り下ろすのは、それなりに大変なので、1日数時間くらい作業をしている。(3日くらい)
とりあえず、ここまでー

RX65N Envision Kit、DRW2D エンジンの仕様?不具合?

先日、RX65N に内臓の描画エンジンを使ってみたが、描画の管理を色々テスト、評価する段階で暗礁に乗り上げた。
RX65Nの場合、内臓メモリは限られているので、ダブルバッファとフリッピングによる手法を行うには無理がある。
そこで、とりあえず、シングルバッファによる方法で、描画と表示を最適化して、何とかならないかと試行錯誤してみたが、「問題」に当たった。

予定では、画面表示と描画を細かく管理する事で、高速な描画エンジンとの連携で何とかなると思っていたが、思っていたように動作せず、悩んでいる。

まず、問題をシンプルにする為、簡単な描画シーケンスを実行してみた。

    d2_startframe(d2_);
    d2_clear(d2_, 0x000000);
    d2_setcolor(d2_, 0, col);
    d2_rendercircle(d2_, 480/2*16, 272/2*16, rad*16, 0);
    d2_endframe(d2_);

上記のプログラムでは、画面全体を消去して、中心に円を描画する、描画の半径は、フレーム毎に変えるようにしている。
※実際に描画にかかる実時間は、半径が最大でも1ms程度と思われる。

普通に考えると、「描画中」は、描画アクセスが優先されるので正しい表示にならないのは判る。
しかし、実際にこのプログラムを走らせると、描画が終わってからも、正しい表示がされない。
※正しい表示がされるのは、次のフレームからになり、毎フレームこの処理を繰り返すと、ほとんど何も表示出来ない常態になってしまう。
ここからは想像なのだが、DRW2Dエンジンにディスプレイリストを渡して描画すると、DRW2Dエンジンがメモリバスを奪い取って放さず、GLCDCの読み出しが無効になってしまい、表示の読み出しが失敗しているように見える。
DRW2Dのキャッシュをフラッシュするとか、描画領域を変更するとか色々考え付く方法を試したが、一旦描画を始めてしまうと、描画の終了に関わらず、メモリバスを占有して離さないようだ、この状態は、垂直同期信号のトリガーでリセットされる。
これは、参った、この状況では、いくらパフォーマンスが高くても、リアルタイム性を要求するような描画を行えない。

何か不足している設定があるのでは?

もしかして、「バス」の優先度を設定するレジスターがあるのでは?
ハードウェアーマニュアルを良く見て、「あーーー」と唸ってしまった、「拡張バスマスタ優先度制御レジスタ (EBMAPCR)」というのがあった・・・
ヨクヨク、サンプルソースコードを見ると、GLCDC、DRW2Dの初期化時にこのレジスターにプライオリティーを設定してる・・

    {  // メインバス2優先順位設定(GLCDC、DRW2D)
        device::BUS::EBMAPCR.PR1SEL = 0;
        device::BUS::EBMAPCR.PR2SEL = 3;
        device::BUS::EBMAPCR.PR3SEL = 1;
        device::BUS::EBMAPCR.PR4SEL = 2;
        device::BUS::EBMAPCR.PR5SEL = 4;
    }

それに習って、上記のように優先順位を設定してみたら、思った通りの表示が行えた~

この問題解決に随分時間をかけてしまったようだ・・・

上の黒い「帯」でDRW2Dエンジンが描画を行っている・・

12トン油圧プレスの設置

去年の年末、ヤフオクで12トンの油圧プレスを購入、それに関する出来事を記しておく。

実際に来たものは上記の写真と異なるが「中華」にはありがちだし、気がつくのが遅く、交換してもらう手続きとか面倒なので、あきらめている・・・
・シリンダの固定方法が異なる。(写真の方が組み立てが簡単)
・高さ調整の穴が、異なる、写真の物はより実用的な穴位置のようだ・・(自分で穴をあければ何とかなる)
とにかく価格が安いし、使えれば文句は無いので、あまり細かい事は言わない事にする、価格には通常送料も含まれているが、離島などでは追加料金が発生する。
本当は「20トン」仕様が欲しかったが、重すぎるので見送った。

12月の中頃に、荷物が届いたー、だが、細長い柱が二本のみだった、「これだけですか」と佐川の配達に聞くと、「これだけです」と言い切った(嫌な予感)。
その時は、後に他が届くのだろうくらいに考えていたが、1週間たっても配達されなかった、既に正月休みで、連絡も取れない。

年が明けてから連絡を取ると、二小口の一つが破損して、それだけ戻った事が判った。
そこで、届かない分をもう一度届けるように手配したと連絡があり、3日後くらいに届いた。
「早速組み立てるゾ!」と開封したら、明らかに部品が足りない・・・
一応入っていたパーツリスト(間違いが多く、不鮮明)を見ながら足りない部品リストを作り、問い合わせた。
間違いが無いように数回やりとりして、足りない部品を再度配送したと連絡があり、やはり三日後くらいに到着。
少し不安になりながら確認して、何とか部品は揃ったようだった。(結局1.5ヶ月くらいかかった・・)

早速組み立て、簡単なテストをしてみて、何とか使えるようだー、ただ「12トン」となっているが、実際には6~8トンくらいが実用範囲のように思う。
※5トンくらい加重をかけるとハンドルがかなり重い。
流石「中華」製だ!、まぁでも自分の利用範囲ではこれでも十分と思う。
※油圧シリンダ?を支える構造が弱すぎのように思う、板圧は倍くらいほしい。(今後剛性が足りないようなら補強しようと思う)
※12トンで、もっと安い製品もあるが、そちらは、自動車の油圧ジャッキを逆さまにしたような構造で、加圧メーターも無く使い勝手がイマイチと思って避けた。(半額以下で買えるのだが・・)

安全の為、角を丸めておいた

中古住宅リホーム(物置)その1

住宅を買った時に物置は付いていたものの、床が錆で朽ち果てており、大きさも微妙に小さく、タイヤを置くと他にほとんど何も置けない状況だった・・
※山梨は、冬、スタッドレスタイヤは必須なので、タイヤ保管しないとならない。

今年は仕事が忙しくない日が多いので、物置をリニューアルする事にした。

まず、古い物置を解体する。
※元の状態を撮り忘れた・・
パーテーション、柱など、タッピングビスで固定されており、上から下へ順番に外していく、錆でネジ山が潰れていて外せないものもあり、ディスクグラインダーで頭を飛ばした。
不思議なのは、「背面」のネジ、背面は、隣の家でブロック塀があり、空間が無い。
組み立ての時、手前にずらして組み立てて背面のネジを全て止めて、押し込んだと思うが、ある程度組み立てた状態だと、かなりの重量になるので、可能なのか?
背面にデッドスペースを作りたく無いので、そうしたいが、重くて動かせないとか、中途半端な状態で動かして、柱が曲がったりしないかとか、ネジの締め忘れとか、色々、不安材料がある・・

とりあえず、地面を整地する必要があるので、おいおい考えるとして、新しい物置のスペースを作る為、芝生を切り取ったりしたが、この作業が思いのほか大変で、空間を作っただけで1日終わってしまった。
芝を切り取る作業、「鎌」を使うのだが、2時間も作業すると、握力が無くなり、鎌を持てなくなる・・・

解体した物置
整地途中

物置は、もう少し右に寄せたいのだが、切り株がある、最初切り株を撤去しようと考えたが、斧やチェーンソーなど道具が必要なので、何とか、出ている「根」だけ取り除いたーー
大体整地出来たのでブロックを置いてみた。

ここで今日は終了。
※やっぱ切り株邪魔だなー・・・
※次の日ブロックを並べる作業をしようと思ったが、寝違えて首が痛い・・、なのでこのまま放置・・・

RX65N Envision Kit 、DRW2Dエンジンを使う

RX65Nには、描画をブーストするDRW2D描画エンジンがある。
ただ、ハードウェアーレジスタの詳細は公開されておらず、C言語による操作ライブラリが公開されている。
今までは、フレームバッファに対する描画は、ソフトウェアーによる描画のみを使っていたが、当然ハードウェアーの方がパフォーマンスは高く、描画中は、他の処理を実行出来る為、効率も良さそうだ。
また、DRW2Dの描画機能は、アンチエリアス付の描画が行え、「線幅」の概念があるので、かなり柔軟で品質の高い描画が簡単に行える。

そこで、DRW2Dライブラリの機能をC++から呼び出すラッパーを実装してみた。
※DRW2Dライブラリのバージョンは1.02をベースにしている。

DRW2Dの基本的な動作は、メモリー上に描画コマンド・リストを定義しておき、その先頭ポインタを描画エンジンに渡す事で描画を行う仕組みとなっている。

描画状況により、割り込みが起動でき、DRW2Dライブラリでは、標準的に割り込みサービスを呼び出すように設計されている。

「drw2d_mgr」クラスでは、初期化で、割り込みベクターを登録している。
「void drw_int_isr(void);」はDRW2Dライブラリの割り込みサービスの入り口で、それを登録しておけば良い、ただ、この割り込みは、グループベクタAL1になっていて、「icu_mgr」クラス内の AL1 dispatch クラスが、内部で振り分けを行うようになっている。
※割り込み関数アトリビュートを付けないようにしなければならない。

extern "C" {
    extern void drw_int_isr(void);
};
 //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  DRW2D 制御/マネージャー
        @param[in]  DRW     DRW2D クラス
        @param[in]  XSIZE   X 方向ピクセルサイズ
        @param[in]  YSIZE   Y 方向ピクセルサイズ
        @param[in]  PXT     ピクセル・タイプ
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <class DRW, int16_t XSIZE, int16_t YSIZE, glcdc_def::PIX_TYPE PXT>
class drw2d_mgr {

...

    icu_mgr::install_group_task(DRW::get_irq_vec(), drw_int_isr);

...

};

DRW2Dの初期化は、以下のように行うようで、「drw2d_mgr」クラスの初期化「start();」から呼んでいる。
この呼び出し後、DRW2Dエンジンを利用出来るようだ。

    d2_ = d2_opendevice(0);
    d2_inithw(d2_, 0);
    rb_ = d2_newrenderbuffer(d2_, dlis, stsz);

「d2_newrenderbuffer」のプロトタイプは以下のようになっている。
dlis: initialsize – number of displaylist entries in the first page (minimum is 3)
stsz: stepsize – number of displaylist entries in following pages (minimum is 3)

内部で「malloc」を使ってメモリを割り当てているので、固定長で使えるように改修する必要があるかもしれない・・

DRW2DライブラリのAPIは非常に豊富に用意されているが、とりあえず、良く使いそうな物だけラップした。
また、座標系のクラスなどを積極的に利用するようにした。
DRW2Dライブラリの構成はOpenGLのコマンドストリームの考え方に近いので(高速、柔軟性、機能性を追及すると、大体、このような構成になる)マネージャーを実装するのは比較的やりやすい。

アンチエリアスされた「線」と「サークル」の描画

とりあえず、基本が出来たので後は、スプライトなどテクスチャーの描画などだ、フォントが一通り描画できるようになったら、ソフトウェアーのエンジンと入れ替えたい・・・

drw2d_mgr.hpp