ななしのさんが、AVRを使って製作された Emotion Unitは
早いもので1年前（http://207.236.16.161/JinSato/MindStorms/HW/BBS/hw_18.html )
になってしまいましたが、自分もすぐ作ってみたいと思っていましたがやはり、この際、少し勉強をして作動原理とか消化してから
と思っているうちに、寄り道をしてしまいました。

しかし、ようやく、電子工作をはじめてきて少しづつですが
分かってきましたので、PIC版の Emotion Unitを作ることに
してみました。
それで、製作途中ですが下記のURLに製作＆実験の様子を公開
してみました。
http://207.236.16.161/JinSato/MindStorms/Dkousaku/PIC-EMU/

まだ、テストとかの様子しか有りませんが、完成目指して
頑張りたいと思います。

Jinです。 2週間かかってしまいましたが、PIC版 Emotion Unit
（略して、PIC-EU)が完成しました。

ファームウエアーの方は、チマチマとバージョン
アップしていくと思いますが、ハードのほうはLEGOで作った
ケースに入れました。
いや〜、ケースに入れるの一日かかってしまいました。

基板の方は試作品ということで、万能基板で手配線です。

機能的な特徴は

１：RCXから、PIC-EUに対してパターンの転送可能
２：転送パターンをEEPROMに、SAVE可能 （4つまで）
３：EEPROM からパターンをLOAD可能。
４：パターン全体を上下、左右に表示位置を調整可能
５：任意のピクセルの、On/Off
６：電源はRCX、もしくは 9Vのバッテリーケースから取得可能
（内部に、ブリッジダイオードを入れてあるので、
配線をの方向は気にする必要なし)

などです。 特徴１，２，３，４，５は全部RCX側からの命令
で制御可能です。
６も、モーターの電源を使うので、PIC-EUのOn/Offも可能です。(^^)

ファームウエアーのほうですが、 まだ、100WORDほどメモリーエリアが残って
いるので、もう少し機能を強化するかもしれません。

早速完成のイメージをごらんいただきたいのですが、なんと、
先ほど、１年ほど使ったメモリーカードが（8Mのスマートメディア）
が昇天してしまいましたので、新規に購入しないといけません。
（何か直す方法があるのかな〜）

ということで、もともとの発案者の ななしのさん、この場を
ありがとうございました。

また、色々とご助言いただいた、mac さん、ありがとうござ
いました。

そのうち、少しづつ、まとめて公開していこうと思います。

Jinです。 週末突然の仕事が入ってきて、工作が出来なかったのですが、月曜日の午後
時間が少し取れて、作業しました。

I2Cを使って、シリアルEEPROMに目のデータ-を入れることを当初の予定にしておりましたが、
現状だと1K Word の中にコードが収まらない可能性が出てきました。

IRの受信、LED-ARRAYの表示、パターンの切り替えと、簡単なアニメ機能で、500WORD
ほど消費しているのですが、I2C のコードを入れると、850WORDほどになってしまい、
アニメーション機能を削るしかなさそうになってきました。

思い切って、シリアルEEPROMを使うのをやめて、PICに初めからあるEEPROM 62Byte
だけに目のデータ-を入れ、それを、RCX側から書き換え可能にする方向も考えています。
（そうなると、登録できるのは4個だけになるのですが、でも、書き換えできるし、
簡単なアニメーションもできるからOKかな？）

いずれにせよ、１KWORDの中に、どの機能を、どのように詰め込むかと言うのは、
大変ですが、面白い作業ですね。

> 現状だと1K Word の中にコードが収まらない可能性が出てきました。

