どよよん現象＠アマチュア無線

　あっという間に三が日が過ぎていきました。晴天が続くよい日和かと思いきや、最終日の昨日は寒風吹きすさぶかなり寒い一日・・・となれば、部屋に篭ってハイボールで暖を取りつつ、へっぽこ実験の一日となりました

　さて、先の記事で予告した通り、件名にも登場している5桁PIC・・・PIC16F18325に振り回された”冬休みヘッポコ実験”についてまとめておきたいと思います。

　このPICはMSSPモジュールを2つ積んでいるという代物で、現在絶賛難航中 のAGC制御部に採用しようとしているPICです。4桁から5桁への変更点として、自分の認識では"Timer0の16ビット化”に尽きると思い込んでいましたが、他にも幾つかの”隠れキャラ”が存在していて、それらに悉く躓きながらの奮闘・・・この辺りを忘れないようにまとめるのが得策でしょう。

　◆クロック指定方法が変わった

　何のために変わったのか自分的にはよく解りませんが、正直妙な変更のように思います。まぁ、クロックをあれこれ動かして動作するような作り物でなければ、コンフィグビットの設定を”ホンの初動”くらいに考え、OSCCON1で必要なシステムクロックに設定し直すという使い方になります。この辺り、諸OMが取り上げていらっしゃるものも無くは無いんで、さらに詳しい解説はそちらに譲ります。

　今回は特に”内部クロック”を使うつもりのため、コンフィグは兎も角（ちなみに”RSTOSC = HFINT32”を設定）、OSCCON1に以下のように値を設定しています。

　① OSCCON1bits.NOSC = 0;      // 発信源、周波数
　② OSCCON1bits.NDIV = 1;        // 分周比

　詳細はデータシートを見て貰うとして、この処理の”肝”は②の分周比です。内部クロックを使う場合のNOSC設定には2種ありますが何れも32MHzとして動作するようで、結局32MHzからの分周を②で設定する格好になるようです。

　ただ、他にも設定の組み合わせがありそうで、気が向いたら改めて調べたいと思います。

　※外部クロックは試していません・・・念のため。

　◆PPSの設定

　この機能は、比較的後発の4桁PICにも採用されていますが、現時点で手に入り易いものではそれほどポピュラーとは言い切れないと思います。ペリフェラルの入出力ポートを柔軟に切り替えられるという意味で必要な機能だとは思いますが、やはり馴染みがないとまごまごします。

　今回チョイスしたPICでは、MSSPのポート割り付けが全てPPSの対象になります。更に、PICでI2Cを接続するポートは"入力ポート"としてTRISxレジスタを設定しますが、このPPSの設定ではTRISxレジスタを入力に設定した上で、クロック側を出力（PICがマスターの場合）、データ側を何と"双方向"に設定する必要があります。

    RC4PPS = 0b11010;               // SCL2 出力
    RC5PPS = 0b11011;               // SDA2 出力
    SSP2DATPPS = 0b10101;      // SDA2 入力

　この情報も解説記事から拾ったもので、やはりここでも先達のお世話になりました。

　こういった障害を乗り越え、漸くLCDが動いたところで冬休みは終わりました。本当にやりたかった実験には到達しませんでしたが、新しいLCDに文字が表示されるとやはり嬉しかったりします。



　おや 秋月にないタイプのLCD・・・確かI2CのLCDを「八潮」に買いに行った筈なのにおかしいですねぇ。この続きは、次の記事にしましょうかね

　XCコンパイラは、PIC純正の安心感と新しいPIC登場への追随速度の点で他を凌ぎますが、如何せんフリー版の「無駄ニーモニックの吐き出し」がプログラムエリアのメモリを大いに消費します。さらに、この部分の無駄が処理速度を落としてしまいます。無論、スタンダード版やプロ版を購入してきちんとオプチマイズすれば良いのですが、これが他のベンダーが販売するものより相当に高価・・・ちょっと買う気になれません そうかといって、他のベンダーのものを購入するにも「決め手」が無く逡巡を続けています。
　そんな中、Microchip社のニュースリリースに「これは」と思う記事を見つけました。2016/1/19の記事ですから、情報に聡い方は「既知」かも知れません。

