たまりば

パソコン・インターネット パソコン・インターネット三鷹市 三鷹市

PIC16のDhrystone MIPSを測ろうとしてみた
2020年04月29日 02:23

PIC、中でも昔ながらのミッドレンジは演算性能が低いことで有名だ。
ベンチマークでどれほど低い値が出るか気になる。マイコンの性能比較に広く使われているDhrystoneは整数演算だけなので低性能なCPUでも走りそうだ。

そう思ってDhrystoneのソースコードを見てみると…
int    Arr_2_Glob [50] [50];

ミッドレンジPICに5000バイトもメモリは無い。最大でも368バイトだ。

-完-



…とここで諦めてしまうのはつまらない。
よく見てみれば2500個の要素を全て使っているわけではない。アクセスするのはわずか4箇所。これならなんとかなるのではないか。
なんとかなるというのはつまり、Dhrystoneをそのまま走らせることはできないにせよ、なるべく結果に影響の出ない範囲でコードをいじったり、もし本来のコードが走ったらどの程度の速度が出るかを推測することで、それなりに意味のある値を出せるのではないか。

というわけでやってみた。
使うコンパイラはMPLABの標準のCコンパイラ、XC8(v1.44)。無償版なのできっと最適化とかに制限があるだろうが気にしない。

まずは何はともあれコンパイルが通るようにしなければならない。適当に配列要素の数を減らそう。50×50要素を7×6要素に。
int Arr_2_Glob [7] [6]; //Arr_2_Glob [50] [50];
typedef int     Arr_2_Dim [7][6]; //[50] [50];
これが妥当かどうかは後で見ていく。
ついでにもう1つこっちも減らさないといけない。50要素を25要素に。
int Arr_1_Glob [25]; //Arr_1_Glob [50];
typedef int     Arr_1_Dim [25]; //[50];
int 50個=100バイトはあるんではないかと思うかもしれないが、コンパイラの仕様上1つのオブジェクトは1バンクに収まっていないとならない。
また総メモリ量もわりときつく、ちょっと増やすとすぐ割り付けに失敗する。

配列の読み書きのコードは変えていない。
範囲外を読み書きすることになるがそこは自分の足を撃てるC言語。何の問題もない。

他数箇所変更した。
・エラーが出るたび適当にそれっぽいヘッダファイルをinclude
よく分からないまま追加しているがまあ多い分には問題ないだろう。

・NOSTRUCTASSIGN
structassignで「can't generate code for this expression」が出たので、それ用に用意されたコードが使われるよう
#define NOSTRUCTASSIGN
したら動くようになった。
これにともないmemcpyがコードに書かれたものが使われるようになったが、ライブラリ側のものと衝突したのでコメントアウトした。

・時間計測のためのTIMEだのなんだのを削除
結果に影響の無い部分なのでバッサリと。
このへんをPICで動くように変更するのは手間なので時間計測はシミュレータで行うことにする。
PICは実行クロック数が確定的なので問題ない。

・mallocができない
のでユーザーズガイドを見ると、
Dynamic memory allocation, (heap-based allocation using malloc, etc.) is not supported on any 8-bit device.
とある。
幸いmallocが使われているのは初期化の部分、ベンチマーク本体のループの外だ。直接宣言してしまおう。
ポインタが指す先のメモリがどう用意されたものかはプログラムを走らせる上で違いはないだろう。
おそらく最適化を防ぐために持ってまわった定義をしているのだろうと思われ、そこまでの最適化はきっとされていないだろうと判断する。少なくともポインタ参照はされている。
/*
  Next_Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type));
  Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type));
*/
  Rec_Type temp1;
  Rec_Type temp2;
  Next_Ptr_Glob = &temp1;
  Ptr_Glob = &temp2;

なお、これで測り終えた後見つけたのだが、別の対処法として、呼び出されると事前に用意したポインタを返す疑似mallocを使っている人がいた。(後述のAVRのコード)
こちらの方がより安全そうなので真似してみたのだが、後述のポインタ幅違いがまた出てどうしてもうまくいかなかった。
諦めて直接宣言のままにした。

・よく分からないエラーが出た
 *Ptr_Ref_Par = Ptr_Glob->Ptr_Comp;
の部分で、「error: (1466) registers unavailable for code generation of this expression」というエラーが出た。
PICでレジスタってなんだろう。RAMとは違うのか。
なんだかよく分からないが2分割したらエラーが消えたのでこれでよしとする。
struct record *temp;

    temp = Ptr_Glob->Ptr_Comp;
    *Ptr_Ref_Par = temp;
…が、後にこれは必要なくなる。後述。

これで先へ進むようになり、コンパイルが通るか…と思いきや意外なことにプログラムメモリが足りない。結構食うんだなあ。
RAMがミッドレンジ最大の368バイトあるものとして手持ちからPIC16F88を選んだのだが、こいつのプログラムメモリは4kワード。
どうせシミュレータで動かすのだし最大の8kワードある石を適当に選ぶか…と思ったが、コードを見ると大量のprintfがあって容量を食っていそうだ。
状況説明のための出力は不要なので開始と終了を1文字だけ残して消す。
結果出力部分に未使用の変数が消されることを防ぐためのprintfがあるがこちらも極力切り詰める。
例えばこれを
  printf ("Int_Glob:            %d\n", Int_Glob);
  printf ("        should be:   %d\n", 5);
  printf ("Bool_Glob:           %d\n", Bool_Glob);
  printf ("        should be:   %d\n", 1);
こうする感じで。
  printf ("a:%d\n", Int_Glob);
  printf ("b:%d\n", Bool_Glob);
こうして切り詰めたら余裕で入った。3kワード弱にまでなった。
なおprintfから呼ばれるputchの実装は、意味のある出力をするものではなく、シミュレータで適宜止めて出力内容を見るための、引数が消されない最低限のコードにした。

これでビルドが通り、(内容はともかく)動作をするようになった。

出力を確かめると、配列の部分の値が違うのは想定通りだが、他に構造体のポインタ演算あたりの部分も違っている。
調べてみるとおかしいのは例の2分割で代入したところで、16bitのポインタに8bitのポインタを代入している。
この際データが不可解な変化を見せており、その影響でそのあとif文で通らないはずの方を通っている。

XC8ではポインタが8bitと16bitの2種類あるのだが、使い分けは手動ではできず、コード中の全ての代入を認識して自動で最適なものを使い分けてくれるという。
これが判定に失敗して間違った代入をしてしまっているように見える。つまりコンパイラのバグではないか。

ループ外に適当に代入文を書いてみたところ今まで8bitだったところに16bitのポインタが使われるようになり、出力が正しくなった。
そして例の2分割代入部分も元のコードでコンパイルが通るようになった。

配列部分も正しく動作しているか調べよう。
配列のアクセスの部分の数値を書き換えて配列内をアクセスするようにし、正しい結果が出るかを見る。
出た。
また、ここで時間計測し、配列アクセス部以外にかかる時間が変化していないことを確認した。
よって、不正なアドレスをアクセスすることで他の実行結果に影響を与えていることは無いと考えられる。

これで多分配列部分以外は本来のDhrystoneの想定通り動いているだろう。



さて配列の量をいじった事によりベンチマーク結果にどれほどの影響が出ているか考えてみよう。

1次元配列の方の要素数は、(2次元配列を[2][3]にしてメモリを空けた上で)[25][30][35][40][48]を試し、実行時間は一切変化しなかった。
こちらの影響は無いものとみて良いだろう。

2次元配列の要素数を[7][6]から変えて変化を見てみる。
配列の宣言の部分と、typedefの部分。
宣\def[50][50][50][6][7][50][7][6][2][2]
[7][6]58005693580056935571
[4][6]58005693580056935571
[8][3]58005693580056935571
[2][3]58005800580058005571

これを見ると、typedefの方の2次元めを変えると実行時間にやや変化が見られるのに対し、
配列の宣言の方は[2][3]でのみ値が変わるが他は要素数によらず一定である。

本来の[50][50]に近づけられないのが気がかりだが、現状の判断として、配列宣言の要素数を大きくしてもベンチマークの実行時間には影響を与えないと考えることにする。
typedefの方は折角なので本来の[50][50]にしておく。

なおこの要素数だが、変えるとコンパイルに失敗することがかなり多い。
要素数の積が48(メモリ量が96バイト)を越えるとメモリ不足でコンパイルできないのは分かるのだが、次表のようにそれ以下でも値に応じて不規則に失敗する。
[*][2][*][3][*][4][*][5][*][6][*][7][*][8][*][9]
[2][*]×××××
[3][*]××××××
[4][*]×××××
[5][*]××××
[6][*]××
[7][*]
[8][*]
[9][*]??
[10][*]??
[11][*]??
[12][*]??
(○: コンパイル成功 / ×: コンパイルエラー / ?および表範囲外: 未チェック / 空欄: 96バイト超)

この時のエラーは次のようなもので、調べるとメモリのバンクへの割り付けに失敗しているエラーで、PICにはよくあることのようだ。有料版だと出なくなることもあるらしい。
D:\P\xc8\v1.44\sources\common\lwdiv.c:30: error: (1357) fixup overflow storing 0x8E in 1 byte at 0x950/0x2 -> 0x4A8 (dist/default/debug\Dhrystone88.X.debug.obj 120/0x26)

配列の宣言の方はこれでいいとして、実際にアクセスする部分はどうか。この分をどう考えるかは難しい。

何らかの計算をしてアドレスを求め、配列の範囲外とはいえどこかしらをアクセスしてはいる。
しかし、ここで生成されているコードはどうあっても2500の全ての要素にアクセスすることはできない。
そのような不完全なコードで時間を計ってよいものか。

とはいえ2500要素5000バイト分のアドレスというものはミッドレンジではそもそも存在し得ないのだから、それを計算するコードとしてどのようなものを想定するのかの正解は無い。

考えた末、以下2点を補正することにした。

・乗算
まず、アドレスの生成部分を見ると、1バイト×1バイト=1バイトの乗算ルーチンが呼ばれている。実行時間は100サイクル程度。
これはまずい。50×50要素の配列にアクセスするには積を2バイトで持たなければならない。
試しに2つのchar型の変数を乗算してみると実行時間は値によって変わり、124や178サイクル。
    char temp01 = 8;
    char temp02 = 100;
    int temp03 = temp01*temp02;
→124
    char temp01 = 38;
    char temp02 = 100;
    int temp03 = temp01*temp02;
→178
この分を適当に補正することにする。1回あたり50サイクル、配列アクセスは4回あるので計200サイクル追加することにする。

・バンク
5000バイトのメモリは存在しないが、せめて複数バンクにわたるメモリのアドレスを算出するコードは考慮しておきたい。
1バンクあたり96バイトという中途半端な値を使うのはさすがに大変すぎる。
仮に大量のメモリを積むならもっとまともなアクセスができるようにするだろう(というか、実際にPIC18やEnhancedミッドレンジでされている)
悩んだ末、「80バイトや96バイトの容量があるバンクが十分に大量にあり、バンクごとに切りの良い64バイトだけを使う」「バンク選択にかかる時間は考えない」ことを仮定し、以下のコードを書いた。
int address = 0x1234
char addrh = address >> 6;
char addrl = address & 0x3F;
これに50サイクル掛かった。2次元配列のアクセスは4箇所あるので200サイクルを追加する。

以上より、実測値5800サイクルに2次元配列アクセスの分を想定した補正値400サイクルを加えた6200サイクルを、ミッドレンジPICにおけるDhrystone1回分の実行時間に相当する値と考える。

これをクロック数に直して24800クロック、1MHz・1秒あたりDhrystone相当値は40.3、1757で割りDMIPS/MHzの推定値は、
0.0229 DMIPSっぽい値/MHz
と得られた。



比較しよう。

16bitや32bitのマイコンの宣伝にはよく公式にDMIPSが書かれている。見ると、比較的性能の低い(インオーダー・シングルコア)のものでも1DMIPS/MHz程度はある。
CPUDMIPS/MHz情報ソース
PIC32MM 1.53http://ww1.microchip.com/downloads/en/DeviceDoc/60001324b.pdf
RL781.39https://www.renesas.com/ja-jp/products/microcontrollers-microprocessors/rl78/rl78-features.html
ARM Cortex-M00.89 (最適化条件を変えれば1.02や1.27)https://developer.arm.com/products/processors/cortex-m/cortex-m0

何十倍も違うとあまり比較にならない。
もっと性能の低い、8bitCPUの値を探そう。
探してみるとそれなりに見つかる。

http://oneweekwonder.blogspot.jp/2013/12/z80-dhrystones.html
Z80。定番だ。
3.5MHzで0.142DMIPSというので、0.04DMIPS/MHz。

http://www.homebrewcpu.com/new_stuff.htm
65(C)02とZ80。6502はファミコンで有名だ。
6502 - 1.02MHz: 37Dhrystone
Z80 - 2.5MHz: 91Dhrystone
というので、
37/1757/1.02 = 0.02DMIPS/MHz
91/1757/2.5 = 0.02DMIPS/MHz
Z80の値が上の半分だ。まあ環境やコンパイラでこの程度の誤差は出るものだろう。

http://ww2.tiki.ne.jp/~maro/AVR/project/bench1/index.html
AVR。PICとよく比較されるマイコンだ。
at90s8515・8MHzで、最速の結果で1.938MIPSとある。0.24DMIPS/MHzだ。
ただしこの人、律儀に2500バイト(?)のために読み書きに3クロックかかる外部RAMを接続している。
(*2500バイトと書いてあるのはたぶん間違いだと思う。C言語的にIntは16bit以上のはず。)
自分のやったように必要な分のメモリだけにするなら外部RAMは要らずもっと速くなる。
4クロックから3クロックに変えるだけで1.659MIPSから1.933MIPSに上がったというのだから、同じ割合で1クロックになれば2.920MIPS・0.365MIPS/MHzに上がる計算になる。

http://www.ecrostech.com/Other/Resources/Dhrystone.htm
AVRもうひとつ。
こちらは内蔵メモリに収まるよう配列要素を半分にするなどしているようだ。先述の疑似mallocはここの記述だ。
ATmega64で、0.328DMIPS/MHz。
上の0.24DMIPS/MHzより速く、推定0.365MIPS/MHzよりは遅い。
調べてみるとat90には乗算命令がなくATmegaにはあるようなので、at90より速いはずだ。してみると上の推定0.365MIPS/MHzは少々怪しいか。

これらの値と今回のPICの推定値を比較してみる。

Z80: 0.02~0.04DMIPS/MHz
Z80はゲームボーイのCPUしか扱ったことがないが、1命令のクロック数は4の倍数で、概ねメモリアクセスの回数×4クロックに一致する。これはPICと似た性能である。
本来のZ80は多少クロック数が異なり、またレジスタが多かったりループ命令があったりするが、大勢に影響は無いだろう。
クロックあたりに行う動作がPICと同程度で、命令がZ80の方が豊富であることから、DMIPS値が1倍~2倍というのはだいたい感覚と合っている。

6502: 0.02DMIPS/MHz
6502はメモリアクセスあたり1クロック+α(内部処理分)といった趣で、Z80よりクロックあたりの性能は高い印象がある。
Z80と同等か低い値というのはちょっと感覚と合わない。まあZ80も2つで2倍の差があるくらいだし、この程度は誤差なのかもしれない。

AVR: 0.24~0.365DMIPS/MHz
Z80や6502と1桁違う。PICの10.5~16倍。感覚的にちょっと多すぎな気もするが、よく考えてみよう。
まずAVRは大半の命令が1命令1クロックで動く。PICは基本的に1命令4クロックなので、命令数では2.6~4倍となる。
ミッドレンジPICとAVRのアーキテクチャを比較すると、
・PICは汎用レジスタが1つのみであり何をやるにもメモリに値を置く必要がある
・PICはプログラムメモリのページ・RAMのバンク切り替えで時間を食う
・PICには乗算命令が無い
・PICは間接アドレッシング用のレジスタが1本しか無いことやメモリのバンク分けのため、C言語に向いていない
・一方AVRは間接アドレッシング用のレジスタが16bit×3本もあり、大変C言語向きである
といったあたりの要因からして、2.6倍くらいは妥当だし4倍もまあありうるのかなと思えてくる。

Conclusion


独自の仮定のもとにそれなりにDMIPSに近いと信じる値を算出し、いくつかの8bit CPUの値と比較して感覚とそれなりに合う結果となったので満足である。



結論に問題があるとすれば、まず一番怪しいのが2次元配列アクセスの補正が正当かどうか。
そしてmalloc除去を始め各所で加えた変更が正当かどうか。
あとはPICでまともにC言語を使ったのは初めてなのでなにか手順にとんでもない間違いがあるかもしれない。
有料版で最適化をかけて別次元の速さになったりしないかも少し心配だ。(「(PRO版なら)最大で60%小さく400%速いコードができていたんだぜ」ってコンパイルするたびに言われるのだ)
コードはgithubに上げたので、何か疑問があれば色々試してみるとよいだろう。
https://github.com/Ikadzuchi/Dhrystone88.X