ずいぶん埋まりましたね。
MBMEだと180Word弱なんですが(^^;

> いずれにせよ、１KWORDの中に、どの機能を、どのように詰め込むかと言うのは、
> 大変ですが、面白い作業ですね。

その一
執念で詰め込みAsmに嵌る

その二
さくっと16F84に見切りをつけ16F86, 16F873, 16F877に飛びつく

のどちらかではないんでしょうか。
機能を絞るなんてもったいなくって、とてもとても(^o^)

どうも〜、mac さん。

> ずいぶん埋まりましたね。

ライン数にすると、600行くらいしかないんですけどね〜

> MBMEだと180Word弱なんですが(^^;

欲張りで、ついつい、いろいろと入れてしまいたくなるんですよ。

I2CをあきらめるとI/Oのピンも4本残るので、外部に出して、
適当にLEDを点滅させたりもしたいし。

抵抗が組み込まれた、LEDも入手したんで、MiniFigにLEDを
埋め込んでみたいし。 (&&)

> > いずれにせよ、１KWORDの中に、どの機能を、どのように詰め込むかと言うのは、
> > 大変ですが、面白い作業ですね。
>
> その一
> 執念で詰め込みAsmに嵌る

いや〜、そこまで根性ないです。 (^^)

Cで書くと他の マイコンにも移植しやすいんじゃないかと
思ってます。 （I/Oとか、イントラプトのところは書き直しですが）

> その二
> さくっと16F84に見切りをつけ16F86, 16F873, 16F877に飛びつく

16F863 は 4Mhz のを１つ入手しました。
これも、いつか、使いたいです。 A/Dも有るし。
別のセンサーをつけて遊ぼうと思っています。

F863がDIP18だったら、うれしいのにな〜。
なぜかというと、完成の折には、26mm X 59mm X 23mm の
大きさの中に埋め込む予定なんです。

面倒だから、全部空中配線にして、ホットグルーで固めて
しまうとか ....(そうなると、量産できないし）

アートワークはまだなんですが、ピン間に2本くらい
配線しないとできそうにないから、自作基板だと少し
つらいな〜なんて感じています。

> のどちらかではないんでしょうか。
> 機能を絞るなんてもったいなくって、とてもとても(^o^)

コードは残しているんで、別のプロジェクトで使いたい
ですね。

しかし、Cで詰め込んで書くのは、なんだか、面白いです。

まあ、でもそろそろ、次のプロジェクトもしたいので、
来週の週末くらいまでは、試作1号完成させたいと思ってます。

> > その一
> > 執念で詰め込みAsmに嵌る
>
> いや〜、そこまで根性ないです。 (^^)
>
> Cで書くと他の マイコンにも移植しやすいんじゃないかと
> 思ってます。 （I/Oとか、イントラプトのところは書き直しですが）

そうなんですが、PICの特にMPLABのASMは、
ちょっとはじめると嵌る性質があるようです。

68kやx86だと、ASMじゃ全然書きたくないんですが、
PICとかTIのDSPとかパズル的で面白いというか、
コンパイラーに完全圧勝できる...
まあ、それだけアーキテクチャが、
高級言語向きでないという話ではありますが...

> F863がDIP18だったら、うれしいのにな〜。

16F86というのは、まさにそれなんですが、
http://www.microchip.com/Download/lit/pline/picmicro/families/16f8x/devices/16f86/30574a.pdf
まだ、Status Future Productで入手困難なようですね。

> > > その一
> > > 執念で詰め込みAsmに嵌る
> >
> > いや〜、そこまで根性ないです。 (^^)
> >
> > Cで書くと他の マイコンにも移植しやすいんじゃないかと
> > 思ってます。 （I/Oとか、イントラプトのところは書き直しですが）
>
> そうなんですが、PICの特にMPLABのASMは、
> ちょっとはじめると嵌る性質があるようです。

それは、あるかもしれません。


> 68kやx86だと、ASMじゃ全然書きたくないんですが、

68Kならば、アッセンブラでもOKかも。
x86だと、8086 までしか覚えてないけど。 68000は
Cで書いて、ハンドコンパイルして、アッセンブラの
コードを書いたりしてました。
グラフィックのルーチンなんか。


> PICとかTIのDSPとかパズル的で面白いというか、
> コンパイラーに完全圧勝できる...
> まあ、それだけアーキテクチャが、
> 高級言語向きでないという話ではありますが...

そうですね〜。 CSS Cのコードは割と良い感じのコードを
出してくれますけど、それでも、Cのコードである程度
ハンドオプティマイズしてあげないといけない感じが
しました。

>
> > F863がDIP18だったら、うれしいのにな〜。
>
> 16F86というのは、まさにそれなんですが、

お〜、ほんとだ。 これいいですね〜 メモリーも多いし。

> まだ、Status Future Productで入手困難なようですね。

ん〜残念。


先ほど、RCXからパターンの定義データーを送って、PICの
EEPROMに書き込むテストしましたが、ばっちり動きました。
NQCでこんなコードを書いてやれば、パターンが定義できます。

task main()
{
SetSerialData( 0 , 0xa0 ); // Function SET PATT
SetSerialData( 1 , 1 ); // INDEX

SetSerialData( 2 , 0x00 ); // 000 00000
SetSerialData( 3 , 0x00 ); // 000 00000
SetSerialData( 4 , 0x04 ); // 000 00100
SetSerialData( 5 , 0x08 ); // 000 01000
SetSerialData( 6 , 0x08 ); // 000 01000
SetSerialData( 7 , 0x04 ); // 000 00100
SetSerialData( 8 , 0x00 ); // 000 00000

SetSerialData( 9 , 0x00 ); // 000 00000
SetSerialData(10 , 0x04 ); // 000 00100
SetSerialData(11 , 0x08 ); // 000 01000
SetSerialData(12 , 0x08 ); // 000 01000
SetSerialData(13 , 0x04 ); // 000 00100
SetSerialData(14 , 0x00 ); // 000 00000
SetSerialData(15 , 0x00 ); // 000 00000

SetSerialPacket (SERIAL_PACKET_RCX );
SendSerial( 0, 16 );
}

Jinです。

http://207.236.16.161/JinSato/MindStorms/Dkousaku/PIC-EMU/
に政策途中をUpdateしました。

現在テスト３です。 これから、EEPROMの Block 単位での Read/Writeの実験を
するつもりです。
あとは、RCXとのコミニケーションのプロトコルトを決めていく感じです。

そろそろ、基板のアートワークも考えたいところですが、74HC299やEEPROMとか
表面実装用の部品に変えて見たい感じもします。

表面実装用の半田ごても必要ですね〜。 （こて先だけ売ってるかな〜）

ということで、簡単な報告でした〜。

Jinさんこんにちは。

おお、PIC版のEmotionUnitですか完成が楽しみです。(^^)

> http://207.236.16.161/JinSato/MindStorms/Dkousaku/PIC-EMU/
私のNET環境が悪いのかもしれませんが上記URLが見れないんですよ。(涙
# 回線が重いのかな

どうも、ななしのさん。

> おお、PIC版のEmotionUnitですか完成が楽しみです。(^^)
ありがとう、ブラッドボードの上ではほぼ動いていますが、パターンのUpdate
をどの方法でやろうか今、頭を15度ほど傾けているところです。

> 私のNET環境が悪いのかもしれませんが上記URLが見れないんですよ。(涙
> # 回線が重いのかな

あ、ほんとうだ、http://www.yk.rim.or.jp/~nanashi/
にアクセスできないですね。 ping も帰ってこないし ... nslookup でも、逆引き
出来ないですね。 www.rim.or.jp のリムネットの法も落ちているし... どうしたんで
しょうね。
サポートのTELなどは繋がりますか〜？ ＞ ななしのさん。

そういえば、リムネットはアメリカのPSIネットが押収したんですよね〜。
（http://www.watch.impress.co.jp/internet/www/article/980826/rim.htm）

PSIネットて実は 自分もメインに使っているメールサーバーの会社をずいぶん前に
押収していて 4日間もメールサーバーがダウンしてたこともあるし、 PSIネット自体も収益が
急激に落ちたりしますね。 心配ですね、いろいろな意味で。

ななしのです。

> ありがとう、ブラッドボードの上ではほぼ動いていますが、パターンのUpdate
> をどの方法でやろうか今、頭を15度ほど傾けているところです。
パターンの変更もサポートするんですね。ますます楽しみです。
一つの案として、PC上のパターン書きこみプログラムを作ってIRTOWER経由で書きかえるとかはどうでしょうか?

> そういえば、リムネットはアメリカのPSIネットが押収したんですよね〜。
インタードットネット(旧リムネット)はPSINetから独立したみたいです。
けどバックボーンにPSINetの回線を使っているのでネットワーク的にはしばらく安定しないこともあるかもしれませんね。

Jin です。

リムネット、今はアクセスできるようになりました。 あ〜良かったです！！。
nslookup で逆引きするとちゃんとIPが 202.247.191.227 と帰ってきました

> パターンの変更もサポートするんですね。ますます楽しみです。
はい、一応、32KのEEPROMを搭載予定です。 でも32Kもいらないので、16Kにしようあな〜
と思ってます。

> 一つの案として、PC上のパターン書きこみプログラムを作ってIRTOWER経由で書きかえるとかはどうでしょうか?
アイディアありがとうございます。
一応、RCX2のファームウエアーで対応した、Serial系の関数を使うと 16Byteのデータ-を
RCXから送ることができるので、それを使ってみようかと考えています。
PCの方からも、RCX2のSerial系のコマンドと同じフォーマットのデータ-送るプログラムを
作るつもりです。

> > そういえば、リムネットはアメリカのPSIネットが押収したんですよね〜。
> インタードットネット(旧リムネット)はPSINetから独立したみたいです。

そうなんですか〜。

> けどバックボーンにPSINetの回線を使っているのでネットワーク的にはしばらく
>安定しないこともあるかもしれませんね。

そのレベルになると、個人的だとあまり出来ることがないですね。
端末のほうのスピードが上がってきてるので、バックボーンの負荷は
これからどんどん高くなるわけなんで、いたちごっこの様に強化していかないと
いけないんでしょうね〜

> nslookup で逆引きするとちゃんとIPが 202.247.191.227 と帰ってきました

つまらない突っ込みですが、名前からドット形式をえるのが「正引き」で、
「逆引き」は、227.191.247.202.in-addr.arpaというような、
IP Addressからホスト名を得るものですので「正引き」の方ですね。

> 一応、RCX2のファームウエアーで対応した、Serial系の関数を使うと 16Byteのデータ-を
> RCXから送ることができるので、それを使ってみようかと考えています。

Emotion mode 開始　＞＞
＜＜Ack
＞＞16 byte転送
wait
＞＞16 byte転送
wait
＞＞16 byte転送
......
＞＞16 byte転送
Emotion mode 終了　＞＞
＜＜Ack

見たいな可変長命令形を作ってしまえば、
リアルタイムでアニメーション表示できるし、
開始と終了だけは確認を取れば、
最小限の信頼性は確保できそうですね。
転送中に通信状態が悪いと、
表示が乱れる可能性が高いけど...

> 端末のほうのスピードが上がってきてるので、バックボーンの負荷は
> これからどんどん高くなるわけなんで、いたちごっこの様に強化していかないと
> いけないんでしょうね〜

全く乱開発の宅地造成みたいな状況ですからね。
有限な土地と違い、仮想世界は面積自体が拡張できるからまだしも...

あまり関係ないけど、
大失敗に終わった「イリジウム」って、もう５年か１０年あとに、
電話ではなくSS無線IPv6移動通信用にデビューしたら、
馬鹿受けだったかもしれませんね。

どうも〜、mac さん

> つまらない突っ込みですが、名前からドット形式をえるのが ..
あちゃ〜、コレクションありがとうございます。 m(。。)m

> Emotion mode 開始　＞＞
> ＜＜Ack
> ＞＞16 byte転送
> wait
> ＞＞16 byte転送
> wait
> ＞＞16 byte転送
> ......
> ＞＞16 byte転送
> Emotion mode 終了　＞＞
> ＜＜Ack

Emotion Unit から Ack を返すのが理想ですが、面倒なんで
受信しっぱなしにしようと思ってます。
また、リモコンでも、動かせたり、のちのち、RCXじゃない
Unitからもコントロールできるようにと思ってます。

> 表示が乱れる可能性が高いけど...

乱れますね。 今使っている、PIC16F84には、タイマーが１つ
しかなくて、そのタイマーでLEDをダイナミックに点滅
させているのですが、それでも、IRを受信するCのルーチンは
タイミングの為に内部でLoopしているみたいですので、
LEDの点滅用のタイマーイントラプトが発生しないように
なってます。

IRの方は、PIN_B0のポートの変化で イントラプトを発生
して、1Byte Getして、リングバッファに入れるようにして、
メインループの中で、リングバッファの状態によって、
処理をするようにしています。

なかなか、難しいものですね。


ほかの方法として考えているのは IR_Module を PIN_B0に
つけるのは同じですが、ポートの変化でイントラプトを
受け、その中で、ポートの変化のイントラプトを止め、
そして、2400BPSのBitを受けるタイミングタイマーを起動して
1Byte受信。

メインのループでは、何も考えず、ただループをしながら
LEDをダイナミックに駆動すると言う方法です。

このほうが、ちらつきは少ないかもしれませんが、
1ByteのGetするルーチンを書くのがめんどくさそうです。 （弱気）


、

Jinです、ちょっとした報告です。

> 1ByteのGetするルーチンを書くのがめんどくさそうです。 （弱気）
と前書きましたが、カナダの4連休をつぶして、書いていました。
イントラプトのところで１つ誤解をしていたので、遠回りを
してしまいましたが、9600BPSでオーバーサンプリングして
シリアルデーターをGETするルーチンを　CCS のC で書くことが
できました。

タイマーイントラプトさえちゃんと発生していれば、簡単に
書くことができました。

おかげさまで、GETCのルーチンとLED ARRAYのダイナミック点滅
も同じタイマーでしているので、LEDのちらつきはなくなりました。


あとは、EEPROMとデーターのやり取りとか、
RCXとのデーターフォーマットなどを決めればいけそうです。
（と、でも、もう１つか２つ、落とし穴がありそうな...)

次の週末にでも、そのへんを責めて見たいと思います。

ということで、ご助言いただいた、mac さんありがとうございました。

> > 1ByteのGetするルーチンを書くのがめんどくさそうです。 （弱気）
> と前書きましたが、カナダの4連休をつぶして、書いていました。

おお、ど根性ものですね(^^;

> あとは、EEPROMとデーターのやり取りとか、

このあたりは頻度が少ないでしょうから、
LEDを一旦全部消して、dynamic driveを止めちゃって、
局所的に別ルーチンにしちゃえばいいですよね。

コマンドパースは当然メインループ内でないとだめですけど。

どうも〜、 mac さん。

> > > 1ByteのGetするルーチンを書くのがめんどくさそうです。 （弱気）
> > と前書きましたが、カナダの4連休をつぶして、書いていました。
>
> おお、ど根性ものですね(^^;

C で書いたので、GETC自体のルーチンはすぐ出来たのですが、

時間がかかったのは、インターバルタイマーの値の計算のところで、１つ大きな
誤解をしていたのが、痛かったです。

今から、見直すと、馬鹿みたいなことなんですが。

> > あとは、EEPROMとデーターのやり取りとか、
>
> このあたりは頻度が少ないでしょうから、
> LEDを一旦全部消して、dynamic driveを止めちゃって、
> 局所的に別ルーチンにしちゃえばいいですよね。

ですね〜。 9600BPS でまわしても、ずいぶん余裕があるみたいなんで、
欲が出てきそうです。

> コマンドパースは当然メインループ内でないとだめですけど。

はい、この部分はずいぶん前に書いてあるんで、リモコンのコマンドと
ファームウエアー２の Serial系のコマンド、両方対応しようかと思ってます。

あと、EEPROMにデータ-を書くときのUploadの様子を LED ARRAYを
使ってみようかな〜とか、いろいろ欲張ってます。

まだ、300WORD くらい容量が残っているので。

> メインのループでは、何も考えず、ただループをしながら
> LEDをダイナミックに駆動すると言う方法です。

getcを書く覚悟を決めてしまえば、
ループをタイマーのフラグ待ちで1/9600 secでまわし、

タイマーフラグのテストと必要によりリロード
IRMの入力とテスト必要により１ビット分の処理
表示のダイナミック点灯と表示用カウンターの更新

を一巡のループにしてぐるぐる単純に回すのが、
PICだと常套手段じゃないかと思います。

1/2400の４倍で回しスタートビットのエッジを検出してから、
二順空振りして、ビット中央に持ってくるわけですね。

どうも、mac さん、getc を書く前に、タイマーの計算値だけ
適正なもを見つけるために計算してみました。

> getcを書く覚悟を決めてしまえば、
> ループをタイマーのフラグ待ちで1/9600 secでまわし、

ななしのさんの方法では、三度で１つのBitを見る感じでしたが
それで計算すると

クロック 10000000
スピード 2400 PBS
サンプリング回数 3 回
サンプリングスピード 7200 秒/回
1秒間の間隔 0.000138889 秒

PICの場合のカウント = (インターバル時間 ／（CPUクロックｘ４)
それで、カウント値 = 5555.555556


TMR0のカウント値＝カウント値／プリスケーラ値
スケール値 -> TMR0のカウント値
256 -> 21.70138889
128 -> 43.40277778
64 -> 86.80555556
32 -> 173.6111111
16 -> 347.2222222
8 -> 694.4444444
4 -> 1388.888889
2 -> 2777.777778

となりました、2,4,8,16ではちょっと細かすぎますよね。
256で考えると、21.70138889 と、 0.70138889 の誤差が結構
気になりました。

それで、サンプリングを４にすると、

-------------------------------------------------------
クロック 10000000
スピード 2400 PBS
サンプリング回数 4 回
サンプリングスピード 9600 秒/回
1秒間の間隔 0.000104167 秒

カウント値 = インターバル時間 ／（CPUクロックｘ４)
カウント値 4166.666667

TMR0のカウント値＝カウント値／プリスケーラ値
スケール値 -> TMR0のカウント値
256 -> 16.27604167
128 -> 32.55208333
64 -> 65.10416667
32 -> 130.2083333
16 -> 260.4166667
8 -> 520.8333333
4 -> 1041.666667
2 -> 2083.333333

となり、256での誤差が 0.27604167 程度になりました。

ということで、9600 のサンプリングスピードでまわして
見ようかと思いますがどうでしょうね〜。

問題は、1回のサンプリングの間に、処理が全部終わらせる
ことができるかという感じですね。

これは、書いてみながら試してみますが、だめなときは
サンプリングを３にしてみようかと思います。

Jin です。
No1390の書き込みですが、数箇所、間違った事を書いていました。

考え方を書き直すと以下の感じですね。

スピード 2400 PBS
サンプリング回数 3 回
サンプリングスピード 7200 秒/回
1秒間の間隔 0.000138889 秒

138us のタイミングでタイマーイントラプトを発生させる。

クロック は 10MHz (10000000)
TMR0 の値は４クロックで１つ上がる。すなわち、
１つのカウントアップは 0.0000001 x 4秒かかる （0.4us)
このカウントアップは、プリスケールで、1:2 , 1:4, 1:8, 1:16, 1:32, 1:64, 1:128, 1:256 から選ぶことが可能。

仮に、プリスケール1:16を選ぶとカウントアップには
0.0000064秒 (0.0064ms もしくは 6.4us) 必要になる。

自分が必要としているのは、138us なので、
138us / 6.4us = 21.5625 （約21）となる。

すなわち、TMR0の値が21.5625になったときに
イントラプトがかかるようにすればよいが、
イントラプトは TMR0の値がオーバーフローする時に発生する。

すなわち、TMR0の値が255から０になるときに発生する。

ということは、TMR0の値を、０からカウントするのではなく
255から、21 を引いた数 234にセットしてやればよい。

もしくは、イントラプトが発生したときの値から、21を引くことで、
次のイントラプトを発生させるタイミングをセットすればよい。

---------------------------------------
てな、感じですね。

それで、CCS C の関数を使って書くとこんな感じでね。


#define T_TICK 21

#int_rtcc void rtcc_isr()
{
set_rtcc( get_rtcc() - T_TICK );
}


main()
{
setup_counters( RTCC_INTERNAL, RTCC_DIV_16 );
set_rtcc( 255 - T_TICK );
enable_interrupts( RTCC_ZERO );
enable_interrupts( GLOBAL );

while ( true ) {
;
}
}

---------------

ただ、コンパイラが吐き出すアッセンブラのコードを見ると
set_rtcc( get_rtcc() - T_TICK ); の部分など、無駄が多い
ので、


#define T_TICK 21
#byte _TMR0 = 0x01

#int_rtcc void rtcc_isr()
{
_TMR0 -= T_TICK;
}

と書いたほうがすっきりしていました。


最後に、上記のコードで、ほぼ 138us のタイマーイントラプトを
作ることができました。

> ということで、9600 のサンプリングスピードでまわして
> 見ようかと思いますがどうでしょうね〜。

ななしのさんのAVRは4MHzですが、
PICにすれば、16MHz相当ですからね。
3 samp 20MHzなら確実な線でしょうが...

> 問題は、1回のサンプリングの間に、処理が全部終わらせる
> ことができるかという感じですね。

毎回きちんと終わらなくても、
1/2400以内に帳尻が合えば、まあ良いので...(?)

Message Ballは赤外線の搬送波のため38kHzで回したんですが、
最初ジッタ−が気になって、
Clock 10Mhzで76kHzの割り込みにしたんですよ。

でも、結局MBMEでは4MHzのフラグ待ちで間に合いました。
というのは、tmr0のreloadを数値を書きこむんじゃなくって、
定数を引くことにしたら、
多少遅れても累積しない事に気づいたんですね。

tmr0 = const;
でなく、
tmr0 -= const;
なんです。

今回の場合、

tmr0 = -16;

for (;;) {
while (tmr0 & 0x80) ;
tmr0 -= 16;
....

とやってしまうと、処理に時間がかかるループと、
短いループ平均して1/9600sec以内なら、
多少遅刻しても大丈夫です。

ただし、tmr0 -= const;の命令は、
厳密に言うと結果がtmr0に反映するのが、2clock後なので、
微調整が要ります。
この辺りは、MBMEのSourceを参考にしていただけると良いのですが、
pri-scalerが大きい場合は、無視できる誤差となることも多いでしょう。

早い話、遅刻してもtmr 0が127を超え頭のビットがひっくり返らないと、
累積誤差はでないので、実際やってみて、間に合わない様なら、
表示のダイナミックドライブを二周に一度とか、
4周に一度とかに間引けば、楽勝だと思います。

どうも〜、mac さん。
Cでタイマーインターバルのテストルーチンを書いて
オシロでタイミングを確認しているのですが、雲行きが
怪しくなってきました。

なぜならば、思ったタイミングでイントラプトがかからない
のですよ〜。

setup_counters( RTCC_INTERNAL, RTCC_DIV_256 );
enable_interrupts( RTCC_ZERO );
enable_interrupts( GLOBAL );

という感じでイントラプトのタイミングをセットして
イントラプトを受けているのですが、イントラプトの
発生タイミングは 26.2msec単位でおきています。

http://www.picfun.com/c08.html


インラインで、アッセンブラのコードを入れるか、
もう少し、CCS Cを研究してみる必要があります。

LSTファイルにはアッセンブラのコードも出ているので
読んだりしてみる必要もありそうです。

あ〜、Cで楽をしたいと思っていたのに ....

> 発生タイミングは 26.2msec単位でおきています。

(1/clock) * 4 * pri-scale * counter =
(1/10e6) * 4 * 256 * 256 = 0.0262144
だから、26.2msでぴったりではないんですか？

後は割り込み先で、先に書いたとおり
tmr0 -= 16;
してあげれば合うと思いますけど。

でも、PICの割り込みって、
W regtを自動退避しハードスタックが3段しかないので、
かなり効率が悪いんですよね。
で、割り込み頻度が高くなってくると、
割り込み使わずフラグ待ちでループをぐるぐる回しした方が、
全体としてのパフォーマンスがあがったりするんですが...

JinSatoです

> > 発生タイミングは 26.2msec単位でおきています。
>
> (1/clock) * 4 * pri-scale * counter =
> (1/10e6) * 4 * 256 * 256 = 0.0262144
> だから、26.2msでぴったりではないんですか？

はい、そのとおりです。 投稿No.1394 にもちょっと
書きましたが、前に考えていたときに１つ思い違いを
しておりました。

> 後は割り込み先で、先に書いたとおり
> tmr0 -= 16;
> してあげれば合うと思いますけど。
プリスケール1:16を使って、 tmr0 =-21 でやってみましたが
うまく動いているみたいです。

> でも、PICの割り込みって、
> W regtを自動退避しハードスタックが3段しかないので、
> かなり効率が悪いんですよね。

スタックが少ないのは辛いですよね。
構造化プログラミングでサブルーチンを作ってやるのに
なれていると、どうも、サブルーチンを沢山作って
しまうので、ずらずらと書くのに抵抗があるんですよね〜。＞自分

> で、割り込み頻度が高くなってくると、
> 割り込み使わずフラグ待ちでループをぐるぐる回しした方が、
> 全体としてのパフォーマンスがあがったりするんですが...
タイミングさえあえば、イントラプト分のオーバーヘッド
少なくなりますからね〜。

I/O 待ちが多くなると、イントラプトを掛けたほうが
すっきりするとは思いますが。

ということで、138us のイントラプトがうまくかかるように
なりましたので、getc のルーチンかいてみます。

どうも、mac さん。

> を一巡のループにしてぐるぐる単純に回すのが、
> PICだと常套手段じゃないかと思います。

マルチスレッドで局所的にいろいろと動かしたりするプログラミングに
どっぷり使っていると、その手法は、懐かしいというか、昔Z80
でプログラムしていたころを思い出しますね〜。

IRの受信、LED Arrayのダイナミック点滅、あとは、Siriaｌ EEPROMの I2Cの
コミニケーションと、それ以外には、LED ArrayのBITMAPのモーフィングなどを
詰め込もうとすると、やはり、16F84じゃちょっとつらいところが有るかもしれない
と思い始めてます。
多分、出来なくないと思うんですが、もう少し、ソフトの実装方法
研究してみます。

CCS Cでどこまでかけるか 楽しそうです。