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

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

RX26TのPLLベースクロック不具合

RX26T の PLL ベースクロック

は、ハードウェアーマニュアルでは、120 ~ 240MHz となっている。

しかし、240MHz を設定すると動作しない状況だった。

120MHz なら動作するので、まぁ問題無いかと思っていたが、やはり気になるので、ルネサス社のサポートに問い合わせていた。

色々、やりとりをした結果、スマートコンフィギュレーターでプログラムを生成して試して下さいとの事だった・・
まぁ、そうなるよなぁーと思っていたが、やはり原因は究明しておかないとと思った。

しかし、オレオレフレームワークがある程度動作する環境だと、結構億劫で、門外漢が強く後回しになっていたが、ようやく作業を始めた。
※E2Studio は起動が遅いし、プロジェクト全体の構成などが複雑で、出来れば触りたく無い。

スマートコンフィギュレーターが生成したプログラムを眺めていて、以下の部分に気がついた。

    /* b19 to b16 should be set the same value as the ICK bit. */
    tmp2_clock = tmp_clock;
    tmp2_clock &= 0x0F000000;
    tmp2_clock >>= 8;
    tmp_clock |= tmp2_clock;

あっ・・・

ハードウェアーマニュアルを確認すると、予約ビットの扱いがひっそり書かれていた・・・

これは、罠だよなぁー・・・、そういえば、RX631でも同じような事があったよなぁー・・・
まぁ、自分のミスではあるのだが・・・
何でそこに気がつかなかったのか悔やまれる。

今回は、PLL ベースクロックが、228MHz なら動作していたもので、微妙な不具合で、デバイスの不良なのかと、ハードウェアーの問題だと思ってしまい、ソフトの問題に気が回らなかった。

今後、予約ビットの扱いは、最新の注意が必要だと痛感した・・・
※予約ビットに特定の値を設定する必要があるなら、「----」にしないで、特定の名称を割り当てるべきと思う。


GNU-RX 8.3.0 202305 バージョンの不具合?

RX26T では、TFUv2 が採用されている。

このサポートには、新しいコンパイラが必要と思われ、GNU-RX ツールチェインを最新にしておいた。

しかし、以下のオプションを使って、「cmath」 をインクルードした状態でコンパイルすると、エラーが出る・・・

-mtfu-version=v2 -mtfu=intrinsic,mathlib

※「mathlib」の部分
※「-mtfu-version」が追加されている。

c:\programdata\gcc for renesas rx 8.3.0.202305-gnurx-elf\rx-elf\rx-elf\rx-elf\include\c++\8.3.0.202305-gnurx\cmath:1122:11: error: ‘::hypotf’ has not been declared

 using ::hypotf;

GNU-RX 8.3.0 202004 とか一つ前のバージョンだと発生しない。

これは、現在、問い合わせ中だ。

mathlib は、通常の数学関数が、TFU を利用した高速版に置き換えられるものと思う。


まとめ

今回の騒動、素直に「スマートコンフィギュレーターを使ったらどうですか?」と言われそうだが、本当にそれが素晴らしいものなら初めから使っている。
色々と、ハードルがあっても、自分の信念は貫きたい、より一層の注意力が必要と思う一件だった。

glfw3_app C++ Mupdf ライブラリ用テストアプリ

Mupdf ライブラリ

以前(数年は前)に、glfw3_app のさらに前に、一度、試していた。

その時は、Mupdf のソースコードを取ってきて、自分でコンパイルして実装した覚えがある。

最近、Mupdf のリソースは MSYS2 でもサポートされ、pacman で簡単にインストール出来るようになっていた。

そんな事もあり、glfw3_app でも Mupdf ライブラリを再び試してみた。

構成が大きく異なる・・

最近のリリースは、以前の構成とはかなり異なっている、昔のコードはそのままではコンパイル出来ない。
サンプルを観たり、ヘッダーのプロトタイプを眺めたりしながら、コンパイルが通るようになった。

しかし、リンクで必要なライブラリが足りなくて失敗する・・

色々調べて、何とかリンクまで成功。

動かすが、クラッシュする・・

簡単なコードにして、PDF ファイルを食わせてみるが、クラッシュする・・

色々調べて、呼ぶ API が足りない事に気がつく。

  fz_register_document_handlers(context_);

コンテキストを生成したら、この API を呼ぶ事がマストのようだった。

描画されない・・

だが、ちゃんと描画がされない・・

良く調べると、良かれと思って追加したインスタンスが余計だった。

  fz_separations *seps = fz_new_separations(context_, 0);
  fz_pixmap* pix = fz_new_pixmap_with_data(context_, fz_device_rgb(context_), w, h, seps, alpha, stride, rgba);

上記「seps」は、使わない場合、必要無いようだ・・

  fz_pixmap* pix = fz_new_pixmap_with_data(context_, fz_device_rgb(context_), w, h, NULL, alpha, stride, rgba);

これで、普通に描画されるようになった。

まとめ

PDF を扱う実装は、RX マイコンのハードウェアーマニュアルから、色々と必要な情報を自動で取得する事を目指していて、その前段階。
その情報を使い、デバイス関係のソースコードを自動生成したり、テストコードを生成する事を考えている。

今回の実装は、その一歩となる。

詳細は、Qiitaに投稿してある。

pdfv アプリは、PDF をプレビューするアプリで、GUI を操作するメイン部は、俺俺フレームワークの助けを借りて 500 行くらいで実装出来ている。

Mupdf ライブラリ、便利!

RXマイコンC++フレームワーク、RX220をサポート開始

RX220 マイコンをサポートする

半導体不足は未だ解消の気配は無く、RXマイコンを買うにしても、以前のような価格では流通していないし、バックオーダーで、買う事も出来ない。

RX220は、機能と価格で、CPはそんなに良くないが、秋月さんで売っているので、入手はしやすいだろうと思う。

  • DIPスイッチを逆に取り付けてしまったバージョンの基板なら比較的安価に購入できる。(1250円)
  • 以前RX72T(200MHz、RXv3コア)が10個で@600円くらいだった事を考えると、最大32MHzでRXv1コアはあまり触手が伸びない。
  • RX220はFPUも内蔵していない・・
  • 既に購入済で、積みボードになっている人もいるかもしれない。

とりあえず、RXマイコン全制覇を目論んでいるし、200番台をサポートするのは、それなりに価値がある。


秋月RX220ボードの改造

秋月さんのRX220ボードは、そのままでは多少使いづらい・・
このボードでは、内蔵フラッシュを書き換えるには、シリアル書き込みがほぼ標準的となる。
その場合、SCI1を使う事になるが、そのままだと、RSー232Cのレベル変換ICに接続されている。
今や、PCとの通信でRSー232Cを使う事は「稀」で、FT232やCP2102NなどのUSB/シリアル変換モジュールを使って、ロジックレベルで行うのが標準的となっている。
そうすると、RXマイコンのTxDは出力なので問題無いとしても、Rxdは入力となっていて、レベル変換ICの出力が接続されているので、モジュールのロジック端子を繋ぐ事ができない。
そこで、ボードのパターンをカットして、接続できるように改造した。
※何かの記事で読んだが、この「カットをする意味が判らない」と綴っている人がいた・・、これは、本当にビックリした、その程度の知識でマイコンをやってる人がいる現実に驚くばかり。
まぁ、でもマイコン掲示板で、自分で何も調べないで、いきなり質問する人や、初歩的と思えるような質問をする人、様々な人がいる現実を考えると、まぁそんなものかもしれない。