　Microchip、定評あるMPLAB® XCコンパイラPROエディションを 低コスト月額サブスクリプション ライセンスでも提供開始

　※ご注意：上記URLはPHPで作成されています。PCのブラウザは問題ありませんが、スマホでは注意が必要です。

　この記事によると、XC8,16,24の各々のプロ版月間ライセンスを販売するというものです。価格を調べてみたら、今日現在どのコンパイラも同額の$29.95でした。自動継続ライセンスですがいつでも解約・再開が可能ということですから、IDEでシミュレーションデバッグを重ねて見通しが立ったらこのライセンスを利用して「1ヶ月以内」に実機デバッグを完了すれば、今の円相場で￥3,400程度の出費で済む・・・まぁざっとこんな形で利用できそうです。

　最近はPICのプログラムメモリも随分と大きくなり、ちょっとした作りものには十分なことが多くなりましたが、処理速度の面でフリー版はやはり劣ります。勿論、高速性が要求される部分のみアセンブラで書くなど、フリー版の欠点を補う方策を考えるのも「頭の体操」としては面白いわけですが、半面「出来上がりまでに時間が掛かる」ということになります。一つのアプローチとして、「必要な時点でのプロ版利用」というのも一考の価値があるかも知れませんね。

　最近は平日の「晩酌」で若干飲み過ぎ傾向となり、「ヘッポコ・プログラミング」はあまり進ませることができません。ただ、こうした微睡みながらの「マッタリ・プログラミング」も捨てがたい自分時間・・・そんな中、今日はちょっと覚書をしておくことにしました。

　C言語の「変数」は、char,int,long,doubleといった「ビット長」についてはコンパイラ依存になるため、この辺りをよく知っておく必要がありますが、XC8の「char」のディフォルトが「unsigned」であるということを今日知りました。過去の経験からてっきり「signed」がディフォルトだと信じ込んでいました

　証拠の品として（）Microchip の日本語資料「50002184A_JP」からの抜粋しました。



　8ビットのプロセッサの場合、C言語上はこの「char」の扱いが重要です。例えば「0以上」（０を含む）といった判定にcharの変数を使うと、Warning レベル設定によってはコンパイル時にWarning がちゃんと出ます。このWarningが気になる場合は、signed charとして明示的に「符号付きだぞ」と定義した方がよい・・・ということですね。

　以上、XC8のプチ備忘録でした

　あっという間に1月最終週を迎え来週はもう2月・・・いろいろと忙しいウィークデーのせいで、カレンダーが超高速で進んでいきます。週末は呼吸を整えるべくPICプログラミングに興じようと、今週初めにXC8のアップデート（1.32⇒1.35）を行ったらWarning の改修があったようで、以下の表示がされるようになりました。

　warning: (752) conversion to shorter data type

　このWarning 自体はそれ程重要なものではなく、普通に（ビット拡張や符号ビットの扱いをきちんと考慮して）コーディングしている限りは問題にならないものですが、「今まで出てなかったのに気持ち悪い」・・・というわけであれこれ情報を漁ってみると、Warning レベル設定が「-3」以下の場合に表示されるようになったようです。「-2」以上であれば表示されません。

　そうこうしている内にVer1.36がリリースされたため一昨日の帰宅後にインストールしてみましたが、このWarning は（Warning レベル-3で）表示されています。こうなると仕様変更が掛かったとみた方が良さそうで、今後はWarning レベルを「-2」にして凌ぐことになりそうです。

　以上、ちょっと覚書しておきました。

　今、完成を目指しているSGには幾つかの課題があります。アナログ系の課題は、自分の興味度合いを含めてまずまず進めることができるんですが、デジタル系・・・とりわけPICのソフト関連は億劫になりがち。手を付けてしまえば、昔取った杵柄よろしく案外サクサク進むんですが、きちんと動くのが当たり前という気持ちが強く、「兎に角、面倒・・・」なんですよね ただ、放っておいてもちっとも進みませんから、この週末は空き時間を利用してI2C関連のライブラリ関数を作成しました。

