AD9833(周波数シンセサイザ)のテスト

マイコンでA/Dコンバーターを使った、ストレージオシロぽぃ物を作る過程で、
機能検査を行う必要があり、手頃な信号発生器を探していた。

最近は良いデバイスがあるもので、ワンチップで、最大12.5MHzまで出力
可能なDDSモジュールが安く売られていたので、早速注文した。

※基準発信器付きで小さいモジュールとなっている。
※中華、船便なので、それなりの時間がかかるが格安。

早速、AD9833のライブラリをネットから取得して、自前のシステムに合うよ
うに、テンプレートクラスとして整形し直した。

このデバイスは、SPI通信で内部設定を行うので、マイコンで制御する必要があ
る。
そこで、とりあえずR8C/M120ANを使ってテストしてみた。
※このIC、3.3Vでも5VでもOKのようだが、とりあえず3.3Vで動作確
認。(モジュールに付いてるOSCはArduino系が主なので5Vと思えるが、
ちょっと調べた限りでは、どの電圧で動作するのか記述が見つからない・・)

サンプルは1KHzのサイン波を出力している。(起動するとデフォで1KHzの
をサイン波を出力する)

実用的に使うには、出力にアンプを追加したり、レンジ切り替え、周波数切り替え、
高性能なエイリアシング除去フィルターなど工夫が必要だと思うが、とりあえず、
機能を実験するだけのシンプルな構造になっている。

ソースコードは AD9833 Sample に上げてある。
※AD9833.hpp テンプレートは chip ディレクトリーにある。
※このデバイステンプレートは、他のマイコンでも修正無しで使えるはずだ。

—–
シリアルポートと57600(8ビット、1ストップ)で接続する事で、対話形式
で、周波数、波形の変更ができるようにした。

freq 2000     ---> 2000Hz
form tri      ---> 三角波
help          ---> ヘルプ
カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする

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

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

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

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


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

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

カテゴリー: バイク(自動車)整備, 中古住宅リホーム, 気になった事を・・・ | コメントする

中古住宅(リホーム:電灯スイッチ交換)

実際は、中古住宅購入後、真っ先にDIYした事だが・・
引越しと仕事が重なってブログを書く余裕が無かった。

パナソニックは、家電が主力なのかもしれないが、細かい部品も非常に優れた物が
多い。
それを感じたのは、何十年も前の小学生の頃だった。
親父に、コンセントが壊れたのでお使いを頼まれて、たまたま、パナソニックのコ
ンセント(部品)を買って帰ったのだが、凄く怒られてしまった、値段も少し高か
ったと思う。
※以前の物と形や大きさが違う為だった(同じものを買ってきて欲しかったと思う)
ところが、親父が、コードをネジで止めて、修繕が終わった頃にはご機嫌になって
いて、さっき怒った事を謝っていた。
なんでも、内部の細かい「出来」や「品質」、「設計」に関心した為だった。
※直ぐに、以前の物より格段に良い物だと感じたと思う。
それ以来、パナソニックの電気部品には、特別で最上のプライドを感じている。
今でも、細かい改造、改修が続けられており、より良い物に洗練され続けている。


中古物件とはいえ、スイッチが壊れていた訳ではないが、前からこのスイッチが気に
なっていたので、早速交換した。

これは、パナソニック製のほたるスイッチ「コスモワイド21」シリーズの物で、
多分、世界中探しても、この値段でこれ以上の物は存在しないとまで言えるくらいの
優れものと思っている。
※アマゾンでは、一般的な「ニ路」より「三路」の方が安いので、交換するなら「
三路」を買って、二本だけ繋げば良いと思う。

「ほたるスイッチ」は、「消灯」時にスイッチの場所を照らす淡い光が灯るもので、
以前は「ネオン管」が使われていたようだが、最近はLEDになっている。
消灯時に光らせる為、照明機器に微弱な電流を流す必要があるので、電気代が微妙に
かかるのだけど、利便性を考えると納得できる、また、スイッチは極限まで大きくて
押しやすく、とても使い勝手が良い。
また、沢山のバリエーションがあり、それらを組み合わせて、自由にカスタムが出来
る。
※当然「ほたる無し」のバリエーションもある。


4路スイッチ:
自分は工業高校の電気課を出ており、「電気工事士」の国家試験を受けて合格してい
るのだが、既に何十年も前で、又、実際にプロとして働いた経験は無い。

1つの電灯を1階、2階の二つのスイッチでON/OFFする方法は知っていた。
ところが、この中古住宅には、中二階があり、3つのスイッチで、1つの電灯を
ON/OFFしている。
どうやったらそんな事が出来るだろうと、考えたが、良い方法を思いつかない。
ネットで調べると、どうやら「4路」スイッチなるものがあるらしい。
結線図を見ると、「あーナルホド」と関心してしまったwww。
当然「コスモワイド21」にも「4路」で「ホタル」がある、ホームセンターで、
スイッチだけ購入して、入れ替えた。




