湿度センサーを18LF2550で使うには? その1


「18LF2550のRC4、RC5はデジタルポートとして使用する場合は、他のPORTCのピットとは異なり、TRISCの設定がなく、インプットポートとしてのみ使用できる」とデーターシートに書いてありました。
PIC 18LF2550を使用するならば、ノキア5110LCDはこのままの配線では表示ができない事が判りました。

その後、ノキア5110LCDへの配線を18LF2550の別の空きポートへ移動してちゃんと表示ができる様になりましたが、どうしても湿度センサーとだけ通信ができません。

どうも、もっと根本的な制御部分の考え方を調べ直す必要が有る様です。
全てのキーワードはオープンドレインの様です。


PICのそのポートがオープンドレインであるかないかで、
制御のしかたを考え直さなければいけないのでした。

今回の様に、オープンドレインでないPICでも信号のやり取りはできるがその場合は、
PICがデータを出力をする場面なのか、
PICがデータを貰う場合なのかで、
PICの双方向ポートに利用している最終段の出力の
トリステート管理(ハイインピーダンス、”H”、”L”)
をうまく利用していないと駄目だという事です。

それが、エレキジャックさんの
(3)双方向のDATAポートのドライブについて
にちゃんと書いてありました。

オープンドレインではないポートを双方向ポートとして利用するには、
そのポートを出力として”L”レベルにしておいたままで、
TRISコントロールと、プルアップ抵抗をうまく使って、
送信(出力)、受信(入力)を行うのです。

オープンドレインではないポートをTRISコントロールで”インプット”に設定すると、
PIC内部のポート部分に仕込まれた回路で、
そのポートが「ハイインピーダンス状態」になるようになるように設計されています。

そのポートが出力として”H”であっても、”L”であっても、
そのポートが「ハイインピーダンス状態」の時は、
このポートの出力先のラインが抵抗でプルアップされていれば、
相手から観れば常に"H"レベルになっているわけです。

これをPICからデータを貰う側から観た時の”H”信号として使うわけです。

それで、このPICのポートで相手からの信号を読み込む時は、
そのポートが「ハイインピーダンス状態」のままでデータをPICに読めば、
”H”はHighレベルになり、
”L”は抵抗でプルアップされていても電流が抵抗でのみ軽く消費されるだけで済み、
SW等の入力と同様にLowレベルとして読めるのです。
もちろんこれがプルアップ抵抗の本来の役割ですから。

このPICのポートを使ってPICからの出力として”L”を相手に送りたい時のみ、
このポートをTRISコントロールで出力ポートに設定すれば、
始めから出力として”L”設定してあった”L”レベルになる。

こうする事によって、
オープンドレイン仕様ではないポートでも、
出力のショートを起こさないで、
ちゃんと双方向にデーターを送受信できるというわけです。
(なお、24FJ64GA002は、デジタル出力は、オープンドレイン構成が可能です。)  

ソフトを変更して、もう一度18LF2550に挑戦してみます。
プログラム容量がフラッシュラム32Kバイト(# Single-Word Instructionsで16K)と大きく16F886の2倍もありあます。

SRAMデータメモリーも2048バイト、EEPROMも256バイトあります。EEPROMは24FJ64GA002に実装されていません。

18LF2550のピン配列も16F886と殆ど互換性があるので、
このままの実験ボードが使えますから、
どうしても利用したいのです。

その後で 24FJ64GA002への挑戦をします。

例によって、いつになる事やら。(Aug. the 7th 2010)


18LF2550でも、16F886と完全互換で稼働いたしました。また、ハード回路図が変わりました。


16F886での14ピン:RC3は、18LF2550では:VUSBとなっていて、内部のUSB電源装置の安定用コンデンサー(C18:1.0μ)を繋げて使用する端子となっており、デジタルI/Oとしては使えません。

また、18LF2550では、RC4、RC5はデジタルI/Oポートとして使用する場合には、入力ポートとしてのみ使用できますが、出力ポートとしては使用できませんので御注意下さい。

下記リンクより、16F886用プロジェクト、18LF2550用プロジェクトをダウンロードして下さい。
供に上記のハードウエアにて動きます。

16F886prrh14.zip(このソースはI/Oインターフェースのショートの問題を含んでいて、稼働できない場合がありるので、掲載を取りやめました。)

18LF2550prrh14.zip(御注意!このソースプログラムは、一応稼働いたしますが、私が無理にいろいろなインターフェースを詰め込んでしまった為に、様々な問題を含んでいて、やはりお進めできません。)

例によって、このソースプログラムは、PICC Pro Lite により書かれています。
気圧センサー部分を含むプログラムの根幹は全て、パレットソフトさんのプログラムを利用しています。

ノキア5110表示用のライブラリー部分は、
CQ出版の「トランジスタ技術2006年3月号」に掲載された、
R8C/15付録マイコン基板活用企画 
第9回 小型グラフィック液晶表示器で作る簡易温度計 山本 秀樹氏 のR8C/15用ソフトウエアをPICC Pro Lite用に移植して使用しています。

湿度センサーSHT-11とのインターフェース部分は、今回はエレキジャックさんのソースリスト利用しております。非オープンドレイン対応でPICの双方向I/O通信をポートバッファ方式で行っています。


この18LF2550と、16F886で、同じハードウエアを共用する事で、思わぬメリットがありました。

それは、メモリー容量の残りが少なくなった16F886では出来なかった事を、メモリー容量の大きな18LF2550でソフトウエアの見直しや、デバッグを行い、ダウンサイジングを行ったソースを、16F886へ移植して使う事が出来るのです。

おかげで、浮動小数点演算を止めて整数演算にするだけで、1K分のメモリーが節約できる事が判りました。

また、湿度センサーのSHT-11との双方I/Oを行うポート(ビット)は、本来オープンドレイン構造のPIC(16F886等)のI/Oポートでのみ利用可能です。非オープンドレイン構造のPICの場合、1つのポート(ビット)で双方の出力が"H"&"L"と食い違った場合に、回路がシュートして破壊する恐れが有るのです。

これを避けて使用する常套手段として、このページの先頭で説明した様に、外部に設けたプルアップ抵抗と、トリステートポートの読み込み設定時が、ポートのハイインピーダンス状態となる事をうまく利用して、非オープンドレインポート構造のPIC(18LF2550等)でこの双方向通信を行う方法があります。

ところが、この方法にはPICのさらなる内部構造から由来する問題が有ります。それは、PICが入力情報を読み込む際に、出力用に使用されている内部のラッチレジスターの値を変更してしまう場合が有るのです。書き換わり現象です。

こうなると、非オープンドレインでの双方向通信が成り立たなくなってしまいます。
PIC 18LF2550もこの書き換わり現象が現れてしまいました。

これは、PICの内部構造の問題なのですが、本来1つのポート(ビット)を双方に使用する事を想定していないのですから致し方ないのです。

それを避ける方法が、ポートバッファリングです。
エレキジャックさんの所で説明されていますが、8ビットをまとめてSHT-11の為にだけ使う事を想定しているので、このままでは、他の用途に使用している入力ビットは共存できますが、他の用途に利用する出力ビットがこのポートの8ビット内に存在する場合は、それぞれの状況を統括して管理する必要があります。

これを解決する良い例が、パレットソフトさんが行っている、device.c での統括管理です。パレットソフトさんでは、プログラムソースは、非常に上手く標準(モジュール)化されていて、device.c部分を、ハードウエアの状況や、使用しているアプリケーションに合わせて変更するだけで、既に出来上がっている各モジュール部分には殆ど手を加える事無く、それらを組み合わせて、いかなるCPUにも再利用可能な状態になっているのです。

これで飯を食っているのですから、趣味でやっている私とは大違いなのですが、ソフトウエアとしての信頼性が高く、しかも柔軟性の高いソフトウエアであり、また、後からのデバックが大変楽です。

いまや、私のソフトウエアは、継ぎはぎだらけのソフトウエアとなってしまっており、そのうちに自分でも何が何やら分からなくなってきてしまいそうです。現在とりあえず動いている事の方が不思議なくらいです。

今一度、ソフトウエア全体を見直して、device.c をちゃんと書き直す必要が有る様です。
(Aug. 12th 2010)


ここで、16F886と18LF2550との共通プログラム間の異なる部分、つまり相互に移植する際に異なる部分を覚え書きとしてまとめておきます。

1.PICC Pro 18 Lite では、pic.h は使えないので、htc.h に書換えて下さい。

PICC Pro Lite の #include 文の先頭で、12F/16F系コンパイラは、
#include <pic.h>
あるいは、
#include <htc.h>
のように、pic.h も、htc.h のどちらか一方を使用できます。

ところが現状のPICC 18 Pro Lite コンパイラは、
#include <htc.h>
のように、htc.hしか使用できません。

12F系や16F系のPICC用のソースリストから18F系へ移植する場合には、pic.h を htc.h に全て置き換えないとコンパイル時にエラーメッセージが出ます。

その逆に、18F系のPICC用のソースリストから12F系や16F系へ移植する場合には、htc.h を pic.h に置き換え必要はありません。PICCの12F系や16F系用の pic.h や htc.h ファイル内で相互に参照されているからです。

2.__delay_us()や__delay_ms()を使用している場合には、
#define _XTAL_FREQ CPUの Fosc の値に修正する事。

3.通信パラメーター等が存在するならば、上記 Fosc の値を元に、パラメーター値を変更して合わせること。

4.12F系、16F系、18F系のそれぞれのCPUに合った config を用意しなければならない。中でも、Foscを決定する部分は、駆動電圧に左右され、CPUによっても異なるので十分注意して決定しなければならない。

5.config以外にも、I/Oの設定に重要な影響を与える物が有る。A/Dコンバーターは、標準で全て有効になっている場合が多いので、デジタルI/Oとして各PORTを使用できる様に、パラメータ"ADCON1”の設定を意識して行う必要がある。また、16F系と18F系で使用ビット数が異なるので、同じパラメーター値にならない事に注意が必要です。

例、A/Dコンバーター入力と共通になっている、全てのPORTをデジタルI/Oとして使用する場合には、
16F886では、
ADCON = 0b00000111;
ANSEL = 0b00000000;
ANSELH= 0b00000000;

18LF2550では、
ADCON = 0b00001111
となる。
18LF2550 には、ANSEL、ANSELH は、供に存在しない!設定しようとすると、コンパイルエラーになる。

6.タイマー2等のレジスタのプリスケーラ値もCPUによって異なり、変更が必要な場合が有る。

7.INT信号を使っている場合に、各CPUでINT信号の扱える数が異なるので、呼び名が異なる。

8.1つのデジタルI/Oビットで双方向のデーターI/Oを行う場合には、非オープンドレイン用のポートバッファリング方式のプログラミングを採用していれば、殆どのPICに互換性のあるプログラムが製作できる。

ただし、それぞれのビットの読み込みについては、各インターフェースルーチンでは直接処理を行わない様にして、プログラムの根幹部分で一元管理しなければ、同一ビットでの入出力の信号のショートを招き、稼働できない、もしくは異常(どのくらいの電流値を異常と云うかは別として)に電流値が流れて電池を早く消耗する。

以上の点に留意すれば、異なるPIC 同士でも、ピン数が足りれば相互のソフトウエアの移植はかなり容易にできると思います。(Aug. 12th 2010)

ソフトウエアの互換性にちょっと気になる所があり、16F886用のプロジェクトを見直しております。
(Aug. 17th 2010)


注意事項
General disclaimer
トッ プページへ

なお、当ホームページで公開しているデーター(写真、音声)等を個人の枠を超えて複製・転用する事はご遠慮下さいませ。
ご意見/苦情/ご感想はこちらまで