なお、本稿をほぼ書き終えた段階で公開用にコードを整形したところ、ループ外の不要部を削っただけなのだが、ループの実行時間は5800サイクルから5824サイクルに増えた。面倒なので文中の数値は直さない。
コードの位置が変わることによりページをまたいだりして実行時間がこの程度変化することは十分考えられる。
他にもループ外にテスト用の乗算コードを書いたら7016→6996に短縮したこともあった。(不正な場所を実行していた時なので実行時間は大きく違う)  

  • ポケットプリンタ制御
    2018年12月22日 17:40

    この記事はGame Boy Advent Calendar 2018の22日めです。

    最近ゲームボーイのプログラミングがマイブームだ。
    ところでポケットプリンタってあるよね。
    動く機械って萌えるよね。

    というわけでやってみた。
    使うのはもちろん使い慣れたPICマイコン。
    ちょうど最近電子ペーパーを試すのに使っていたPIC16F1508が手頃だったのでこれを使うことにした。(電子ペーパーについてもブログに書こうと思っているのだが…)
    なお固有の機能は特に使っていないのでEnhancedミッドレンジならどれでも容易に移植できるはず。SPI送信のみとかわざわざ機能調べるほうがめんどい。

    ポケットプリンタ(海外名はGameboy Printer)の制御方法の情報は下記2サイトによくまとまっている。
    In Depth: The Game Boy Printer
    https://shonumi.github.io/articles/art2.html
    Furrtek.org : Reversing GameBoy Printer
    http://furrtek.free.fr/?a=gbprinter (原文フランス語)
    http://furrtek.free.fr/?a=gbprinter&i=2 (英語; 未翻訳部あり)

    さらに実際の送受信内容のダンプが公開されているのが嬉しい。
    http://furrtek.free.fr/noclass/gbprinter/hexdump.txt
    チェックサムが「1バイトごとの和を2バイトで」という珍しい形式なのでこれが無ければ理解は困難だっただろう。

    これらサイトの情報を元に、「最低限動くプログラム」を作った。
    最初のプログラムというものは単純なら単純なほどよい。バグも入りにくいし、他人も参考にしやすい。

    具体的には、
    ・印刷する画像サイズは最小の160×16(ヘッドの1行分)
    ・上下のマージンは手動でフィードすればよいので0
    ・データの圧縮はしない(そもそも白黒でないとほとんど圧縮されなそうだし、圧縮しなくても送信に1秒掛からないし)
    ・データは送信のみ、プリンタからの返答は見ない
    ・statusコマンドのポーリングによる印刷終了判定もしない
    ・各種データはプログラムに直書き
    ・EnhancedミッドレンジPICのデータは14bit中8bitしか使えない簡易な読み方と全部読める読み方があるが、楽な前者
    ・電源ONで自動で1回だけ送信
    といった感じ。

    用紙は感熱紙自体は容易に手に入る。サイズが合わないのでノコギリで切って…
    http://furrtek.free.fr/?a=gbpcable&i=2
    「No paper ? Take a used receipt」
    なるほどその手があったか!
    不要なレシートならそのへんに落ちている。

    電池を用意し(多いなあ…)
    電池6本

    以前GBAと通信を試したときに通信ケーブル変換コネクタをばらして作った線でつないで(コネクタが入手できなければ本体をばらして線をつなぐのが早いと思う)
    GB通信ケーブルからつなぐ線

    …動かない。
    色々チェックし見つけたバグを修正したがやはり動かない。

    出力は確かに出ている。クロック線とデータ線も間違っていない。
    簡略化のためにプリンタからの応答を見なかったのはまずかったか…とも思ったがそれ以前にプリンタからのSO(Serial Out; 分かりやすくいえばMISO)線に何も出ていない。
    何も出ていないというのはつまり、常にHigh-Zになっている。
    出力していない時の信号が不定でHigh-Zにするのはまだ分かるとして、[furrtek]によれば何か信号を入れたら00が返ってくるように書かれているのだが。

    線にLEDをつないでのデバッグではこのくらいが限度だ。
    仕方ない。重い腰を上げオシロスコープを引っ張り出してきて(先日のPCのクラッシュで制御ソフトが消えていたのでインストールもして)確認してみる。
    PICからポケットプリンタへの信号
    想定どおりである。(電源の都合上この時は電圧が違うが本番は5Vで動かしている)
    ポケモンカードGBから印刷して実機の信号も見てみる。
    ゲームボーイからポケットプリンタへの信号
    こちらも想定どおりである。困った。

    実機と違うところといえば、以下2点。
    速度は[furrtek]には「1kHz以下(もっといけるかも)」くらいに書いてあったので、1kHz以下でプログラムが簡単なところとして約650Hz。
    実機の速度は約8kHzだが、ふつう同期シリアル信号というものは遅い分には問題が無いものだ。
    怪しいのは電源投入時だ。線をつないでから
    プリンタ電源ON→PIC電源ON→300msほど待つ→送信開始
    というシーケンスで操作しているが、このPIC側電源投入時にクロック線が暴れて不正なデータが入っているのかもしれない。
    しかし、先頭のマジックバイト8833というのはこの辺の同期ズレをリセットするためのものではないのか?
    つまり、電源投入時から(バイト単位でなく)ビット単位で信号を見て「1000100000110011」のパターンがあったらそこで同期するという仕組みではないのか。

    まあ他に打つ手も無いのでこの2つを修正してみることにした。
    通信速度は8kHz弱に。念のため上の画像でも見える1バイトごとに半bit分くらい止まる部分も実機に合わせた。
    PIC電源投入時の待ち時間を5秒ほどに伸ばし、電源投入シーケンスを
    PIC電源ON→(5秒の間に)プリンタ電源ON→送信開始
    とした。

    すると、
    ポケットプリンタ_ハローワールド
    成功!

    どちらが効いたのか片方づつ試すと、なんと両方とも必要だった。
    650Hzの速度では、全く反応しない。
    電源投入時のシーケンスを最初のものに戻すと、まれに成功するもののほとんど反応しない。(20回ほど試し2回成功)
    再び両方修正後のコードで何度か試すと、ほぼ確実に成功する。(失敗は接触不良か?)

    これは不思議である。
    遅い信号を弾くのはノイズを信号と判断しないためではないのだろうか。そうであれば300ms空けたところでリセットしていてほしい。
    一方そうでないなら、挿抜時のノイズを無視するためにマジックバイトがあるのではないのだろうか。そうであれば挿抜時にどんなノイズが乗っても正しく信号を受けてほしい。

    何か間違っているかもしれないが、おそらく動くようにはなった。
    もっとちゃんとした画像表示もそのうちやりたい。

    [余談]
    ・折角買った感熱紙だし切った。
    感熱紙のロールをノコギリで切った
    …55分掛かった。間に1時間の休憩を入れて。
    学研のふろくじゃなくまともなノコギリを持っておいたほうがいいな。

    ・画像データは以下のようにして作った。
    GIMPで描く
    ハローワールド
    ペイントで8×8ドットごとに並び替える(背景色を変えるとやりやすい)
    ハローワールド_並び替え
    上下反転・色反転、GIMPでトーンカーブを使って上位bitと下位bitのデータを作る
    bit分割
    モノクロビットマップで保存
    バイナリエディタで開く
    テキストエディタで適宜置換

    ・何度か試したの図↓
    何度か試した

    コード:

        list p=16F1508
        #include p16F1508.inc
        radix dec

        ;     Vdd +-v-+ Vss
        ;     RA5 |   | RA0/DAT
        ;     RA4 |   | RA1/CLK 4_1
        ;1_0 (RA3)|   | RA2 CLC1
        ;     RC5 |   | RC0 CLC2
        ;21/4 RC4 |   | RC1
        ;2_0  RC3 |   | RC2
        ;3_1  RC6 |   | RB4 3_0
        ;1_1  RC7 |   | RB5 4_0
        ;CLC3 RB7 +---+ RB6

        __CONFIG _CONFIG1, _FOSC_INTOSC & _WDTE_OFF & _PWRTE_OFF & _MCLRE_OFF & _CP_OFF & _BOREN_OFF & _CLKOUTEN_OFF
        __CONFIG _CONFIG2, _WRT_OFF & _STVREN_OFF & _BORV_LO & _LPBOR_OFF & _LVP_OFF

    #define DATPIN 4
    #define CLKPIN 5

        cblock 0x20

        endc
        cblock 0x70
            cntl, cnth, suml, sumh
            dat, bitcnt, waitcnt, portbuf
        ;    temp, temp2
        endc

        org 0
        goto init

        org 4
    init:
        banksel OSCCON
        movlw b'01101010'
        ;        ^^^^ || IRCF 1101=4MHz (※クロックを4MHzにすると1命令1μsで計算しやすい)
        ;             ^^ SCS SystemClockSelect 1x = internal
        movwf OSCCON

        banksel 0
        clrf PORTC
        clrf PORTB
        movlw b'00110000'
        movwf PORTA

        banksel TRISC
        clrf TRISA
        clrf TRISB
        clrf TRISC

        banksel ANSELC
        clrf ANSELC
        clrf ANSELB
        clrf ANSELA

        banksel 0

        clrf cntl
        clrf cnth
        clrf suml
        clrf sumh
        clrf dat
        clrf bitcnt
        clrf waitcnt
        clrf portbuf

        ;少し待つ
        ;//65536*5=327 680
        ;11*65536*7=5046272
        movlw .11
        movwf waitcnt

        decfsz cntl,F
        goto $+2
        decfsz cnth,F
        goto $+2
        decfsz waitcnt,F
        goto $-5

        ;init
        movlw .4
        movwf cntl
        movlw .1 ;プログラムの都合で+1
        movwf cnth
        movlw high(cmd_init)
        movwf FSR0H
        movlw low(cmd_init)
        movwf FSR0L
        call sendcmd

        ;データ
        movlw 0x84
        movwf cntl
        movlw 0x02+1
        movwf cnth
        movlw high(cmd_data)
        movwf FSR0H
        movlw low(cmd_data)
        movwf FSR0L
        call sendcmd

        ;空データ
        movlw .4
        movwf cntl
        movlw .1
        movwf cnth
        movlw high(cmd_data0)
        movwf FSR0H
        movlw low(cmd_data0)
        movwf FSR0L
        call sendcmd

        ;print
        movlw .8
        movwf cntl
        movlw .1
        movwf cnth
        movlw high(cmd_print)
        movwf FSR0H
        movlw low(cmd_print)
        movwf FSR0L
        call sendcmd

        goto $ ;終了

        ;コマンド送信
        ;具体的には、「88,33,本体,チェックサム,ダミー×2」を送信
    sendcmd:   
        clrf suml
        clrf sumh

        ;magic byte 88,33
        movlw 0x88
        call sendbyte
        movlw 0x33
        call sendbyte

        ;本体
    sendcmdloop:
        moviw FSR0++
        addwf suml,F
        btfsc STATUS,C
        incf sumh,F
        call sendbyte

        decfsz cntl,F
        goto $+2
        decfsz cnth,F
        goto sendcmdloop
        ;チェックサム
        movf suml,W
        call sendbyte
        movf sumh,W
        call sendbyte
        movlw 0
        call sendbyte
        movlw 0
        call sendbyte
        return

        ;1バイト送信
        ;相手はクロック立ち上がりで読む
    sendbyte:
        movwf dat

        movlw .18 ;タイミングを現物合わせ
        movwf waitcnt
        decfsz waitcnt,F
        goto $-1

        movlw .8
        movwf bitcnt
        clrf waitcnt
        ;DAT,CLKをlowにした値を用意
        movf PORTA,W
        andlw ~((1<<DATPIN)|(1<<CLKPIN)) ;b'11001111'
        movwf portbuf
    sendbyteloop:
        movlw .18 ;タイミングを現物合わせ
        movwf waitcnt
        decfsz waitcnt,F
        goto $-1

        movf portbuf,W ;読み込み
        rlf dat,F
        btfsc STATUS,C
        iorlw 1<<DATPIN ;データが1ならDATをhigh
        movwf PORTA ;書き込み

        movlw .20 ;タイミングを現物合わせ
        movwf waitcnt
        decfsz waitcnt,F
        goto $-1

        bsf LATA,CLKPIN ;クロック操作
        decfsz bitcnt,F
        goto sendbyteloop
        return

        ; magic 8833
        ;   cmd   comp  len L/H     sum L/H     dummy
    cmd_init:
        ;dt 0x88, 0x33,
        dt 0x01, 0x00, 0x00, 0x00; 0x01, 0x00, 0x00, 0x00
    cmd_init_len equ $-cmd_init ;やっぱりめんどいので直書きにする
    cmd_print:
        dt 0x02, 0x00, 0x04, 0x00
        dt 0x01, 0x00, 0xE4, 0x40
        ;  ???? margin palt exposure
    cmd_status:
        dt 0x0F, 0x00, 0x00, 0x00
    cmd_data0:
        dt 0x04, 0x00, 0x00, 0x00
    cmd_data:
        dt 0x04, 0x00, 0x80, 0x02
        dt 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x03,0x01,0x03,0x03,0x03,0x07,0x07,0x07
        dt 0x28,0x70,0xFC,0x78,0xFC,0xFE,0xFC,0xFE,0xFC,0xFE,0xFC,0xFE,0xFE,0xFC,0xF8,0xFC
        dt 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x0C,0x3E,0x7C,0x7F,0xFE,0x7F,0x7F
        dt 0x00,0x00,0x03,0x00,0x2F,0x1F,0x1F,0x3F,0x1F,0x3F,0x1F,0x1F,0x0F,0x1F,0x07,0x0F
        dt 0x03,0x00,0x87,0x7F,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFE,0xEC,0xF0
        dt 0x1E,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0x7E,0x7E,0x7E
        dt 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x06,0x01,0x7F,0x3F,0x7F,0x3F
        dt 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x33,0x0F,0x7F,0xFF,0xFF,0xFF,0xFF,0xFF
        dt 0x03,0x01,0x07,0x0F,0x0F,0x0F,0x8F,0x47,0xCF,0xE7,0xC7,0xE7,0xE7,0xE3,0xE3,0xC3
        dt 0xDF,0xEF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFE,0xF8,0xE0,0xE0,0xE0,0xE0,0xE0,0xE0
        dt 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0x0F,0x0F,0x1F,0x0F,0x1F,0x0F,0x1F,0x1F
        dt 0xC0,0xE0,0xC0,0xE0,0xC0,0xE0,0xE0,0xC0,0xE0,0xC0,0xCE,0xC1,0xFF,0xDF,0x9F,0xDF
        dt 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x07,0x00,0x1F,0xFF,0xFF,0xFF,0xFF,0xFF
        dt 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x70,0xF8,0xF8,0xF0,0xF8,0xF0,0xF0,0xF0
        dt 0x01,0x03,0x01,0x03,0x01,0x03,0x01,0x7B,0x79,0x7B,0x79,0x7B,0x79,0x7B,0x79,0x7B
        dt 0xF8,0xF8,0xF8,0xF8,0xF0,0xF8,0xF8,0xF0,0xF8,0xF0,0xF0,0xF0,0xF0,0xF0,0xF0,0xF0
        dt 0x03,0x01,0x03,0x01,0x0B,0x01,0x11,0x09,0x39,0x19,0x18,0x39,0x78,0x39,0x39,0x78
        dt 0xFF,0xFE,0xFF,0xFE,0xFF,0xFE,0xFF,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFF,0xFF
        dt 0x00,0x01,0x00,0x01,0x01,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x0F,0xFF,0xFF,0xFF
        dt 0xE7,0xEF,0xE7,0xEF,0xEF,0xE7,0xEF,0xE7,0x00,0x00,0x00,0x00,0x80,0x00,0x80,0x80
        dt 0x07,0x0F,0x0F,0x0F,0x0F,0x1F,0x3F,0x1F,0x3F,0x3F,0x3F,0x7F,0xFF,0x7F,0x7F,0xFF
        dt 0xFC,0xF8,0xFC,0xF8,0xF0,0xF8,0xF0,0xF8,0xF8,0xF0,0xE0,0xF0,0xE0,0xE0,0xC0,0xE0
        dt 0x3F,0x7F,0x7F,0x3F,0x3F,0x3F,0x3F,0x1F,0x0F,0x1F,0x0F,0x0F,0x07,0x0F,0x07,0x07
        dt 0x07,0x8F,0xC7,0x87,0xA7,0xC3,0xE3,0xC3,0xE1,0xE3,0xF1,0xF1,0xF9,0xF0,0xF0,0xF8
        dt 0xF0,0xE0,0xE0,0xF0,0xF0,0xF0,0xF8,0xF1,0xFF,0xFF,0xFF,0xFF,0xFE,0xFF,0xF8,0x70
        dt 0x7E,0x7E,0x7E,0x7E,0x7E,0x7E,0x7C,0xFE,0xFC,0xFE,0xFC,0xFC,0x60,0x80,0x00,0x00
        dt 0x3F,0x3F,0x1F,0x3F,0x3F,0x1F,0x14,0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
        dt 0xFF,0xFF,0xFC,0xFF,0xE8,0xF0,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
        dt 0xC1,0xC3,0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
        dt 0x80,0xE0,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x03,0x01,0x0F,0x07,0x1F,0x1F
        dt 0x3F,0x1F,0x1F,0x3F,0x3F,0x7F,0xFE,0x7F,0xFE,0xFE,0xFE,0xFC,0xFA,0xFC,0xFC,0xF8
        dt 0xDF,0x8F,0x07,0x8F,0x8F,0x07,0x07,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
        dt 0xFF,0xFF,0xFB,0xFC,0x90,0xE0,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
        dt 0xE0,0xF0,0x01,0x00,0x01,0x01,0x01,0x03,0x03,0x07,0x0F,0x07,0x0F,0x3F,0x7F,0x7F
        dt 0x79,0xFB,0xF1,0xFB,0xF1,0xFB,0xF9,0xF3,0xF9,0xF3,0xE1,0xF3,0xF1,0xE3,0xE1,0xE3
        dt 0xE0,0xF0,0xE1,0xF0,0xE3,0xF1,0xE7,0xF3,0xE7,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF
        dt 0x79,0xF8,0xF8,0xF8,0xF8,0xF8,0xF8,0xF8,0xF8,0xF8,0xF8,0xF0,0xC0,0xE0,0x40,0x80
        dt 0xFF,0xFF,0xFF,0xFF,0xFC,0xFC,0xFC,0xFC,0xFC,0xFC,0xFC,0xFC,0xF8,0xFC,0x78,0xFC
        dt 0xFF,0xFF,0xFF,0xFF,0x1F,0x7F,0x03,0x07,0x02,0x03,0x00,0x00,0x00,0x00,0x00,0x00
        dt 0x80,0x80,0x00,0x80,0x00,0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x55,0xAA ;※末尾の55AAはデバッグ時に使ったものの消し忘れ

        end

    (2019/09/03 修正) コード中のシフト演算子がHTMLタグ扱いで消えていたのを修正しました。  

  • I2C液晶が動かない理由が分かった
    2017年01月31日 01:54

    以前、秋月で超小型のI2Cキャラクタ液晶(I2C接続小型キャラクタLCDモジュール 8x2行)を買い、PIC10F200で色々と表示していた。
    ある時思いついたネタを実装しようとしたところ10F200ではROMが足りなかったので、石をPIC12F510に変えることにした。
    移植作業はわりと楽であった。ADコンバータ関連を無効化すればあとはだいたい似たようなものである。
    しかし動かない。
    しかも不思議な事に信号線にLEDやテスターをつなぐと動く。つまり原因は単純なプログラムのミスではなくアナログ的な微妙な差異によるもののようだ。
    色々考えたが分からないのでその時はあきらめた。一昨年の5月ころだ。

    (昨年の4月に)その原因が判明したので顛末をここに書き留める。何かの参考になれば幸いだ。

    まず最初に言っておくと、このプログラムで出していた信号は正常なI2Cではない。
    第一に、本来I2CはLowとプルアップで駆動するものをHighとLowで駆動している。プログラムの簡略化と高速化の為だ。
    第二に、クロック立ち下がりからデータ変化の時間、tHD:DATはデータシートによれば最小0・最大0.9μs(後述)のところ、最小ギリギリの0にしている。10F200で可能な間隔が1μsの為だ。またデータシートによればこれでも300nsの余裕があるように読める(後述)。

    もっとまともな信号にすれば動くかもしれなかったが、それは解決にならない。
    問題は動かない事ではなく、動かない理由が分からない事である。
    規格外や規格ギリギリではあるものの、これでも動くはずだと考えてやっているのだし、実際10F200ではほぼ確実に動くのである。
    この状態で適当に変更して動くようになったとしても本当にその変更が正しかったのか分からない。何か重大な思い違いがあったら危険だ。
    またなにより、何が問題なのか分からないままというのは気持ち悪い。

    移植して動かなかった時から(覚えている限り)時系列に沿って状況を書く。

    MPLABのシミュレータで見た波形は全く同じ。
    怪しいのは実際に信号が出ているかだ。TRISの設定を間違ったり、間違って別のピンにつないでいたりすることはしょっちゅうだ。
    なので信号が出ているかどうかを確認するため、信号線に青LEDをつないだ。(LEDをつなぐと点滅具合で色々分かる。青なのは電源が電池2本の時抵抗を入れなくても大丈夫で便利だからだ)
    すると…不思議なことにほぼ確実に動作するようになった。
    最初はデータとクロック両方に付けていたが、データ線だけでも動作する。
    赤LED(+抵抗)だと駄目。電圧の問題かと思い赤LED+ダイオード1、2本で試すも駄目。また、データ線にテスターを当てるとほぼ確実に動作する。

    この時点で問題はアナログ的なものと分かった。

    アナログ的な仕様に何か違いがあるのではないかとデータシートを見る。ほとんど同じだったが、1つだけ、デバイスリセットタイマ(DRT)の時間が異なっていた。早速その分の待ちを入れてみる。
    …が、変わらず。

    もはやこれはオシロスコープを買うしかない。
    2万円の機種と迷ったが3万円のものを購入。オシロスコープで12F510で動く時(青LED付き)と動かない時を確認すると信号に違いが!
    …と思ったがよく見るとそれはACKが返っていないだけであった。
    分かったことは、最初の1バイト(アドレス)から既にACKが返っていないということだけ。
    あとはノイズだが、電源投入からI2C送信までの間に目立ったノイズは無く、電源投入時のノイズはわりと酷いがどちらも同様に酷い。

    そして10F200と12F510を比較してみると、I2C信号を送信するところは一切違いが見当たらないが、リセット直後の挙動が違っていた。
    調べてみると、デバイスリセットタイマ相当の待ちを入れた時、待ちの後にHigh-ZからHighにするつもりのところを間違って待ちの前にHighにしてしまっていた。
    …しかしこれを直しても変わらず。
    もしかしてデバイスリセットタイマ中とプログラムが走っている時では何か違いがあるのだろうか。そうなると12F510で動かすのは不可能ということに。

    この辺でできることも無くなり諦めてしばらく経った。

    ある日、なんとなくI2Cについて考えていて思った。なぜtHD:DATに上限があるのだろう。
    液晶コントローラのデータシートに上限があるように書かれていたので不審に思いながらも従っていたのだが、やはりおかしい。
    I2C液晶データシート
    I2Cのデータシートを見ると、違う書かれ方をしている。(なお後で知ったが古いデータシートでは上限0.9μsになっていた)
    I2Cデータシート
    上限はなし、その上で注釈として、
    The maximum tHD:DAT could be 3.45 μs and 0.9 μs for Standard-mode and Fast-mode, but must be less than the maximum of tVD:DAT or tVD:ACK by a transition time.
    最大のtHD:DATはスタンダードモードで3.45μs、ファースト(fast)モードで0.9μ秒になりうるが、tVD:DATまたはtVD:ACKの最大値よりトランジション時間だけ短くなくてはならない。
    This maximum must only be met if the device does not stretch the LOW period (tLOW) of the SCL signal.
    この最大値はデバイスがSCL信号のLOW期間(tLOW)をストレッチしないときのみ満たす必要がある。
    If the clock stretches the SCL, the data must be valid by the set-up time before it releases the clock.
    もしクロックがSCLをストレッチするなら(訳注: 意味が分からない。SCLはクロックだ)、データはそれ(訳注: どれ? クロック?)がクロックを解放する前にセットアップ時間だけ有効でなければならない。
    CBUSとの兼ね合いかとも思って調べようともしていたが、どうも死んだ規格らしく情報がない。その辺で当時は諦めていた気がする。
    しかしさらに考えてやっと分かった。この0.9μsという上限の値は、スレーブに対する制限なのだ。
    「マスターがクロックを生成しスレーブがデータを送信するとき、マスターがクロックをLowにしている間にスレーブはデータを変化させなければならない」という当たり前の制限について言っているだけだ。

    クロックがLowの間にデータを変化させるには、データのホールド時間(tHD:DAT)・データの立ち上がり時間(tr)または立ち下がり時間(tf)・データのセットアップ時間(tSU:DAT)の和がクロックのLow期間(tLOW)より短くなければならない。
    I2Cタイミング関係
    ファーストモードではクロックのLow期間の最小値が1.3μs、立ち上がり時間の最大値が300ns、データセットアップ時間の最小値が100nsなので、
    1.3-0.3-0.1=0.9
    となり注記の値に一致する。

    スタンダードモードでも同様に
    4.7-1-0.25=3.45
    となる。

    今回データ送信はマスター側からのみ行うため、スレーブの制限は無関係だ。よって最大0.9μsは無視してもっと長い時間とれば余裕を持った通信ができる。

    解決方法は見えた。あとは原因の方だ。10F200と12F510、LEDやテスタリードを付けた12F510で何が違うのか。

    もう一度オシロで波形を見てみよう。
    ここまでI2Cの通信内容が分かる程度の縮尺で見ていたのだが、限界までサンプリング速度を上げて拡大して見てみる。すると波形が明らかに違っていた!
    I2C_10F200/12F510比較
    10F200はシンクが強いのか立ち下がりが速い。
    これによって、SCK・SDAを同時に操作してもSCKの立ち下がりの後にSDAの立ち上がりが来てくれていたようなのだ。それが12F510では逆になっている。
    この違いで動作が分かれていたのだろう。
    なおこの3万円のオシロのサンプリング速度は250Msps(2ch時)、帯域は60MHz。迷っていた2万円の方の機種は100Msps・25MHzである。
    1/(60MHz)=17ns、1/(25MHz)=40nsであり、25MHzの帯域で今回の波形の違いを捉えられたかはかなり怪しい。
    高い方を選んで良かった。

    さて最後に、冒頭で言った300nsの余裕の件だ。

    tHD:DATの下限について、以下のように注釈がある。バージョンによって言い回しが少々変わっているが内容は同じようだ。
    ・A device must internally provide a hold time of at least 300 ns for the SDA signal (referred to the VIHmin of the SCL signal) to bridge the undefined region of the falling edge of SCL.
    ・A device must internally provide a hold time of at least 300 ns for the SDA signal (with respect to the VIH(min) of the SCL signal) to bridge the undefined region of the falling edge of SCL.
    この文章も微妙に意味が取れないのだが、精一杯の訳が以下だ。
    「SCLの立ち下がりの不定区間を橋渡しするため、デバイスはSDA信号に対して内部的に最低300nsのホールド時間を(SCL信号のVIH(min)を基準に)用意しなければならない。」
    internally・reffered・with respect to・bridgeあたりの意味がよく分からない。
    なお誤訳の可能性を考えてオランダ語の原文があるかと探したのだがどうやら英語が原文のようである。

    これを自分はこう理解した。

    受信側はSDA線の立ち下がりから300ns間内部的にHighと扱う。
    よってSCKよりSDAが(300ns-立ち下がり時間)だけ早くてもよい。
    立ち下がり時間の最大が300nsなので、都合余裕は0。

    これは12F510で動作しない現状と食い違うが、上記の文章の解釈は他に思いつかない。
    (「送信側がSDA線を300ns遅らせて駆動しなければならない」という説も見かけたが、それではinternallyでないのと、それはtHD:DATの下限が300nsと書けばよいことなので、別に注釈として書かれている説明がつかない。)
    自分の解釈が間違っているのか、このデバイスが仕様に従っていないのか分からない。
    まあどちらにせよ、諸悪の根源はI2Cの仕様書が分かりづらいせいだ。マスターの条件とスレーブの条件が混ざって書かれているし、0.9μsだの300nsだのと注釈で変な条件を追加するし、その注釈は文章の意味が取れない。

    とそんなわけで不可解な点は残ったものの、まとめると、

    ・最大値が0.9μsだと思っていたが制限は無かった。
    ・最小値が0だが300nsの余裕があると思っていたが、文の解釈はよく分からず、現に余裕は無かった。
    ・石を変えて動かなくなったのは立ち下がりの速さの差のせい。

    tHD:DATを長くしたところ、安定して動くようになった。
    12F510でI2C液晶が動いた
    (なお表示は温度計を作ろうとしていた時のダミー表示)  

  • ゲームボーイの吸い出し機を作った (後編)
    2017年01月16日 22:44

    前編の続き。プログラム側について。

    まずは単純に読むことを試みる。
    手持ちの中でバンク切り替えなし(32kB)のソフトとしてDr.マリオを選択。

    バンク切り替えが無ければアドレスを出してデータを読むだけ。
    …とはいえCLKとかCSとかRDとかどう制御すればいいのか。
    GBのカートリッジの仕様くらいいくらでも見つかると思っていたのだが、ROMの読み出し方法は常識なのか、細かい解説が意外と見つからない。
    結局、分かってみると単純で、
    /RDがLにアサートされている間、アドレスピンで指定されたアドレスのデータが、データピンに出る
    というだけのことだった。
    つまり読み出すには、/RDをLにアサートしたままアドレスを順次変え、データピンを読むだけでよい。
    これが分かるまでに/RDをH/L切り替えてしていた。
    あと/CSはSRAMを読む時アサートするものだった。

    プログラミング自体もなんだかんだで苦労した。
    やはり合っているか分からない操作を正しく組めているか分からない機械にプログラムするのは疑心暗鬼に陥ってだいぶ精神を消耗する。
    まずシリアル通信するところからしてうまくいかない。
    シリアルポートが全く反応しなくて焦った挙句Windows10へアップグレードした時にケーブル類全部抜いてたのを戻してなかっただけだったりもした。
    何か出るようになったと思えば文字化けしている。これはどうもTeraTermのバグかWindows10との相性のようで、最新版を使ったら正常であった。
    新しいPICを使う際には毎回のようにGPIO以外の機能を切っていなくて問題が起こるのだが、今回もまんまとその罠にはまった。
    ADコンバータとコンパレータを切ったまでは良かったのだが、それで読もうとしても何も読めない(FFが読める)。
    ポートのレジスタを直接インクリメントしてたのがまずかったかと思い、別の変数をインクリメントしてそれを出力するようにしたところ何かは読めるようになったが、全体にわたりほぼ確実に8バイトづつ同じ値が取れる。
    つまりアドレスの下3bitが何かおかしい。そのピンを調べると、LCDドライバの電圧生成機能がデフォルトでONであった。
    ということはポートのレジスタを直接インクリメントすること自体は問題なく、最下位bitの書き込みが無視されていたせいでインクリメントできていなかったんだな。

    というわけでついにDr.マリオが読めた。
    Dr.マリオ

    次はバンク切り替え…の前に色々なソフトをバンク0だけ読んでみることにした。
    するとポケモンYellowやポケモンカードなど読めるものもあるが、ポケモンSilverが読めない。
    読めないというのは、ほぼ全てFFが返ってくる。ごく稀にFF以外のものが返ってくることもあるのがまた不可解である。
    FFでない箇所のパターンは規則的で、なにかありそうである。2進数で「xxxx xxx1 0000 000x」と「xx00 0110 0000 0001」、つまり0100, 0101, 0300, 0301,…と0601, 4601がFFでない。
    不要なはずのクロックだがMBCを積んでいることもあり何か変わるのではないかと入れてみる。当然変わらず。
    …散々悩んだ挙句、電圧不足であった。
    いつもPICを動かす時はEneloop2本(2.6V程度)を使っていて、使いやすい5V電源を持っていないこともあり、とりあえずそれでやっていたのだが、GBの電圧は5Vなので動かなくてなんの不思議も無いのであった。
    Dr.マリオを始めいくつかのソフトで(バンク0は)読めていたので発覚が遅れた。

    改めてバンク切り換えだ。
    バンクの少ない(最少の4バンク)ものとしてQIXを選択。
    バンク切り換えの手順はMBCによって少々違うが、基本的に特定のアドレスにデータを書き込むだけである。
    書き込むべきデータを入れていなかったり、PICのIOを入力のまま出力したつもりになっていたり、書き込むアドレスを間違ったりして手間取ったが、まあまあすんなりと読めた。
    QIX

    さて続いて本命のポケモンSilverだ。
    128バンクあるが、バンク切り換えのやり方は同じなので、単純に数が多いだけ。難しいことは何もない。
    しかしなぜか途中でデータが飛ぶ。読み取ったデータを見るとファイルサイズが想定より小さい。
    今までこのような大量のデータをシリアルで受信したことは無かった。シリアル通信の信頼性はこの程度なのだろうか。
    だがそれは想定の内。1バンクごとに目印を入れてあるのでどこで抜けたかは分かる。何度か読んで正常な部分を切り貼りすればよいだろう。
    …と思っていたのだが、不思議な事に常にエラーが出ている場所がある。
    バッファ切れを疑ってバッファ量を変えたりウェイトを入れたりしてもなんとなく変化はあるものの直らず。
    データの問題かと思いXOR 0x55したデータを送ってみると抜けの量はほぼ変わらず、抜けの位置が変わった。特定のデータが来ると問題が起こるのだろうか。
    速度を落としてみるとだいぶ改善した。抜けが6バンクまで減ったので試しに起動してみると、一応起動はした。
    ポケモンSilver_データ抜け1ポケモンSilver_データ抜け2
    このような分かりやすいバグった表示になるものなんだなあ。
    なお部屋に出口がないので進めなかった。その後もう1バンク正常に取れたのでそれと合わせると部屋から出られたがBGMが異常になったりする。
    しかしここで何度とってもほぼ同じ場所でエラーを起こす。
    やはり速度を落とすだけでは解決しない。特定のデータが問題という線で考えてみよう。
    改行の処理に時間が掛かっている可能性を考えてCRの後にウェイトを入れてみる。むしろ悪化。
    あとは…エスケープシーケンス。何らかのエスケープシーケンスが来るとそれの処理に時間がかかってデータを取りこぼすのではないか。
    ここでTeraTermを調べて、受信した文字をすべて表示するデバッグモードがあることを知る。
    デバッグモードで受信するようにしたところ、一切取りこぼさなくなった!
    ポケモンSilver
    後で調べたところ、制御シーケンスに「1B 63: 端末リセット」というものがあるらしい。
    つまりこのバイト列が来るとTeraTermがリセット動作を起こし、その間に来たデータを取りこぼしていたようだ。
    調べてみると「1B 63」は最後まで読めなかった5バンク中の3ヶ所にあった。残り2ヶ所やそれ以前のエラー箇所は分からないままだがたぶん他のエスケープシーケンスだろう。
    デバッグモード以外にエスケープシーケンスを無視する方法がないか調べたのだが、見つからなかった。
    人が読む文字列を出す時は改行は使いたいのだが、致し方ない。

    次に困ったのがX(エックス)だ。バンク切り替えができない。
    調べてみるとこれに使われているMBC2はバンク切り替え時に書き込むアドレスに制限があり、今まで使っていた0x2000では駄目だった。
    と0x2100に変えてみたが、やはりバンクは切り替わらない。
    そこで読み取れたバンク0のコードを見てみることにした。この中にバンク切り替えのコードがあるはずである。
    するとやはり0x2100に書き込んでいる。
    合っているのにおかしいなと思い更に調べると、バンク1に変更する時は0x2100だったのだが、バンク2では0x2101、バンク3では0x2102…と、バンクNに変更する時0x2100+(N-1)に書き込むようになっていた。
    1少ないのは書き込み後のインクリメントの関係だろう。ということでバンクNに変更する時は0x2100+Nに書き込むようにコードを書き換えてみると、見事読み取りに成功した。
    なんだろう。バスコンフリクトだろうか。ファミコンのMMCでバスコンフリクトを起こすものがあるという情報はあるが、GBで起こるというのは見たことがなかった。
    X(エックス)

    さて次はニンテンドウパワーのGBメモリの読み取りを試みている。
    これは複数のMBCの動作を再現する特殊なコントローラを積んでおり、普通のバンク切り換えとは異なるコマンドを入れる必要があるらしい。
    色々試しているのだがまだ一切反応がない。一番つらい時期だ。
    読み取りができたら、どうも書き込みも出来るらしいのでやりたい。自作ソフトを実機で動かすのは夢である。

    ただその前に、どうも読み取りが安定しないのでどうにかしたい。
    今まで読めていたソフトでも読めなくなったりしている。
    断線しかかっているとかだろうか…。  

  • ARMマイコンはじめました。
    2016年05月28日 14:43

    はじめました。2013年6月頃に。なぜ今頃書くかというと、9割書き上げて放置されていたのを今発掘したためだ。

    その頃、LPC810というARMマイコンがでた。
    8ピンDIPなのでブレッドボードに直接挿せるという。

    これが秋葉原のマルツに入荷したというので早速買いに行った。

    売り切れだった。

    しかし上位種のLPC812は残っていたのでこれを買ってきた。
    LPC812はピン数やメモリ容量、周辺機能といった全ての面でLPC810を上回っており、値段もあまり変わらない。今見ると25円差。当時もたぶんそれくらいだったと思う。
    ただ1つだけ重大な欠点があり、パッケージがDIPではなくSOPで扱いづらい。
    ハーフピッチのユニバーサル基板でピッチ変換してみたが、後悔した。めっちゃめんどい。
    LPC812をハーフピッチ基盤にハンダ付け
    秋月でちょうどいい変換基板が80円で売られているのでお勧めだ。

    さてこの石はPICやAVRと違って専用の書き込み機が必要ないので出費が少なくて嬉しい。

    書き込み用の接続は開発環境が無くても試せるのでまずこれを試す。

    用意する物はシリアルポートと7404(NOT)か何かとあと抵抗。
    自分はこんなこともあろうかとシリアルポート付きのPCを買っているが、きっとUSB-シリアル変換ケーブルでも大丈夫だと思う。
    7404は要するに論理を反転できればいいので7400(NAND)とか7402(NOR)でもよい。自分が使ったのもNANDだ。
    シリアルポートとの接続はこのページを参考に直結した。
    軽く説明すると、シリアルポートの受信側インピーダンスは3kΩ~7kΩらしいのでそのための4.7kΩと、電圧が高いので電流を落とすための100kΩである。

    この回路をLPC812のUSART0ポートに接続、そしてブートローダーを立ち上げるためにPIO0_1をGNDに落とす。
    以上で準備は完了。
    LPC812 をシリアルポート接続
    電源を繋ぎ、適当なターミナルソフトからデータ8bit、パリティなし、ストップ1bit、速度任意の設定で「?」の1文字を送信する。
    成功すれば「Synchronized<改行>」が表示されるはずだ。
    LPC812_Symchronized

    接続に成功したので次は開発環境のLPCXpressoIDEをいれる。登録とか要るのでまあ適宜なんとかする。
    さらに書き込みソフトのFlashMagicをいれる。

    IDEを立ち上げる
    左下に「Quickstart Panel」があり、その中の「Start here」の中に「Import project(s)」
    Examplesフォルダが開いてるのでその下から
    \NXP\LPC800\NXP_LPC8xx_SampleCodeBundle.zip
    のようなものを探してあとは適当に全部入れる。
    Project Explorerを見ると色々入っている。BlinkyというモノがLEDを点滅させてくれそうだ。してみるとこれだけ入れればよかったか。まあいいや。
    Blinkyを選んだ状態でメニューからProject→Build Projectを選択。
    すると何やら動きだし、デバッグビルドができたようだ。リリースビルドの方が良かったかと切り替えてみたら何やらエラーが出た。まあデバッグで困ることもないしいいや。
    さてビルドができたのでFlashMagicから書き込もうとしてみるが、できたファイルはaxfで書き込むためのファイルはhexのようだ。
    調べてみるとどうやらaxfファイルはIDEから直接書き込んでデバッグとかするためのファイルのようで、hexファイルを出力するにはaxfから変換する必要があるようだ。めんどい。
    http://support.code-red-tech.com/CodeRedWiki/OutputFormatsを参考に
    下のバーの右手側にあるというプロジェクト名を探したら左側にあったが、気にせずCtrlクリック。
    intel形式のhexファイルにしたいので
    arm-none-eabi-objcopy -O ihex blinky.axf blinky.hex
    を実行。失敗。ファイルが無いと言われる。
    パスが違ってた。こうだな
    arm-none-eabi-objcopy -O ihex debug/blinky.axf blinky.hex
    今度は成功。思っていたところの1階層上に出力されたがまあいいや。

    あとはFlashMagicで適に設定して書き込み。これは難なく成功した。
    FlashMagicでLPC812に書き込み

    ブートローダー設定用のGNDに落としたピンを外して電源を入れると
    …動いた!
    LPC812_blinky
    3つのLEDが順番に消灯する。多分順番に点灯するべきなので、+-を間違っているようだがまあいいや。

    その後TVにカラー出力など試していた
    LPC812でNTSCカラー
    が、命令プリフェッチの関係かクロック数がどう数えても合わないので力尽きた。
    より困難な(プリフェッチ幅が広く、I/O命令が遅い)LPC1114でNTSCカラー出力を実現したPancake(IchigoJam周辺機器)はすごいと思う。尊敬する。  

  • SDカードから1セクタ読み取るまでの手順解説
    2015年10月05日 01:09

    数年前からマイコンでSDカードを読みたいと思い続けていたが、やっと実行に移した。(そしてそれをブログに書くまでに1ヶ月…)
    使うマイコンはもちろん慣れ親しんだPIC。中でも最近一番のお気に入りの10F200…といきたかったのだが多少無理があったので12F510に。
    10F20012F510
    Flash256ワード1024ワード
    RAM16バイト38バイト
    I/Oピン4本6本
    主に問題なのはI/Oピン数。SDの操作に4ピン使うので、10F200では他にピンが余らない。またFlash容量も心許ない。読み取りだけならなんとかなるにしてもデバッグ用に出力などする余裕が全くないだろう。

    回路はこちら。単純につないだだけ。
    回路写真
    現在、第0セクタ512バイトを読んだところである。
    SDカード_1セクタ読み出し
    次はファイルシステムを解釈してファイルの読み書きをしようと思っているが、その前に今回得た知見をブログにまとめておくことにする。



    まず参考資料。

    1. https://www.sdcard.org/downloads/pls/simplified_specs/
    数年前からSDカードの仕様は公開されている。完全な仕様書ではなく「Simplified」ではあるものの、れっきとした公式資料。
    これが公開される前はマルチメディアカード(MMC)としてのコマンドで扱うしかなかった。SPIモード部分についてはMMCとSDは互換性があるのでそれでも扱えるのだが、4ピンを使う高速なSDカード本来のプロトコルは使えない。
    この仕様書の公開によってついにSDカード本来のプロトコルが使えるように…なったかと思いきや実は足りない部分があってMMCの仕様書を見て埋めないといけないとも聞く。
    まあとりあえず今のところSPIモードしか使うつもりはないので困らない。

    2. MMC/SDCの使いかた
    ChaNさんのサイト。日本語のサイトの中ではもっとも詳しく説明されていると思う。何度見たか分からない。

    この2つの資料で分からない事はそのたびに適当に検索して調べていたのでどのサイトを見たかあまり覚えていない。
    思い出せるところでこのへんか。
    http://bluefish.orz.hm/sdoc/psoc_mmc.html
    http://bitcraft.web.fc2.com/embedded/microchip/microchip.html



    次にSDから1セクタ読むまでの手順…の前に色々解説。

    SDのSPIモードでの操作は、(当たり前ではあるが)すべてSPIのプロトコルに則った通信で行われる。つまりすべての通信は1バイト単位で行われる。
    そしてすべての通信は機器側がマスター、SDカードがスレーブで行われる。つまりSDカードが自発的にデータを送ってくることはなく、常にマスターがクロックを送ることでデータを読みだすことになる。
    なおSPIは全二重の通信ができる規格だが、SDカードの操作では大抵どちらかがデータを出すときはもう一方はデータを出さない(0xFFを出す)。両方がデータを出しているのはデータパケットの受信を止める時くらいか。
    SDモードでは1本のデータ線で半二重通信をするのでそれと合わせたのかもしれない。あるいはそもそも必要ないしそっちの方が楽ということかもしれない。
    SPIモードに入ってからの通信はすべてコマンドを送信して返答を読み取るトランザクション単位で行われる。
    そしてトランザクションはパケット単位で行われる。1つのトランザクションの流れは次のようになる。
    ・コマンド送信
    ・レスポンス受信
    ・(あれば)データ送信or受信
    なおコマンド送信後すぐにレスポンスが読み取れるとは限らない。0xFFが読めた場合それを読み飛ばす必要がある。
    1つのトランザクションが終わった後には1バイト以上のクロックを送信しなければならないという奇妙な仕様がある。
    マスターはクロックをいつでも中断できる(ACMD41の最中を除く)。

    コマンドは、6バイト固定で次のような構造をしている。
    ・1バイトのコマンド番号
     うち頭2bitはスタートビットと、通信方向を示すTransmission Bit
    ・4バイトの引数
    ・1バイトのCRC
     うち末尾1bitはEnd Bit(って書いてあるけどストップビットって名前のほうが馴染みがある)
    1バイト単位なのにスタート・ストップビットがあるという奇妙な構造だが、1bit単位で通信を行うSDモードと共通化したためであろう。通信方向を示すのもSPIモードでは送受信に別の線が割り当てられているしCSもあるのだから不要である。
    CRCはSPIモードでは基本的にはチェックされないため適当な値を入れればよいが、そうでないところもあり要注意だ。
    レスポンスには以下の種類がある。
    ・R1: 1バイトで、単純な状態を返す。
    ・R1b: R1の後にビジー応答(連続したLowレベル)を返す。
    ・R2: 2バイトで、R1に加え詳細なエラー状態を返す。
    ・R3/R7: R1に加え4バイトの情報を返す。
    ・R4/R5: SDIOのための予約らしい。
    ・R6: どうやらSDモード専用のようだ。
    データパケットは、任意バイト数のデータを1バイトのヘッダと2バイトのCRCで挟んだ構造である。
    コマンドと異なりデータパケットのヘッダは先頭bitが0ではない。こちらはSPIモード専用なので1バイト単位で読む前提のようだ。



    改めて、SDから1セクタ読むまでの手順。

    ・コマンド送信前の儀式
    まずSDカードの電源を投入してから1ms待ち、74個以上のクロックを送ることでコマンドを受け付ける準備が完了する。
    74とは中途半端だが、この時点ではSDモードなのでクロック数が8の倍数である必要がないためだ。もっともSPIで制御するなら切りよく80クロック送るのが楽だろう。

    これ以下はSPIモードと考えて良い。

    ・CMD0 リセット
    このコマンドは本来の機能の他にSPIモードへの切り替え機能を持っており、CSをLowにした状態で送ることでSDカードをSPIモードにすることができる。このコマンドを送信する時点ではSPIモードではないのだが、コマンド送信についてはSDモードとSPIモードでほぼ同じ形式なのでSPIモードのつもりで問題ない。
    SDモードで使うときにはCSをHighでこのコマンドを送ることで、SPIモードのレスポンスとは違う何かが起こる(よく知らない)。
    引数は任意と書かれているところと0固定と書かれているところがあってよく分からない。たぶん任意だと思うが、まああえて0以外を送る理由もない。
    SPIモードでないためCRC必須。引数が0の場合CRCは0x95である(ストップビット含む)。
    返答はidleフラグのみの立った「0x01」であるはずである。

    ・CMD8 インターフェースコンディション確認
    引数は、0x000001XX。
    XXは任意。0xAAが推奨されているが、私は0xABをおすすめする。これにすると、CRCの値をCMD0と同じにすることができる。
    仕様書にはSPIモードでもCRC必須とある。
    ネット上の情報では「CMD0のみCRC必須」と書かれているものがあるが、どうもCMD8はSDカードのver.2からできたコマンドのようで、それ以前はCMD0のみがCRC必須のコマンドだったせいで混乱しているように見える。
    このコマンドは対応している電圧範囲を取得するコマンドであり、レスポンスはR7で引数に指定された電圧範囲に対応しているかと、上で「任意」と書いたチェックパターンがそのまま返ってくる。
    ただ、これは全電圧範囲に対応しているか否かを調べるだけで、普通は対応しているし、対応していなかったらどうしようもないので、調べる意味はあまりない。
    が、これを送ることでSDHC/SDXCはCMD58とCMD41を有効化するということなので、送信は必須のようだ。
    なおこれはver2以降のカードの場合であり、それより前のカードでは不正コマンドとなり、返答はR1で「0x05」となる。つまりver2以降か否かを調べるという効果もある。
    1バイトしか返答がないところ5バイト読むと、残りはデータ線がHighのままなので0xFFが読める(害はない)。

    ・CMD1またはACMD41 初期化
    初期化コマンドは仕様書を読む限り、「CMD1を使うとMMCとSDの区別がつかないので非推奨」と読めるのだが、手元のいくつかのカードで試してみたところ、CMD1を受け付けないカードがいくつかあった。ACMD41を使わなければならないのだろうか。しかしそれではSDのSimplified仕様書が公開される前にMMCとして扱えていたという情報と矛盾するように思う。
    なんにせよ今回使ったSDはCMD1に反応したので今回のコードではCMD1のままである。
    CMD1は引数任意でレスポンスはR1。初期化が完了するまではidleを示す0x01、完了したらエラー無しの0x00が返る。
    ACMD41の引数はホストのSDHC/XCサポートの有無を示すHCSの1bitのみ(他のbitは予約)、応答はR3でOCRレジスタの内容が返る。
    idleでなくなるまでCMD1またはACMD41を送り続ける。

    ・CMD58 OCRレジスタ読み取り
    レスポンスはR3で、32bitのOperation Conditions Registerの値を読み取る。内容は対応している電圧範囲、SDHC/SDXCか否かを示すbit、ビジーフラグ。電圧範囲はCMD8でも確認してこちらでも確認するのだろうか。よく分からない仕様だ。
    なお今書いていて気づいたのだが、このコマンドはSDカードでは予約扱いになっており、OCR読み取りにはACMD41を使う前提のようだ。しかし使ったカードではきちんとレスポンスを返してくれた。よく分からない。

    ・CMD9 CSDレジスタ読み取り
    Card-Specific Dataレジスタの値を読み取る。カードの容量など様々な情報が含まれている。
    このレジスタはOCRレジスタと異なり16バイトあるためレスポンスの中身ではなくデータパケットとして送られてくる。
    なお今回のコードではこの内容は読むだけで使っていない。

    ・CMD16 ブロックサイズ指定
    SDHC/SDXCではこのコマンドは無視され512バイト固定だが、SDの一部でデフォルトが512バイトでない場合がありうるので必要らしい。
    面倒なので今回のコードでは省略した。

    ・CMD17 1ブロック読み取り
    このコマンドでカード本体の内容を読める。
    引数は読み取り開始アドレス。
    無印SDカードは1バイト単位、SDHCおよびSDXCはセクタ(512バイト)単位で指定する。
    1ブロック分のデータパケットが得られる。



    以下自分の悩んだ点をまとめておく

    ・CSの操作
    1回のトランザクションごとにCSをHighに戻す。
    つまり、CSをLowにアサート、コマンド送信、レスポンス受信、(データパケットがあれば送受信、)CSをHighに。
    CSの動作として当たり前なのだろうが、これが確信が持てなくてだいぶ悩んだ。

    ・ダミークロック
    トランザクションごとに1バイト分のダミークロックが必要。
    ダミークロックについては仕様書の(SPIモードでなく)SDモードの部分に書いてある。
    CSはHighでもLowでも構わないと書いてあるサイトがあった。とりあえずHighにしている。

    ・ACMDの処理
    CMD55,CMDnのシークエンスをACMDnという。
    それはいいのだが、CMD55と次のコマンドの間の処理がよくわからなかった。
    CMD55を送って返答の1バイトが返ってくるまでで1トランザクション、ここでダミークロックまで送り、次のコマンド本体とその返答がまた1トランザクションということのようだ。

    ・クロック周波数
    初期化中のクロック周波数は100kHz~400kHzと書かれているが、仕様書を読むともっと詳しく書かれている。
    ACMD41を発行しカードの初期化が完了するまで、ホストは次の2つのうちどちらかを行わなければならない。
    1) 周波数100kHz~400kHzの連続的なクロックを出力する
    2) ホストがクロックを停止したいならば、50ms以内の間隔でACMD41によりビジービットをポーリングする
    マイコンでSPIモードを使うならふつうクロックは断続的になるだろうから見るべきは2番の方である。
    ところで50ms以内の間隔ならクロックは100kHzを下回ってもよいのだろうか。
    よいならば最低クロックはACMD41とレスポンスで50msになる値、レスポンスが即時に返ってくるとして6+1+6+5=18バイト分なので、(18*8)/0.05=2880Hzということに…
    なるかと思いきや、よく図を見るとトランザクション中の時間は50msに含まれていない。
    SD仕様書_クロックの制限
    するとクロックが50ms以上止まらなければよいのだろうか。であれば1/(50ms*2)=10Hz…?
    これはちょっと実験してみたいところだ。
    なお、ACMD41を除いてクロックは好きな時に停止してよいようだ。これは助かる。

    ・CRC
    分からない。
    色々な所を見たが、見る所ごとに書いてあることが違う(ように感じる)。
    結局、ここのコードを中身を理解しないままJavaScriptに移植して使ったところ、思ったのと1bit違うところで答えが出たのでそのまま使った。
    http://nabe.blog.abk.nu/0355

    ・自分のプログラムのバグ
    他人の役に立つとは思えないが、面白いバグだったので書き留めておく。
    起こった現象
    初期化シーケンスに対する返答が順に以下のようであった。
    CMD0に0x01が返る。idleフラグのみ立った状態であり、これは正しい。
    CMD8に0x00FFFFFFFFが返る。つまり1バイト目はエラー無しを示しているのにその後に続くはずのデータが来ない。古いSDでCMD8に非対応だからだろうか。
    CMD1に常に1回で0x00が返る。idle待ちがあるはずだが…まあきっと通信が遅いせいだろう。たぶんおかしくない。
    CMD58に0x00FFFFFFFFが返る。つまりCMD8と同様エラー無しなのにデータが無い。

    別のカードを使ってみると違う結果が返るものがあり、
    CMD8に0x00000001AAが返るものがある。idleでないのが不可解だがデータは正しい。
    CMD58に0x0080FF8000や0x0000FF80が返るものがある。これは正しい。

    さて困った。正しいデータが返るものもあるのだから、SPIやシリアル通信のプログラムが間違っているとも思えない。

    CMD58に返答が返るものを使えばとりあえず先に進めるのだからよく分からないがこれを使っておくか…
    …と思ったが、色々考えてみるとやはりCMD8に0x00が返ってくるのはおかしい。非対応ならエラーフラグの立った0x05が返るはずである。
    CMD1のidle待ちが無いのも不可解だ。いくら遅いとはいえ1ループ数ミリ秒で回しているのだが、このidle待ちは「数百msかかることがある」というもので、早くても数十msはかかるのではないか。

    つまり、頭の1バイトだけなぜか0x00に化けているのではないか。しかしそんな都合のいいバグが…あった。
    どういうバグかというと、
    ダミークロックを送る関数でバンク0に用意したループカウンタを回すつもりだがバンクを変えておらず、
    運良くシリアル送信との兼ね合いでバンク0にしていた1回目のCMD0を除き、みなバンク1の変数を回していた。
    そしてそこにちょうど読んだデータの1バイト目があったため、カウントダウンしてループを抜けるときには常に0になっていたというわけだ。
    ミッドレンジのPICならバンク切り替えの必要は無かったので、もっと余裕をもった石を使うべきだったかもしれない。(もっとも10F200でなく12F510にした時点で余裕をもったつもりだったのだが)



    最後にコード
    ページ0/1を両方使っているが、ページ1はメッセージだけなのでそれを除けば512バイトのPICにも収めることができる。まあそんなPICはほとんど無いのでできてどうするという話ではあるが。

    ・コード内訳
    000-1FF メインコード・サブルーチン
    200-2FF メッセージ
    300-3FF 未使用
    なおベースラインPICの仕様上ページの前半にしかCALLで飛べないため、サブルーチンの本体は後半に置きつつ前半に一度CALLしてからGOTOで本体に飛ばす構造になっている。


        list    p=12F510
        #include p12F510.inc
        radix dec

        ;    12F510
        ;      Vdd+-v-+Vss
        ;      GP5|   |GP0 DAT
        ;      GP4|   |GP1 CLK
        ;    (GP3)+---+GP2

        ;-    /--
        ;CS  |
        ;DI  |
        ;Vss |
        ;Vcc | 表
        ;SCL |
        ;Vss |
        ;CO  |
        ;-   +---

        variable env
    env=    _IOSCFS_ON
    env&=    _MCLRE_OFF
    env&=    _CP_OFF
    env&=    _WDT_OFF
    env&=    _IntRC_OSC
        __config env

        cblock 0x0A ;バンク共通
            bitcnt, bytecnt, skipcnt
            commdat, spioutbuf
        ;バンク0
            flag
            cnt0, cnt1, cnt2, cnt3
            temp, temp2
            arg0, arg1, arg2, arg3
            msgptr
        endc
        ;バンク1は読み取ったデータの保存領域

    ;ram alias

    ;bytecnt equ bytecnt

    ;flag bit
    RXFLAG  equ 0
    TIMEOUT equ 1

    MOSIPIN equ 0
    MISOPIN equ 3
    SCLKPIN equ 1
    CSPIN   equ 2
    RXPIN   equ 4
    TXPIN   equ 5
    MORSEPIN equ 5
    MOSIBIT equ 1&lt;&lt;MOSIPIN
    MISOBIT equ 1&lt;&lt;MISOPIN
    SCLKBIT equ 1&lt;&lt;SCLKPIN
    CSBIT   equ 1&lt;&lt;CSPIN
    RXBIT   equ 1&lt;&lt;RXPIN
    TXBIT   equ 1&lt;&lt;TXPIN

    CMD equ 0x40
    CRC_CMD08 equ 0x95
    ;CMD0: 40 00 00 00 00 と
    ;CMD8: 48 00 00 01 AB で兼用

    #define flagWAIT STATUS,GPWUF
    #define flagCMD8 STATUS,CWUF


    ;##### EntryPoint #####
        org 0x00
        goto init

    ;##### Subroutine Entry #####
    ;関数のcall先。ベースラインではページの前半しかcallできないためここにまとめてある。
    ;関数の本体はメインコードの後に置いてある。
    txmsg232:
        goto txmsg232core
    getmsgbyte: ;これのみページ1へ飛ばす
        bsf STATUS,PA0
        movwf PCL
    skipandread1: ;Wに1を入れてskipandreadn。すなわち1バイト読む
        movlw .1
    skipandreadn: ;0xFFのバイトを読み飛ばした後にNバイト読む
        bsf flagWAIT
    readn: ;Nバイト読む
        goto readncore
    skip2np1:
        goto skip2np1core
    skip2n:
        goto skip2ncore
    tx232hex:
        goto tx232hexcore
    ;readresponse1:
    ;    bsf respcnt,0
    ;readresponse:
    ;    goto readresponsecore
    sendnibble:
        goto sendnibblecore
    sendsdcmdarg0:
        goto sendsdcmdarg0core
    sendsdcmd:
        goto sendsdcmdcore
    ;morse8:
    ;    movwf dat
    ;    goto f1
    ;morse:
    ;    goto morsecore
    ;morsespace:
    ;    ;interword(7)-interchar(3) =4
    ;    movlw .8
    ;    goto waithalfdit

    readspi: ;SPIで0xFFを送信する
        movlw 0xFF
    spi:
        goto spicore
    tx232:
        bsf GPIO,TXPIN ;0
        bcf flag,RXFLAG
        movwf commdat
        goto tx232core
    rx232:
        btfss GPIO,RXPIN ;[0,3)
        goto rx232
        goto rx232core
    rx232withtimeout:
        bcf flag,TIMEOUT
    rx232waitloop:
        btfsc GPIO,RXPIN ;[0,5)
        goto rx232core
        incfsz cnt0,F
        goto rx232waitloop
        incf cnt1,F ;待ち時間を正しくカウントするために必要
        btfsc GPIO,RXPIN
        goto rx232core
        incfsz cnt1,F
        goto rx232waitloop
        incf cnt2,F ;
        btfsc GPIO,RXPIN
        goto rx232core
        incfsz cnt2,F
        goto rx232waitloop
        bsf flag,TIMEOUT
        retlw 0

    ;##### Main Code #####
    init
        movwf OSCCAL
       
        movlw b'10001000'
        ;       /GPWU
        ;        /GPPU=0: PullUp ON
        ;         T0CS=0: Fosc/4,
        ;          T0SE Don'tCare
        ;           PSA Don'tCare
        ;            PS2:0 Don'tCare
        option
       
        clrf ADCON0
        bcf CM1CON0,C1ON
       
        movlw MOSIBIT|CSBIT
        movwf GPIO
        movlw MISOBIT|RXBIT
        tris GPIO

        movlw 0x2A
        movwf FSR
    b12:
        clrf INDF
        bcf FSR,5
        clrf INDF
        bsf FSR,5
        incfsz FSR,F
        goto b12

    initsd: ;1ms待ってから74個以上のクロックを出力
        ;wait 1ms
        clrf cnt0
    b9:
        goto $+1
        goto $+1
        nop
        decfsz cnt0,F
        goto b9
       
        movlw .5 ;10byte&gt;74
        call skip2np1

    test:

    ;メッセージ出力
        movlw msg_cmd0
        call txmsg232

        bcf GPIO,CSPIN

    ;CMD0を引数0で送信
        movlw CMD|.0
        call sendsdcmdarg0
    ;受信しつつ応答が来るまでスキップし、応答を1バイト読む
        call skipandread1
    ;応答が来るまでにスキップした回数と受信内容を出力
        decf skipcnt,W
        call tx232hex
        movlw ','
        call tx232
       
        movlw 0x30
        movwf FSR
        movf INDF,W
        bcf FSR,5
        call tx232hex
    ;CSをHighに
        bsf GPIO,CSPIN
    ;1バイトダミークロック出力
        movlw .0
        call skip2np1

    ;CMD8で同様
        movlw msg_cmd8
        call txmsg232

        bcf GPIO,CSPIN
       
        movlw 0x01
        movwf arg2
        movlw 0xAB
        movwf arg3
        movlw CMD|.8
        call sendsdcmd
    ;CMD8の応答は5バイト
        movlw .5
        call skipandreadn
       
        bsf GPIO,CSPIN
       
        movlw .0
        call skip2np1
       
        decf skipcnt,W
        call tx232hex
        movlw ','
        call tx232
    ;5バイト出力。もうちょっとまともにやりたい。
        movlw 0x30
        movwf FSR
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
       
    ;CMD1。ACMD41を試してた名残りがある。
        movlw msg_cmd1
        call txmsg232
       
    b13:

    ;    movlw CMD|.55
    ;    call sendsdcmdarg0
    ;   
    ;    call skipandread1
    ;    bsf GPIO,CSPIN
    ;    movlw 0x30
    ;    movwf FSR
    ;    movf INDF,W
    ;    bcf FSR,5
    ;    call tx232hex
       
        bcf GPIO,CSPIN
        movlw CMD|.1
        call sendsdcmdarg0
       
        call skipandread1
        bsf GPIO,CSPIN
       
        movlw .0
        call skip2np1
       
        movlw '/'
        call tx232

        decf skipcnt,W
        call tx232hex
        movlw ','
        call tx232
       
        movlw 0x30
        movwf FSR
        movf INDF,W
        bcf FSR,5
        movwf temp2
        call tx232hex
           
        movf temp2,W
        btfss STATUS,Z
        goto b13
    ;CMD58
        movlw msg_cmd58
        call txmsg232
       
        bcf GPIO,CSPIN
        movlw CMD|.58
        call sendsdcmdarg0
       
        movlw .5
        call skipandreadn
       
        bsf GPIO,CSPIN
       
        movlw .0
        call skip2np1
       
        decf skipcnt,W
        call tx232hex
        movlw ','
        call tx232
       
        movlw 0x30
        movwf FSR
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
    ;CMD9
        movlw msg_cmd9
        call txmsg232
       
        bcf GPIO,CSPIN
        movlw CMD|.9
        call sendsdcmdarg0
        call skipandread1
       
        decf skipcnt,W
        call tx232hex
        movlw ','
        call tx232
       
        movlw 0x30
        movwf FSR
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
       
        movlw .16
        call skipandreadn
       
        decf skipcnt,W
        call tx232hex
        movlw ','
        call tx232
       
        movlw 0x30
    b18:
        movwf FSR
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        movf FSR,W
        andlw 0x1F
        btfss STATUS,Z   
        goto b18
       
        movlw .3
        call readn
       
        movlw 0x30
        movwf FSR
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
       
        bsf GPIO,CSPIN
       
        movlw .0
        call skip2np1
       
    ;---
    ;CMD17
        movlw msg_cmd17
        call txmsg232
       
        bcf GPIO,CSPIN
        movlw CMD|.17
        call sendsdcmdarg0
        call skipandread1
       
        decf skipcnt,W
        call tx232hex
        movlw ','
        call tx232
       
        movlw 0x30
        movwf FSR
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
       
        movlw '/'
        call tx232
       
        call skipandread1
       
        decf skipcnt,W
        call tx232hex
        movlw ','
        call tx232
       
        movlw 0x30
        movwf FSR
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex

    ;512バイトを16バイトごとに受信して表示
        movlw .512/.16
        movwf cnt0
    b17:
        movlw msg_nl
        call txmsg232
       
        movlw .16
        call skipandreadn
       
        movlw 0x30
    b16:
        movwf FSR
        bsf FSR,5
        movf INDF,W
        bcf FSR,5
        call tx232hex
        incf FSR,F
        movf FSR,W
        andlw 0x1F
        btfss STATUS,Z   
        goto b16
       
        bcf FSR,5
        decfsz cnt0,F
        goto b17
           
        goto $

    busychk: ;あれ、なんでこんなところに置いてあるんだろう。ページ前半でないとcallできない。
        goto busychkcore

    ;##### Subroutine Core #####
    busychkcore: ;ビジーチェック…のはずだけどどうやら使っていない。
        call readspi
        movf commdat,W
        btfsc STATUS,Z
        goto busychkcore
        retlw 0

    readncore: ;Nバイト読み取り
        movwf bytecnt
        movlw 0x30
        movwf FSR
        clrf skipcnt
    readloop:
        call readspi
        btfss flagWAIT
        goto f2
        incf skipcnt,F
        incf commdat,W
        btfsc STATUS,Z
        goto readloop
        bcf flagWAIT
    f2:
        movf commdat,W
        movwf INDF
        incf FSR,F
        decfsz bytecnt,F
        goto readloop
        bcf FSR,5
        retlw 0

    sendsdcmdarg0core: ;SDのコマンドを引数を0にして送信
        clrf arg0
        clrf arg1
        clrf arg2
        clrf arg3
    sendsdcmdcore: ;SDのコマンドを送信
        call spi
        movf arg0,W
        call spi
        movf arg1,W
        call spi
        movf arg2,W
        call spi
        movf arg3,W
        call spi
        movlw CRC_CMD08
        call spi
        retlw 0

    skip2np1core: ;2N+1バイト分のダミークロックを出力
        bsf bitcnt,3
    b14:
        bsf GPIO,SCLKPIN
        goto $+1
        bcf GPIO,SCLKPIN
        decfsz bitcnt,F
        goto b14
    skip2ncore: ;2Nバイト分のダミークロックを出力
        movwf bytecnt
        movf bytecnt,W
        btfsc STATUS,Z
        retlw 0
    b11:
        bsf bitcnt,3
    b10:
        bsf GPIO,SCLKPIN
        goto $+1
        bcf GPIO,SCLKPIN
        goto $+1
        bsf GPIO,SCLKPIN
        goto $+1
        bcf GPIO,SCLKPIN
        decfsz bitcnt,F
        goto b10
        decfsz bytecnt,F
        goto b11
        retlw 0

    spicore: ;SPI 1バイト送受信
        movwf commdat
        rrf GPIO,W
        andlw ~(0x80|SCLKBIT&gt;&gt;1|CSBIT&gt;&gt;1|MISOBIT&gt;&gt;1)
        movwf spioutbuf
    ;    bcf GPIO,CSPIN
       
        bcf STATUS,C
        bsf bitcnt,3
    spiloop:
        rlf commdat,F
        rlf spioutbuf,W ;CS:L SCLK:L MOSI&lt;-C / c0
        movwf GPIO
        goto $+1
        bsf GPIO,SCLKPIN
        btfsc GPIO,MISOPIN
        bsf commdat,0
        decfsz bitcnt,F
        goto spiloop
       
        bcf GPIO,SCLKPIN
       
        retlw 0

    ;### RS232C
    ;RS232Cシリアル関連のコード。

    txmsg232core: ;文字列を送信
        movwf msgptr
    msgloop:
        call getmsgbyte
        bcf STATUS,PA0
        movwf temp
        andlw 0x7F
        call tx232
        btfsc temp,7
        retlw 0
        incf msgptr,F
        movf msgptr,W
        goto msgloop
        retlw 0

    tx232hexcore: ;1バイトを16進表記で送信
        movwf temp
        swapf temp,W
        call sendnibble
        movf temp,W
        call sendnibble
        retlw 0
       
    sendnibblecore: ;下位ニブルを送信
        andlw 0x0F
        movwf commdat
        movlw .6
        addwf commdat,F
        movlw '0'-.6
        btfsc STATUS,DC
        movlw 'A'-.10-.6
        bsf GPIO,TXPIN ;0
        bcf flag,RXFLAG
        addwf commdat,F
        goto tx232core

    rx232core: ;1バイト受信。使っていない。
        bsf flag,RXFLAG ;[4,7) mean5.5
        movlw 0xFF
        movwf commdat
        goto $+1
    ;    btfsc flag,BAUD300
    ;    goto wait0r5a
    ;waitend0r5a:
        goto $+1
        goto $+1
        goto $+1
        goto $+1
        goto $+1

    ;tx232:
    ;    bsf GPIO,TXPIN ;0
    ;    bcf flag,RXFLAG
    ;    movwf commdat
    ;    goto tx232core
    tx232core: ;1バイト送信
        nop ;5
        bsf bitcnt,3

    loop232:
        goto $+1
    ;    btfsc flag,BAUD300 ;ボーレートを115200と300で選べるようにしようと思ったが結局115200固定に。
    ;    goto wait1b
    ;waitend1b:
        goto $+1
        nop
        bcf STATUS,C
        btfss GPIO,RXPIN ;read 28.5 +17n
        bsf STATUS,C
        rrf commdat,F
        movf GPIO,W
        andlw ~TXBIT
        btfss STATUS,C
        iorlw TXBIT
        movwf GPIO ;send 20 +17n
       
        decfsz bitcnt,F
        goto loop232
       
    ;    btfsc flag,BAUD300
    ;    goto wait1c
    ;waitend1c:
        ;連続受信を極力早くするためここでreturn(2命令挟んで次のcallでストップビット中央)
        btfsc flag,RXFLAG
        retlw 0

        goto $+1
        goto $+1
        goto $+1
        goto $+1
        goto $+1
        goto $+1
       
        bcf GPIO,TXPIN ;send stop +17
        goto $+1
    ;    btfsc flag,BAUD300
    ;    goto wait1d
    ;waitend1d:
        goto $+1
        goto $+1
        goto $+1
        goto $+1
        nop
        ;連続送信で安全な時間空ける(1命令挟んで次のcallでストップビットが17サイクル)
        retlw 0

    ;### morse
    ;デバッグ出力用にモールス信号を出力するコードを書いたが結局使わなかった。

    ;morsecore:
    ;    movwf dat
    ;b3:
    ;    decf cnt0,F
    ;    rlf dat,F
    ;    btfss STATUS,C
    ;    goto b3
    ;f1:
    ;    movlw .8
    ;    addwf cnt0,F
    ;
    ;b4:
    ;    ;bcf GPIO,OUTPIN
    ;    rlf dat,F
    ;    movlw .6 ;dah
    ;    btfss STATUS,C
    ;    movlw .2 ;dit
    ;    movwf cnt2
    ;
    ;b5: ;2MHz,4*256cyc: ~1kHz
    ;    movlw 1&lt;&lt;MORSEPIN
    ;    decfsz cnt3,F
    ;    goto b5
    ;    xorwf GPIO,F
    ;    decfsz cnt1,F
    ;    goto b5
    ;    decfsz cnt2,F
    ;    goto b5
    ;
    ;;bsf GPIO,OUTPIN
    ;
    ;;1点間隔
    ;    movlw .2
    ;    movwf cnt3
    ;b7:
    ;    ;4cyc,2MHz: .13sec
    ;    nop
    ;    decfsz cnt1,F
    ;    goto b7
    ;    decfsz cnt2,F
    ;    goto b7
    ;    decfsz cnt3,F
    ;    goto b7
    ;
    ;    decfsz cnt0,F
    ;    goto b4
    ;
    ;;interchar(3)-interelem(1) =2
    ;    movlw .4
    ;;    goto waithalfdit
    ;
    ;waithalfdit:
    ;    movwf cnt3
    ;b6:
    ;    ;4cyc,2MHz: .13sec
    ;    nop
    ;    decfsz cnt0,F
    ;    goto b6
    ;    decfsz cnt2,F
    ;    goto b6
    ;    decfsz cnt3,F
    ;    goto b6
    ;    retlw 0

    ;メッセージ。最上位bitを立てることで終端を示している。ASCIIしか使えないが、\0終端と比べ1メッセージあたり1バイト節約できるのが利点。
    ;GBのアセンブラにあった機能を真似してみた。
        org 0x200
    msg_cmd0:
        dt "\r\nCMD0 reset&SPI mode\r", '\n'|0x80
    msg_cmd8:
        dt "\r\nCMD8 &gt;ver.2?\r", '\n'|0x80
    msg_cmd1:
        dt "\r\nCMD1 initialize\r", '\n'|0x80
    msg_cmd58:
        dt "\r\nCMD58 read OCR register\r", '\n'|0x80
    msg_cmd9:
        dt "\r\nCMD9 read CSD register\r", '\n'|0x80
    msg_cmd17:
        dt "\r\nCMD17 read single block\r", '\n'|0x80
    msg_nl:
        dt "\r", '\n'|0x80
        end
      

  • 初代PIC解説
    2015年09月22日 05:27

    PICマイコンの歴史を追っていこうと思う。
    以前ベースラインPICの注意点としてベースラインからミッドレンジでの差異を書いたが、今回はそのさらに前、PIC1650について。

    PIC1650はまだMicrochipが分社化される前、GIにより作られたもので、「商業的に入手可能な最初のPIC」であるようだ。
    CP1600という16bitマイコンの周辺インターフェース制御のために作られたそうだ。
    そう、なんで8bitなのにPIC16なのかの謎がこれで解けた。

    ネットで探すとデータシートが見つかるので現在のPICと比較してみたところ、これが現在でいうベースラインPICとほとんど同じと言っていい作りであった。初代から現在まで連続的に拡張を繰り返しているわけだ。それはアーキテクチャも変態になろうというものだ。
    この頃はまだアーキテクチャが単純で整然としている。

    具体的に見ていこう。

    クロックは外部クロックと外部RCが使用でき、最大周波数は1MHz。
    現在のPICはほとんどがRC発振器内蔵・発振子用の発振回路内蔵だがそのようなものはない。

    コールスタックはベースラインと同じく2レベル。

    レジスタは今でいうSFRを含め32本のみ。ページングなし。
    今のようにアセンブラで指示するためのレジスタ名は付いていないようで、F0など数字で書かれている。
    F0 (名前なし)
    F1 Real Time Clock Counter Register
    F2 Program Counter (PC)
    F3 Status Word Register
    F4 File Select Register (FSR)
    F5 I/O Register A (RA)
    F6 I/O Register B (RB)
    F7 I/O Register C (RC)
    F8 I/O Register D (RD)
    これを見て分かるように、周辺機能と呼べるものはReal Time Clock Counterしか存在しない。

    現在のPICで最も近いと思われるPIC16F5xと比較してみよう。
    00 INDF
    01 TMR0
    02 PCL
    03 STATUS
    04 FSR
    05 PORTA
    06 PORTB
    07 PORTC (16F57,59のみ)
    08 PORTD (16F59のみ)
    09 PORTE (16F59のみ)
    普通にアクセスできるレジスタに関しては全く同じ構成であることが分かる。(後述するようにOPTION_REGとTRISxは無い)

    ただし機能は異なるものもある。順に比較しよう。
    ・F0
    今のINDFと同じ
    ・F1
    リアルタイムクロックなどと大層な名前が付いているが今のTMR0の外部入力モードと同じ。
    内部クロックのカウント機能は無い。ただしクロック出力ピン(現在のものと同じく1/4出力)はあるので外部でタイマー入力につなぐことで同じ動作が可能。
    プリスケーラや入力エッジ選択機能も無い。
    ・F2
    今のPCLと違い、書き込みのみで読み出し不可。
    つまり現在のような「ADDWF PCL」でのジャンプは出来ないことになる。定数テーブルの読み出しが面倒である。
    ・F3
    内容は、
    1 1 1 1 PC9 Z DC C
    PC9はPCの(0から数えた)9bit目、今でいうPA0相当。ただし将来のための予約bitで、PIC1650は512Wordしかないため未使用。
    スリープ・WDT関係のフラグが無く、PA0相当の位置が違うが、内容は現在のSTATUSとかなり近い。
    ただし今のSTATUSと違い、ビットセット/クリア命令でのみ書き込み可能。
    今のSTATUSは、「C,DC,Zのうちいずれかのフラグに影響する命令を使うと、この3つ全てのフラグへの書き込みが無視された上で、命令の影響でフラグがセットされる」という複雑な仕様である。
    ・F4
    今のFSRと同じ。未使用bitが「1」で読めるところも今と同じ。
    ・F5-F8
    今のPORTxに相当するが、TRISxレジスタは無い。
    しかしポートは入出力が可能ということになっている。説明を読むと、
    1を書き込むと、Highになる
    0を書き込むと、Lowになる
    読むと、現在のピンの状態が読める
    これだけ見るとただの出力ピンだが、このHighというのが出力電流100μAでしかない。そうか、この頃はCMOSじゃなかった。
    つまり、実質的に、1でプルアップ・0でLowということなので、1を書き込んだ状態でプルアップ付き入力として使えるわけである。
    説明を読むと、TTLデバイスの入力やオープンコレクタデバイスの出力につなげますよと書いてある。TTLの出力には繋げないのだろうか。

    命令を並べてみると、整然としている。
    000000 0 00000No OperationNOP
    000000 1 fffffMove W to fMOVWF
    000001 0 fffffClear WCLRW
    000001 1 fffffClear f CLRF
    000010 d fffffSubtract W from fSUBWF
    000011 d fffffDecrement fDECF
    000100 d fffffInclusive OR W and fIORWF
    000101 d fffffAND W and fANDWF
    000110 d fffffExclusive OR W and fXORWF
    000111 d fffffAdd W and fADDWF
    001000 d fffffMove fMOVF
    001001 d fffffComplement fCOMF
    001010 d fffffIncrement fINCF
    001011 d fffffDecrement f, Skip if ZeroDECFSZ
    001100 d fffffRotate Right fRRF
    001101 d fffffRotate Left fRLF
    001110 d fffffSwap halves fSWAPF
    001111 d fffffIncrement f, Skip if ZeroINCFSZ

    0100 bbb fffffBit Clear fBCF
    0101 bbb fffffBit Set fBSF
    0110 bbb fffffBit Test f, Skip if ClearBTFSC
    0111 bbb fffffBit Test f, Skip if SetBTFSS

    1000 kkkkkkkkReturnRET (ビットパターンは原文ママ; 後述)
    1000 kkkkkkkkReturn and place Literal in WRETLW
    1001 kkkkkkkkCall subroutineCALL
    101x kkkkkkkkGo To addressGOTO
    1100 kkkkkkkkMove Literal to WMOVLW
    1101 kkkkkkkkInclusive OR Literal and WIORLW
    1110 kkkkkkkkAND Literal and WANDLW
    1111 kkkkkkkkExclusive OR Literal and WXORLW
    000000000000 No OperationNOP
    0000001fffffMove W to fMOVWF
    0000010fffffClear WCLRW
    0000011fffffClear f CLRF
    000010dfffffSubtract W from fSUBWF
    000011dfffffDecrement fDECF
    000100dfffffInclusive OR W and fIORWF
    000101dfffffAND W and fANDWF
    000110dfffffExclusive OR W and fXORWF
    000111dfffffAdd W and fADDWF
    001000dfffffMove fMOVF
    001001dfffffComplement fCOMF
    001010dfffffIncrement fINCF
    001011dfffffDecrement f, Skip if ZeroDECFSZ
    001100dfffffRotate Right fRRF
    001101dfffffRotate Left fRLF
    001110dfffffSwap halves fSWAPF
    001111dfffffIncrement f, Skip if ZeroINCFSZ
    0100bbbfffffBit Clear fBCF
    0101bbbfffffBit Set fBSF
    0110bbbfffffBit Test f, Skip if ClearBTFSC
    0111bbbfffffBit Test f, Skip if SetBTFSS
    1000kkkkkkkkReturnRET (ビットパターンは原文ママ; 後述)
    1000kkkkkkkkReturn and place Literal in W RETLW
    1001kkkkkkkkCall subroutineCALL
    101xkkkkkkkkGo To addressGOTO
    1100kkkkkkkkMove Literal to WMOVLW
    1101kkkkkkkkInclusive OR Literal and WIORLW
    1110kkkkkkkkAND Literal and WANDLW
    1111kkkkkkkkExclusive OR Literal and WXORLW
    現在のベースラインPICの33命令と比べ、無い命令がTRIS, OPTION, SLEEP, CLRWDTの4つ。
    TRISは先述。
    OPTIONは、設定するほどオプションが無い。
    NMOSなのでクロックを止めたところで電力は減らないのでスリープという概念が無い。(という理解でいいのかな…)
    ウォッチドッグタイマは無い。
    その他の命令はベースラインと同一である。
    GOTOの9bit目が「x」と表記されているが、説明を見るとページ切り替えということで、動作はベースラインと同じで表記が異なるだけのようだ。たぶんリテラルを8bitに合わせたかったのだろう。
    RET命令が表に載っているがなぜかビットパターンはRETLW命令と同じである。説明を見ると「0→W, RAR→PC」とあり(RAR = Return Address Register)、たぶん誤植で本来は「1000 00000000」と書きたかったのだろう。
    現在もベースラインでRETURN命令は「RETLW 0」のエイリアスとなっているのでそれと同じことである。

    なおベースラインでの追加4命令+隠し命令HALTのビットパターンを見ると、後から隙間に追加したことがよく分かる。
    0000 0000 0001 HALT
    0000 0000 0010 OPTION
    0000 0000 0011 SLEEP
    0000 0000 0100 CLRWDT
    0000 0000 0101 TRIS PORTA

    0000 0000 1001 TRIS PORTE
    ついでにEnhancedベースラインの追加命令も並べておこう。こちらは空き領域の上から攻めてきているようだ。
    0000 0001 1111 RETFIE
    0000 0001 1110 RETURN
    0000 0001 0kkk MOVLB
      

  • PICで浮動小数点ウェイトルーチン
    2015年05月26日 00:00

    ふと思いついたので書いてみた。
    呼び出すと、Wレジスタの値を浮動小数点数として見た量だけウェイトを掛ける。
    具体的には、指数部3bit、仮数部5bitで、
    1.仮数×2^(指数+4)
    または指数部が0の時
    0.仮数×2^(1+4)
    で表される値×80。
    最小が1の時の80、最大が255の時の322560…かと思いきやちょうど上手く0の時に327680になっている。
    グラフにするとこうだ。
    PIC_浮動小数点ウェイト

    さて、ふと思いついて面白そうだったので書いてみたのだが、使い道が思いつかない。
    思いついたきっかけは液晶モジュールの初期化時に27μsと1msと200msのようなウェイト量を要求されたからなのだが、数回使うくらいなら固定値のウェイトルーチンで済むし、10回程度までは単純な2バイトのウェイトルーチンを作った方がよいだろう。
    役立てるには数十回のダイナミックレンジの広いウェイトを要求される必要があるが、そのような状況が思いつかない。
    まあ書いてて楽しかったので特に問題はない。

    何か使い道を思いついた方はご自由に使ってください。
    fwait:
    ;使用レジスタ:
    ;cnth, cntl, exp
    ;cnthは事前にゼロクリアのこと。

    ;浮動小数点数を分解して適切な場所に置いたりケチ表現解除
        movwf cntl
        andlw 0xE0
        movwf exp
        btfss STATUS,Z
        bsf cnth,1
        btfss cnth,1
        bsf exp,5
        btfsc cntl,4
        bsf cnth,0
        swapf cntl,F
        movlw 0xF0
        andwf cntl,F
        bcf STATUS,C
    ;指数部が1xxなら4bit左シフト
        btfss exp,7
        goto f1x4
        swapf cnth,F
        swapf cntl,F
        movf cntl,W
        andlw 0x0F
        iorwf cnth,F
        movlw 0xF0
        andwf cntl,F
    f1:
    ;指数部がx1xなら2bit左シフト
        btfss exp,6
        goto f2x1
        rlf cntl
        rlf cnth
        rlf cntl
        rlf cnth
    f2:
    ;指数部がxx1でなければ1bit右シフト
        btfss exp,5
        rrf cnth,F
        btfss exp,5
        rrf cntl,F
    ;素通りに掛かる時間分の調整
        movlw .8 ;40/5
        subwf cntl,F
        btfsc STATUS,C
        incf cnth,F ;繰り下がり処理しつつ+1
    b0:
    ;時間待ち処理本体
    ;ここにウェイトを入れ、上の調整部分も合わせると、全体のウェイト量を定数倍できる
        decf cntl,F
        btfsc STATUS,Z
        decfsz cnth,F
        goto b0
        nop ;時間調整
        retlw 0
    ;分岐の時間合わせ
    f2x1:
        nop
        goto f2
    f1x4:
        goto $+1
        goto $+1
        goto f1
      

  • PICで平方根ルーチンができた気がする
    2015年05月06日 23:32

    なんとなく欲しくなったので作ってみたらできた気がする。
    sqrt:
        movlw 0x60
        movwf diff
        movlw 0x40
        movwf subhnd
        bsf count,3
    sqrtloop:
        movf subhnd,W
        subwf valh,W
        btfsc STATUS,C
        movwf valh
        movf diff,W
        rlf vall,F
        rlf valh,F
        rrf diff,F
        btfss vall,0
        xorwf subhnd,F
        btfsc vall,0
        addwf subhnd,F
        decfsz count,F
        goto sqrtloop
    19命令、固定124サイクル。
    valh:vallに平方根を求める値を入れる。vallに答えが出る。
    このルーチンに入る前にcountはゼロにしておく。

    入力は16bitを受け付けてくれるかと思いきや、大きすぎると計算途中でオーバーフローするようである。
    15bitなら多分大丈夫。もうちょっと大きくても大丈夫な気がする。0b1011...まで大丈夫な気がしたがそんなことはなかった。

    アルゴリズム

    平方根の求め方 - 魔法使いの森
    こちらのタイガー計算器での開平計算のアルゴリズムを参考にした。
    同じことを2進法で行うのだが、2進法なので引く数を増やしながら順に引いていくところは1回だけで終わりである。

    具体的には、
    ・平方根を求める数をAとする
    ・B=1
    {
    ・Aの2nビット目からBを引き、キャリーを答にシフト (そのまま使えるのでPICのボローは楽である)
    ・引けたなら、B++; B<<1; B++
    ・引けなかったなら、B--; B<<1; B++
    ・A<<2
    }繰り返し
    なお図形的に考えたものに合わせAとB両方シフトするように書いたが、実際にはAを1bitシフト、Bを右に伸ばしていくようなコードになっている。これはタイガー計算器でもそうである。
    コードに落としこむにあたって、引けた時と引けなかった時の計算に使う値を1つにまとめたのと、キャリーを壊さずに後の方まで使いまわしているのが楽しいところ。
    引く数は最後の方は下位bitを切り捨てているので答えが多少ずれるだろうと思っていたのだが、いくつか試したところずれていないような気がする。不思議だ。
    (5/7追記: √0が1になった。やっぱりなー。この程度は想定の範囲内。)  

  • ベースラインPICの注意点
    2015年04月11日 23:36

    PICマイコンは時代を追ってベースライン→ミッドレンジ→ハイエンドと進化してきたが、日本で有名になったPIC16F84がミッドレンジのせいか、ベースラインPICに関する日本語の情報が少ない。
    そのためミッドレンジに慣れた者がベースラインを使おうとして戸惑うのをたまに見かける。
    そこで、ミッドレンジからベースラインへのマイグレーションを念頭に、この2つの違いを解説したい。
    今更ベースラインを使う意味があるかは微妙な所だが、安さで10F200や16F57を選ぶこともあるだろう。

    PIC10F200: 現在秋月で35円、aitendoで30円。自分の知る限り最安のマイコン。
    PIC16F57: 現在秋月で70円。I/Oピンが20本あり、3.5円/ピン。自分の知る限りI/Oピンあたり価格が最安のFlashマイコン。
    (ワンタイムを含めるとI/Oが43ピンで8個400円のこいつに負ける→ H8S16ビットワンタイムマイコンHD64P2128PS20V(8個入))

    見分け方

    比較の前に、まずベースラインとミッドレンジの見分け方について。
    型番で簡単に見分けられるのだが、これが知らないと分かりづらい。自分も最近まで知らなかった。
    まずPICの型番を見ると先頭に10F, 12F, 16F, 18Fとある。(さらには17F, 24F, dsPIC30, dsPIC33, PIC32MXとあるがこれらは単純なので割愛する。Fの部分がLFやCやHVのものもあるが割愛する)
    PICを分類するのにこの先頭の数字で分類されるのが一般的だが、実はこの数字はベースラインとミッドレンジの区別には役立たない。
    12Fがベースライン、16Fがミッドレンジであるとする誤った記述をたまに見かけるが注意が必要だ。
    (ただしハイエンドを見分けることはできる。18Fがハイエンドだ。)
    ではどこで見分けるかというと、英字の次の桁。
    これが(現在のところ、ごく一部の例外を除き)2か5ならばベースラインである。(また、ベースラインならば2か5である)
    例えば10F222、16F54、12F509はベースラインであり、10F322、16F84、12F609はミッドレンジである。
    (初期に命名法が確立していなかったと思しきPIC16C55Xというミッドレンジが存在する)
    また後半の数字が1始まりで4桁以上ある12F1*,16F1*はEnhancedミッドレンジである。
    また現在のところ数は少ないが、Enhancedベースラインというものも存在する。型番の規則はベースラインと同じだ。
    現在存在するEnhancedベースラインはおそらく、12F529T39A, 12F529T48A, 16F527, 16F570の4つのみである。

    なお先頭の数字10,12,16は、ピン数に対応している。6ピンが10、8ピンが12、14ピン以上が16だ。
    (ただし通常のI/Oピン以外に特殊機能のピンがある場合これに従わない。例:12F529T39A)
    (また今後8ピンも16Fになるようだ。例: 16F18313)
    (ハイエンドの8ピンはどうなるかというと、今のところ存在しないが、実は発表だけされて発売されなかった18F010/020がある)


    以下機能の違いを見ていく。

    割り込み

    ミッドレンジで追加された機能で最も重要と言える。
    割り込みを使ったコードは全てポーリングに書き直すしかない。
    割り込みがどうしても必要ならミッドレンジを使うしかないし、そうでなくとも割り込みの方が簡単に書けるならミッドレンジを使うのが身のためだ。
    ただもしかするとウォッチドッグタイマ(WDT)によるリセットで割り込みの代用ができるかもしれない。

    タイマーのオーバーフロー

    ベースラインもミッドレンジもTMR0の機能は基本的には同じである。
    ただし、ベースラインには割り込み機能が無いのに伴ってオーバーフローフラグも無い。
    割り込みを使っていなくてもオーバーフローフラグを使っていたプログラムは書き直しが必要だ。
    簡単な対処法として、TMR0を7bitのタイマーと考えて、最上位bitをオーバーフローフラグの代わりに使う方法が考えられる。
    タイマーが1周する前にチェックする必要がある点を除けば同様のプログラムが使える。
    またはクロック単位できっかり合わせたいなら例えばこんな感じ。
    synch:
        btfss TMR0,7
        goto $-1
        btfsc TMR0,7
        goto $-1
        decf TMR0,W
        addwf PCL,F
        nop
        nop
        nop
    when:

    スリープからの起床

    ベースラインもミッドレンジもSLEEP命令によるスリープ機能は持っているが、起床時の動作が異なる。
    ミッドレンジではスリープから起床するとSLEEP命令の直後から実行を再開する。(加えてその前に割り込みを掛けることもできる)
    それに対しベースラインではスリープからの起床はリセットと同等であり、SLEEP命令の直後から実行する機能は無い。
    先頭にパワーオンリセットとスリープからの起床を判別するコードを書いて分岐する必要がある。

    命令

    ベースラインからミッドレンジで追加された命令はわずか4つのみである。
    ADDLW, SUBLW, RETURN, RETFIE
    また、命令一覧から消えた命令が2つある(実はミッドレンジでも使える)。
    TRIS, OPTION
    その他の命令は、機能は同じだがアドレス指定のビット数が増えている。これによる違いはメモリ構造の項にて。

    これらの追加命令の対処法を示す。
    ・ADDLW
    比較的簡単。RAM1つ使用、2命令増で次のようにできる。
        addlw NN
        ↓
        movwf temp
        movlw NN
        addwf temp,W
    そもそも加算の順番を変えるだけで済むこともあるだろう。
    また、加算が必要かと思いきやIORLWが使える状況もたまにある。

    ・SUBLW
    単純に置き換えようとするとWの退避が面倒なことになる。
        sublw NN
        ↓
        movwf temp
        movlw NN
        movwf temp2
        movf temp,W
        subwf temp2,W
    順番を変えて事前に被減数を用意しておくのがよいだろう。つまり、
        movlw NN
        movwf minuend
    と準備しておくことにより
        subwf minuend,W
    とできる。定数からの減算なら準備は1回でよいためコア部分は同命令数にできる。

    ・RETURN
    ベースラインには値を返さないRETURN命令が無く、RETLWしか無かった。
    Wの値を使いたければ、適当な場所に保存しておく必要がある。
        movwf w_buf
        retlw 0
    ;---
    ;(呼び出し元)
        call where
        movf w_buf,W
    Wを保存しておく必要が無ければ適当な値を返すRETLWをそのまま使えばよい。というより、ベースラインでは「RETURN」が「RETLW 0」のマクロとして登録されているので、何も考えず「RETURN」と書くだけでよい。
    なのでむしろ、RETURN命令を使ったミッドレンジ向けコードが書き換えずそのまま動いてしまうことに注意が必要である。

    ・RETFIE
    割り込み機能が無いので当然ながらどうしようもない。

    メモリ構造の違い

    ・RAM(ファイルレジスタ)のマッピング
    RAMのバンク分けがミッドレンジ128バイトごとに対しベースライン32バイトごとと、バンクごとの容量が1/4しかなかった。
    (対応してファイルレジスタを指定する命令すべてでアドレス指定のbitが7→5と少ない。)
    また連続で使えるメモリ量はミッドレンジの80バイトや96バイトに対しベースライン16バイト(bank0は+数バイト)。
    ミッドレンジからベースラインへ移行する場合はメモリ量が足りたとしてもバンク切り替えが増えるのに注意が必要である。
    ただ、間接アドレッシングで16バイトを超えるメモリを連続的に扱いたいときは、FSRの4bit目を常にセットするように扱えばよいので、ミッドレンジの80バイトと96バイトの領域が混在する複雑な構造よりだいぶ楽である。
    またバンク共通のメモリの位置も異なり、ミッドレンジでは各バンクの最後16バイトであるが、ベースラインは前半16バイトのうちSFRでないあまり部分がバンク共通となっている。
    図にまとめると以下のようになる。
    ベースラインとミッドレンジのRAM構成比較
    注:
    大抵の機種はこの構成に従っているが、そうでないものもある。おそらく古いものが異なるのだろう。例えば16F84Aはベースラインに似た割り付けである。
    図は可能な最大量を示した。実際に実装されているメモリ量がこれより少ない場合、データシートの図はこれと異なる。
    ベースラインのバンク共通メモリの量はSFRの量に依存するため、機種により異なる。例えば12F509では9バイト、16F526では3バイトである。

    ・特殊なレジスタマッピング
    特殊なレジスタにTRISxとOPTIONがある。
    この2つは、ベースラインでは通常のレジスタとしてマッピングされていない。
    その代わりに、「TRIS」命令と「OPTION」命令でWの内容を書き込む仕組みになっている。
    書込みのみで読み出しはできないため、あとで値が必要になるなら適当なRAMに保存しておく必要がある。

    命令の使い方は、OPTIONはオペランドをとらず、1つしかないOPTIONレジスタにWを書き込む。
        option
    ミッドレンジで同等の動作は、(適切なバンクになっている前提で)こうである。
        movwf OPTION_REG

    TRISは、オペランドにI/Oポートレジスタ(のアドレス)をとり、対応するTRISxレジスタにWを書き込む。
        tris PORTA
    ミッドレンジではこう。
        movwf TRISA

    ・FlashROM
    Flashのページ分けは注意が必要である。
    まず、ミッドレンジの2048(0x800)ワード毎に対し、ベースラインでは512(0x200)ワード毎にページが分けられている。
    つまり、ミッドレンジでは「0x800の壁」と呼ばれているものはベースラインでは0x200の壁となる。
    これに対応してGOTO命令では飛び先のアドレスが9bit指定できるのだが、CALL命令では飛び先のアドレスは8bitしか指定できない。
    その分のアドレス1bitを別の場所で指定できるわけでもないため、CALLの飛び先のアドレスは各ページの前半256命令のみで、後半256命令にはCALLで飛ぶことはできない。
    ミッドレンジではGOTO・CALLとも同じく11bitになりこの状況は解消されているので、ベースライン特有の制限である。

    CALLで飛べるのがページ前半のみということは、後半はサブルーチンに使えないのかというと、そうでもない。
    このようにすれば、1命令・2サイクル余計に掛かるものの、サブルーチンの実体を後半に置くことができる。
    ;(前半)
    func1entry:
        goto func1core
    ;(後半)
    func1core:
        ...
        retlw 0
    前半に置かなければならないのは、定数テーブル参照などPCL操作をするようなコードのみである。
    というわけで、実は印象の割には大した制限ではない。

    ・バンク・ページ選択
    バンクおよびページの選択方法はベースラインからミッドレンジで様変わりしており、注意が必要である。
    ROMページ:
    ミッド… PCLATHレジスタで指定。
    ベース… STATUSレジスタの上位3bitにPA2:0があり、これがミッドレンジのPCLATHと同様の働きをもつ。
    RAMバンク:
    ミッド… STATUSレジスタの上位3bitにIRP,RP1:0があり、それぞれ間接アドレッシングと直接アドレッシングのバンクを指定する。
    ベース… 間接アドレッシングはFSRのみでアドレスを指定できる。直接アドレッシングの場合、FSRの上位3bitと命令からの5bitでアドレスを指定する。

    というように、STATUSレジスタの上位3bitの扱いが変わっているので注意が必要である。
    またベースラインは間接アドレッシングと直接アドレッシングで別のページを指すことができないことに注意が必要である。

    コールスタック

    ミッドレンジのコールスタックは8段あり、複雑な事をしなければ足りなくなることはあまり無い。
    それに対しベースラインのコールスタックはわずか2段であり、よく考えて使わないとすぐに足りなくなる。

    どうしても3段のネストが必要になったら、自力で戻りアドレスを保存してCALL・RETURNを模擬する必要がある。
    単純な例を挙げればこんな感じ。
    mycall macro where
        movlw $+3
        movwf retAddr
        goto where
        endm
    ;---
    myreturn macro
        movf retAddr
        movwf PCL
        endm
    PC上位を保存しておく必要があったり再入可能にするならもっと面倒になるが、そこまで必要になったことが無いので考えていない。

    主要レジスタの機能比較

    周辺機能の制御用を除いた、コア機能のためのレジスタを比較する。

    ベースラインに無いレジスタは、説明済みのPCLATHと、割り込みが無いためINTCONが存在しないのみである。
    なお、上で述べたとおり、INTCONが無いということはTMR0のオーバーフローフラグも無いことに注意が必要である。

    機能の違うレジスタは3つ。
    STATUS, FSR, OPTION(_REG)
    FSRについては説明済み。
    STATUSとOPTIONを詳しく見る。
    なおビット名については、I/OポートがPORTBかGPIOかにより異なる場合がある(例: GPWUF/RBWUF)。ここではGPIOの方を示した。

    STATUS
    ミッド: IRPRP1RP0/TO/PDZDCC
    ベース①: PA2PA1PA0/TO/PDZDCC
    ベース②: GPWUFCWUFPA0/TO/PDZDCC
    下位5bitは共通。上位3bitが問題となる。
    ミッドレンジではおそらくすべての機種で間接・直接のバンク選択に割り当てられている。
    ベースラインでは、
    ①機能の無いもの(例: 16F5x)では3bitすべてページ選択(=PCLATH相当)に割り当てられている。
    もっとも、ベースラインのFlash量は最大でも2kワードなのでPA2が使われている機種は無さそうである。
    ②機能のあるものでは、上位2bitが2種のウェイクアップフラグ(GPIOピン変化・コンパレータ変化)に割り当てられている。
    このため両機能のあるものではFlashを2ページ(1024ワード)までしか積めないことになる。

    OPTION (レジスタ名はミッドレンジではOPTION_REG)
    ミッド: /GPPUINTEDGT0CST0CEPSAPS2PS1PS0
    ベース: /GPWU/GPPUT0CST0CEPSAPS2PS1PS0
    下位6bitは共通。上位2bitが、
    ミッドレンジではポートのプルアップと割り込みエッジ。
    ベースラインではピン変化ウェイクアップとポートのプルアップ。
    …なんでわざわざポートのプルアップのビットの位置を変えたんだろう。

    【余談】

    ・OPTION_REG
    ミッドレンジの「OPTION_REG」レジスタだが、古い機種のデータシートでは「OPTION」レジスタであった。
    おそらくOPTION命令との衝突を避けて名前を変えたのだろう。
    データシートのリビジョンで記述が変わっていることもあるようだ。
    PIC16F87/88 データシート
    上: Revision B (August 2003)
    下: Revision D (October 2011)
    OPTION_REGデータシート比較

    ・TRIS命令
    TRIS命令は命令表にはビットパターンが
    0000 0000 0fff
    と書かれているがこれは不適切で、PORTA~PORTEまである石では、
    0000 0000 0101
    0000 0000 0110
    0000 0000 0111
    0000 0000 1000
    0000 0000 1001
    がTRISに相当する。

    ・OPTION2
    OPTIONレジスタに加えてOPTION2レジスタをもつ石が存在し(例: PIC16HV504PIC16HV540)、これに書き込むにはTRIS命令を使う
        tris OPTION2
        tris 7
    どちらも表に見えていないレジスタに書き込むという実質的に同じ動作なのだろう。
    なお、てっきり「tris OPTION2」と書けるものだと勘違いしていたが、OPTION2はincファイルに定義が無く、マジックナンバー「7」で書き込まなければならない。「OPTION2」を「7」と定義しておいてくれれば楽なのにと思いもするが、勘違いで「movwf OPTION2」などと書かせないためだろうか。

    ・ミッドレンジで隠し命令
    TRIS命令とOPTION命令は命令一覧には載っていないもののミッドレンジでも使用可能である。
    バンクを切り替えなくともOPTION_REG・TRISレジスタに書き込めるのは便利である。
    ただしいくつか制限があり、
    ・PORTA,B,Cの3つ限定
    ・Enhancedミッドレンジでは指定する値はPORTA,B,Cとは関係なく5,6,7
    ・MPLAB8で試した所シミュレータでは不正な命令扱いになってしまった。



    編集履歴
    2015-08-29  

  • EEPROM書換え上限テスト
    2014年11月17日 08:06

    PICマイコンに内蔵されていたりするEEPROMには書換え回数に限界がある。
    PIC16F628A内蔵のものでは、書換え耐性は最小10万回、標準100万回となっている。
    これをテストしてみよう。

    なおこれは既にやっている方がいる。
    参考: 自己満足系 「PIC耐久試験」

    同じことをやっても芸が無いので、書込みデータを変えてみた。
    EEPROMの書き込み手順はまず0xFFにクリアしたのち、必要なbitのみ0にするという手順を踏むそうだ。
    であれば「0」のみを書き込み続けた場合と「0」「1」を交互に書き込んだ場合では「0」のみの方が早く限界に達するはずだ。
    これはMicrochip社のアプリケーションノート「AN537」を見てもそう書いてある。(figure4)
    これを確かめるため、書込みデータは「0x5C」と「0xAC」の交互にした。上位(7bit目~4bit目)が0/1交互、3,2bit目が1固定、下位(1,0bit目)が0固定だ。
    これが意外な結果になるのだが…。

    プログラムは最後に載せるが、内容を説明すると以下のとおり。
    ・電源ONでまずEEPROMの内容を全て出力し、その後待機状態に入る
    ・スイッチを押すとLEDを点灯させて開始を示し、1秒後に消灯して処理を開始
    ・書込み後に読み出してベリファイし、値が異なっていればエラー表示をして終了
    ・0x5Cと0xACの2回の書き込みを1セットとし、256セットごとにEEPROMに書込み回数を保存
    ・256セットごとにスイッチを監視して、一時中断が可能

    装置はこんな感じ。
    EEPROM破壊装置
    下の3つは置き場が無くて挿してあるPICで、回路に無関係である。上のコンデンサについては後述する。
    橙の線はスイッチ代わり。LEDは開始・終了のインジケーター。もう1個エラー表示もつけようと思ってプログラムもそう書いたのだが、よく考えてみれば終了LEDだけでことが済んだのでつけなかった。
    余談だが、LEDが青なのはこの試験中に青色LED開発者がノーベル賞を取ったのでなんとなく元は赤だったのを変えてみたためだ。

    試験を開始する。
    電源は仕様上3V以上必要なのだが、いつもEneloop2本で動かしているので今回もそれでやってしまった。どうせ厳密な試験をするつもりもなし、動いてるので問題ないだろう。
    まず少々処理が進んだところで一時中断し、書き込み速度をチェックする。
    どうやら1回あたり5msほど掛かっている。時間からして書き込みは行われているようだ。
    (プログラムの製作中は書き込み操作をコメントアウトしていたが、この時はマイクロ秒単位でループが回っていた)
    ここから破壊予定を計算してみよう。
    100000*5/1000/60=8.33
    1000000*5/1000/60/60=1.39
    より、最小の10万回ならわずか8分強、標準の100万回でも1時間半ももたない計算になる。
    上記の先人の使った16F84は標準1000万回のところ2300万回で破壊に至ったということなので、同じ割合なら3時間ほど。
    何日も点けっぱなしにするのは面倒なのでこれは楽でいい。
    と思ったのだが…。

    試験はTwitterにつぶやきながら行っていたので、ログを見ながら進行状況を書いていく。
    10/05 16:55 試験開始
    10/05 17:13 開始20分で2*0x1A400回 (※書き込み2回ごとに1カウントしている)
    10/05 18:43 標準値を突破、1.3M回超
    10/05 20:04 標準寿命の倍を超えたがまだ動く
    10/05 21:12 3.1M回を超える
    10/05 22:15 2*1D6600回
    10/05 23:56 5M回
    10/06 01:51 6.5M回
     標準寿命の2,3倍程度だろうと思っていたため、寝る前に終わる予定でいたので困る。
    10/06 06:04 結局点けっぱなしで朝、9.5M回
     標準寿命の10倍近くでまだ正常と主張しているのでそろそろプログラムのミスが疑われ始める。
     とりあえず中断し、電池を充電する。
    (10/06 21:38 再開時刻記録忘れ。遅くともこの時刻)
    10/07 00:22 11,661,312回
     本格的にプログラムのミスが心配になる。
    10/07 01:44 ついに終了

    以上、延べ17.25時間掛けて、12,663,170回目でエラー発生。なんと標準値の12倍ももつという記録が出た。
    書込み回数の記録をグラフにするとこんな感じ。
    EEPROM書込み回数グラフ
    記録がいい加減(「標準の倍を超えた」とか)なわりには意外と綺麗なグラフになっている。温度で書込み時間に違いが出たりするかと期待していたが、少なくともこのレベルの記録には残らないようだ。

    エラーの内容だが、8Cが読めているので、ACを書き込んで8Cが読めた、つまり5bit目が異常になったエラーのようだ。これは不思議なことで、前述のとおり常に0を書いている下位2bitが真っ先にやられるものと予想していた。
    それはそうとここから先は未知の領域なのでとりあえず試験を続ける。
    まず意外だったのが、一度8Cが読めた箇所を20回ほど読んでみても正しくACが読めることだ。どうやらEEPROMのエラーというものは、一度エラーが出たらそれっきりというものではなく、「書いた値が稀に正常に読めない」という症状を示すようだ。
    その後再度同じプログラムで走らせても、しばらくの間は正常にベリファイが走る。やはりエラーは確率的なもののようだ。
    これを考えると、テストのやり方は正しくなかったと言える。1千万回で初めてエラーが出たとして、それ以前から確率的に読み取れない状態になっていたのだろうから、ある程度の回数書き込むたびに読み出しが正しくできるかのテストを数百回なり数千回なり読み出してみて調べるべきだろう。まあこれは今後の研究課題ということで。

    さてその後も同じプログラムで何度も走らせてみた。結果がこれだ。
    EEPROM書込みエラー記録
    プログラムを走らせ、エラーが発生して停止するまでに書込みが行われた回数を毎回記録している(最後除く)。
    3色の◆の部分が最初と同じプログラムで走らせたものである。
    傾向として最初の1266万回から回を追うごとに減っていき、15回目あたりからエラーまでの書き込み回数がほぼ一定になっているのが見て取れる。これは512回である。
    最初に書いたとおり、このプログラムでは2回×256セットごと、すなわち512回ごとにEEPROMに書込み回数を保存している。つまりこの書込み直後の読み込みが失敗しやすいようである。
    この原因として書込みによって電圧が下がっている可能性を考え、コンデンサを付けてみた(赤部分)。するとしばらくの間書き込みエラーが起こりにくくなったような気もするが、またコンデンサを外しても14万回とかなりの回数が出たのでよく分からない。
    もう少し確かめてみたかったが、そうこうしている間に別のエラーが発生した。
    部分が、読めた値が2Cであった部分である。AC→2Cになったものであろうから、7bit目が異常になったようだ。またも上位bitからエラーが発生した。このとき累計書込み回数1663万回。
    その後数回2Cが続き、再び8Cでのエラーが発生。
    ここで、プログラムを変更する。異常になった2つのbitをマスクして、他のbitのみを見るようにした。これが紫部分。
    変更後最初のエラーまでに64万回、累計1765万回。1Cが読めたので、5C→1Cで6bit目が異常。
    その後2回ほど試したのち、またマスクを変更。3つのbitをマスクする。これが水色部分。(なぜか凡例だけマークが「*」になっているが、Excelが異常で凡例のマークをどうやっても変更できなかった)
    変更後最初のエラーまでに209万回、累計1974万回。4Cが読めたので、5C→4Cで4bit目が異常。
    これで上位4bitが全て異常になり、下位4bitには異常が見られないという状況になった。
    不可解だがとりあえず続けよう。マスクを変更。上位4bitをマスクするようにした。
    すると、いつまで走らせても一向にエラーが起こらない。累計1億回、すなわち標準寿命の100倍に達してなおエラーが出なかったので、あきらめて試験を終了することにした。この時点が橙である。

    以上まとめると、0/1を交互に書き込んだ場合は標準寿命の10~20倍で最初のエラーが発生し、0のみまたは1のみを書き込んだ場合は標準寿命の100倍を超えてもエラーが発生しないという結果になった。
    資料から予想した結果と違っており不可解だが、この結果から考えられることとして、PICのEEPROMは前回と同じ値を書き込むときは消去・書込み動作を行わないのだろうか。
    EEPROMはバイトごとに消去が行われるものと思っているのだが、bitごとの消去ができるものもあるのだろうか。この辺も今後の研究課題である。

    また、エラー発生時の累計回数の生データを見ると1つ不思議なことが分かる。以下がそのデータだ。
    609CC0, 6545D4, 675110, 67C8C0, 6A3690, 6A3700, 6AB598, 6AB600, 6AB710, 6AB800, 6AC59C, 6B08C0, 6B0D58, 6B14D0, 6B1500, 6B1600, 6B1700, 6B1800, 6B1900, 6B1A00, 6B1B00, 6B1C00, 6B1D00, 6B1E00, 6B1F84, 6B2048, 6B2100, 6B2200, 6B2304, 6B2400, 6B2500, 6B2600, 6B2700, 6B3380, 6CE7D8, 6CE800, 6D0904, 6D2590, 6D2654, 6D2710, 6D2800, 6D4184, 6D4200, 6EB540, 702D10, 702E10, 702F00, 703000, 745114, 7A5C14, 7A5D10, 7A5E04, 7D1404, 7D1504, 7E2B0C, 7E2C00, 7E2D00, 7EE104, 7EE200, 7EE30C, 7EED00, 81C300, 86A514, 86A600, 86A70C, 969F00
    1の位に0,4,8,Cと4の倍数しか現れていない。00になるのはEEPROM書込み直後なので分かるとして、4の倍数、すなわち8回ごとにエラーが起こる理由が分からない。内部構造に原因があるのだろうか。今後の研究課題だ。研究課題多いなあ。

    最後にコード。
        list p=16f628a
        #include p16f628a.inc
        radix dec
        __CONFIG _INTOSC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & _CP_OFF & _LVP_OFF & _MCLRE_ON & _BODEN_OFF

        radix dec


    ;     RA2 +-v-+ RA1
    ;     RA3 |   | RA0
    ;     RA4 |   | RA7
    ; Vpp RA5 |   | RA6
    ;     GND |   | Vdd
    ;     RB0 |   | RB7 PGD
    ;     RB1 |   | RB6 PGC
    ;     RB2 |   | RB5
    ;     RB3 +---+ RB4

    ; EEPROM制御がしやすいよう、変数はbank1にとる
        cblock 0xA0
            targetaddr
            dataaddr
            cnt0,cnt1,cnt2
            cnt232
            dat,datbuf
            waitcnt0,waitcnt1
        endc
    ; 結局使わなかった割り込み退避用変数
        cblock 0x70
            wbuf
            sbuf
        endc


    #define TESTPTR 0x00
    #define MASK 0xFF ;結果をマスクするときここを変える

    ;pin
    #define TXPIN232 0
    #define BUTTON 1
    #define ERRLED 2
    #define STOPLED 3

        org 0
        goto init

        org 4
        retfie

    init:

        bsf STATUS,RP0 ;BANK1
        movlw b'00000011'
        ;       ^/pull up enable
        ;        ^int edge
        ;         ^tmr0 clock source 0:internal
        ;          ^tmr0 source edge
        ;           ^prescaler assignment 0:tmr
        ;            ^^^prescaler rate
        movwf OPTION_REG
        movlw 1<<BUTTON
    ; 間違ってPORTBの値を設定する前にTRISBを設定しているのでたまにシリアル出力の先頭が化けることに後で気づいたが直し忘れた
        movwf TRISB
        bcf STATUS,RP0
        movlw 0x07
        movwf CMCON
    ; EEPROMの制御のためコードはすべて全てbank1で走らせる
    ; そのため変数はすべてbank1にとった
    ; bank0のレジスタでPORTBだけ必要なのでINDFをPORTBにしておく
        banksel 0x80 ;bank1
        movlw PORTB
        movwf FSR ;INDF=PORTB
        clrf INDF
        clrf cnt232
    ; EEPROMに保存してある書込み回数カウントを取得
        movlw (~TESTPTR)&0x7F
        movwf targetaddr
        movlw TESTPTR*4
        movwf dataaddr
        
        movf dataaddr,W
        movwf EEADR
        bsf EECON1,RD
        movf EEDATA,W
        movwf cnt2
        incf dataaddr,W
        movwf EEADR
        bsf EECON1,RD
        movf EEDATA,W
        movwf cnt1
        movf dataaddr,W
        addlw .2
        movwf EEADR
        bsf EECON1,RD
        movf EEDATA,W
        movwf cnt0
    ; 書込み回数カウントを…と思ったが面倒なのでEEPROM全体をシリアルに出力
        movlw '/'
        call tx232
    showeep:
        clrf EEADR
    showeeploop:
        bsf EECON1,RD
        movf EEDATA,W
        call tx232hex
        incf EEADR,F
        btfss EEADR,7
        goto showeeploop
    ; スタート待ち
        btfsc INDF,BUTTON
        goto $-1
    ; LEDを1秒点灯させスタート表示 (停止表示用だった名残が名前に見える)
        bsf INDF,STOPLED
        
        call wait1s
        
        bcf INDF,STOPLED

    main:
        movf targetaddr,W
        movwf EEADR

    mainloop:
    ; データAを書込み、読み取り、比較
        movlw 0x5C ;データA
        call writeeep
        clrf EEDATA
        bsf EECON1,RD
        movlw 0x5C
        xorwf EEDATA,W
        andlw MASK
        btfss STATUS,Z
        goto err

        movlw 0xAC ;データB
        call writeeep
        clrf EEDATA
        bsf EECON1,RD
        movlw 0xAC
        xorwf EEDATA,W
        andlw MASK
        btfss STATUS,Z
        goto err

        incfsz cnt0
        goto f
    ; 256カウントごとの操作
    ; 上位カウント
        incf cnt1,F
        btfsc STATUS,Z
        incf cnt2,F
        bcf STATUS,C

    ; カウント値を保存
        movf dataaddr,W
        movwf EEADR
        movf cnt2,W
        call writeeep
        
        incf dataaddr,W
        movwf EEADR
        movf cnt1,W
        call writeeep
        
        movlw 0x02
        addwf dataaddr,W
        movwf EEADR
        movf cnt0,W
        call writeeep

    ; ボタンを確認し、押されていれば中断
        btfss INDF,BUTTON
        goto stop

    f:
        goto mainloop

    ; 書込みエラーが発生したら、カウント下位および読み取った値を書き込んで、LEDを点灯させ停止
    err:
        bsf dataaddr,1
        incf dataaddr,W
        movwf EEADR
        movf EEDATA,W
        call writeeep
        movf dataaddr,W
        movwf EEADR
        movf cnt0,W
        call writeeep
        
        bsf INDF,ERRLED

    stop:
        bsf INDF,STOPLED
        goto $

    ; EEPROM書込みサブルーチン
    ; WをEEADRで示すアドレスに書き込む
    writeeep:
        movwf EEDATA
        bsf EECON1,WREN
        movlw 0x55
        movwf EECON2
        movlw 0xAA
        movwf EECON2
        bsf EECON1,WR
        btfsc EECON1,WR
        goto $-1
        return

    ; Wを16進表記でシリアル出力 (IOピン直結)
    tx232hex:
        movwf datbuf
        swapf datbuf,W
        call sendnibble
        movf datbuf,W
        call sendnibble
        return

    sendnibble:
        andlw 0x0F
        movwf dat
        movlw .6
        addwf dat,F
        movlw '0'-.6
        btfsc STATUS,DC
        movlw 'A'-.10-.6
        addwf dat,W
    ; Wをシリアル出力
    tx232:
        movwf dat
        bsf INDF,TXPIN232
        bsf cnt232,3
    tx232loop:
        rrf dat,F
        movf INDF,W
        andlw ~(1<<TXPIN232)
        btfss STATUS,C
        iorlw 1<<TXPIN232
        movwf INDF
        decfsz cnt232,F
        goto tx232loop
        goto $+1
        goto $+1
        nop
        bcf INDF,TXPIN232
        
        retlw 0

    ; 1秒くらい待つ
    wait1s:
        clrf waitcnt0
        clrf waitcnt1
    waitloop0:
    waitloop1:
        goto $+1
        goto $+1
        goto $+1
        goto $+1
        goto $+1
        goto $+1
        decfsz waitcnt1
        goto waitloop1
        decfsz waitcnt0
        goto waitloop0
        
        return

    ; 初回のみここのコメントを外してビルドしEEPROMのデータ保存領域を0で初期化する
    ;    org 0x2100
    ;    dt 0,0,0,0,0,0
        
        end
      

  • 最弱のPICマイコンでカレンダー_ちょっと短縮
    2014年11月02日 04:03

    先日の「最弱のPICマイコンでカレンダー」だが、ちょっと思いついてコードを短縮してみた。いい感じにキモくなったと思う。

    変更箇所は2点。
    【シリアル通信】
    元のコードではRS232Cシリアルの送受信コードをそれぞれ書いていたが、これを1つにまとめることにより短縮した。
    コア部分がこちら。1つのループの中で1bitの送信と受信を同時に行うようになっている。
    loop232:
        movlw 0xF8
        addwf GPIO,W  ;0xF8を足すことでGPIO[3]をCに入れる
        movlw 1<<TXPIN
        rrf dat232,F  ;ローテートでCをバッファに、バッファの反対端をCに
        btfsc STATUS,C
        xorwf GPIO    ;送信データに応じてGPIOの送信ピンをトグル
        decfsz cnt232
        goto loop232
    具体的な挙動は次のようになる。
    ・送信時
    バッファに送信データを入れておき、スタートビットを送信してからこのループで1bitづつ送信する。
    (なお時間の都合でXORでトグルしているので、事前にバッファに入れる値を調整しておく必要がある。)
    同時に受信操作も行われるが、特にスタートビットに合わせているわけではないので、無意味な値が取れる。
    ・受信時
    バッファに全0を入れておき、スタートビットの受信を待ってからこのループで1bitづつ受信する。
    同時に送信操作も行われるが、スタートビットも出さずデータが全0なので何も起こらない。

    これで2つが1つになったので半分くらいに縮んでほしかったのだが、前処理が増えたせいで計30ワード→25ワードとわずかな短縮に留まった。まあ縮んだだけよしとしよう。

    【月データ】
    元のコードでは月ごとに「当該月の日数」と「基準の年の当該月1日の曜日」の2つのテーブルを持っていた。
    しかし月の日数は28~31、曜日は0~6しか値を取らないので、それぞれ1バイトとるのは無駄が多い。
    そこで2つのデータを1バイトにまとめてみたのだが、最初は単純に上下4bitづつに分け、月の下位4bitと曜日を表そうとしていた。
    しかし途中でもっといい方法を思いついた。
    ・下位bitで月を表す。
    ・残りのビットを適に設定して、全体でmod7で曜日を表す数にする。
    というものだ。なおmodの計算の都合上全体の数は132を超えられないので、最上位bitは実質0固定。そして曜日に3bit使うので、月には4bitしか残らず、あとで0x10を足す形になった。
    それでできた値がこれだ。
    getmonthattr:
        addwf PCL,F
        dt .95, .28, .63, .94, .47, .78,
        dt .31,.111, .30, .95,.126, .79,
        dt .31,.125

    さらにmodの計算ルーチンを変えて1命令短縮した。
    元は「7を引き続け、0を下回ったらループを抜け、答えを0~6にするため7を足して完了」というものだったが、最後の7を足す部分が無駄である。
    そこで「7を足し続け、オーバーフローしたら完了」に変えた。このため256%7=4だけ値を補正しておく必要がある。

    これにより、テーブルが1つ減って15ワード減、読み取り部分はなんだかんだで同命令数、mod7の1命令減があって計16ワードとかなりの短縮になった。


    この2点の変更で188ワード→167ワードとなった。
    PICのコードをバイトで数えることはあまりしないのだが、計算してみると167*1.5=250.5バイト。おお、256バイトを切っている。

    なお、感覚としてはもう数命令は縮められそうな気はするが、縮めたところで別に他に入れる機能もなし、面白いことは無いかなと思うので今のところやる気はしない。
    とりあえず「Y?>」「M?>」のメッセージを無くすだけで13ワード縮む。

    全コードは以下。
        list p=10F200
        #include p10f200.inc
        radix dec

        __CONFIG _MCLRE_OFF & _CP_OFF & _WDT_OFF

        cblock 0x10
            dat232
            yearh, yearl, month
            cnt, dowcnt, daycnt, cnt232
            day
            temp
        endc

    ;ピン
    #define TXPIN 0
    ;RXPINは3固定

        org 0
    init:
        movwf OSCCAL ;クロック補正値セット
        movlw b'11001000'
        ;設定データ。プルアップOFF、他Don'tCare
        ;ちょうど下位3bitがDon'tCareなのでI/O設定と共用
        clrf GPIO ;出力ピンを全Lowに
        tris GPIO ;I/Oモード設定
        option ;設定

    main:
        clrf cnt
        clrf cnt232

    ;"Y?>"
        movlw 'Y'
        call tx232
        movlw '?'
        call tx232
        movlw '>'
        call tx232
       
    ;年4桁受信: abcd
    ;年上位 = 10a+b ≡ 2a+b
        call rx232
        movf dat232,W
        movwf yearh ;*1
        addwf yearh,F ;*2
        call rx232
        movf dat232,W
        addwf yearh,F
    ;年下位 = 10c+d
        call rx232
        movf dat232,W
        movwf yearl ;*1
        bcf STATUS,C
        rlf yearl,F ;*2
        rlf yearl,F ;*4
        addwf yearl,F ;*5
        rlf yearl,F ;*10
        call rx232
        movf dat232,W
        addwf yearl,F

    ;"M?>"
        call newline
        movlw 'M'
        call tx232
        movlw '?'
        call tx232
        movlw '>'
        call tx232
       
    ;月2桁受信: ef
        call rx232
        movf dat232,W
        andlw 0x01 ;1っぽければ10をセット
        btfss STATUS,Z
        movlw .10
        movwf month
        call rx232
        movf dat232,W
        andlw 0x0F
        addwf month,F ;C0

    ;閏年判定
        movf yearl,W ;年下位を取り、
        btfsc STATUS,Z ;0なら
        movf yearh,W ;年上位を取り、
        andlw 0x03 ;下位2bitが
        btfss STATUS,Z ;0でなければ
        goto notleap ;平年。

    ;閏年1,2月を13,14月扱い
        movlw .3
        subwf month,W
        movlw .12
        btfss STATUS,C
        addwf month,F
    notleap:

    ;年ごとの曜日の基準を算出
    ;年下位 + 年下位/4 + (年上位%4)*2
        rrf yearl,W
        movwf temp
        rrf temp,W
        andlw 0x3F
        addwf yearl,F
        rlf yearh,W
        andlw 0x06
        subwf yearl,F
    #define doworg yearl ;名前変更: DoW origin

    ;当月の曜日の差分に相当する数を基準に足す
    ;および、当月日数を取得
        decf month,W
        call getmonthattr
        addwf doworg,F
        andlw 0x0F
        iorlw 0x10
        movwf daycnt

    ;mod7を求めるが、簡略化のため、
    ;7を加算していきキャリーが出た時点で終了する。
    ;256%7=4だけずれるのでデータ側で補正済
        movlw .7
    mod7loop:
        addwf doworg,F
        btfss STATUS,C
        goto mod7loop

    ;ループ用にNと(6-N)を生成、コードの都合上+1
        movlw .8
        movwf dowcnt
        incf doworg,W
        subwf dowcnt
        movwf cnt
       
        call newline

    ;月初めの日まで空白で埋める
        goto dayadjstart
    dayadjloop:
        movlw ' '
        call tx232
        movlw ' '
        call tx232
        movlw ' '
        call tx232
    dayadjstart:
        decfsz cnt,F
        goto dayadjloop

        clrf day
    dayoutloop:
    ;表示用日(BCD)を++
        movlw .7
        addwf day,F
        movlw .6
        btfss STATUS,DC
        subwf day,F
       
    ;1日分の表示
        movlw ' '
        call tx232
        swapf day,W
        andlw 0x0F
        btfsc STATUS,Z
        movlw ' '
        btfss STATUS,Z
        iorlw 0x30
        call tx232
        movf day,W
        andlw 0x0F
        iorlw 0x30
        call tx232

        decf daycnt,F
        btfsc STATUS,Z
        goto break ;1月分出力完了で抜ける

        decfsz dowcnt,F
        goto dayoutloop ;日ループ

        movlw .7
        movwf dowcnt
        call newline
        goto dayoutloop ;週ループ
    break:
        call newline

        goto main

    ;### subroutine ###

    ;改行を出力
    newline:
        movlw '\r'
        call tx232
        movlw '\n'
        call tx232
        retlw 0

    ;下位4bitが「当該月の日数」であり、
    ;全体が「基準の年の当該月1日の曜日+4」とmod7で等しいような数を返す
    getmonthattr:
        addwf PCL,F
        dt .95, .28, .63, .94, .47, .78,
        dt .31,.111, .30, .95,.126, .79,
        dt .31,.125

    ;RS232Cで1バイト受信し、下位ニブルのみ返す
    rx232:
        btfss GPIO,3 ;rx start [0,3)
        goto $-1
        clrf dat232
        goto $+1
        goto f
    ;RS232Cで1バイト送信する
    tx232:
        movwf dat232
        bcf STATUS,C
        rlf dat232,W
        xorwf dat232,F
        bsf GPIO,TXPIN ;tx start 0
    f:
        bsf cnt232,3
    loop232:
        movlw 0xF8
        addwf GPIO,W ;read [9,12)+9n
        movlw 1<     rrf dat232,F
        btfsc STATUS,C
        xorwf GPIO ;write 7+9n
        decfsz cnt232
        goto loop232

        movlw 0x0F
        andwf dat232,F
        xorwf dat232,F
        goto $+1
        bcf GPIO,TXPIN ;stop
        retlw 0

        end
      

  • 最弱のPICマイコンでカレンダー
    2014年10月30日 01:12

    「プロ生ちゃんカレンダー プログラミング プチコンテスト 2014」という面白そうなものを知った。
    カレンダーに載せる、"カレンダーを表示するソースコード"を募集するコンテストである。
    思えばカレンダーのプログラムを書いたことが無かったので自分も何か書いてみたくなり、さて何で書くかと考えたところ、やはり最近マイブームなPIC10F200でいくことにした。
    (その後よく考えてみたらJavaScriptでカレンダーを書いたことがあったが、まあ自力で閏年判定とかが初めてということで)

    コードは末尾に載せたが、中でも今回自分で書いてて気に入っているポイントをいくつか挙げると、
    ・数値を受け取るそばから要らない部分を捨てて保存する(年の1000の位は2倍して100の位に足す)
    ・不正な値は完全無視(月の10の位は最下位bitしか見てないとか)
    ・6命令で閏年判定
    movf yearl,W
    btfsc STATUS,Z
    movf yearh,W
    andlw 0x03
    btfss STATUS,Z
    goto notleap
    といったあたり。
    あとはいつも使ってるコードだけどシリアル送受信は自信作。

    使い方は、シリアルポートに抵抗だけ挟んで写真のように直結し、電源ON。
    PIC10F200カレンダー_回路

    「Y?>」に対して年を4桁で、「M?>」に対して月を2桁で入力すると、当該月のカレンダーを出力してまた「Y?>」から入力待ちとなる。
    表示はこんな感じ。(ローカルエコーON)
    PIC10F200カレンダー_コンソール
    プログラム容量は余裕があるのでもうちょっとまともなメッセージにしてもよかったかもしれない。

    以下プログラム。
    プログラム容量は188ワード。PIC10F200の容量256ワードのうち使用率75%ほど。
    (なお最初書き上げたときは201ワードだったのだが、コードにコメントなどつけて整理していたらいつの間にかここまで縮んでしまった。)
    使用メモリは11バイト。16バイトの7割。
    どちらも余裕であった。
    ;### PIC10F200 Calendar###
    ;by Ikadzuchi (@Pleist)
        list p=10F200
        #include p10f200.inc
        radix dec

        __CONFIG _MCLRE_OFF & _CP_OFF & _WDT_OFF

        cblock 0x10
            txdat, rxdat
            yearh, yearl, month
            cnt, dowcnt, daycnt, cnt232
            day
            temp
        endc

    ;ピン
    #define TXPIN 0
    #define RXPIN 3

        org 0
    init:
        movwf OSCCAL ;クロック補正値セット
        movlw b'11001000'
        ;設定データ。プルアップOFF、他Don'tCare
        ;ちょうど下位3bitがDon'tCareなのでI/O設定と共用
        clrf GPIO ;出力ピンを全Lowに
        tris GPIO ;I/Oモード設定
        option ;設定

    main:
        clrf cnt
        clrf cnt232

    ;"Y?>"
        movlw 'Y'
        call tx232
        movlw '?'
        call tx232
        movlw '>'
        call tx232

    ;年4桁受信: abcd
    ;年上位 = 10a+b ≡ 2a+b
        call rx232
        movf rxdat,W
        movwf yearh ;*1
        addwf yearh,F ;*2
        call rx232
        movf rxdat,W
        addwf yearh,F
    ;年下位 = 10c+d
        call rx232
        movf rxdat,W
        movwf yearl ;*1
        bcf STATUS,C
        rlf yearl,F ;*2
        rlf yearl,F ;*4
        addwf yearl,F ;*5
        rlf yearl,F ;*10
        call rx232
        movf rxdat,W
        addwf yearl,F

    ;"M?>"
        call newline
        movlw 'M'
        call tx232
        movlw '?'
        call tx232
        movlw '>'
        call tx232

    ;月2桁受信: ef
        call rx232
        movf rxdat,W
        andlw 0x01 ;1っぽければ10をセット
        btfss STATUS,Z
        movlw .10
        movwf month
        call rx232
        movf rxdat,W
        andlw 0x0F
        addwf month,F ;C0

    ;閏年判定
        movf yearl,W ;年下位を取り、
        btfsc STATUS,Z ;0なら
        movf yearh,W ;年上位を取り、
        andlw 0x03 ;下位2bitが
        btfss STATUS,Z ;0でなければ
        goto notleap ;平年。

    ;閏年1,2月を13,14月扱い
        movlw .3
        subwf month,W
        movlw .12
        btfss STATUS,C
        addwf month,F
    notleap:

    ;年ごとの曜日の基準を算出
    ;年下位 + 年下位/4 + (年上位%4)*2
        rrf yearl,W
        movwf temp
        rrf temp,W
        andlw 0x3F
        addwf yearl,F
        rlf yearh,W
        andlw 0x06
        subwf yearl,F
    #define doworg yearl ;名前変更: DoW origin

    ;当月日数を取得
        decf month,W
        call getdaysinmonth
        movwf daycnt
    ;当月の曜日の差分を取得し基準に足す
        decf month,W
        call getfirstdayinmonth
        addwf doworg,F

    ;%=7
        movlw .7
    mod7loop:
        subwf doworg,F
        btfsc STATUS,C
        goto mod7loop
        addwf doworg,F

    ;ループ用にNと(6-N)を生成、コードの都合上+1
        movlw .8
        movwf dowcnt
        incf doworg,W
        subwf dowcnt
        movwf cnt

        call newline

    ;月初めの日まで空白で埋める
        goto dayadjstart
    dayadjloop:
        movlw ' '
        call tx232
        movlw ' '
        call tx232
        movlw ' '
        call tx232
    dayadjstart:
        decfsz cnt,F
        goto dayadjloop

        clrf day
    dayoutloop:
    ;表示用日(BCD)を++
        movlw .7
        addwf day,F
        movlw .6
        btfss STATUS,DC
        subwf day,F

    ;1日分の表示
        movlw ' '
        call tx232
        swapf day,W
        andlw 0x0F
        btfsc STATUS,Z
        movlw ' '
        btfss STATUS,Z
        iorlw 0x30
        call tx232
        movf day,W
        andlw 0x0F
        iorlw 0x30
        call tx232

        decf daycnt,F
        btfsc STATUS,Z
        goto break ;1月分出力完了で抜ける

        decfsz dowcnt,F
        goto dayoutloop ;日ループ

        movlw .7
        movwf dowcnt
        call newline
        goto dayoutloop ;週ループ
    break:
        call newline

        goto main

    ;### subroutine ###

    ;改行を出力
    newline:
        movlw '\r'
        call tx232
        movlw '\n'
        call tx232
        retlw 0

    ;当該月の日数を返す
    getdaysinmonth:
        addwf PCL,F
        dt .31, .28, .31, .30, .31, .30 ;1~12月
        dt .31, .31, .30, .31, .30, .31
        dt .31, .29 ;閏年1,2月

    #define ADJ .7 ;負にならないよう補正するため
    ;基準の年の当該月1日の曜日を返す
    getfirstdayinmonth:
        addwf PCL,F
        dt 0+ADJ, 3+ADJ, 3+ADJ, 6+ADJ, 1+ADJ, 4+ADJ ;1~12月
        dt 6+ADJ, 2+ADJ, 5+ADJ, 0+ADJ, 3+ADJ, 5+ADJ
        dt 6+ADJ, 2+ADJ ;閏年1,2月

    ;RS232Cで1バイト送信する
    tx232:
        movwf txdat
        bsf GPIO,TXPIN ;start 0
        bsf cnt232,3
    tx232loop:
        rrf txdat,F
        movf GPIO,W
        andlw ~(1<     btfss STATUS,C
        iorlw 1<     movwf GPIO ;write 7+9n
        decfsz cnt232,F
        goto tx232loop
        goto $+1
        goto $+1
        nop
        bcf GPIO,TXPIN ;stop
        retlw 0

    ;RS232Cで1バイト受信し、下位ニブルのみ返す
    rx232:
        btfss GPIO,3 ;start [0,3)
        goto $-1
        movlw 0x80
        movwf rxdat
        bcf STATUS,C
    rxloop:
        goto $+1
        movlw 0x0F
        rrf rxdat,F
        btfss GPIO,RXPIN ;read [9,12)+9n
        bsf rxdat,7
        btfss STATUS,C
        goto rxloop
        andwf rxdat,F
        retlw 0

        end

    おまけで機械語。1ワード(=1命令)が12bitで、16進数にすると3文字という独特の見た目が気に入っている。
        0   1   2   3   4   5   6   7   8   9   A   B   C   D   E   F
    0x 025 CC8 066 006 002 075 078 C59 99E C3F 99E C3E 99E 9AE 211 032
    1x 1F2 9AE 211 1F2 9AE 211 033 403 373 373 1F3 373 9AE 211 1F3 97B
    2x C4D 99E C3F 99E C3E 99E 9AE 211 E01 743 C0A 034 9AE 211 E0F 1F4
    3x 213 643 212 E03 743 A3B C03 094 C0C 703 1F4 313 03A 31A E3F 1F3
    4x 352 E06 0B3 0D4 980 037 0D4 98F 1F3 C07 0B3 603 A4A 1F3 C08 036
    5x 293 0B6 035 97B A5B C20 99E C20 99E C20 99E 2F5 A55 079 C07 1F9
    6x C06 723 0B9 C20 99E 399 E0F 643 C20 743 D30 99E 219 E0F D30 99E
    7x 0F7 643 A79 2F6 A5E C07 036 97B A5E 97B A05 C0D 99E C0A 99E 800
    8x 1E2 81F 81C 81F 81E 81F 81E 81F 81F 81E 81F 81E 81F 81F 81D 1E2
    9x 807 80A 80A 80D 808 80B 80D 809 80C 807 80A 80C 80D 809 030 506
    Ax 578 330 206 EFE 703 D01 026 2F8 AA1 AAA AAB 000 406 800 766 AAE
    Bx C80 031 403 AB4 C0F 331 766 5F1 703 AB3 171 800 --- --- --- ---
    Cx --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
    Dx --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
    Ex --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
    Fx --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Cxx
      

  • PIC10F200 OSCCAL調整用コード
    2014年02月12日 00:29

    PICの周波数調整用コードを書いた。
    軽く説明しておくと、PICには(大抵)内蔵発振器があり、その周波数は(物によって)OSCCALレジスタの設定値で128段階などに微調整出来る(する必要があると言うべきか)。

    周波数調整で問題なのが何を基準に合わせるかだが、今回はシリアル通信を使うことにした。
    シリアル通信のボーレートを自動調整する事がよくあるが、それを逆に利用することで、クロック周波数が分かる。

    動作のアルゴリズムは単純で、"?"の文字を受信するとそのパルス幅を数え、その数値を送信するだけである。それにボーレートを掛ければクロック周波数が分かるという仕組みだ。
    なぜ"?"なのかだが、これは世のボーレート自動設定機能も大抵"?"を使っているのだが、実は作ってみるまで理由が分かっていなかった。
    "?"のASCIIコードは0x3Fで、シリアルではスタート・ストップビットが付き、最下位bitから送信するので、0111111001となる。
    この1が6連続と長く並んでいるので、この部分の長さを計って6で割るのだろうと最初は思っていたのだが、6は切りが悪いし、"@"なら0000000101と0が7つ並ぶのでこちらのほうが長い。また、0→1と1→0の遷移で時間が同じ保証がない。
    ではどこを見るかというと、0→1の遷移が最初と最後にあるが、この間がちょうど8ビット時間と切りが良い。さらにその間に余計な0→1の遷移がない。
    この条件を満たすには下位bitが1・上位bitが0でその間に切り替わりが1回のみである必要があるので、0x7F、0x3F、0x1F、0x0F、0x07、0x03、0x01のいずれかとなり、そのうち印字可能文字は"?"のみである。
    世のボーレート自動設定のコードを見たことはないが、おそらくこれが"?"を使っている理由なのではないかと思っている。

    概要を説明する。
    まず使うPICは10F200である。これは最も機能の少ない石なので、プログラムを直して他の石で動くようにするのは簡単だろう。
    ボーレートは300とした。これは10F200のタイマーで計れる最長時間がプリスケーラーを使って65536サイクルなので、8ビット時間がこれ以下になる値ということで決めた気がするが、実際の計り方を考えるとこれはあまり意味がなかった。まあいいや。
    65536サイクルを計るわけだが、計数精度が1バイトでは心もとない。しかし2バイトで数えようとすると繰り上げ処理に時間を食ったりで途端に大変になるのでどうしようかと考えた結果、面白い方法を思いついた(のでブログに書きたくなった)。
    アイディアの骨子はこうだ。
    ・まずオーバーフローしない程度の低分解能で大体の時間を計る
    ・もう一度今度は高分解能でオーバーフローを気にせず計る
    ・それを統合する
    ここで上位バイトと下位バイトは1bit分重ねておく必要がある。そうでないと2回の誤差でちょうど繰り上がった時に判断ができない。

    実際のコードでは、8ビット時間分の計測対象の前にちょうど1ビット時間分のスタートビットがあるので、これを低分解能で計っている。
    あとは1回毎にOSCCALの設定値を2づつ(最小単位が2)変えて、計測結果とその時のOSCCALの値をシリアルで送信…しようと思ったが面倒なので1つ前のOSCCALの値とその時の結果を送信している。
    シリアル送信のボーレートをきちんと合わせるのも面倒なので、1つ前の、しかも低分解能の計測結果を使っている。
    なので正常に通信できないことを考えて、クロックが最大11%ずれていても送信できるモードを考えた。
    ・16進数を送信したいだけなので、下位4bitが正常に送れれば良い。
    ・しかし、ストップビットが正しくないと受け付けられない。
    ・であれば、上位bitをストップビットと同じ"1"にしておけば良い。
    ・16進数の0-Fを0xC0-0xCFとして送ることにしよう。
    ・0xC0は「タ」、0xCFは「マ」である。
    ・これをタマモードと名付けよう。
    しかしなんか普通に送れたので使う機会がなかった。一応コードには残してあるが未チェックである。使うならストップビットの時間も長くしたほうがいい。

    さてそれで計った生データがこちら。
    1667D014678612663E1065F90E65B30C647B0A64350863F00663A904625E0262190061D4FE618EFC6079FA6035F85FF0F65FAAF45E62F25E1BF05DD6EE5D90EC5C5AEA5C13E85BD0E65B8BE45A40E259FBE059B7DE5872DC5823DA57DFD8579CD65658D4560FD255CAD05586CE5441CC540ACA53C6C85383C6523FC451F6C251B2C0506FBE502BBC4FB9BA4E76B84E32B64DEFB44DA8B24C63B04C23AE4BDEAC4BA8AA4A64A84A24A649E0A4499AA24858A048169E47D29C47849A46449846029645C09444799244399043F58E43B58C427D8A423D8841FB8641BA844072824030803FF0823FAF843FEE8640308840728A41BA8C41FB8E423D90427D9243B59443F79644379844799A45C09C46029E4644A04786A247D4A44814A64858A8499AAA49E2AC4A24AE4A66B04BA8B24BDFB44C21B64C65B84DA7BA4DEFBC4E32BE4E76C04FB8C2502BC4506FC651B2C851F6CA523FCC5383CE53C6D0540AD25441D45586D655CAD8560FDA5658DC579CDE57E1E05824E25871E459B7E659FCE85A41EA5B89EC5BCEEE5C15F05C5AF25D90F45DD6F65E1BF85E60FA5FAAFC5FEFFE603400607A02618F0461D30662190862600A63A90C63F00E643610647B1265B41465F916663E1867861A67D01C68161E685D2069A32269F1246A39266A7E286BC52A6C112C6C582E6D9E306DE5326E1E346E66366FAB386FF33A703C3C71843E71CB4072134273884473D046741648745E4A75AB4C75F34E76385077805277BA5478015678495879915A79DD5C7A255E7A6D607BB4627C03647C4B667D93687DDB6A7E286C7E706E7FB6707FFD72803674807E7681C478820B7A82577C839E7E83E47C842B7A83E478839E76825774820B7281C470807E6E80366C7FFD6A7FB5687E6E667E28647DDB627D93607C4B5E7C055C7BB45A7A6D587A255679DC5479915278495078024E77BA4C77814A763B4875F34675AB44745E4274164073D03E73883C72133A71CC38718436703C346FF1326FAB306E642E6E1E2C6DE62A6D9E286C58266C11246BC6226A7E206A381E69F11C69A31A685B1868161667D01467861266401065F90E65B30C647A0A64350863F00663A904625E0262190061D4FE618EFC6079FA6035F85FEFF65FAAF45E60F25E1BF05DD6EE5D91EC5C5AEA5C15E85BD0E65B8BE45A41E259FCE059B7DE5872DC5824DA57DFD8579CD65658D4560FD255CAD05586CE5441CC540ACA53C6C85383C6523FC451F7C251B2C0506FBE502BBC4FB9BA4E76B84E32B64DEFB44DA8B24C66B04C23AE4BDFAC4BA9AA4A67A84A24A649E2A4499AA24858A048169E47D59C47879A46459846029645C1

    グラフにしたのがこちらである。
    PIC10F200 OSCCAL設定値と周波数
    これを見ると面白いのが、32個ごと(値は64ごと)に不連続な点が見える。折角なので差分もグラフにしてみると、16個ごとや8個ごとにも値が飛んでいるのが分かる。
    たぶん、周波数の微調整のためにはCR発振器のCやRを変化させるために抵抗ラダーのような構成にしているのだろうが、その特性のずれが見えているのだろう。

    コードは以下のとおり。無保証あずいず。
    シリアルポートとの結線はこちらを参考にしました。
    RS-232C - TTLレベルの簡易変換方法 (ELM by ChaN)
        list p=10F200
        #include p10f200.inc
        radix dec

        ;    N/C+-v-+(GP3)
        ;    Vdd|   |Vss
        ;    GP2|   |N/C
        ;    GP1+---+GP0

        __CONFIG _MCLRE_OFF & _CP_OFF & _WDT_OFF

        cblock 0x10
            tmr32
            tmr2
            flag
            cnt
            waitcnt
            waitcnt2
            txdat
        endc

    ;レジスタ使いまわし
    #define temp waitcnt
    #define temp2 waitcnt2

    ;プリスケーラー設定用
    #define OPTVAL2  b'10010000' ;2:1
    #define OPTVAL32 b'10010100' ;32:1
    #define OPTVAL64 b'10010101' ;64:1
    ;                  ^/GPWU: DontCare
    ;                   ^/GPPU DontCare
    ;                    ^T0CS=0: Fosc/4,GP2=I/O
    ;                     ^T0SE Don'tCare
    ;                      ^PSA TMR0
    ;                       ^^^PS

    #define FCLK .4000000 ;クロック周波数
    #define BAUD .300 ;ボーレート
    #define ASCEND 0

    #define TAMA 0 ;タマモード(未使用)

    #define SERIAL_WIDTH (FCLK/4 / BAUD / 32) ;シリアルの1ビット時間(プリスケーラー32)

    init:
        org 0x00
        
        movwf OSCCAL
        movlw SERIAL_WIDTH
        movwf tmr32

        clrf cnt
        
        clrw
        movwf GPIO
        tris GPIO

        bcf flag,ASCEND

    mainloop:
        movlw OPTVAL64
        option ;ps=64

    wait2bhigh: ;wait 2bit high pulse

        btfss GPIO,3 ; wait ^
        goto $-1
        clrf TMR0
        bcf STATUS,C
        rrf tmr32,W
        movwf temp
        bcf STATUS,C
        rrf temp,W
        subwf tmr32,W; W=tmr32*0.75
        btfsc GPIO,3 ; wait v
        goto $-1
        subwf TMR0,W
        btfss STATUS,C
        goto wait2bhigh

        movlw OPTVAL32
        option ;ps=32

    count1bit:
        btfss GPIO,3 ;wait ^ [0,3)
        goto $-1
        clrf TMR0 ;[2,5)+2
        btfsc GPIO,3 ;wait v [0,3)
        goto $-1
        goto $+1
        movf TMR0,W ;[4,7)
        movwf tmr32

        movlw OPTVAL2 ;ps=2
        option
        clrf TMR0 ;[8,11)

    count8bit:
        btfss GPIO,3 ; wait ^
        goto $-1
        btfsc GPIO,3 ; wait v [0,3)
        goto $-1
        nop
        movlw 2 ;(8-4)/2
        addwf TMR0,W ;[4,7)
        movwf tmr2
        
        movlw 2
        btfss flag,ASCEND
        movlw -2
        addwf OSCCAL,F

    ;方向転換    
        movlw 0x80
        subwf OSCCAL,W
        btfsc STATUS,Z
        bsf flag,ASCEND
        movlw 0x7E
        subwf OSCCAL,W
        btfsc STATUS,Z
        bcf flag,ASCEND

    ;カウント上位を補正
        rlf tmr2,W ;tmr2,7 -> C
        rlf 0x0F,W ;Cが欲しいだけ
        xorwf tmr32,W
        movwf temp
        btfss temp,0 ;if tmr2,7!=tmr32,0 then do
        goto skipadj
    ;補正実行
        btfsc tmr2,6
        decf tmr32
        btfss tmr2,6
        incf tmr32
    skipadj:

    ;結果送信
        swapf OSCCAL,W
        call tx232
        movf OSCCAL,W
        call tx232
        swapf tmr32,W
        call tx232
        movf tmr32,W
        call tx232
        swapf tmr2,W
        call tx232
        movf tmr2,W
        call tx232

        goto mainloop

    ;シリアル送信
    tx232:
        andlw 0x0F
        movwf txdat
    #if TAMA
        movlw 0xC0
    #else
        movlw 6
        addwf txdat,W
        movlw '0'
        btfsc STATUS,DC
        movlw 'A'-10
    #endif
        bsf GPIO,2 ;#
        addwf txdat,F
        nop
        call wait32n
        bsf cnt,3
    txloop:
        movf GPIO,W
        andlw 0x0B
        rrf txdat,F
        btfss STATUS,C ;極性反転
        iorlw 0x04
        movwf GPIO ;# >9, >9>
        call wait32n
        decfsz cnt,F
        goto txloop
        call wait6
        bcf GPIO,2 ;# >3
        call wait32n
        retlw 0

    wait32n: ;wait 3+32n
        movf tmr32,W
        movwf waitcnt
    waitloop:
        nop
        movlw .9
        movwf waitcnt2
    waitloop2:
        decfsz waitcnt2,F
        goto waitloop2
        decfsz waitcnt,F
        goto waitloop
        retlw 0

    wait6:
        goto $+1
        retlw 0

        end
      

  • 最弱のPICマイコンで電子オルガン(デラックス版)
    2013年08月14日 02:04

    最弱のPICマイコン、PIC10F200でまた電子オルガンを作ってみた。
    I/Oピン4本の10F200で、前回は追加部品なしで8キーの入力をとる方法を示したが、ダイオードを使えばなんと28入力まで可能となる。


    【ニコニコ動画】最弱のPICマイコンでまた電子オルガンを作ってみた(実演編)


    【ニコニコ動画】最弱のPICマイコンでまた電子オルガンを作ってみた(解説編) (※縮小表示になってるので埋め込みプレイヤーでの視聴は非推奨)

    28キーの配線

    解説しよう。
    まず参考になるのがこちらのページ。
    ELM - ポートが足りないときは
    3ピンの場合で描いた図がこちら。(プルアップ抵抗は省略)
    スイッチ_ダイオード
    左3つのキーは普通にそれぞれ1,2,3番のピンのみをGNDに落とすが、他のキーは複数のピンを同時にGNDに落とす。ダイオードは逆流防止だ。
    マイコン側では3本のピンの値の組み合わせを見ることで、
    HHH
    HHL
    HLH
    LHH
    HLL
    LHL
    LLH
    LLL
    の2^3=8通りを判別できる。このうち何も押されていないHHHを除いた7通りで7キーまで扱える。
    4ピンなら2^4-1=15通りとなる。
    なおマイコンへの入力のありうる全組み合わせがそれぞれのキーに対応していることからも分かるように、キーの同時押しは判別不可能である。同時押しはどこか別のキーとして読み取られる。

    さらにこれにキーマトリクスの原理を組み合わせる。
    ピンを2本追加した場合を考えると、
    スイッチ_ダイオード+マトリックス
    ピン4とピン5の出力をどちらをLowにするかで、左右の7つづつのキーをピン1-3の入力側で上と同じように判別することができる。
    これをさらにCharlieplexingのように入力側と出力側を兼用する配線にしたのが最終的な今回の回路である。
    回路図
    基板上の配線は、秋月の細長い基板に綺麗に収まった。なかなかの自信作である。
    基板配線

    テーブルキーのbit数

    さて25個のキーを扱うにはもうひとつ問題がある。

    押されたキーを判定するには、
    ・全ピンがHighの時、ピン0,1,3の値
    ・ピン2がLowの時、ピン0,1,3の値
    ・ピン0,2がLowの時、ピン1,3の値
    ・ピン1,2がLowの時、ピン0,3の値
    の計10個の値を判断する必要がある。
    10bitのテーブルを引ければそのままテーブルのキーにするだけだが、Flashが256ワードしかないためテーブル引きをするには8bitしか扱えない。
    そこでどうするかだが、この10bitのテーブルは空きが多いので、2つの値を1つにまとめてしまっても運よく別のエントリと衝突しないことがある。
    言葉で説明しづらいので例を挙げる。
    このような4bitのテーブルがあったとする。
    A・B1100
    C・D\1010
    11ab
    10cd
    01e
    00f
    この場合、AとBの代わりにA|Bという値を使っても、全てのエントリが区別できる。
    A|B
    C・D\
    10
    11ab
    10cd
    01e
    00f

    これにより4bitから3bitにキーのビット数を減らすことができた。

    実際には、
    A + B<<1 + C<<1 + D<<2 + E<<2 + F<<3 + G<<4 + H<<4 + I<<6 + J<<7
    のような計算で10bitを8bitに畳んでいる。

    音高データのbit数

    ついでに今回は音高の精度を11bitに上げた。
    テーブルの値は8bitなので、次のような2段階のテーブル引きで11bitの値を取得している。

    キー押下パターンをキーにして引く第1のテーブルの値は、「音高データの下位3bit」「8va 1bit」「第2テーブルを引くキー4bit」という構造をしている。
    次にそのキーで第2のテーブルを引き、音高データの上位8bitを得る。
    最後に、8vaが1ならば、右シフトして値を半分にする。
    なお細かいことだが、ここで「8vaが0」で判定すると余計なbitを消すのに手間がかかる。1で判定すれば8vaが0の時も1の時も下位バイトの下位4bitを消すだけで済む。

    第1のテーブルに入れるキーと音高データを兼用することで同じ2段階のテーブルでもっと精度を上げることもできる。ただ11bitあれば人間に判別できない精度にはなるようなので今回はやらなかった。

    ソース

    以下のとおり。なお前回の8キー版で詳しく説明した部分はコメントをサボっているので前回のものも見た方がよい。
        list    p=10F200
        #include p10f200.inc
        radix dec ;プログラム中では一応16進も10進も明記するつもりで10進はよく忘れるのでデフォルトは10進

        ;    N/C+-v-+(GP3)
        ;    Vdd|   |Vss
        ;    GP2|   |N/C
        ;CLK GP1+---+GP0 DAT

        __CONFIG _MCLRE_OFF & _CP_OFF & _WDT_ON
    ;GPIO3を使いたいので_MCLRE_OFF
    ;消費電力低減のためWDTを使う

        cblock    0x10
            waitcount ;ウェイト用カウンタ
            index ;テーブルを引くためのキー
    ;(ここにあった不要な変数を消したので、このソースのアセンブル結果は動画の最後のものと一致しない)
            tonel ;音の周期上位
            toneh ;音の周期下位
            acc ;周期の微調整のためのアキュムレータ
        endc

    #define origin 169 ;テーブルの一番大きな隙間が0番地~に来る位置

    ;音階に対応するサイクル数と、マクロで扱うための順序数(第2テーブルのキー)
    ;配列で定義したいところだがそういう機能が無いので桁で分けて強引に2つをまとめた
    do  equ .1911 + 0x0000
    di  equ .1804 + 0x1000
    re  equ .1703 + 0x2000
    ri  equ .1607 + 0x3000
    mi  equ .1517 + 0x4000
    fa  equ .1432 + 0x5000
    fi  equ .1351 + 0x6000
    so  equ .1276 + 0x7000
    si  equ .1204 + 0x8000
    la  equ .1136 + 0x9000
    li  equ .1073 + 0xA000
    ti  equ .1012 + 0xB000
    doh equ  .956 + 0xC000
    ;低いオクターブでは1周期がこの値(HighとLowでこの半分づつ)
    ;高いオクターブではその半分
    ;例: 1000000/1136=880.28169 ≒ 880Hz

    ;上で定義した音階名と1オクターブ上げる指示(以下8va)から第1テーブルの値を生成するマクロ
    tone macro name, high
        retlw low(name<<5) + (high<<4) + (name>>12)
        ;     音高の下3bit   8va         第2テーブルのキー
        endm

    #define ADJUST 57 ;音高データを補正するための、地のプログラムで消費するサイクル数

    init
        org 0x00
        movwf OSCCAL ;補正

        ;スリープからの復帰の場合は不要な初期化処理を飛ばそうとしたが、
        ;いまいち仕様がよく分からなかったため、やめた
    ;    btfss STATUS, NOT_PD ; /PD=0 then wake up from sleep
    ;    goto afterSleep

        movlw b'10000000'
        ;       ^/GPWU :ピン変化によるウェイクアップはWDTによるウェイクアップと競合しそうなのでOFF
        ;        ^/GPPU=0: PullUp ON
        ;         ^T0CS=0: Don'tCare
        ;          ^T0SE : Don'tCare
        ;           ^PSA=0: WDTを最速で動かすためプリスケーラをTMR0に割り当て
        ;            ^^^PS2: タイマは使用しないためDon'tCare
        option

    main
        movlw b'00001011' ;とりあえずピン2以外Z
        tris GPIO

    mainloop
        call readkey ;スイッチに応じたビットパターンを生成
        call gettone ;スイッチに応じた音階データを取得(第1のテーブル引き)
        movwf tonel
        incfsz tonel,W ;無音を分岐; if FF then sleep
        goto soundOn
        sleep ;無音ならスリープ、WDTで18ms後にリセット
    soundOn
        andlw 0x0F
        call gettoneh ;C=0 ;第2のテーブル引き
        movwf toneh
        ;8va処理
        btfsc tonel,4
        rrf toneh,F
        btfsc tonel,4
        rrf tonel,F

        ;音高データのサイクル数から地のプログラムで消費するサイクル数を引く
        movlw (ADJUST&3)<<6
        subwf tonel,F
        movlw ADJUST>>2
        btfss STATUS,C
        decf toneh,F
        subwf toneh,F

        call wait ;指定サイクル数のウェイト
        clrwdt
        bsf GPIO,2 ;圧電スピーカーへの出力をH

        call adjustHL

        call wait
        goto mainloop


    ;H側とL側のサイクル数の差を補正
    ;無駄の多いコードだが、Flashには余裕があるのでよしとする
    adjustHL:
        goto $+1
        goto $+1
        goto $+1
        goto $+1
        goto $+1
        goto $+1
        goto $+1
        retlw 0


    ;スイッチを読み、10bitを8bitに畳んでテーブルを読むためのキーとする
    ;テーブルを引くキーと鍵盤のキーが紛らわしいので後者をスイッチって呼ぼうとしたけど関数名はkeyのままだった
    readkey
    ;全てHで読む
    ;xxx3x10x ←この位置にピンを読んだ結果を入れる
        rlf GPIO,W
        andlw b'00010110'
        movwf index

        movlw b'00001010'
        tris GPIO
        bcf GPIO,0

        nop ;プルアップでHighになるまでの猶予

    ;0がLで読む
    ;xxxxx31x
        rrf GPIO,W
        andlw b'00000101'
        addwf index,F
        andlw 1
        addwf index,F

        movlw b'00001001'
        tris GPIO
        bcf GPIO,1

        nop

    ;1がLで読む
    ;xxxx3xx0
        movf GPIO,W
        bcf GPIO,2 ;下で読むためにGP2をL (圧電スピーカーの容量で時間がかかりそうなので早めに)
        andlw b'00001001'
        addwf index,F

        movlw b'00001011'
        tris GPIO

        nop

    ;2がLで読む
    ;3x10xxxx
        swapf GPIO,W
        addwf index,F

        retlw 0


    ;テーブルの隙間にコードを書いているので場所が飛ぶ
        org low(origin+.214)
    ;toneh:tonelの値に応じてウェイト
    wait:
        ;toneh*4
        movf toneh,W
        movwf waitcount
        nop
        decfsz waitcount,f
        goto $-2

        ;tonel[7:6]
        btfsc tonel,6
        goto $+1
        btfsc tonel,7
        goto $+1
        btfsc tonel,7
        goto $+1

        ;tonel[5:4]/4 (ディザリング)
        movf tonel,W
        andlw 0x30
        addwf acc,F
        btfsc acc,6
        goto $+1
        bcf acc,6

        retlw 0


    gettoneh ;第2のテーブルから音高データその2を取得
        addwf PCL,F
        nop
        retlw low(do>>3) ;音高データの上位8bit
        retlw low(di>>3)
        retlw low(re>>3)
        retlw low(ri>>3)
        retlw low(mi>>3)
        retlw low(fa>>3)
        retlw low(fi>>3)
        retlw low(so>>3)
        retlw low(si>>3)
        retlw low(la>>3)
        retlw low(li>>3)
        retlw low(ti>>3)
        retlw low(doh>>3)


        org origin-2
    gettone ;第1のテーブルから音高データを取得
        movf index,W
        addwf PCL,F
    ;第1のテーブルはFlash全域にわたる
        org low(origin+.179)
        tone do, 0
        org low(origin+.204)
        tone di, 0
        org low(origin+.212)
        tone re, 0
        org low(origin+.85)
        tone ri, 0
        org low(origin+.165)
        tone mi, 0
        org low(origin+.38)
        tone fa, 0
        org low(origin+.81)
        tone fi, 0
        org low(origin+.209)
        tone so, 0
        org low(origin+.197)
        tone si, 0
        org low(origin+.181)
        tone la, 0
        org low(origin+.53)
        tone li, 0
        org low(origin+.69)
        tone ti, 0
        org low(origin+.196)
        tone do, 1
        org low(origin+.207)
        tone di, 1
        org low(origin+.211)
        tone re, 1
        org low(origin+.57)
        tone ri, 1
        org low(origin+.156)
        tone mi, 1
        org low(origin+.77)
        tone fa, 1
        org low(origin+.201)
        tone fi, 1
        org low(origin+.205)
        tone so, 1
        org low(origin+.194)
        tone si, 1
        org low(origin+.175)
        tone la, 1
        org low(origin+.19)
        tone li, 1
        org low(origin+.0)
        tone ti, 1
        org low(origin+.37)
        tone doh, 1

        org low(origin+.213)
        retlw 0xFF ;無音

        end


    --15/06/15
    前回へのリンク追加