交換は簡単なのだが、古いスイッチを外す際、コードのリリースボタンが固着してい
て、押しても感触が無くまったく外れない個体がいくつかあり、電線を切断して対応
した。
ビンの蓋を利用して、スイッチ金具を壁に当ててリリースボタンを押すと、力が入り
やりやすい。

カテゴリー: 中古住宅リホーム, 気になった事を・・・ | コメントする

中古住宅(リホーム:混合水栓の交換)

「混合水栓」の前に、トイレの「ボールタップ」を交換(結局1階、2階、両方)
した。
これが結構な値段で、1個4950円、痛い出費だったが、以前の物は、かなりや
れてて、リークはするし、手を洗うとこから水が出ないとか、もう駄目な状態だっ
た。

最初、ホームセンターに買いに行ったら、種類が沢山あり、どれを買うべきか判ら
なかったが、店員に聞いて、タンクの型番が判ればどれが適合するか判ると言って
いたので、出直した。
何でも、各メーカー(特にTOTO)、微妙に仕様の違うタンクを作りすぎて、製
品が溢れてしまい、部品の種類が多くなりすぎて管理できないような「無双」状態
らしい、それでも最近ようやく一本化したとか・・・
又、TOTOはパッキン類なども独自仕様(他メーカーに使えないようにしている
らしい)で、他メーカーと共通化していない為、TOTO製の蛇口や水周りの部品
を修理する際注意が必要らしい。
※TOTOって結構クソメーカーだったんだなぁー・・・


まず、今回購入した中古住宅の水周りで大きな問題が見つかった。
排水口の処理がいいかげんで、キッチン、洗面所で、排水パイプ(60パイ)に繋
がるホースが、ただ差し込んであるだけで、ガバガバな状態、普通はゴムのパッキ
ンなどで隙間を塞ぐが、それもしていない状態だった。

洗面台などは、そのおかげて、湿気が上がり、洗面台の下の空間がグズグズになっ
ていた、洗面台の下にある蛇口は、サビサビで、固着して使えない状態だったので、
新品に交換、洗面台も棄てて、新規に購入した。
※不思議なのは、前のオーナーは、何故、ほおっておいたのだろうか???
今回、排水パイプへの接続は、隙間の生じないタイプを見つけたので、色々加工し
て無理やり付けたが、水漏れは無い。




※エンビ用接着剤を使って、ジャバラホースとパイプなどを接着してある。

この交換は、洗面所のフローリングを修理した後にするので、今回は触れない。

さて、「混合水栓」の交換だが、かなり難儀した。

まず、古いやつはパッキンが駄目で、リークする為、最初はパッキンを交換すれば
良いと思ったが、既に製造を終了しており入手出来ないと聞いた。
そこで、最新の「混合水栓」を購入しておいた。

※ボールタップ地獄の真相を知る前だったので、TOTOを買ってしまった・・・
シャワーヘッドが外せて伸びるタイプで、水のフィルターも入っている豪華な
仕様だ、住宅を買った喜びで浮かれて高い買い物をしてしまったが、使ってみ
ると凄く便利で使いやすい、まぁこれはこれでいいかーー


古いタイプは、裏側に大きなナットがあり、それを外す必要がある。
※ここも、TOTOの製品乱発地獄の影響を受けたようだ。
このキッチンで混合水栓裏にアクセスするのは、非常にスペースが狭い。
目視の確認も出来ないので、水栓をネットで調べて、ナットの径を調査した。
その結果38mmと判り、一番安いレンチを購入したのだが、全然合わない・・
よく調べると、44mmとか46mmとか色々なバージョンがあるようだ・・・
※実際は46mmだった

また、レンチを買うのもバカバカしいので、プライヤーで回す事にして、裏板のベ
ニヤを少し切って広げ、手が入るようにしたのだが、非常に硬く締まっていて、か
なり頑張ったが、ビクともしない。

「もういいや古い水栓を破壊しよう」と言う事で、ディスクグラインダーで、切り
刻んで、無理やり外した、最初からそうすれば良かった・・・
※真鍮にメッキがしてあるのが判った。
※金属の粉だらけになった・・・

キッチンの側はステンレス製だが、0.3mmくらいのペラペラで、水栓を取り付
ける穴の裏に合板が当ててあるのだが、これがグズグズになっており、ボロボロ崩
れてくる。
このボロボロになった木屑をあらかた取り除いて、硬い合板(10cm四方10m
m、ホームセンターの木っ端売り場で購入した、フローリングの切れ端)に穴をあ
け(35mm)、接着剤を塗り、キッチンの裏に当て、混合水栓の取り付け金具を
固定した。


※裏からの作業なので、目に木屑が入らないようにゴーグルをして作業したが、口
に木屑が入った・・・


最新型の混合水栓は、固定方法が良く考えられており、5mmのボルト二本を使い
金具ではさんで固定するようになっている、金具は、上から入る(横にして入れる)
ように配慮された型をしており、落下しないように配慮されており、下からアクセ
ス出来なくても取り付けが出来るように工夫されている。