ソフトディレイの調整

RX220は最大32MHz(内蔵発振器動作)で動作する。

  • クロックジェネレーターにはPLL回路が無い為、外部にクリスタルを接続して利用する場合は、最大20MHzとなる。
  • クリスタルの発信器は、20MHzを超えると、ちょっと特殊な回路にしないと発振が安定しない(発振しない)ので、そうなっていると思う。
  • ただ、外部クロック入力でも最大20MHzなので、その他の物理的な要因が関係しているのかもしれない。
  • 内部発信器だと、正確性やジッタの問題があるとも思うが、意外と安定していると思う。
  • 内部発信器は最大50MHzで発振する事も出来るので、50MHzオーバークロックで動かしてみたが、普通に動作はするようだ。

最初、1マイクロ秒のソフト遅延を行う為、NOP命令のループ回数を調整していたが、思うように調整出来ない・・・
ある値を境に、遅くなったり、速くなったり、不思議な現象が発生した。

                for(uint32_t n = 0; n < device::clock_profile::DELAY_MS; ++n) {
                    asm("nop");
                }

・・・

少し考えたら、理由は判った、今まで、最低速度は、RX24Tの80MHzだったので、ループ回数はそれなりの値で問題無かった。
しかし、32MHzだと、ループ回数は少なく、ある値を境に、「asm("nop");」が、インライン展開されてしまう。

そこで、RX220の場合は、専用のAPIにした。

        static void delay_us() noexcept
        {
            // 定数(DELAY_MS)で指定すると、ループ数が少なくインライン展開され、予想した時間にならない為、直で’NOP’数で調整する。
            if(ICLK == 32'000'000) {  // 32MHz 用
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
            } else if(ICLK == 20'000'000) { // 20MHz 用
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
                asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop");
                asm("nop"); asm("nop"); asm("nop");
            } else {
                for(volatile uint8_t i = 0; i < (ICLK / 1'000'000) - 10; ++i) {
                    asm("nop");
                }
            }
        }

rx_prog でも、RX220をサポート

最初、とりあえずルネサスフラッシュプログラマーで書き込みを行ったが、非常に不安定で、書き込みに失敗、そもそも接続も出来ないなどのトラブルが多発した。
この原因は追究していないが、USBシリアルデバイスがCP2102Nなのが問題なのかと思った。

  • CP2102Nは、FTDIより高速で、同じボーレートでも、転送にかかる遅延が非常に少ない為と思った。
  • RX200系は、RXマイコン初期の物なので、あまり枯れていないのかもと思った。
  • ルネサスフラッシュプログラマーの無料版は、ノークレームなので、改修を要求する事さえ出来ない。

そこで、まず、rx_prog にRX220のプロトコルを追加する事にした。
ブートモードの説明を斜め読みした感じでは、RX63Tとほぼ同じ感じで、そのまま行けると感じた。

「rx_prog.conf」に、RX220 デバイスのプロファイルを追加して、「rx220_protocol.hpp」を追加、説明と照らし合わせた。

R5F52206 {
    group = "RX220"
    clock = 3200
    divide_sys = 1
    divide_ext = 1
    rom = 256K
    ram = 16K
    data = 8K
    comment = "; RX220 Flash:256K DataFlash:8K RAM:16K"
    rom-area  = FFFC0000,FFFFFFFF
    data-area = 00100000,00101FFF
    ram-area  = 00000000,00003FFF
}

「rx63t_protocol.hpp」ほぼ同じでOKだったが、ファイルは別けておいた。

まず、コネクションを試してみた。

 % rx_prog -d RX220 --verbose
# Platform: 'Cygwin(MSYS2)'
# Configuration file path: '/usr/local/bin/rx_prog.conf'
# Group: 'RX220'
# Serial port path: 'COM7'
# Serial port speed: 230400
# Erase Page Wait: 2000 [uS]
# Write Page Wait: 5000 [uS]
# Serial port alias: COM7 ---> /dev/ttyS6
# Serial port path: '/dev/ttyS6'
# Device: R5F52206 (first find)
#   Master clock: 32.00 MHz
#   ICLK multiplier: 1 (32.00 MHz)
#   PCLK multiplier: 1 (32.00 MHz)
Connection OK. (RX62x)
#01/01: Device: RX200 Series (LittleEndian)
#01/01: Device ID: 0x33306A37
#01/01: Clock Mode: 0x00
#01/02: Multiplier: 1
#02/02: Multiplier: 1
#01/02: Frequency Min: 32 MHz, Max: 32 MHz
#02/02: Frequency Min: 32 MHz, Max: 32 MHz
#01/01: Change baud rate: 115200
#01/01: Boot Area: FF7FC000, FF7FFFFF
#01/01: Area: FFFC0000, FFFFFFFF
#01/26: Area: FFFFF000, FFFFFFFF
#02/26: Area: FFFFE000, FFFFEFFF
#03/26: Area: FFFFD000, FFFFDFFF
#04/26: Area: FFFFC000, FFFFCFFF
#05/26: Area: FFFFB000, FFFFBFFF
#06/26: Area: FFFFA000, FFFFAFFF
#07/26: Area: FFFF9000, FFFF9FFF
#08/26: Area: FFFF8000, FFFF8FFF
#09/26: Area: FFFF4000, FFFF7FFF
#10/26: Area: FFFF0000, FFFF3FFF
#11/26: Area: FFFEC000, FFFEFFFF
#12/26: Area: FFFE8000, FFFEBFFF
#13/26: Area: FFFE4000, FFFE7FFF
#14/26: Area: FFFE0000, FFFE3FFF
#15/26: Area: FFFDC000, FFFDFFFF
#16/26: Area: FFFD8000, FFFDBFFF
#17/26: Area: FFFD4000, FFFD7FFF
#18/26: Area: FFFD0000, FFFD3FFF
#19/26: Area: FFFCC000, FFFCFFFF
#20/26: Area: FFFC8000, FFFCBFFF
#21/26: Area: FFFC4000, FFFC7FFF
#22/26: Area: FFFC0000, FFFC3FFF
#23/26: Area: 00101800, 00101FFF
#24/26: Area: 00101000, 001017FF
#25/26: Area: 00100800, 00100FFF
#26/26: Area: 00100000, 001007FF
#01/01: Program size: 256 Bytes
#01/01: ID Protect: false

問題無い。

次に、書き込み、ベリファイも試して、問題無かった。
rx_prog は、多少書き込み速度が遅いものの、安定して書き込めるし、OS-X、Linux でも同じように動作する実績がある。
※RX220 は、OS-X、Linux では試していないけど・・

rx_prog -d RX220 --progress  --write --verify sci_sample.mot
Write:  #################################################
Verify: #################################################