　まずは、I2C接続できるLCDを相手に「マスターモードの送信」がきちんと行えるかを確認すべく、ライブラリの上に超簡単なテストプログラムを載せて実験。またしても「ついうっかり忘れて毎度引っかかるトラップ」にしっかり躓き、さらに微妙～なバグに翻弄され、昨日の午後はこれで潰れてしまいましたが何とかLCD表示は出来るように・・・ここでスナップショット



　活躍したのは豆電球のように写っている白色LEDです。これで「何処まで来たか」を確認しながら進めるという原始的な方法ですが、昔のマイコンベースの製品でも、同様な方法でデバッグしたもんです・・・って、急に爺ぃ化しても仕方ないか LCDが保護シートを被っていて見にくいですが、思った通りに表示できました。ライブラリ関数自体の大きさも100バイトに満たないコンパクトな仕上がりに満足・・・って、まぁI/Oを叩いているだけみたいな感じですからこんなもんでしょう。

　ここまで動けば「スレーブモードの受信関数」も序でに作ってしまおうとチャチャッと組んでチャチャッとデバッグし切りました。これもスナップショット



　このスナップに何の意味があるんでしょう・・・とお思いでしょうが、その通り、自分にしか解りません これでも「LCDの初期化に必要なI2C通信で飛んでくるデータをきちんと受信したらLEDが点灯するように組んだプログラム」で、想定したデータを受信した状態。これで、PIC-PICの組み合わせでも片方向の通信は出来るようになりました。

　I2C通信は、マルチバス対応であることから「コリジョン」や「コンテンション」を考慮できるように設計されており、メーカが製品に採用する際にはこの辺りを考慮したプログラム作りが必要になりますが、PICなどの小さなマイコン、かつ趣味の世界では「どこまでプロトコルに忠実に作るか」によってプログラム規模が変わってきます。今回作ったライブラリでは、とりあえず1対1通信で困りそうな部分は「戻り値」で返すように考慮してありますが、半二重通信の範疇ではそれも必要ないかも・・・などと思いつつ、今週末のプログラム作成は当初の予定通り「完了」に漕ぎ着けました

　予想に反して関東地方への台風11号の影響は少なく、一昨日の幕張での打ち合わせに向かう「弱々路線」（武蔵野線、京葉線）も特に支障なく過ごすことができました。昨日は時折小雨が降る中、我がおババ様（母です）と旅行代理店で3週後に迫った夏期休暇中に企画した夏の小旅行の予約を取り、帰りにはビールで乾杯して帰宅・・・三連休の一日が過ぎていきました。

　今日・明日のお休みの予定は「散髪」しかなく、怠惰な連休を過ごすつもり。それでも、次の作りものの準備だけでも進めようと、暫く放ったらかしのPICのコンパイル環境をバージョンアップしました。大きくアップしているのはIDE。Ver2.26⇒3.05というメジャーバージョンのアップですが、「開発環境のアップなんて知れたモンよ・・・」と思いつつ、コンパイラのリビジョンアップ（V1.33⇒V1.34）も含めて敢行。そして、今回は既存のバージョンをアンインストールした後に「Program Folder」の「Microchip」のフォルダも手動で削除した上、レジストリの掃除まで行って立ち上げ直し・・・即ち、クリーンインストールに近い形でセットアップを終えました。



　備忘録として、IDEとコンパイラのバージョンが見える形でスナップショットしました。特に大きく変わっていませんが、エディタのタブに補助線が入って見易くなったかな

　さぁ、次の作りものはなんでしょね・・・お楽しみに って、気が乗れば直ぐにでも着手しますが、他にもやりたいことがあったりして

　LCメータ作成にあたってPIC関連の気付いた点を、例によって備忘録としてブログ活用・・・これがあるお陰で結構救われることもあるんで、今回もまとめておきます。

◆    PICkit3でプログラムを書き込む場合のIDEの設定

　PICをたまにしか弄らないことが原因なんですが、MPLAB X IDEを「バージョンアップする機会」が多く、その度にプログラムを書き込むための設定が消えてしまいマゴマゴしてしまうんで、改めてこの部分を記しておきます。



　プロジェクトのプロパティでPICkit3を選択した後、上のイメージのように「Power」タブで電源供給を行う＆供給電圧を指定するという部分をきちんと設定しないと、プログラム書き込みの際にエラー停止します。この設定忘れで毎度躓いて・・・って、単にもの覚えが悪いだけなんですが、ひとまずここまで書いておけばもう大丈夫でしょう

◆    PLLENの設定

　振り返ってみると、PICで作ったヘッポコ作品において「外付けのクリスタル」を使ったものが2作目です。これが、今回のLCメータ製作で躓くポイントになってしまうとは・・・。
　気に入って使っている「PIC16F18xxシリーズ」を含めた新し目のPICでは、4倍クロック動作をサポートしています。これが何と「ディフォルトでON」なんです



　ConfigビットのPLLENの仕様はご覧の通りで、丸囲みの部分のディフォルト設定値が「1」・・・ということは、何もしないと「1 = 4xPLL enabled」となります。今回のLCメータ製作の初っ端で躓いたのがここで、簡単な初期化の後にLCD表示をしても上手くいかず、論理バグでないことを確認した上でConfigを見直したら・・・といった形で行き着きました。LCDの初期化のタイミング論理が全て4倍速になってしまっては、まともな初期設定はできませんからねぇ・・・。

　Configビット設定については、プログラム上「pragma 設定部分」を使い回しており、ミニ・エレキー⇒低周波発振器⇒ミニ・パワー計という順で製作してきたものは全て「内蔵クロック使用」のため、これまでは特に問題にならなかった（内蔵クロックで4倍クロック動作が有効になるのは、PIC16F18xxでは「16MHz」の設定の場合のみ）ということです。
　また、これまでに外付けクリスタルを使ったのは「PIC16F648A」・・・こいつにはそもそも4倍クロック動作機能がなく、今回は「知らぬ間に生きちゃった」という格好なんですが、どうもこの「ディフォルト」が解せないぞよ・・・と悔し紛れにボヤいてしまいました。4倍クロック動作の方が「特殊」な気がするんですがねぇ・・・

　PIC工作には抵抗は無くなったものの相変わらずたま～にしか触らないため、その都度開発環境がバージョンアップします。するとその間に操作方法が変わっていたり・・・というか、忘れてしまっていることが多くて嫌になります。まぁ、そもそも上等でない脳みそが時間と共に劣化しているわけですから、何かしらで補わないとねぇ

　これまで何度か同じ場面に遭遇し、覚え書きしておかなくちゃ と思っていたPICのConfig ビットに纏わる「落とし穴」についてまとめておこうと思います。以前にMCLRがアサインされるポートのConfig 設定がおかしいとして書いた記事がありますが、これって全然舌っ足らずな情報なんですね、実は。そこで、その後もう少しきちんと調べた結果を備忘録として残しておこうというのがこの記事の主旨です。

　XC8のConfig表現は独特ですが、自分は以下のように使っています。



　pragmaで一つひとつ設定しているのが判ると思いますが、ここで「CLKOUTEN」に着目して下さい。ソース内の定義は「ON」であるにも関わらず、コンパイル結果では「OFF」・・・これって一体 ・・・答えはデータシートにあります。



　実はConfig ビットの各ビット値については、ハード論理とリンクするようにハイ・ローが逆の定義のものがあります。シンボル名にオーバラインがあるものがそれで、CLKOUTENにも実はオーバラインが付いています。すると、ソースで定義した「ON」は逆論理・・・実際の設定値としては「OFF」、即ち「0」になります。IDEの方ではそれをきちんと表現しているんですが、実際の意味合いとしてはデータシート上の値が設定値・・・つまり逆になります。　

　上記のソース内では「CLKOUTは使いたくないから1に設定しよう」という意図で「ON」（=1）にしています。データシート上、この値では「1 = CLKOUT function is disabled. I/O function on the CLKOUT pin.」となりますから問題なし。ところが、何かの拍子にIDEのConfig ビットを見てしまうと「OFF」となっていて混乱するわけです。

　この件はIDEのマニュアルのどこかに書いてありそうですが、流石に探す気になれず・・・まぁ、そんなに頻繁に見る場所でもないですから普通は意識しなくてもいいんですが、「ちょっとEEPROMを・・・」といった場合（bit 8）にも気をつけないと、思わぬ動きに翻弄されかねませんね。

　仕事の多忙に加え、またしても填まってしまったゲームに余暇を費やしてしまい、無線系に割く時間が短い状況です。GPSモニタのソフトについてはボチボチ完成しそうなんで、適当にブレッドボードに組んでデバッグしてしまいたいところなんですが、ついついゲームパッドに手が行ってしまいます・・・年甲斐も無く

　幾つか覚え書きしておきたいことを得意のパワポで書き出していますが、GPSモニタの次に着手するであろう周波数カウンタ・・・まぁ、この構想も幾つかバリエーションがあるんでどういう風に進んでいくか自分でも謎ですが、PIC16Fシリーズで実現する場合に関わりそうな部分を今回の「公式備忘録」（＝このブログの記事）にしました。

　まず、PIC内蔵のタイマで周波数を測定する場合、タイマ０かタイマ1をカウンタとして使いますが、タイマ０は固定的に内部クロック（システムクロック）と同期カウントさせるような仕掛けになっていることから、プリスケーラなしでは数MHz程度までしか測定できません。
　一方のタイマ１は、この内部同期を取る・取らないの選択ができ、同期を取らなければカタログ値でも数十MHｚまでのカウントができるようです。さらにタイマ1は「カウンタ・ゲートの制御機能」を持っており、特に拡張ミッドレンジ・・・簡単に手に入るシリーズでは18xxや19xxなどのPICでは、かなりのバリエーションのゲート制御ができますから、周波数カウンタとして使うならタイマ1に軍配が上がるものと思います。

　タイマ1のゲート制御方式の中に、タイマ０のカウント・オーバフローを使ったものがあります。タイマ0のオーバフローをトリガにタイマ1のカウントを停止させるこの方式を使うことで、ゲートタイムの設計を柔軟に考えることができる非常に好都合な機能なんですが、ゲートタイムとしての正確性を確保できなければ意味がありません。そこで、このタイマ0に正確なクロックを与えることが命題となります。
　タイマ０に正確なクロックを与える方法は、システムクロック自体を正確なものにするか外から与えるかの二択になりますが、システムクロックをタイマ0で分周してゲートタイムを作るとすると、比較的長い時間のゲートタイム・・・例えば1秒のものは、タイマ0の分周のみでは非常に低いシステムクロック（約262KHz）となってしまい、ちょっと現実的ではありません。勿論、ソフト処理を介在させればどうにでもなるんですが、ソフトで片付けるのは余り面白くありません

　・・・と、能書きは置いて（え、能書きだったの）、タイマ０で無理なく分周でき、かつ長いゲートタイムが作れるよう、タイマ0に外からクロックを供給した場合の動作をまとめました。



　実は直前の記事が伏線になっていたりします タイマ0に与えるクロックが「2のべき乗」になっていると、分周設定が楽・・・ここでは「256Hz」を与えたことにしました。

　タイマ0のT0CKIのサンプリングは、命令タイミングのQ1、Q3の立ち上がりエッジが起点となります。Q1で認識されたもの（図中の黄色）は3クロック後のQ4、Q3で認識されたもの（図中のオレンジ）は5クロック後・・・つまり次の命令タイミングのQ4ということになります。また、あまりに短いパルスは認識できませんが、この辺りの詳細は各PICのデータシートに記載されています。
　図では、前提となっている「★」の条件にした場合65ns程度の遅れが生じることから、多分「Q3で認識される」という様子をオレンジで示しており、この65nsの遅延は常に同じですから、タイマ0のカウントアップも常に同じタイミングで起きる・・・という解釈をしています。