やはり、最新の「蛇口」は良くできている~

—–
モンキーレンチの正しい使い方?:

よく、車やバイクの動画で、「モンキーレンチの使い方が違う」とか鬼の首を取っ
たかのようにコメントする「ヤカラ」がいるけど、自分で整備をした事も無い、口
だけ達者な無知蒙昧なのかと思う。
と言うのも最近のモンキーレンチは、右周りでも左周りでも大丈夫なように設計さ
れており、可変サイズでも、「ガタ」が出ないような構造にしてある。
また、スパナと同じような角度がついている事で、回す角度が取れないところでも
裏、表と使う事ができるようになっている。
自分が使っているバーコのモンキーレンチもどちらで使って、力をかけてもも大丈
夫なタイプだ。(15年以上前に既にそうなっている)
また、ナットをゆるめる以外の使い方で、板を曲げたりもしているが全く問題無い。
「使い方が違う」と言っている人は、モンキーが壊れる(痛む)とか、ナットを舐
めやすくなるとか言いたいのだと思うが、それは、全く当てはまらない。
モンキーレンチは、工作精度や、仕組みを改善して、工具メーカーが進化させた新
しい工具の一つなのだ。
※こんな基本的な事は、知らなくても、使っていれば判る事なんだけどね・・

カテゴリー: 中古住宅リホーム, 気になった事を・・・ | コメントする

中古住宅(引っ越し編)

最近ようやく落ち着いた。

11月始め頃に山梨県大月市で中古住宅を購入。
ここに生活の拠点を移す事を計画、この計画は今年の初め頃から、中古住宅の物件を
探したり、色々情報を集めていた。
長野あたりに住む事も考えたが、大月市くらいなら、実家(埼玉)へも直ぐに帰れる
事から、大月、上の原、相模原などで探していた。

何故「山梨」かと言えば、「安い」からにつきる、それと、最近はネット環境があれ
ば仕事ができるので、都会に住む必要も無く、自然が近いところ、空気が綺麗で水が
美味しいとこなどに憧れがある。
※周りは山ばかりwww

値段が安いには理由がある、今回買った物件は、高速道路のそばであり、夜など静か
な時には、高速を走行する車の音がかすかに聞こえる、また、微振動もある。
※微振動については、下見では気がつかなかったが、それなりに揺れる。
色々不満はあるが、立川のアパートに5年住んだら、ペイできる金額なので、あまり
気にしていない。
築25年だが、それなりに綺麗で、引渡し後直ぐに住める状態、それで、4LDK、
庭付きのマイホームが入手できるのだから文句は無い。
それでも、「やれて」る部分はあるので、コツコツリホームするつもりだ、それも楽
しみと考えている。

12月も末になって、ようやく引越しも終え、立川のアパートを引き払い、住民票も
移動した。
※退去する際に、敷金を2ヶ月と、残り(日割り)の家賃を全て修繕に使い切ったの
で、1円も残らなかった・・・(言いくるまれた気もするが・・・)

引越しは、重い荷物は手伝ってもらったが、基本、ステップワゴンを使って全部自分
で荷物を運んだ。(引越屋に見積もりをとったところもの凄い金額になった為)
※多分12回くらいは往復したと思う。
※ETCの深夜割を利用したり、20号線で下道を使ったり、色々だったが、合計、
5万くらい(主にガソリン代)で出来たと思う。

苦労した点や、手順:
・かなり大きいブラウン管テレビがあったが、リサイクル券を購入して廃棄した。
・46型の薄型テレビは、かなり昔に買ったものだがまだまだ使えるので、友人に手
伝ってもらい運んだ。(最近のは軽いので一人で運べる)
・洗濯機も、壊れていたので、リサイクル券を購入して廃棄した。
・エアコンが二台あったので、自分でポンプダウン(冷媒を循環させて室外機に貯め
る操作)を行い、配管を外して、室内機、室外機を運んだ。(室外機はそれなりに重
いものの、一人で運べた)
※中古住宅購入時、ほぼ各部屋にエアコンは付いていたが、古い物が数台あるので、
自分で交換しようと思う。
・引越しの際、粗大ごみや燃えるごみなどを大量に処分したが、それでも、もの凄い
荷物が残った。(よく2DKの部屋に収まっていたものだと関心したww)
・100サイズのダンボール70箱(6900円)を使い、小物を運んだ。
・それ以外は、クリアケース、紙袋、など色々使い効率的に運んだ。
・小型フライス盤は、そのままでは重過ぎて腰を痛めそうだったので、コラムを外し
て、二つに分けて運んだ。(それでもかなり重い)
・小型旋盤は、ベアリング交換の為、分解していたので、普通に運べた。
・400リットルの冷蔵庫は、友人に手伝ってもらい運んだが、横にした為、何だか
調子がイマイチな気がする・・・(一応冷えているが・・・)
※運んだ後に気がついたが、横にしたら駄目らしい・・・(壊れたかもしれない・・)