これで、RX220を正式サポートした事になると思う。

Makefile は、以下の部分のみ異なるだけで良く、RX220 に移る事は簡単だ。

DEVICE      =   R5F52206

RX_DEF      =   SIG_RX220

まとめ

現状、サンプルプログラムは、「FIRST_sample」、「SCI_sample」のみだが、今後拡充してゆく予定。
※基本、各プロジェクトで、Makefileを用意すればOKだが、まだ、RSPIや、RIIC(I2C)ペリフェラルの追加などをしていない。

RX220 は浮動小数点を扱うとエミュレーションになってしまうが、「utils::format」の表示関係は、内部はほぼ整数を使っているし、速度以外はそれなりに使えると思う。
もう少し安価に入手できれば・・・
それでも、32ビットなので、RL78などの8ビット系に比べて大きなアドバンテージがあるのは言うまでも無い。

Start SCI (UART) sample for 'AE-RX220' 32[MHz]
SCI PCLK: 32000000 [Hz]
SCI Baud rate (set): 115200 [BPS]
  Baud rate (real): 117647 (2.08 [%])
  SEMR_BRME: false
  SEMR_BGDM: false
CMT Timer (set):  100 [Hz]
  Timer (real): 100 [Hz] (0.00 [%])
#

現在、RX631/RX63N もサポート中で、秋月ユーザーでも、C++ フレームワークを使ってみる機会がそれなりに増えると思う。

C++ に対する嫌悪感

主にC言語しか使わない人は、C++ に対する嫌悪感が半端ない事が多い。
また、C++ は判らないし、難しそうだから近寄らない人も多い。

しかしながら、マイコン初心者(プログラムの経験が全く無い人)に教える場合、C++ から始めても、そんなに敬遠したりしない事が判っている。
※もちろん、最初はあまり多くを示さないで、簡単な事、理解しやすい事、シンプルな事から始める。
むしろ、半端にプログラム出来る人より、飲み込みが速く、応用が利く人が多いように思う、これは、教え方次第のように思う。
年齢は関係無い、若い人は頭が柔らかく、吸収する力が大きいように感じる。

C++だと、コンパイラが教えてくれる事が多く、小さなミスは、ほぼ起きなくなるし、柔軟で応用範囲が広いライブラリなど、利便性が高い。

今回 RX220 をサポートしたが、アプリケーションレベルでは変更が全くなく、同じように動作する。

今後、勉強会や、講習会、YouTubeビデオなど、学べる機会や媒体を増やしていく予定でいる。

RX62Nのフラッシュ書き換えツール実装でまた発見!

基板の提供ありがとう~

基板の提供を受けました、「Lathe」さん大変ありがとうございます。


RX62N の フラッシュ書き換えツール対応

RX62N の C++ フレームワーク対応も、ほぼ出来上がり、これで、本格的に使えるようになった感じ。

一番厄介だった、MTU 関係も、何とかなり、ブログに記事をまとめていたのだが、


とりあえず、フラッシュの書き換えは、「Renesas Flash Programmer V3.06.01(無償版)」を使って USB 接続で書き換えしていた。

しかし、書き換えの度に、USB 接続をしたり切ったりするのが何だかなぁーと思って、遅くてもシリアルで書き換え出来るようにしておこうと思い、SCI1 にコネクタを接続しておいた。

そして、フラッシュ書き換えツールも対応しておこうと思い、ブートモードの解説を観ていたら、どうやら、これは RX63T にかなり近い仕様だと判った。
RX63T のリソースを使い、それを改造すれば割と簡単に対応可能だと判り実装を始めた。


奇妙な事を発見

まず、最初は、

  • ブートモードで起動
  • 接続
  • シリアルの通信速度をキック
  • デバイス情報の取得
  • 書き換え

ざっと、こんな感じなのだが、その過程で、「デバイス情報取得」で奇妙な事が起こっていた。

 % rx_prog -d RX62N --verbose
# Platform: 'Cygwin'
# Configuration file path: 'rx_prog.conf'
# Device: 'RX62N'
# Serial port path: 'COM7'
# Serial port speed: 230400
# Erase Page Wait: 2000 [uS]
# Write Page Wait: 5000 [uS]
# Serial port alias: COM7 ---> /dev/ttyS6
# Serial port path: '/dev/ttyS6'
Connection OK. (RX62x)
#01/01: Device: RX600 Series
#01/01: Device ID: 0x35307936
#01/01: Clock Mode: 0x00
#01/02: Multiplier: 1, 2, 4, 8
#02/02: Multiplier: 1, 2, 4, 8
#01/02: Frequency Min: 8 MHz, Max: 100 MHz
#02/02: Frequency Min: 8 MHz, Max: 50 MHz
#01/01: Change baud rate: 115200
#01/01: Boot Area: FF7FC000, FF7FFFFF
#01/01: Area: FFF80000, FFFFFFFF
#01/54: Area: FFFFF000, FFFFFFFF
#02/54: Area: FFFFE000, FFFFEFFF
#03/54: Area: FFFFD000, FFFFDFFF
#04/54: Area: FFFFC000, FFFFCFFF
#05/54: Area: FFFFB000, FFFFBFFF
#06/54: Area: FFFFA000, FFFFAFFF
#07/54: Area: FFFF9000, FFFF9FFF
#08/54: Area: FFFF8000, FFFF8FFF

...

#50/54: Area: 00102000, 001027FF
#51/54: Area: 00101800, 00101FFF
#52/54: Area: 00101000, 001017FF
#53/54: Area: 00100800, 00100FFF
#54/54: Area: 00100000, 001007FF
#01/01: Program size: 256 Bytes
#01/01: ID Protect: false

このデバイスは、「R5F562N7」なので、「フラッシュ:384K、RAM:64K」品のハズなので、
「Area:」は、FFFA0000 から始まるハズなのだが・・・

ん??

これは、もしや・・・

物理的なデバイスは、全て「R5F562N8」と同じ物で、デバイスIDで識別しているだけなのでは?

そこで、Makefile のデバイス名を切り替えて、プログラムを書き換えると、普通に書き換え出来たーーー

# BlueBoard-RX62N_100pin
#DEVICE     =   R5F562N8
# FRK-RX62N (CQ出版)
#DEVICE     =   R5F562N7
DEVICE      =   R5F562N8
USER_DEFS   =   CQ_FRK
Memory Configuration

Name             Origin             Length             Attributes
RAM              0x00000000         0x00017a00         w
USTACK           0x00017e00         0x00000004         w
ISTACK           0x00018000         0x00000004         w
ROM              0xfff80000         0x0007ffd0         w

そして普通に動く!!!

やっぱりね・・

まぁ、そういう事なのだろう。

驚いた事に、ルネサス、フラッシュプログラマーでも、普通に書き換えが出来、動くようだ・・

とゆー事は、「刻印」が違うだけなのか・・・


まぁ、ROM が 384K から 512K に増えても、そんなに大きなプログラムを作らない限り変わらないかもしれないが、RAM が 64K から 96K だと、やはり使いかってが違うと思う。


まとめ

これは、今回のボードに載っているデバイス特有の事なのかもしれない・・

