割込処理のタイミングは
416uS：タイマー割込で生成
20mS ：タイマー割込内で 416uS * 48(19.968mS)として生成
1S 　：タイマー割込内で 19.968mS * 50(0.9984S)として生成

生成したタイミングでそれぞれの処理をします

しかし、20mS のタイミングでは
416uS と 20mS の処理が重なって処理されます

さらに、1S のタイミングでは
416uS、20mS、1S の全ての処理が重なって処理されます

クロック 4MHz の場合、416uS の割込の間に実行できる命令数は 416命令、

割込処理のオーバーヘッド(最低限必要な処理)は約18命令
RX data input：約45命令
TX data output：約37命令
A/D Service：約46命令
判定処理：約22命令

小計：約168命令　　　BG:約40%　FG:約60%　でまだかなり余裕があります

この命令数の中には分岐命令(１命令で2uSかかる)も有りますが
もし、分岐命令で分岐した場合は幾つかの命令を飛ばして下へ行きますので
実行する命令数は少なくなります
従って、ループ(上に分岐)しない様にコーディングしたプログラムは、
単純に記述した命令数を数えただけの実行時間より長くなる事は有りません


20mS のタイミングで実行する命令数は
416uS処理の最大値：約168命令
判定処理：約90命令

小計：約258命令　　　BG:約62%　FG:約38%　でまだ少し余裕があります


1S のタイミングで実行する命令数は
416uS処理の最大値：約168命令
20mS処理の最大値：約90命令
判定処理：約86命令

小計：約344命令　　　BG:約83%　FG:約17%　でほとんど余裕がありません
裏返して言うと、CPUを最大限効率良く使っているとも言えます


当初、タイマー割込は 208uS でコーディングしていました
割込時間をオシロスコープで観測するために、割込毎にポートに
パルス出力する様に命令を追加して、観測してみると希にパルスが
欠ける場合が見つかりました

「パルスが欠ける」理由
割込に使っている TMR0 は、8bit フリーランニングカウンタなので
ユーザがプリセットしなければ 256 カウント毎にオーバーフローして
(許可されていれば)割込がかかります

上述の様に割込の処理時間を計算してみると、
20mS のタイミングで実行する命令数は約258命令
分岐しないで全ての命令を実行した場合、すでに次の割込(208uS後)は
間に合わない事になります

さらに TMR0 は、フリーランニングカウンタなので
208uS に同期せず次の割込がかかります
分岐が起これば 208uS に間に合わう場合もあるため
この現象は不規則に発生します

以上、原因が分かりましたので以下の対策をします

対策：割込時間を 416uS とする

さらに、１分、１時間などの処理を追加したい場合は
(１分に１回発生しても特に問題有りませんが)
たとえ１分に１回でも気持ちが悪いので、以下の対策をします

(例)
1S 毎の処理は 20mS*50 のタイミングで実行せず、フラグをたてます
次の 416uS 割込の時に実行します

416uS 割込ですでに処理時間がオーバーする場合は
クロックの速いPIC(PIC12F683 : 8MHz)にします

PIC12F1822/1840 : 内臓クロック 32MHzでは
UART を内臓していて　シリ／パラ変換はハードでできますので
割込をもっと長くできます

失敗例(２)

PICマイコンではRAMなどの資源が限られています 
そこで、出来るだけ資源を節約する様にしました 
・ 通信タスクで使用するフラグ類は 1BYTE(8bit)に納めました 
・ ビットカウンタ(受信中、送信中のビット番号を保持するカウンタ)を 
　TX、RX 各4bitとして 1BYTE(8bit)に納めました 
・ クロックカウンタ(1bit及び1/2bitの時間を作成するカウンタ)も 
　TX、RX 各4bitとして 1BYTE(8bit)に納められますが未実施です 

　PICの場合はRAMが不足気味ですので、プログラムが多少複雑になって 
　ROMの消費が増えても RAMの節約を優先しました 

工夫例(２)