まずは、トイレから~、この家、トイレが1階と2階にあるので、温水便座を買い足
した。

DL-WL20(Panasonic)
DL-WL20(ECカレント販売)
以前からパナソニック製を愛用していて、非常に優れていると感じる。
今回も、以前に買ったシリーズと同じだが、改修されておりより良くなっている。
以前の物は二階のトイレに設置した、まだ使えるけど、新しいのが凄く良いので、買
いなおそうかと思ってる。

今回はここまで。

カテゴリー: 中古住宅リホーム, 気になった事を・・・ | コメントする

MSYS2/mingw64 で boost/asio を使う場合の要点

MSYS2 では、BSD ソケットの API を使う場合は、msys2 環境で行う必要があり、
mingw32/64 環境では、windows 依存の WinSock2 などを使う必要がある。
※WinSock は、BSD ソケットに似ているが、完全に同じではなく、BSD ソケット
用に書かれたソースコードをそのままコンパイルする事は出来ない。

そこで、今後の互換性(マルチプラットホーム)や、発展性を考えて、boost/asio
を使う事にした。
mingw32/64 では、boost の環境依存ライブラリーをパッケージマネージャーで簡
単に導入できるので、コンパイルする必要も無い。
多くのサンプルが、VC環境の場合が多く、MSYS2 環境で、gcc や clang での利
用方法が少ないので、覚書程度に要点をまとめてみた。

まず、boost をインストールする。
現在は、

 % pacman -Ss boost
mingw32/mingw-w64-i686-boost 1.63.0-1
    Free peer-reviewed portable C++ source libraries (mingw-w64)
mingw64/mingw-w64-x86_64-boost 1.63.0-1 [インストール済み]
    Free peer-reviewed portable C++ source libraries (mingw-w64)

「1.63.0-1」がカレントのようだ。

※インストールする場合

 pacman -S mingw-w64-x86_64-boost

—–
サーバー、クライアントのサンプルは、TCP – boostjpが判りやすい。

コンパイルの際に注意する点として:

-DWIN32 -DBOOST_USE_WINDOWS_H -DWIN32_LEAN_AND_MEAN

を定義しておく必要があるようだ。

また、リンク時のライブラリーは、

boost_system-mt ws2_32 wsock32

をリンクする必要がある。
※OS-X や Linux 環境では、「boost_system-mt」だけリンクすれば大丈夫だ。

あと、boost が出力するエラーメッセージは、日本語化されているのは良いのだが
CP932(ShiftJIS)な為、UTF-8 などに変換する必要がある。
※もしかしたら、UTF-8 を標準にする切り替えが出来るのかもしれないが調べてい
ない、ただ、コンパイルし直す必要があるかもしれない・・

—–
コネクション(同期関数利用)の際に、エラーが発生した場合に、エラーステート
か、例外の補足を選択できるようだが、私の環境依存なのか、コアダンプが出て正
常に動作しなかった、async_connect にしたら、問題は解決した。
※mingw64 の boost 絡みのバグなのかもしれない・・・
※OS-X で同じプログラムを動作させると、問題無く動作した。

あと、asio を使ったサンプルは、動作しないものもあるようなので、注意が必要と
思う。
サーバーとクライアントが不明確だったり、関係性を説明していないものも多く、
単純には動作しないものもある。

基本的に、TCPでは、サーバーを動作させて待機しておき、クライアントが接続に
行くスタイルなので、単純に繋げて、データをやりとりする事は出来ない。
少なくとも、サーバーとクライアントのプログラムを実装する必要がある。

boost::asio は使ってみると、良く出来ていると感じる、それでも、タイムアウトし
た場合のケアなど、かなり前もって緻密に設計しておかないと、後で苦労しそうでは
ある。
また、例外でエラーを受け取るのは、ソケットの場合、以外と相性が悪いかもしれな
い。
※非同期で行う場合は特にそう感じる。

カテゴリー: ソフトウェアー・エンジニアリング | コメントする

RXマイコン、TPUテンプレートクラス、その1

最近、仕事が忙しく、更新が無かった・・・

RXマイコンでタイマー割り込みに使うのに適したペリフェラルはCMTだろ
う、単機能、シンプルで扱いやすく、理解しやすい。

しかし、CMTのカウンターは16ビットだが、プリスケーラーの仕様により
最大で、PCLKBの1/8の周期になってしまう為、間隔の短いタイマー割
り込みを組みたい場合に、誤差が大きくなる場合がある。
※メインクロックとの相性もあるが・・

そこで、他の選択肢としてTPUを使ったタイマーを実装する事にした。
※TPUは、PCLKBの1/1を選択可能なので、より正確なタイミングを
生成でき、ポートの出力も制御できる。

TPUユニットは、RX24Tには無いが、RX64Mには、1ユニット、6
チャネルある。
※RX631、RX63Nなどにもあるようだ。