このボード、かなりの数を出荷したと思うが、当時、「7」の384K品が不足していた為、512K品を刻印だけ変えて出荷したとも考えられる。

他に試せるデバイスを持っていないので、判らないが・・・

まぁ、どちらにしても、うれしい誤算である事は言うまでもない。

このボードを持っている人は試してみる事を勧める~

R8C、RX開発環境のアップデート

R8C の開発環境が作れないとのツイートをもらう・・

先日、Twitter で 過誤出来ないツイートをもらった。

ツイートは短く、詳細は不明なので、実際にどんな事が起きているのか判らなかった。

何度かやりとりをする中で、どうやら、これは Linux 環境で発生している事が判った。

その要因は、最新の gcc 環境(Version 11)などで、gcc-4.9.4 の C++ ビルドで失敗する事が判った。

そういえば、Windows の MSYS2 環境もしばらくアップデートしていない、そこで、まずは、MSYS2 をアップデートする事から始めた。
※Linux 環境は、ノートPC にあり、古いので、新しい環境に入れ直す必要があり、確認するのも時間がかかる。

pacman -Sy pacman
pacman -Syu

この段階で、データベースの更新に失敗して、先に進まない・・

MSYS2 は、かなり更新しているようで、根本的にシステムが大幅に変わったようだ、そこで、インストールからやり直す事にした。

念の為、MSYS2 のコア部分、「C:\msys64」をリネームして、残しておいた。

最新版をインストールして、必要なツールをインストール。
※複数パッケージのインストールが、マルチスレッドで同時進行するようになっているw

MSYS2 はアイコンが少し新しくなり、大きな変更があったようだ。

また、新たな環境が二つ追加された:

  • MSYS
  • mingw32
  • mingw64
  • ucrt64(追加)
  • clang64(追加)

※追加された環境が、どのような特徴があるのか調べていない。(clang64 は何となく判る)

MSYS のカレント gcc は11系になっている。

gcc (GCC) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

次に、R8C 用 gcc のビルドにとりかかる。
gcc のビルドは、MSYS で行う。(この環境がもっとも Linux などに近い)

手順を進めていって、やはり、gcc C++ の構築でエラーが発生して止まる・・・

うーーん、これは、どうしたものか・・・

そもそも、gcc-4.9.4 は古すぎると以前から思っていた。
しかし、開発環境を変更する事で、発生する別の問題を恐れて「まぁ動いているから枯れた方がいいかな」とも思っていた。

この機会に、手始めに R8C の開発環境をアップデートして、gcc-11 でエラー無くコンパイル出来るようにした方が建設的ではと思った。
この段階で、エラーを報告してくれた人は、ネットの情報を精査して、configure で生成された Makefile に、C++11 のオプションを付ける事で回避したようだ。
※なるほど、その回避もあるよなぁーと思ったが、やはり、gcc のビルドで特別な事を行うのは少し抵抗がある。


RX マイコンの開発環境では、最近は GNU-RX(魔改造されている)を使っている為、素の gcc を使う事が無くなっている。

RX のツールチェインは、以下の組み合わせとなっている。

binutils-2.34
gcc-7.5.0
newlib-2.4.0

組み合わせは重要で、リリースが同じくらいのパッケージを組み合わせないと、ビルドが通っても、コンパイル中にインターナルエラーで止まったり、
出来たコンパイラで作ったバイナリーをマイコンに焼いても動作しないなど、色々なトラブルが起こったりする。

そこで、R8C(m32c-elf)のビルドを上記組み合わせで作ってみた。

ビルド途中で、エラーで、失敗する・・・

うーーーん・・・

この組み合わせは、m32c-elf では相性が悪い・・・

そこで、少し古いバージョンの組み合わせで、色々試してみた。
m32c-elf は多分、メンテナンスされていないので、欲張らずにそこそこ新しい物で我慢する方が安全と考えた。
SSD(1TB) と、大きな主記憶(32GB)で武装された、最新の PC(Rizen7) でも、gcc のビルドは、そこそこの時間を要する。

色々、試して:

  • binutils-2.28.1.tar.gz
  • gcc-6.4.0.tar.gz
  • newlib-2.4.0.tar.gz

この組み合わせで、ビルドが通った。


boost 問題・・・

r8cprog など、一部のコードは、boost を使っている。

本来なら、MSYS 環境に boost を入れるのが良いと思うが、mingw64 などには対応しているが、MSYS 環境には無い。
そこで、mingw64 環境に入れた boost を間借りする形で使っていた。
しかし、新しい MSYS2 ではそのやり方では問題が発生する事が判った。

そこで、boost_1_74_0 のアーカイブを取ってきて、C ドライブのルートに展開し、そのパスを食わせる事で解決した。

この変則的なやり方は、あまりスマートとは言えないが、手順は難しく無いので、まぁ及第点だろうか・・


R8C のプロジェクトを全ビルド

新しく出来たツールチェインを使って、R8C のプロジェクトを全てビルドしてみた。

エラー無くビルドが通った。

とりあえず、「UART_sample」を動かしてみて、ちゃんと動作するバイナリーが出来る事も確認した。


RX 関係も確認

RX 関係も、一応確認した。

RX の gcc ビルドは問題無く通ったので、「良し」としたが、boost のパスは、R8C と同じく変更した。


RL78 環境

RL78 も、R8C と同じ環境にして、gcc をビルドしてみた。
これも、順調に通り、構築出来た。

しかし、プロジェクトをビルドすると、gcc がインターナルエラーで停止する・・・

rl78-elf-g++ -c  -std=c++17 -Wall -Werror -Wno-unused-variable -Wno-exceptions -Wno-unused-function -Os -mmul=g13 -DSIG_G13 -DF_CLK=32000000  -I. -I../ -I../G13  -o release/main.o main.cpp
In file included from main.cpp:15:0:
../common/format.hpp: In member function 'void utils::basic_format<CHAOUT>::out_fixed_point_(VAL, uint8_t, bool) [with VAL = long long unsigned int; CHAOUT = utils::stdout_chaout]':
../common/format.hpp:589:3: internal compiler error: in push_reload, at reload.c:1348
   }
   ^
unrecognized DWARF version in .debug_info at 6
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [Makefile:112: release/main.o] Error 1

うーーーん、これは痛い・・・

そーいえば、ルネサスさん、RL78 用に LLVM ベースのコンパイラをリリースしているんだよなぁー、アレ試してみたいんだよなぁー

今ここ。


まとめ

とりあえず、R8C、RX 関係は、何とかなったので、RL78 も何とかしたいけど、時間切れ。
Linux 環境も試しておく必要があるし、まだ、時間がかかる。

R8C の教材も中途だし、中々先に進まない。

しかし、Windows の最新環境にマッチするように改修したのは、大きな進歩と思える。

RXマイコン、デジタルストレージオシロスコープ(その4)

かなり間が空いたが、再び、デジタルストレージの作業を行った。

ソフトの作業も平行して行っており、かなり充実してきている。


プローブを買い直す。

60MHz のプローブを買い直した、まぁ現代は、それなりに安く購入できるので助かる。

