Darkside(リンクエラー修正しました)

2018年11月の記事

<< 前のページ

2018年11月12日(月) 22:03

キー情報受信

 再配線完了。
 オレンジと茶の配線は、ブザー用。

 メインPICが20ピンになったことで、ピンが2つ余る。1つはMCLRで、白い配線。もう1つは、緑の配線。これらは、将来の拡張用としてキープしておく。MCLRは入力専用だ。
 PICにおいて、MCLRは一貫して入力専用である。出力が可能なPICは無いようだ。しかしMCCでは、図形式のピンアサイン一覧で output にも切り替え可能なので紛らわしい。チェックボックスを備えた一覧の方では、output のチェックボックスが存在しないのに。

 デジタル入力が全く不要なケースは少ないので、MCLRが無駄になることは少ない。だが、この制限だけはPICに付きまとう。

 再配線が正常にできたかどうかの確認も兼ねて、サブPICからのキー状態を受信してみる。すると、不安定化している。正常に取得できつつも、すべてのデーターが1になることが多い。液晶ディスプレイが激しくチラ付く。
 ビット区切りを正常に認識できていない?
 あるいは、機種が変わったことで割り込み遅延や処理速度も変わったのか?

 さっそくオシロで確認。ポーリングによる遅延は2μ秒強で、ビット認識のマージンは2〜3μ秒。見たところ、PIC16F1827 と変わらない。
 だが、半分ぐらいの確率で、データーが1になったまま戻らない。

 サブPICがデーター一式を送り出した後、データーを0に戻す処理は入っていない。無くても動作するはずだ。今回のトラブルと直接の関係はないはず。
 更に何度も試していて、これはビット数の食い違いな気がして来た。1回のパケットで26ビットを送り出していたのが、25ビットに仕様変更した。ソースリストを見る限り、サブPICもメインPICも、間違いなく25ビットになっている。しかし・・・そのプログラムはPICに書き込んだっけ?

 書き込んだつもりだが、忘れていたかもしれない。そう考えてサブPICのプログラムを改めてコンパイルし、書き込む。とは言え、実際には、書き込む前に必ずコンパイルが実行される。恐らく、ソースファイルを変更したがコンパイルを忘れるというミスは、良くあるからだろう。
 案の定、正常に動作するようになった。

written by higashino [バトルタンク改造Tiger1] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2018年11月11日(日) 21:53

交換を決断

 まさに、急がば回れ。

 数日を余分に費やしても、20ピン対応に作り直すのがベストだと判断した。サブPICはそのままで良いだろう。メインPICだけを交換する。
 強力なオートウエルドで接着済みなので、交換しようとすれば破壊するしかない。6ミリドリルで幾つか穴を開け、基板を除去する。

 実際に面倒なのは、配線の取り外しと再取り付けの方だが。

 動作確認まで済んだ配線完了基板を破壊するのは、ほんとうに辛い。だが、それを決断させるほどメモリーソリースの差が巨大に過ぎる。

 新しい基板を製作。

 メインPICは、外付けパーツが少ない。更に、既存の基板を参考にできる。そのため、最初に作った時に比べると楽。
 抵抗2本は、I2C用だ。

 ICソケットが20ピンに長くなったため、パッド側の穴を余分に削らねばならない。

written by higashino [バトルタンク改造Tiger1] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2018年11月10日(土) 20:05

メモリー容量

 PIC16F1827 が登場したのは7年前なので、近い将来に新機種が登場してもおかしくない。以前チェックしたときは、まだ PIC16F1827 が最新っぽくて、だからこそ乗り換え先に選んだのだ。ただし、あらゆる部分が強化された中でメモリー量だけはそのままだったのが不満だった。
 では、更にメモリーの多い8ビットPICは、どのようなものがあるのか?

 それを調べて、愕然とした。
 もしかすると、18ピンのPICは切り捨てられるのかもしれない。PIC16F84A から始まり、18ピンの8ビットPICはメジャー品というイメージを持っていた。だからまさか、後継が出なくなるかもしれないとは想像もしなかった。
 だが、考えてみると8ビットPICは、ピン数によって重要ピン(GNDやVCCやMCLR)の位置が固定されている。機種によってピンアサインは異なるが、ピン数が同じなら基本的に重要ピンの位置は変わらない。そのため、ライターでは「何ピンのPICであるか」によってジャンパーを変えたりする。

 すなわち、重要ピンの配置は、おいそれと変更できない。
 もしかすると18ピンPICは、重要ピンの配置が悪いので、メーカーが後継の開発に消極的ではないのか?
 例えば、外付けパーツを実装する際。正確なクロックが必要だからと水晶を使用する場合、GNDと配線したい。だが、GNDは反対側にある。また、MCLRを有効としプルアップしようとした場合も、VCCは反対側にある。どう考えても、GNDとVCCは入れ替わっている方が遥かに使い勝手が良い。初期の、設計ミスだろう。しかし、今更これら重要ピンの配置は変えられない。

 18ピンばかり見ていたので、必然的に PIC16F1827 に辿り着いた。だが、それ以外のピン数にまで目を広げると、去年に新製品ラッシュが起きていた。6年の差があるため、PIC16F1827 より進歩している。例えば、20ピンの PIC16F18346 だ。内蔵ペリフェラルの制限が大幅に緩和され、MCLR(未だに入力オンリー)以外の大半のピンを自由にアサインできる。
 もちろん、18ピンPICとはGNDとVCCの位置が入れ替わっている。

 何より魅力的なのは、メモリー容量。プログラムコードが4Kワードから16Kワードへと4倍になり、RAMに至っては384バイトから2048バイトへと激増している。クロックは最大32MHzのままだが、現在のネックが機能性能ではなくメモリーなので、この差は余りにでかい。

 パッケージが18から20へと少し大きくなるのはマイナスだが、メモリーの魅力が巨大過ぎる。MCC対応なので、乗り換えや併用も負担にならない。ソースコードはCだから、流用もできる。試しにメインPICのプログラムを移植してみたところ、圧倒的。
 これはUSART関係を外してあるので、本番フル実装したら PIC16F1827 の方はプログラムエリアをほぼ使い切ってしまう。

 作成中の送信機は、ゲームパッドの数多いキーをフルに生かしている。そのため、ソフト次第で冗長なアイデアをいろいろ実現できる。しかし、PIC16F1827 は、そのためのプログラムエリアが無い。
 PIC16F18346 であれば、圧倒的にアイデアを広げる余地がある。

 そこまで大袈裟ではなくても、例えばこの送信機は「マルイのバトルタンク改」「コイルガンストームタイガー」「ドリル戦車」の3つで共用する可能性が高い。何ヶ月も掛けて豪勢仕様のハードを作るのだ。共用可能なポテンシャルは十分にあるし、共用しないのはもったいない。
 PIC16F18346 ならば、3位置スライドスイッチで3機種の設定を切り替えるようなこともできる。コイルガン戦車なら、コンデンサーの充電電圧をセンシングして液晶ディスプレイに表示したりしたくなるが、バトルタンクにそのような表示は不要である。そういった機種ごとの差異を実装すると、プログラムが膨らむ。PIC16F1827 ならば、機種ごとにソフトを差し替えるしかないだろう。