ただ、面倒なのが、割り込み設定で、RX64Mではモジュールが大量に増え
た為、TPUの割り込みは固定ベクターではなく、選択的なベクターになって
いる。
TPUの操作をテンプレートで実装する場合に、割り込みベクターの管理を自
動で行いたいので、工夫してみた。
※RX631のTPUは、固定ベクターなので、その辺りも上手く吸収できる
ようにしなければならない。

また、TPUの機能は、タイマー割り込みの他、色々な機能があるので、それ
も簡単に扱えるような工夫が必要となるが、全ての機能を盛り込むと、設定が
複雑になるので、ある程度は妥協も必要で、その辺りのバランスが難しい。
※現在は、拡張中・・


TPUを考える前に、省電力機能の管理を少し拡張した。
「省電力機能」は、内部ペリフェラルの電源を「On/Off」して、使わない電力
を削減できるもので、起動時、最低限必要なものしか有効になっていない。
※ドライバー実装時、この省電力を「無効」にするのを忘れて、ペリフェラル
が動作せずに、時間を浪費した事があるのでは無いだろうか?
※注意事項には書いてあるのと、「お約束」ではあるのだが・・

ペリフェラルのテンプレートでは、個別IDを設定しておいて、それを定義に
忍ばせておく事で、他の連携クラスが、固有の動作を切り替えて実現でき、ま
た、連携クラスの実装分担を、ペリフェラルの定義から分離できる。

この簡単な仕組みにより、ペリフェラルの実装時、ペリフェラルやチャネルに
より異なる実装を隠蔽できる。

自分は、「手」を動かす事が好きなので、あーでもない、こーでもないを繰り
返して今の実装になっている。

ペリフェラルの定義:

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  ペリフェラル種別
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
enum class peripheral : uint16_t {
    TPU0,   ///< 16 ビットタイマパルスユニット0
    TPU1,   ///< 16 ビットタイマパルスユニット1
    TPU2,   ///< 16 ビットタイマパルスユニット2
    TPU3,   ///< 16 ビットタイマパルスユニット3
    TPU4,   ///< 16 ビットタイマパルスユニット4
    TPU5,   ///< 16 ビットタイマパルスユニット5

...

};

TPUの定義:

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  16 ビットタイマパルスユニット(TPUa)
    @param[in]  base    ベースアドレス
    @param[in]  per     ペリフェラル型
    @param[in]  intra   割り込み要因A
    @param[in]  intrb   割り込み要因B
    @param[in]  intrc   割り込み要因C
    @param[in]  intrd   割り込み要因D
    @param[in]  intru   割り込み要因U
    @param[in]  intrv   割り込み要因V
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <uint32_t base, peripheral per,
    uint8_t intra, uint8_t intrb, uint8_t intrc, uint8_t intrd, uint8_t intru, uint8_t intrv>
struct tpux_t {

...

    //-----------------------------------------------------------------//
    /*!
        @brief  ペリフェラル型を返す
        @return ペリフェラル型
    */
    //-----------------------------------------------------------------//
    static peripheral get_peripheral() { return per; }
};

TPUチャンネル毎の定義:

typedef tpux_t<0x00088110, peripheral::TPU0, 15, 16, 17, 18,  0, 19> TPU0;
typedef tpux_t<0x00088120, peripheral::TPU1, 20, 21,  0,  0, 22, 23> TPU1;
typedef tpux_t<0x00088130, peripheral::TPU2, 24, 25,  0,  0, 26, 27> TPU2;
typedef tpux_t<0x00088140, peripheral::TPU3, 28, 29, 30, 31,  0, 32> TPU3;
typedef tpux_t<0x00088150, peripheral::TPU4, 33, 34,  0,  0, 35, 36> TPU4;
typedef tpux_t<0x00088160, peripheral::TPU5, 37, 38,  0,  0, 39, 40> TPU5;

※「割り込み要因」は、選択型割り込みを設定する際に必要なIDで、チャネル
毎に機能が微妙に異なるが、シンプルな定義になっている。(0は、割り込み要
因が存在しない場合)

省電力管理で、必要な要素として、チャンネルの起動と廃棄時、まだ、使ってい
るチャネルがある場合に、省電力機能を無効にしないようにする事で、リファレ
ンスカウンタのような仕組みが必要な点だ。

実装は、簡単なのだが、スタティック変数の定義問題がある。
現在、ほぼ全ての実装は、ヘッダーのみで行っているので、それを壊したくは無
いが、単純にスタティック変数を記述すると、その実態として、ソースコードに
も書く必要があり、そうすると、そのソースコードのオブジェクトをリンクしな
ければならなくなる。

そこで、簡単なテンプレート関数を書いて、その中で定義できるようにした。
テンプレートにすると、「実態」をヘッダーに書けるので、ソースとヘッダーに
分ける必要が無くなる。

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  スタティック・ホルダー・テンプレート・クラス
    @param[in]	ST	構造体
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <class ST>
class static_holder {
public:
    static ST    st;
};
template <class ST> ST static_holder<ST>::st;