以前に買った 60MHz のプローブはトリマを回すのに特殊なドライバーが必要で(ドライバー無くした)、もっと安いプローブがあったので、別件で部品を買うついでに買ってみた。

60MHz プローブ(TEXAS60)


昔会社勤めの時、プローブの扱いに注意するよう散々言われた、テクトロニクスの 350MHz オシロ用プローブは1本5万くらいしていた。
※実験で色々作業している過程で、プローブを壊す(先のピンを折ってしまう)事が多かったようだ。
※テクトロのプローブは、沢山の知恵が詰っている優れもので、感動した事を覚えている。

プリアンプを考える

実験的に、初段のプリアンプとして、OPA2134Aを使っていたが、これは、オーディオ用なので、帯域が足りない。
※高い周波数でゲインが低下する。
※それに、そんなに安いオペアンプではない。

そこで、色々なオペアンプを探すものの、高性能な物は値段が高く、オーバースペックでもある。
サンプリングが 2MHz だと、高い周波数は測れないのは当然なのだが、
低い周波数でも矩形波を観測した場合などに、立ち上がりや立下りが実際と異なり鈍ると測定器として成立しない。
※正弦波でも、周波数によってゲインが下がって、正確な電圧を計測出来ない。
入力インピーダンスは通常1Mオームと高いので、高速でも、バイアス電流がある程度必要なオペアンプは使えない。

意外と丁度良い物が無い・・

基本的な特性として、以下の点が挙げられる。(これは、今回のプロジェクトに合致する)
※他にも、色々な項目があり、以下の条件をクリアしていても使えない場合もある。

  • スルーレートが高く、GB積が大きい
  • 入力バイアス電流が低い
  • 雑音が少ない
  • +-5V で使える
  • コストがそれなり
  • 二個入り

探す目安でしかないが、非常に沢山の品種から探すのは、何かトピックが無いと絞るのが難しいので、これらの項目で絞って選択する事になる。
※「A/D 変換の入力プリアンプ用」も選択の目安となると思う。
※1個単位で買えて、それなりに安い事も重要。

入力バイアス電流、雑音、速度は、一般的にトレードオフの関係があり、昔は、そのようなオペアンプは無かったと思うが、現在は、技術革新があり、そのような品種がリリースされている。

それで見つけたのが「アナログデバイセズの AD8066」、チップワンストップで10個程購入した(1個400円くらいだった)
※現在は、廃盤になったのか、在庫分くらいしか無いようで、倍の値段になっている・・・

主な特徴は:

  • 入力バイアス電流:1pA
  • 低価格
  • 145MHzで-3dBの帯域幅(G = +1)
  • 180V/µsのスルーレート(G = +2)
  • 低雑音
  • 5~24V
  • 単一電源およびレール・ツー・レール出力
  • 低いオフセット電圧:最大1.5mV

部品が来て、実験すると、まさに思った通りの性能で、感動した!
素晴らしいとしか言いようが無い!

アナログデバイセズ AD8065/AD8066

DC カップリング

RX72N Envision Kit の外部ポートには、200オームの保護抵抗があり、直でドライブするのは不安な為、FETスイッチを入れてある。

DC を除去する「AC」モードと、DC を観測する機能の切り替えとして、回路を簡単にする為、簡易な回路に変更した。
単純に、カップリングのコンデンサを、フォトモスリレーでショートするだけにした、実験では問題無いようだ。
※ACからDCに切り替える時、コンデンサに溜まった電荷をショートするが、ON 抵抗があるので問題無いだろうと思う。

※ただ、この時使った「PS7200K」は、現在では入手が難しいようなので、他の部品を探す必要がある。

一応入力保護

入力に過大な電圧が入った場合に回路を保護するサージ対策について調べた。
完全に保護する事は出来ないが、ある程度のバリアにはなると思う。
すると、非常に高性能でありながら、回路に与える影響が非常に少ない部品(ガス放電管アレスタ)がある事に気がついた。
値段もそんなに高く無い。
今回は、海外の部品で「Littelfuse SG90」を使う事にした(SMD 部品)。
※日本製は数がまとまらないと入手が難しい。(日本製を使いたいのに、このような制約で使う事が出来ない・・)
※最低発注数1000個とか無理!

Littlefuse GDT-SG90

レンジ切り替え

基本、RXマイコンのA/D入力(0~3.3V)なので、レンジ切り替えが必要で、以下の回路を考えてみたが、実験すると、これでは駄目な事が判った・・・

74HC4051 の入力部分には、寄生容量があり、波形が鈍る・・・
※最初は、2MHz のサンプリングなので十分と思っていたが、オシロスコープの入力インピーダンスは1Mオームと高いので、微小な容量でも効いてくる。

アナログSWを通した場合:

本来の波形:

結局、メカリレーにするしか無いかもしれない・・・
※一応、そんな事もあろうかと、部品は買ってあるが、回路を作るのが面倒だし、リレーをドライブする回路を追加する必要がある。

その前に、フォトMOSリレーをスイッチ替わりにして実験してみようと思う。

まとめ

オペアンプは、価格が高いので、他を探す必要がある。(一応候補は見つけたが、実験しておく必要がある。)
ガス放電管アレスタは、Digikey から購入する事になると思うので、キリが良いところで、まとめて発注する。

本当は、PCB のトラックを引くところまで済ます予定だったが、レンジ切り替えの問題で、先延ばしになった。

今回はここまで、別件もあり、中々集中する事が出来ない・・

RX66T、RX72Tのオーバークロック

RX66T、RX72T について

  • RX66T は最大 160MHz
  • RX72T は最大 200MHz
  • 共に RXv3 コア(DFPU は内蔵しない)

同じ RXv3 コアの RX72N、RX72M などは最大 240MHz 動作となっている。

  • RX66T、RX72T は、主にモーター制御などに特化したデバイスで、高クロックで MTU、GPTW などのタイマーを駆動出来る。
  • また、タイマー出力を微妙に遅延させて、より細かい PWM 波形を作る事が出来る機能を内蔵する。
  • CAN を内蔵する事から、ハイブリッドや電気自動車のコントローラーとして需要が大きいのかもしれない。

RX66T は RXv3 コアとして初めての製品なので、160MHz と言う能力は何となく判るが、同時期に出た RX72T の 200MHz は何故なのか疑問を持っていた。
モーター制御としては、下位に RX24T(80MHz) などがあり、それに比べて能力が格段に上がっている。

周波数が高ければ、1個のデバイスで複数のモーターを同時にケア出来る。

普通に考えて、RXv3 コアは共通なのだから、RX66T や RX72T 用に専用のコアを設計する事は考えにくい。
RX66T は、RX72T の選別漏れでは無いかと思っている。(周波数以外は機能は同じ)
多分中身のコアベースは、RX72N と遜色無いのだろうと思える。
ただ、動作周波数が最大 120MHz のRX66N(RX72N の低速版)があり、RX72N として作ったが、選別で落ちて、低速版として再利用しているのは考えられるので、一概に、動作周波数を制限しているのかは、何とも言えない部分でもある。


オーバークロックしてみる