　以上、これまた自分にしか必要の無い備忘録でした。

　ワールドカップが近づいてきました。今朝は、本線前の最後のテストマッチとなるザンビア戦。1993年に不幸な事故に見舞われたザンビア代表がその後メキメキと頭角を現し、2年前のアフリカネーションズカップで優勝したのは記憶に新しいところ。本線前のマッチメークとしては、非常に恵まれたものとなりました。
　昨晩は飲み会で遅くに帰宅し、試合直前に目覚めたものの見事な宿酔い・・・それでもしっかり観戦しました。打ち合いとなった試合に本戦への一抹の不安を感じつつ4-3という辛勝を見届け、ツイッターをのぞき見し、そして早めの昼食。すると、体内残存のアルコールが再度回り始め、なんと ちょっとダラダラの週末になってしまいました

　さて、そろそろ梅雨を迎える時期となり、春の工作祭りは何処・・・ってな塩梅ですが、作りたいものがどんどんと移り変わってしまい、どういうわけか「LCD表示用のPIC用ライブラリをC言語で作らねば」というところに落ち着きました。LCD表示は、既にLCメータ製作の過程で制覇していますが、その後「生産性重視」を念頭に、アセンブラからC言語へメイン開発言語をスイッチしたため、C言語で組み直してライブラリ化しようと計画したわけです。
　まぁ、ライブラリと言っても本格的な「リンクするだけで使える」というようなものにはせず、必要に応じてヘッダファイルのみ書き換えてリコンパイルする・・・お得意の「ナンチャッテ・ライブラリ」です

　最近のLCD制御は、制御信号数が少なくて済む「I2C」にも及んでいますが、LCDの表示バリエーション・・・何文字何行という形での選択肢を考えると、ポピュラーなパラレル制御のものを準備しておくのも意味がありそう。しかし、技術的には何の面白みもないものを作ることになります。実はこれが「うわぁ・・・超億劫」という気持ちを誘い、なかなか着手しなかった原因。満を持して・・・というより、仕方なく・・・といったテンション低めのプログラミングでしたが漸く完了させました。

　今回のコンセプトは、ヘッダファイル定義の変更のみで（リコンパイルすれば）まずまず使える・・・ってなものです。結局、以下のようになりました。

　1)　LCDとして「2行」のタイプを網羅、4行タイプは16,20文字に対応
　　　特にソフト処理部分での工夫はないが、表示文字のライン、カラムを関数パラメータにして対応。

　2)　CD制御のインターバルにはタイマを用い、よく使うクロックに対応
　　　0.5,1,2,4,8,16,32MHzに対応。

　3)　タイマ#2に加え、拡張ミッドレンジに具備されているタイマ#4,6にも対応
　　　タイマ#2を別用途で使う場合に対応。

　4)　使用する4ビットの制御ポートは上位/下位4ビットの何れにも対応
　　　4ビットが飛び飛びに設計されるということは考え難いため、上位4ビットか下位4ビットかを設定。

　2) から4) までの部分の変更は「lcd.h」というヘッダファイルで設定できるようにしました。



　特に工夫した点は、タイマ#2には「Fosc/4」が供給されることから、分周比を160としてPR2の設定値を選択的に設定することで、殆どのクロックに対応できるようにした点です。タイマ#4,#6も、この部分は同様になります。



　ソースファイルの「lcd.c」の先頭で「lcd.h」で設定した値を引き込み、プログラム・コード部分で使うラベルに変換しています。これらの値を使って、使用するタイマの設定を行います。



　プログラム部分では、上位/下位4ビットの選択によって必要なニーモニックを生成するようにしています。

　プログラムサイズは、上記の設定を適宜変更してリコンパイルしますので、タイマ#2使用時に212バイト、タイマ#4,#6で217バイトになりました。アセンブラで組むよりは大きくなりましたが、拡張ミッドレンジではメモリも比較的大きいため問題ないでしょう。

　さぁ、デバッグして早く使えるようにしないと・・・。