実際の定義では以下のようになっている。

struct pad_t {

    uint8_t    tpu_;

    pad_t() : tpu_(0) { }
};
typedef utils::static_holder<pad_t> STH;

この構造体の具体的な操作は、「RX64M/power_cfg.hpp」で行っている。

これら関連したコードはGitHubにプッシュ済み。

今回はここまで。

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする

RL78関係をマルチデバイスに対応する

RL78を再開したのは、RL78関係の仕事を受注したのが大きい。

本来R8CやRXもまだまだなので、RL78をやるのは、現状では良く
ないが、仕事を請けたので、仕方がないが、丁度良かったかもしれない。

RL78は、他のマイコンに比べて、かなり魅力的なところがある。
・以外と高速で動作する。
※WAVファイル(16ビット、48KHz)をSDカードからSPIで
読み、再生する能力がある。
・とにかく電気を食わない。
・周辺機器(UART、I2C、SPI、ADCなど)が充実している。
・C++ で開発が可能。
・デバイスの値段が安く、バリエーションも多い。

マイナス要因:
・グループ(シリーズ)が多すぎる。
・内部は基本8ビットなので、32ビットなどの値を扱うと、肥大化して
遅くなる。
・アクセスできる範囲は16ビットが基本なので、64Kの空間を、特別
なポリシーを使って、RAM領域と、ROM領域に分けている為、設計の
段階で気を使う必要があり、リソースの再利用でも、注意を要する。
※これが結構、判りずらい場合がある。

仕事では、G13とL1Cグループに対応して欲しいとのオーダーを受け、
G13専用の構造を修正して、L1Cも含めるように改修した。

RXマイコンで複数グループ対応を行い、どのような構造にするとシンプル
(アプリケーション側でグループの違いを意識しなくて済む)になるのか、
実績があるので、それらの構造を継承している。

・デバイスのクラスでは、「ペリフェラル」型を設定して、それを取得でき
るようにした。

たとえば、SAU(シリアル・アレイ・ユニット)では、以下のテンプレート
として実装されている。

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  シリアル・アレイ・ユニット・テンプレート
    @param[in]  PER     ペリフェラル型
    @param[in]  UOFS    ユニット・オフセット(0x00、0x40)
    @param[in]  CHOFS   チャネル・オフセット(0x00, 0x02, 0x04, 0x06)
    @param[in]  SDR_O   SDR レジスターオフセット
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <peripheral PER, uint32_t UOFS, uint32_t CHOFS, uint32_t SDR_O>
struct sau_t {

...

    //-------------------------------------------------------------//
    /*!
        @brief  ペリフェラル種別を取得
        @return ペリフェラル種別
    */
    //-------------------------------------------------------------//
    static peripheral get_peripheral() { return PER; }
};
typedef sau_t<peripheral::SAU00, 0x00, 0x00, 0x00> SAU00;
typedef sau_t<peripheral::SAU01, 0x00, 0x02, 0x02> SAU01;
typedef sau_t<peripheral::SAU02, 0x00, 0x04, 0x34> SAU02;
typedef sau_t<peripheral::SAU03, 0x00, 0x06, 0x36> SAU03;

「peripheral」は、enum class で定義されている、RL78のデバイス機能
分類。

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

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  UART 制御クラス・テンプレート
    @param[in]  SAUtx   シリアル・アレイ・ユニット送信・クラス(偶数チャネル)
    @param[in]  SAUrx   シリアル・アレイ・ユニット受信・クラス(奇数チャネル)
    @param[in]  BUFtx   送信バッファサイズ(8バイト以上のサイズである事)
    @param[in]  BUFrx   受信バッファサイズ(8バイト以上のサイズである事)
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <class SAUtx, class SAUrx, class BUFtx, class BUFrx>
class uart_io {

割り込み関係を設定する場合、以下のようにシンプル
に書ける。