自分の C++ フレームワークでは、クロック設定は、「clock_profile.hpp」に、希望のクロックテーブルを実装すれば、自動で設定されるようにしてある。
SCI、CAN、I2C、タイマーの周期なども、各クラスが、「clock_profile」の設定を継承して、各クラス内で自動で計算するので、気にする必要は無いよう工夫されている。

そこで、まず、RX66T をオーバークロックしてみた。

少しづつ上げて、レイトレースプログラムで実験してみた(浮動小数点などの計算がかなり含まれる)。

結果から言うと、普通に 240MHz で動作するようだー

namespace device {

    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  クロック・プロファイル・クラス @n
                ・分周器の仕様を超える値を指定しない事 @n
                ・PLL_BASE は、0.5 倍単位 @n
                ・他は、PLL_BASE を基数とする整数除算値 @n
                ・詳細はハードウェアーマニュアル参照の事
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    class clock_profile {
    public:
    #if defined(USE_USB)
        static constexpr bool       TURN_USB    = true;             ///< USB を使う場合「true」
        static constexpr uint32_t   BASE        =  12'000'000;        ///< 外部接続クリスタル
        static constexpr uint32_t   PLL_BASE    = 144'000'000;        ///< PLL ベースクロック(最大160MHz)

        static constexpr uint32_t   ICLK        = 144'000'000;        ///< ICLK 周波数(最大160MHz)
        static constexpr uint32_t   PCLKA       =  72'000'000;        ///< PCLKA 周波数(最大120MHz)
        static constexpr uint32_t   PCLKB       =  36'000'000;        ///< PCLKB 周波数(最大60MHz)
        static constexpr uint32_t   PCLKC       = 144'000'000;        ///< PCLKC 周波数(最大160MHz)
        static constexpr uint32_t   PCLKD       =  36'000'000;        ///< PCLKD 周波数(最大60MHz)
        static constexpr uint32_t   FCLK        =  36'000'000;        ///< FCLK 周波数(最大60MHz)
        static constexpr uint32_t   BCLK        =  36'000'000;        ///< BCLK 周波数(最大60MHz)
    #else
        static constexpr bool       TURN_USB    = false;            ///< USB を使う場合「true」
        static constexpr uint32_t   BASE        =  10'000'000;        ///< 外部接続クリスタル
#if 0
        static constexpr uint32_t   PLL_BASE    = 160'000'000;        ///< PLL ベースクロック(最大160MHz)

        static constexpr uint32_t   ICLK        = 160'000'000;        ///< ICLK 周波数(最大160MHz)
        static constexpr uint32_t   PCLKA       =  80'000'000;        ///< PCLKA 周波数(最大120MHz)
        static constexpr uint32_t   PCLKB       =  40'000'000;        ///< PCLKB 周波数(最大60MHz)
        static constexpr uint32_t   PCLKC       = 160'000'000;        ///< PCLKC 周波数(最大160MHz)
        static constexpr uint32_t   PCLKD       =  40'000'000;        ///< PCLKD 周波数(最大60MHz)
        static constexpr uint32_t   FCLK        =  40'000'000;        ///< FCLK 周波数(最大60MHz)
        static constexpr uint32_t   BCLK        =  40'000'000;        ///< BCLK 周波数(最大60MHz)
#else
        // Over clock... 動く、動くぞ・・・
        static constexpr uint32_t   PLL_BASE    = 240'000'000;        ///< PLL ベースクロック(最大160MHz)

        static constexpr uint32_t   ICLK        = 240'000'000;        ///< ICLK 周波数(最大160MHz)
        static constexpr uint32_t   PCLKA       = 120'000'000;        ///< PCLKA 周波数(最大120MHz)
        static constexpr uint32_t   PCLKB       =  60'000'000;        ///< PCLKB 周波数(最大60MHz)
        static constexpr uint32_t   PCLKC       = 120'000'000;        ///< PCLKC 周波数(最大160MHz)
        static constexpr uint32_t   PCLKD       =  60'000'000;        ///< PCLKD 周波数(最大60MHz)
        static constexpr uint32_t   FCLK        =  60'000'000;        ///< FCLK 周波数(最大60MHz)
        static constexpr uint32_t   BCLK        =  60'000'000;        ///< BCLK 周波数(最大60MHz)
#endif
#endif
    };
}
RX66T Start for Ray Trace: 320, 240
# Render time: 371ms (1)

続いて、RX72T、こちらも、問題無く動くw

namespace device {

    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  クロック・プロファイル・クラス @n
                ・分周器の仕様を超える値を指定しない事 @n
                ・PLL_BASE は、0.5 倍単位 @n
                ・他は、PLL_BASE を基数とする整数除算値 @n
                ・詳細はハードウェアーマニュアル参照の事
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    class clock_profile {
    public:
#if 0
#ifdef USE_USB
        static constexpr bool       TURN_USB    = true;             ///< USB を使う場合「true」
        static constexpr uint32_t   BASE        =  16'000'000;        ///< 外部接続クリスタル
        static constexpr uint32_t   PLL_BASE    = 192'000'000;        ///< PLL ベースクロック(最大200MHz)

        static constexpr uint32_t   ICLK        = 192'000'000;        ///< ICLK 周波数(最大200MHz)
        static constexpr uint32_t   PCLKA       =  96'000'000;        ///< PCLKA 周波数(最大120MHz)
        static constexpr uint32_t   PCLKB       =  48'000'000;        ///< PCLKB 周波数(最大60MHz)
        static constexpr uint32_t   PCLKC       = 192'000'000;        ///< PCLKC 周波数(最大200MHz)
        static constexpr uint32_t   PCLKD       =  48'000'000;        ///< PCLKD 周波数(最大60MHz)
        static constexpr uint32_t   FCLK        =  48'000'000;        ///< FCLK 周波数(最大60MHz)
        static constexpr uint32_t   BCLK        =  48'000'000;        ///< BCLK 周波数(最大60MHz)
#else
        static constexpr bool       TURN_USB    = false;            ///< USB を利用しない場合「false」
        static constexpr uint32_t   BASE        =  16'000'000;        ///< 外部接続クリスタル
        static constexpr uint32_t   PLL_BASE    = 200'000'000;        ///< PLL ベースクロック

        static constexpr uint32_t   ICLK        = 200'000'000;        ///< ICLK 周波数
        static constexpr uint32_t   PCLKA       = 100'000'000;        ///< PCLKA 周波数
        static constexpr uint32_t   PCLKB       =  50'000'000;        ///< PCLKB 周波数
        static constexpr uint32_t   PCLKC       = 200'000'000;        ///< PCLKC 周波数
        static constexpr uint32_t   PCLKD       =  50'000'000;        ///< PCLKD 周波数
        static constexpr uint32_t   FCLK        =  50'000'000;        ///< FCLK 周波数
        static constexpr uint32_t   BCLK        =  50'000'000;        ///< BCLK 周波数
#endif
#else
        static constexpr bool       TURN_USB    = true;             ///< USB を使う場合「true」
        static constexpr uint32_t   BASE        =  16'000'000;        ///< 外部接続クリスタル
        static constexpr uint32_t   PLL_BASE    = 240'000'000;        ///< PLL ベースクロック(最大200MHz)

        static constexpr uint32_t   ICLK        = 240'000'000;        ///< ICLK 周波数(最大200MHz)
        static constexpr uint32_t   PCLKA       = 120'000'000;        ///< PCLKA 周波数(最大120MHz)
        static constexpr uint32_t   PCLKB       =  60'000'000;        ///< PCLKB 周波数(最大60MHz)
        static constexpr uint32_t   PCLKC       = 240'000'000;        ///< PCLKC 周波数(最大200MHz)
        static constexpr uint32_t   PCLKD       =  60'000'000;        ///< PCLKD 周波数(最大60MHz)
        static constexpr uint32_t   FCLK        =  60'000'000;        ///< FCLK 周波数(最大60MHz)
        static constexpr uint32_t   BCLK        =  60'000'000;        ///< BCLK 周波数(最大60MHz)
#endif
    };
}
RX72T Start for Ray Trace: 320, 240
# Render time: 371ms (1)

実用になるのか?

スペックを超えて動作させるのは、現場では決して行わないが、アマチュアの遊びとしては、それなりに面白い。

現在、デバイスの入手性が極めて悪く、RX72T、RX72N、RX72M などはほぼ入手が出来ない状況となっている。
RX66T については、多少割高だが入手出来るようだ。(自分が買った時の倍近い)
※RX66T と RX72T は値段の差が少ないので(以前、潤沢にデバイスが買えた時期には、逆転現象もあった)、RX72T 一択となるだろうと思える。

まだ、タイマーなど、高クロックで駆動するペリフェラルを評価していないので何とも言えない部分もあるし、連続で動かしている時に停止するとか、色々なアクシデントはあるかもしれないが、とりあえず、動作は確認出来た。

周波数を制限する要因が何なのか、想像でしか無い為、非常にグレーな部分が多いものの、240MHz で動くなら、色々と有利な面も多い。

最近の半導体は、昔に比べて、マージンが大きいし、基本的なスペックは、元々の能力では無く、営業的な側面から決められている事も考えると、動いて当たり前なのかもしれない。

自分としては、低価格で購入でき、高性能な RXxxT シリーズは前から好きなので、これからもこのシリーズには注力したいと思う。


それにしても半導体不足はいつまで続くのか・・・

内燃機関に関する覚書

はじめに

いつもは、電子工作が中心な内容で、趣味のバイク関係がほんの少しの内容だが、最近の流れに伴った、事をつらつらと・・

CO2 と温暖化問題

この問題に関して、殆どの人はマスコミから流れてくる情報を100%信じていると思う。

そもそも、大気の0.02%しか無い CO2 が増えたから温暖化する科学的な根拠はいまだに示されていない。
※色々なメカニズムやデータは示されていても100人が納得するような根拠は乏しい物が殆ど。

以前にハワイのデータとして、「CO2 が増えたら、温度が上がった」グラフを観た事があるが、良く観ると・・
「温度が上がったら、CO2 が増えた」ように見え、実際、そうだった。
※温度が上がると海水に溶けている CO2 が揮発され、CO2 濃度が上がったものと推測される。

温暖化の CO2 犯人説は、IPCCが言っているポエムでしか無いと思われるが、何故か、この言説がまかり通っている。

これは、環境問題では無く、政治問題で、裏に隠れている本質は、世界の人口が増え過ぎた為に起こっているものと思う。
自然環境が劣化していると感じる大きなファクターは、人口が増えすぎた為に起こっているものと思われる。

大きな都市では、昔に比べて、ゲリラ豪雨(夏場)など、気象の変化が頻繁に起こると思われている。
この本質も、自動車だけでは、無い、エアコンの室外機の排熱が大きく関与しているものと思う。
※人口が少ない過疎地では、ゲリラ豪雨のような気候変動は少ない。
※エアコンの室外機は、今では、一部屋に1つはある勘定で、それが全て稼働していないとしても、都市部では莫大な熱量になる。

日本政府は、温暖化を理由に大きな税金を動かしている。
もし、本当にに CO2 が温暖化の要因なら、その税金分を発展途上国の為に使ったら、CO2 の削減を日本で減らす1000~10000倍は減らす事が可能と思う。
しかし、そのようには絶対にしないので、CO2 を根本的に減らそうとは思っていない事は明白だと思う。
単に税金を使う為の屁理屈に過ぎない。

分別とリサイクル

これも多くの人が騙されている問題と思う。

普通に考えて、分別したり、リサイクルしたら、多くのエネルギーや資源を浪費するので、環境には害悪でしかない。
※CO2 も余分に消費する。

たとえば、ペットボトルをリサイクルすると、余分に、多くのコストやエネルギー(コスト=エネルギー)がかかる。
※これは税金で負担されている。

  • 分別で余分にかかる輸送コスト
  • ペットボトルの清掃コスト(これがかなり大きい)
  • ペットボトルを分解して、材料にするコスト

これは、原油の精製から出てくる材料より多くのコストとエネルギーを消費し、しかも、製品の品質は、リサイクル品の方が低い。

それでは、どうすれば良いか?
現在の技術では、「燃やす」以外に経済的な方法は無い(将来、より良い方法が生まれるかもしれないが・・)
※焼却場では、分別により、水分が多いゴミが集中して、燃えにくくなっており、燃料をかけている場合があると聞く。


金属に関しては、分別して、回収した方が良いとの話もあるが、途中(改修や輸送など)で税金が使われているので、何とも言えない。
※これもある程度利権があるので、うさん臭い処がかなりある。


内燃機関は悪か?

欧州では、内燃機関自動車を廃止して電動自動車にシフトすると言っているが、それで、万事解決するような事項では無いのは誰でも判る。

  • 電気は多くの場合、火力発電所で作られるので化石燃料を使う。
  • 太陽光発電は、生み出すエネルギーが小さすぎて実用にはならない。
  • 原子力発電は、化石燃料よりウランの枯渇が速いと思われるし、放射性廃棄物を処理する事が出来ないので、やはり実用的とは思えない。
  • 送電線でロスする分と、リチウムイオンを主体とするバッテリーを製造する事による「環境負荷」が大きい。
  • バッテリー劣化による交換サイクルなどもかなり大きな環境負荷となる。
  • 原油を精製すると、軽油やガソリンは必ず一定量出てくるので、将来内燃機関の自動車が無くなったら、別の問題が発生する。

※将来、自動車に使われなくなった軽油やガソリンは、発電所で使われるものと思う。

他にも沢山あるが、「電動」が「内燃機関」より優れているとは(現状では)到底思えない。

なぜ、「電動」にシフトするのか?

多分、問題の一つは、現状で、高性能な内燃機関(ハイブリッド車)を全ての部品を製造して量産出来る国は日本しかない。

これが大きいものと思う。
こんな事を言うと、ドイツやアメリカでも内燃機関の自動車を製造していると言う人がいるが、「全ての部品」となると、やはり日本しかない。

たとえば、エンジンの中で、バルブ(排気、吸気)について考えても、ほぼ日本の独壇場で、高性能(長寿命で壊れない)な金属材料を作れる工場は日本にしか無い(日立金属だと思われる)。
※「たたら」による鋼の製錬をルーツ(日本刀の材料)に持っていると言われる。
※チタンバルブは、価格が高いのと、寿命が短いので量産車には利用出来ない。

中国はかなり長い間、単独で内燃機関の材料の製造、設計、組み立て、などを行う努力をしたが、日本の製造技術に追いつく事が出来ないのであきらめた、そこから「電動」にシフトしだした。
※中国単独で製造したエンジンの寿命は、日本製の 1/5 とか 1/10 程度しか無い。
※中国の高性能内燃機関自動車の多くは日本製のエンジンを OEM している。
※欧州やアメリカは、かなり前にお手上げ状態となっていて、日本製の部品を輸入したり、電動自動車に舵を切ったと思われる。

これら事実から、このまま内燃機関のハイブリッド車が支流になったら、自国の産業が死滅してしまうので、脱炭素とからめて高性能な内燃機関の日本車を排除する政治的な戦略を進めているものと思う。
このような「手練手管」は白人の独壇場だ、日本人はお花畑な人が多く、「人は卑劣な事をしないものだ」と思っているので簡単に騙される。

まとめ

マスゴミや、腐った政治家の言う言説を鵜呑みにしないで、自分で考えたり、調べたりしないと、間違った方向に誘導されてしまう事になるのではないか?

「自動車」メーカーが CO2 の削減とか言っていたり、電動自動車シフトに抵抗する様子が無いので、
多分、このままでは、内燃機関は駆逐され、将来は、嗜好品になり、クローズドコースだけでしか利用出来ないような世界になるのだろうか・・

WR250X のクラッチ修理(その2)

やっと修理出来たー

※ブレーキペダルが邪魔なので、外してある。

随分時間が経ってしまったが、やっと、クラッチの修理をした。


金属プレートの計測

クラッチ板は減るのは理解出来る、だけど、こんな「硬い」金属プレートが減るの?
ノギスで測ると、殆ど差が判らないので、マイクロメーターで計測してみた。

その「差」わずかに0.04mm、6枚で0.24mm、こんなの誤差のように思う・・

以前に「金属プレートを交換する意味」として、熱が入り歪む場合があると聞いたので、定盤に乗せて歪みを計ってみた。

※この状態で、プレートを回すと、歪みがあれば、数値が動くと思われる。

全く問題無い・・・

だけど、折角買ったので、新品に交換しておく・・・


クラッチスプリングを強化スプリングへ

色々調べると、WR250R、とWR250Xではスプリングが異なるようだー
※WR250Rの方が強化スプリング

そこで、強化スプリングへ交換した。

YZ125と同じ物との事で、純正ではないサードパーティー製を購入(少し安い!)

強化スプリングの方が自由長がかなり短い・・


クラッチホルダーの交換はスルー

一応、クラッチホルダーも購入したが、何だか勿体ないので、交換はしないで、とりあえず、この状態で様子を見た。

直った!

少し走ってみたが、以前のようにパワーをかけてもクラッチが滑る気配は全く無くなった。

多分、「強化スプリング」が利いているものと思う、それにしても微妙な不具合だなぁー

試走

とりあえず、近くの峠でガツンとアクセルを開けてみて滑らないか試してみたが全く問題無い。

ただ、やっぱ多少クラッチは重いかも・・

いつものコースで一回りしてみた。

  • 県道30号
  • 県道33号
  • 県道18号
  • 国道139号

やっぱりクラッチが滑らないと快適に走れて気持ちイイ~

2021年、扇山登山、その1

今年初めての登山

自宅から「扇山」山頂(1138m)へは直線距離で約3.5キロ、結構近いが、上れば往復6時間くらいかかる。

自宅からは、宮谷地区からの登山道を利用する事になるが、使う人がほとんどいない為、整備がされておらず、かなり荒れている。
それに、かなり大回りしなくてはならない・・

かと言って、鳥沢駅や、猿橋駅方向からだと、遠回りでもあるし、時間がかかり過ぎる。

そこで、最短ルートで登れそうな経路で登る、「アドベンチャースタイル」w、を開拓しつつある。
道は険しいが、登山道と違って面白味があるし、同じルートを通らないので、毎回新鮮だ。

この方法は、5回くらい、色々なルートで登って、「何とかなる」と思えるようになった。

今回は、新規ルート、事前に等高線を調べて考えたルートで登り、ほぼ同じルートで降りてきた。
※上りは3時間、下りは2時間30分くらい。

上りは意外と簡単だが、下りは難しく、稜線に沿って下りていると思っても、いつのまにかルートから外れて、急な斜面を降りていたりするので、細心の注意が必要となる。
間違ったルートを一旦下りてしまうと、登る事も降りる事も出来ないような、緊急事態になったりする。
※以前にそれで、崖から転落するとこだった・・
※砂防ダムも注意が必要で、絶対に小川を下りてはいけない事を悟った。

宮谷からの上り口

稜線はいくつもあるが、急過ぎて使えない場合や、生えている木の種類、倒木、岩の状態など、難易度が異なる。
また、最初はなだらかでも、途中で急こう配で登れない場合もある。(迂回も出来ない)
※2月頃、プレ登山で状況をある程度確認しておいた。

登山道からU字溝が見える場所から入っていく。
この辺りは、植林された木々で、作業用の道らしきものがあるので、それに沿って上っていく。
途中から稜線に沿って登っていく。

多分ルートは、上のようなもので、途中、急こう配があるが、それをクリアすれば、稜線に沿って登っていける。
1109mの処に合流しれば、通常の登山道となる。
ここまで来れば、整備されていて、登山客も多い。
この「赤い」ルートは単に稜線に沿って登るだけの簡易的なルートだが、所々、ピンクのテープが巻いてあるので、以前に誰かが上った事があるものと思う。
ルートには動物の糞(鹿や小動物?)や足跡がある、最近は、それが新しいのか古いのかが判るようになってきた。







写真で見える景色は、普通に見えるが、斜度はそこそこあり、登りは結構厳しい!

下りのルート選び

登山道では無い、稜線を下るのは、標高が高いと、道が狭く、他にルートは無いので、単純で簡単だが、降りるにしたがって勾配が緩くなると、行ける範囲が広がり、選択枠が多くなる。
そうすると、思ってもしない方向に行ってしまう事が起こる、それを補正しながら慎重に下っていく。

iPhone アプリ「ジオグラフィカ」を使い、ルートを外れていないか確認しながら降りていく。(このアプリ、非常に便利)

途中、間違ったルートを下りて登ってをしたが(ロスは100mくらい?)、無事に宮谷の登山道まで降りてこれた。

富士山は、途中見えていたが、山頂に付いた頃(お昼)にはガスって見えなかった。

多分、今までで一番速い。

それでも、6時間近く歩いたので、ヘロヘロになっていた、2日くらい筋肉痛だった・・

このルートは、中々面白いので、もう一回くらいは挑戦してみたい。
iPhoneの助けを借りずに、降りてこられたら、文句は無い。