written by higashino [バトルタンク改造Tiger1] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2018年11月9日(金) 21:06

配線切り詰め

 適切な長さに配線を切り詰め、ハンダ付けし直す。さもないと、筐体に物理的に収められない。
 この青い配線は、被覆を極めて剥き難いという欠点がある。それが、作業性を著しく悪化させている。

 要所をアラルダイトで固定し、振動モーターの収まるボックスとの干渉も避ける。一部は削らないと、干渉を回避できない。配線を取り付けできるパターン露出部分の位置が悪いため、完全に干渉を回避するような配線は不可能。どうしても、削らざるを得ない。
 振動モーターの錘が回転する空間を、確実に確保することも配慮せねばならない。パッケージングは、常に厄介だ。

 PICのプログラムも修正する。バッテリー電圧はAD変換されたナマ値を送信していたが、ボルト変換後の値を送信することにした。というのも、変換計算は8ビットマイコンにとっては重い処理で、プログラムコードを結構必要とするのだ。
 サブPICは圧倒的にプログラム領域に余裕があるため、サブ側で変換計算を行っておこうという考え。送信データーも、1ビット減らせる。

 メインPIC側の入力も正常にできることが確認できたので、同様に配線を切り詰める。
 ブザー用の配線(茶とオレンジ)も、取り付けるだけは取り付けておく。

 メイン基板の電源GND(青)が、細い配線の下になってしまい、これでは抜き差し困難だ。上側になるよう、ハンダ付けし直さねばなるまい。
 それが終了すれば、ハード作成は仕上げ段階。

 後は、ソフト次第で自由に機能を実装できる。ゴールは近い・・・と思ったら、でかい爆弾が存在した。それは、PICのプログラム領域である。
 ただちに足りない、という訳ではない。しかし、プログラムコードが膨らまないよう頑張って配慮しなければ、4Kワードに収まらないであろうことは既に見当が付いている。サブPIC側でバッテリー変換計算を済ませるのも、その一環だ。

 しかし、プログラム領域に余裕が無いということは、余分な機能を実装することはできないという意味でもある。

written by higashino [バトルタンク改造Tiger1] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2018年11月8日(木) 21:24

様子を見る

 録画中LEDがピタリと時間通りに点滅を終了せず、1秒長かったり1秒短かったり。思った以上に調整に手間取った。

 本来のリモコン機能は、問題なく動作。

 これで動作確認は終了し、LEDおよび新配線をアラルダイトで固定する。
 アラルダイトは、何度も使っているうちにチューブから漏洩してベトベトになる。いつもそうだ。原因不明である。チューブに穴が開くわけではなく、キャップの隙間から漏れるのだ。キツく締めておいても、漏れる。訳が分からない。
 そのため、アラルダイトの容量を使い切れることがない。

 固定強度よりも、短時間で固定したいときにアラルダイト。

 C言語になったことで、PICのプログラムも強化。録画中に、子機のボタン入力を受け付けるように改良。結構面倒であり、アセンブラならやってられなかった。
 XC8なら複雑な制御も十分に可能だし、ソフトの保守性が良くなる。将来更にPICを変更することがあっても、流用は容易だろう。

 実は、コネクターから先のカメラリモコンコード部分は元のままである。作り直すためには、カメラリモコンを新規調達せねばならない。仮にこの部分が接触不良であれば、録画失敗トラブルは解消しない。
 しかし逆に、録画失敗がまだ発生するようであれば原因がカメラリモコン部分だと特定できる。それならば、購入し直しも無駄にならない。

 当分は、コレで様子を見る。録画中に割り込んで録画し直しが出来るようになった機能強化も、ほんとうに想定通りに動くかどうか実地のフィールドテスト。この旧リモコンで動作確認できれば、ハイスピードカメラ用の新リモコンにも流用できる。

written by higashino [カメラ] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

<< 前のページ

Darkside(リンクエラー修正しました)

Generated by MySketch GE 1.4.1

Remodelling origin is MySketch 2.7.4