    intr::set_level(SAUtx::get_peripheral(), level);
    intr::set_level(SAUrx::get_peripheral(), level);
    intr::enable(SAUrx::get_peripheral());

また、ポートの設定などは、デバイス毎にイレギュラー的に異なるが、これも
シンプルに書ける。

manage::set_uart_port(SAUtx::get_peripheral());
manage::set_uart_port(SAUrx::get_peripheral());

「L1C」は扱ってみると、「G13」と大きく違う事が判った。
・割り込みテーブルのエントリーがかなり異なり、完全に分ける必要がある。
・当然割り込み関係のハンドリングも異なるので、これらの違いを隠蔽して
ドライバーからは同じように扱えるように改修作業を行っている。
・L1CはUSB対応デバイスの為、最大動作周波数は24MHzとなって
いる。
※ソフトディレイをかなり強引な方法で実装している。
・A/Dコンバーターは、12ビットになっている。(G13は10ビット)
・DMAコントローラーが廃止され、DTC(データトランスファコントローラ)
と、ELC(イベントリンクコントローラ)が追加されている。
・USB2.0コントローラーがある(L1C特有)
※USBは、PC側のドライバーが関係するので、簡単では無いが、USB
接続機器を接続する事が出来るのは大きいかもしれない。
※2.0と言っても、フルスピード(12Mbps)、ロースピード
(1.5Mbps)しかサポートされない。
・LCDコントローラーを内臓している。(今回は使用しない)

今回使っているデバイスは、FlashROM:64K、RAM:8K、デー
タフラッシュ:8Kの仕様で、gcc リンクファイルの領域記述を誤り、謎の
挙動を示した、しばらく原因不明で苦労したが、ようやく原因を特定して、
思ったように走るようになった。

※個人的にはG14グループを使いたいなぁーと思うのだが・・・

—–
ハードウェアーマニュアルの書き方が、日立や三菱系では無く(多分NEC系)
慣れが必要で、レジスターの令名規則も、構造的になっていない為、テンプレート
クラスを実装する際、整理しないと駄目なところが痛い。
※アセンブラで、直接ビット操作をするような場合には都合が良いのかもしれ
ない・・
※RXの三菱系が一番スマートだと思う。

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする

RL78を再開

以前に、gcc では、内部データフラッシュメモリーへのアクセスがサポートされない
事で、開発をストールさせていたが、GR-Cotton でRL78/G13が使われており
WEBコンパイラは gcc となっている、また、データEEPROMのアクセスライブ
ラリーもあるようなので、これらを利用する事にした。
※以前に、ルネサスのIDEでは、RL78はC++をサポートしないので、gcc 用
ライブラリの提供をお願いした際「できません」と断られた事があった。

GR-Cotton では WEB コンパイラで gcc を使っていて、gcc 用ライブラリーを同梱し
ている。
それなら、それを教えてくれてもいいと思うのだが、ケチくさいと言うか、イジワル
と言うか、全く話にならない対応だった(経験的に海外のメーカーでは、このような
不親切な対応は行わないと思う)
※それでもルネサスを使うのは「ドM」と言われても仕方ないが・・・

今回、仕事でRL78のオファーを受けた事で、データ・フラッシュは必須なので、
検討を始めた。
以前に、データフラッシュライブラリのオブジェクト(CS+IDE)をダンプした
ら、リバースエンジニアできそうな感じだったのだが、gcc 判があれば話が早い。

早速、GR-Cotton のプロジェクトを作成して、ソースコード一式を入手した。

その中にデータEEPROM操作関係のAPIがあるので、関係する部分を取得して、
自分のシステムに組み込んでみた。
※肝心な部分は、やはり、ライブラリーになっており隠蔽されている。(pfdl.a)

「pfdl.a」は、2つのオブジェクトをアーカイブしたものであるようだ。

% rl78-elf-nm pfdl.a

pfdl.o:
0000009d R _PFDL_Close
00000025 R _PFDL_Execute
00000091 R _PFDL_Handler
00000000 R _PFDL_Open
0000009d R PFDL_Close
00000025 R PFDL_Execute
0000006b r PFDL_Execute_erase
0000008a r PFDL_Execute_exit
00000061 r PFDL_Execute_firmware
0000007c r PFDL_Execute_read
0000007f r PFDL_Execute_read_next
00000091 R PFDL_Handler
00000000 R PFDL_Open

pfdl_version.o:
00000000 R _PFDL_GetVersionString
00000009 R _PFDL_VERSION_STRING
00000000 R PFDL_GetVersionString

ライブラリから、オブジェクトを分解して、肝心なオブジェクトを逆アセンブルして
みた。

rl78-elf-ar x pfdl.a
rl78-elf-objdump -D pfdl.o > pfdl.lst
00000000 :
   0:	c1                            	push	ax
   1:	c3                            	push	bc
   2:	a8 08                         	movw	ax, [sp+8]
   4:	71 00 90 00                   	set1	!f0090 .0
   8:	c7                            	push	hl
   9:	16                            	movw	hl, ax
   a:	bf 04 08                      	movw	!f0804 , ax
   d:	8c 01                         	mov	a, [hl+1]
   f:	9f 01 08                      	mov	!f0801 , a
  12:	e5 03 08                      	oneb	!f0803 
  15:	f2                            	clrb	c
  16:	fc f8 ff 0e                   	call	!!efff8 
  1a:	c6                            	pop	hl
  1b:	cf 80 08 04                   	mov	!f0880 , #4
  1f:	62                            	mov	a, c
  20:	9d f0                         	mov	0xffef0, a
  22:	c2                            	pop	bc
  23:	c0                            	pop	ax
  24:	d7                            	ret

上記は、PFDL_Open API の逆アセンブルソースだが、妙なアドレスをアクセスしている。
「F0804、F0801、F0803、F0880」これは、データフラッシュ関係の
制御レジスターと思われる。(ハードウェアーマニュアルには記載は無い)
また、「EFFF8」をコールしている、この部分に、データEEPROMのファーム
があるものと思われる。(このファームの存在も、一切記述が無い)

※改めて思うが、何故、隠蔽して、情報をオープンにしないのか、全く理解に苦しむ。
※本当に知りたいのなら、リバースエンジニアリングできるし、制限を設ける理由も思
いつかない。(ユーザーは不便になり、メーカーはサポートする仕事が増えるだけ)

早速テスト・・・
PFDL_Open関数を呼び出すと、戻ってこない・・・
PFDLライブラリのドキュメントを調べると、暗黙的に利用するワークRAMがあるよ
うだ。(セルフRAM領域)
※不思議な事に、デバイスにより、必要な場合と不必要な場合がある。
しかし、自分が使っているRL78/G13(R5F100LG)では、セルフRAMは
必要無い。
また、これとは別に、デバイス共通で、RAMの最終アドレス付近は、(0xFFE20
~後ろ)はライブラリの利用領域として予約されている。
※スタックやデータバッファと記述がある。

自分は、スタックを共有する為、RAMの最終アドレスを設定している。

色々、悩んだ末、解決した。
どうやら、ライブラリ内では、スタックを再設定して、内部処理を行い、ライブラリを出
る時に元に戻しているようだ。
この動作の為、共有していると正常に動作しないようだ、アプリ側のスタックを完全に分
離して、オーバーラップしないようにしたら、あっけなく動作した・・・
※これだからブラックボックスは嫌いだ・・・(まぁ自分の思い込みが原因ではあるけど)

以前にRXマイコンで作成した、対話形式で、データフラッシュの操作を行うプログラム
を組み込んで、実際に操作してみた。

問題なく書き込める!

とりあえず、操作できるようだ、これで、RL78も他のマイコンと遜色無く使える事が
判ったので、色々利用してみたい。
RL78はコストが安いので、R8C/M120とRXの中間を埋める「駒」として重宝
しそうだー

RL78データフラッシュサンプル

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする

VL53L0Xを使ったR8C(100円マイコンM120AN)による距離測定

中華製、VL53L0Xのモジュールを入手したので、距離を測定する実験を行った。

元にしたソースは、Arduino の物で、ほぼ、そのまま利用させてもらった。
ただ、Arduino のソースは、ヘッダーとソースに分かれており、C++の有意義な部分
を使っていないものが多く、その辺りは、C++流に書き換えた。

たとえば・・
・「define」マクロ関数を使っている。
※C++では、define マクロを使って関数を定義するメリットは全く無いので、一般的
に使う必要性が無い。
※実行速度も改善されないし、「型」の検査や、定義を台無しにしてしまう。
・生の「enum」を使っている、C++では、「enum class」を使う事で、冗長な書き方
や不整合を回避できる。
※部分的には、逆に「冗長」になる場合があるが、「型」安全になるので許容する。
・(定義)ヘッダーと、(実装)ソースを分ける必要性が無い。
※Arduino では、ソースとヘッダーに分かれている。
※ヘッダーに全て書けば、管理や、修正などが簡単で、間違いが少ない。
・VL53L0XはI2Cインターフェースで通信を行うが、元のソースは、I2Cの
標準的なAPI(Cの関数)を呼び出して使っている。
※I2Cのインターフェースクラスは、テンプレートで渡す仕組みにしている。
・「参照」渡しが使われていない。
※わざわざ、ポインターにする必要が無い。

I2Cは電源を入れると、4ピンなので、写真のようなコネクターを使っている。
片側は4ピン、片側は2ピンx2となっており、電源、信号接続の違いを吸収できる。

メイン部分では、I2Cを初期化して、LX53L0Xを初期化する。
※R8C/M120ANでは、ソフトウェアー処理でI2Cを実現している。
距離の測定は、「単発」で行い、0.5秒おきに、コンソールに出力する。

・I2C、VL53L0Xの定義

    // I2C ポートの定義クラス
    // P4_B5 (12): SDA
    typedef device::PORT<device::PORT4, device::bitpos::B5> sda_port;
    // P1_B7 (13): SCL
    typedef device::PORT<device::PORT1, device::bitpos::B7> scl_port;

    typedef device::iica_io<sda_port, scl_port> iica;
    iica	i2c_;
    typedef chip::VL53L0X<iica> VLX;
    VLX		vlx_(i2c_);

・初期化

// I2C クラスの初期化
{
    i2c_.start(iica::speed::fast);
}

// VL53L0X を開始
if(!vlx_.start()) {
    utils::format("VL53L0X start fail\n");
} else {
    // 20ms
    vlx_.set_measurement_timing_budget(200000);
}

・メインループ

    ++itv;
    if(itv >= 50) {
        auto len = vlx_.read_range_single_millimeters();
        utils::format("Length: %d\n") % len;
        itv = 0;
    }

出力される距離には、50mmオフセットが加算されているようだが、正確だ!

VL53L0X.hpp

VL53L0X R8C/M120AN サンプル

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする