 |
|||||
        |
|
|||||
|
HOME > 技術談話 > PIC microcontroller > シリアル通信モニタ
はじめに こんな感じ 主な仕様 回路図 配置例 実装例 サンプルプログラム
通信速度と処理時間 通信速度と誤差
| PIC16F1823（試食）で紹介したデバイスを利用してシリアル（UART）通信をモニタする装置を作成します。 既に同様の機能を持つPICマイコン用のサンプルプログラムは幾つもありますが…。 デバイス（PIC16F1823）が目新しい（？）と言うことでご容赦願います。 二番煎じながらも今回の目玉は…。最大通信速度 230.4Kbps の連続通信のモニタを目標としています。 装置としての利用頻度は少ないかもしれませんが、１つあると何かと便利かと。 なお「通信モニタ」と称してはいますが、あくまでも「簡易版」です。表示領域も滅茶狭いです ですが、今回の装置がより機能的な装置を作るための足掛かりになれば幸いです。 シリアル通信の基本処理は、以前紹介したシリアル通信ドライバを利用しています。 PIC16F1823 でもユーザ定義ファイルだけの修正で利用できました。 相変わらず進捗は遅いかも…。そのような場合は「つぶやき」をチェックしてみてください。  途中経過やホームページの更新タイミングで何かしら独り言をつぶやいてます。 |
| 2011/02/27 |
| ▲ |
| 今回はブレッドボードの実験を行った後、ケースに入れてみました。 |
 |
| PICマイコンには PIC16F1823 を利用し、内蔵クロック 32MHz で駆動します。 主な部品として秋月電子通商さんの横長のユニバーサル基板、16文字＊2行のLCDモジュールを利用しました。 ケースが妙にマッチしていますが、無印良品さんのペンケース・横型（税込み189円）を利用しています。 偶然にも、ユニバーサル基板とテストクリップが具合良く収納できました（今回は受信だけなので都合３本です）。 電源は外部から DC5V を供給する方式です。これはLCDモジュールの駆動電源による制約です。 注意： ペンケースはずいぶん前に購入した物で、現在は取り扱っていないようです。 新たに「ダブルペンケース」という製品を扱っている様なので、基板のサイズが許せば収納は問題無いと思います。 専門店以外にもコンビニで取り扱っている場合もあります。 |
| 2011/02/27 |
| ▲ |
| シリアル通信モニタの主な仕様は以下の通りです。 |
| 項目 | 適用 | |
| マイコン | PIC16F1823、内蔵クロック32MHz利用 | |
| LCD | 16文字＊2行、バックライト無し | |
| 通信種別 | PICマイコン内蔵UART通信（RS232Cではなく、レベル変換は今回は省略）、1chのみ | |
| 通信速度 | 230.4K/115.2K/57.6K/38.4K/19.2K/9600/4800/2400bps、ショートピンで設定 | |
| データ構成 | 調歩同期式通信（非同期通信）、8ビット長、パリティ無し | |
| エラー検出 | フレーミングエラー、オーバーランエラー、検出時は共に受信データを破棄 | |
| 制御コード | 復帰（CR）、改行（LF）、消去（FF）、座標指定（0x1E/0x1F, 0x10 - 0x1F） | |
| 表示文字種 | LCDモジュール仕様に準拠、制御コード以外は文字として扱う | |
| 表示周期 | 64msで表示一巡、15.6fps相当、ソフトウェアで構築した疑似VRAMを経由して表示 | |
| 送受信機能 | 受信機能のみ、送信機能については今回は省略 | |
| 電源電圧 | DC5V、外部から供給 |
| シリアル通信モニタとしては、よくある仕様。になりました。 それでも 230.4Kbps のベタ通信（Min43.4us/byte）でもオーバーランを発生しない構成が特徴です。 ん？高速通信に表示が追従できないはず。 そうです。追従はできません。不可能です。 けど、ガァーと通信してピタッと通信を停止した場合の表示は追従します。 PICマイコンの書き込みは外部で行います … 参考：書き込みテスト オンボードで行う仕組みもあるのですが、ピン数の都合、保護回路云々があるので今回は見送りです。 |
| 2011/02/27 |
| ▲ |
| 回路図を以下に掲載します。極論を言えば、PIC16F1823 にLCDモジュールを接続しただけです（汗 |
 |
| PIC16F1823 におけるデータバス信号の割り付けが不揃いですが、実装優先で割り付けています。 RA3/_MCLR は RA3 として利用していますが、将来的な用途として確保し、現時点では未使用です。 RA0/1/2/3 は内蔵プルアップを有効にしているので、外付け部品は不要です。 プルアップ抵抗とプルダウン抵抗は 10K〜47KΩ を接続します。今回は接続相手側もプルアップしている事を想定して若干高めの抵抗値を選択しました。このあたりは手持ちの抵抗値で置き換えても大丈夫です。 通信ラインに直列に接続している 51Ω はおまじないです。無くても動作します。 今回の回路では PICkit? によるオンボード書き込みには対応していません。ご注意下さい。 書き込み手法はこちらに … 書き込みテスト この回路で受信モニタのみ（送信無し）、47KΩ抵抗値の場合ですが、消費電力は約 4mA でした。 内蔵クロック 32MHz 駆動なので若干消費電力が高いです。それでもLEDを1個点灯させるよりは低いです。 なお注意事項は再度確認していただけると幸いです。 |
| 2011/02/28 |
| ▲ |
| 基板に対する部品の配置例です。画面をクリックすると大きなサイズで表示します。 |
 |
| 黒い太線は裏面（配線面）、赤い太線は表面（部品面）です。配線には 0.5mm 錫メッキ線を利用しました。 今回は大丈夫でしたが、赤い太線はLCDモジュールとの干渉に注意して下さい。 基板の左側にスペースがあり、妙な配線が伸びていますが…。 このスペースにはRS232C通信ドライバを載せることを想定しました。狭いようですがピタリと実装できます。 今回は需要がなさそうなので、通信ドライバ無しの構成のみ公開します。見たい人、いるかな？ スペースと言えば、横18縦10 にもあります。ここにショートピンを付けて RA3 を接続(ry 将来的なスペースです。 ちなみに、今回使用した片面ユニバーサル基板はこちら → 秋月電子通商さん、P-03250 配置例では座標数値を記載しましたが、基板には座標表記がないので位置の間違いに注意して下さい。 |
| 2011/02/28 |
| ▲ |
| 以下は実装例です。 表示文字列は…。お決まりのメッセージです（笑 |
 |
| コネクタからのケーブル長は 10cm 程度です。マイコン直結の信号なので長いケーブルはお薦めできません。 コネクタ本体の実装は任意です。ケーブル直付けでも問題有りません。このあたりは臨機応変にどうぞ。 実装上の注意点： 前述のケースに収納する場合、LCDモジュールはオスコネクタのみで直付けとして下さい。メスコネクタを付けるとケースに干渉します。なお、新型のケースの場合は高さが若干増えたので、メスコネクタを利用できるかもしれません。このあたりは現物あわせになります。 ケースへの基板取り付けは厚さ2mm程度のゴム足を利用しました。ケース外側はネジもなくスッキリです。 LCDモジュールはバックライト無しです。バックライト有りの場合は高さと消費電力に注意して下さい。 |
| 2011/02/28 |
| ▲ |
| （１）ダウンロード サンプルプログラムを公開します → UartMon0100.zip 開発環境は MPLAB IDE V8.63 と HI-TECH C V9.81 を利用しています。 注意事項 HI-TECH C v9.70 で作成されたプログラムを v9.81 以降のコンパイラで再コンパイルする際の注意点 → 開発環境による修正 2011/03/09 利用しているメモリ容量は、ROM:1462/2048word(71.4%)、RAM:77/128byte(60.2%) です。 総てC言語で記述したかったのですが、処理速度の関係で一部、インラインアセンブラを採用しています。 インラインアセンブラ…。たいしたことやってないです。分岐の無い、似た様な命令の繰り返しです（汗 |
| （２）ファイル 同梱されるソースファイルは以下の通りです。 |
| ファイル名 | 説明 | |
| _AtrDef.h, _AtrMpu.h | 標準シンボル（参考ページ）、変更は適宜 | |
| DrvCom.c, DrvCom.h, DrvCom.u | シリアル通信ドライバ（参考ページ）、変更箇所はユーザファイルのみ | |
| DrvLcd.c, DrvLcd.h, DrvLcd..u | LCD表示ドライバ、変更箇所はユーザファイルのみ | |
| version.h | バージョン番号 | |
| device.c, device.h | デバイス依存部制御ファイル | |
| main.c, main.h | メイン処理（LCDサイズを除きデバイス非依存）、割り込み処理 | |
| _debug.h | デバッグ用途（実体は未添付） |
| （３）装置の設定 装置は電源オン時にショートピンの状態を読み取り、通信速度を設定します。 起動画面表示後、受信したデータを随時表示します。 設定可能な目標通信速度は以下の通りです。誤差は源発振が 32MHz で動作している場合の数値です。 PIC16F1823 内蔵クロックそのものに誤差（温度や出荷時調整のばらつき）が存在することに注意して下さい。 |
| ShortPin C（左） | ShortPin B（中） | ShortPin A（右） | 目標通信速度 | 誤差 | |
| Open | Open | Open | 230400bps | - 0.79% | |
| Open | Open | Short | 115200bps | + 0.64% | |
| Open | Short | Open | 57600bps | - 0.08% | |
| Open | Short | Short | 38400bps | + 0.16% | |
| Short | Open | Open | 19200bps | - 0.08% | |
| Short | Open | Short | 9600bps | + 0.04% | |
| Short | Short | Open | 4800bps | - 0.02% | |
| Short | Short | Short | 2400bps | + 0.01% |
| （４）プログラム構造 プログラム構造を図にすると、こんな感じです（フローチャートは省略）。 |
 |
| メイン処理は自動生成されるスタートアップ処理から呼び出され、初期設定、割り込み許可を行います。 タイマ0のオーバーフロー（約8ms）をポーリングし、現在の表示メモリ（VRAM）の内容を４文字分だけ表示します。 一度に４文字相当なので、表示メモリ（VRAM）の内容を総て反映するには８巡しなければなりません（約64ms）。 割り込みはUART受信割り込みだけが許可されています。 割り込み発生で受信データを取得し、その内容を分析して表示メモリ（VRAM）に格納します。 PIC16F1823は内蔵RAMが128byteと少なく、表示メモリ（VRAM）で32byte確保しているので残りわずかです。 将来的な予備を残す為、今回のサンプルプログラムではシリアル通信用の受信バッファは確保していません。 表示メモリの内容が更新されなくても表示を行う…。確かにそうですが、今回は気にしないで下さい（汗 表示メモリ（VRAM）の排他制御が必要な雰囲気ですが、繰り返し表示を行うので制御を省略しています。あくまでもアピールする対象が「人間」なので、新旧の表示データが混在しても最悪64ms後には表示安定します。このあたりは割り切りです。反応速度の遅い液晶モジュールですし。。 反面、反応速度の速い高価なHDディスプレイの制御であれば排他制御は必要です。見た目も目立ちます。。 |
| （５）パフォーマンス 通常動作としてメイン処理と割り込み処理があります。各処理の実行実績は以下の通りです。 処理時間はシミュレーションで算出した値です。 |
| 処理 | 実行場所 | 実行タイミング | 最大処理時間 | |
| 4文字相当の取得と表示 | メイン処理 | 約8ms周期（厳密には8192us） | 429us | |
| 受信データの取得と分析 | 割り込み処理 | 受信割り込み要求発生時 | 27us |
| 最大通信速度 230.4Kbps(43.3us/byte) で連続受信が発生しても、割り込み占有率は 62.4% なので受信オーバーランエラーが発生する事はありません。たまたまですが、割り込み禁止による遅延もありません。 今回、割り込み処理時間が短くて済んだ要因として、 ・源発振が 32MHz である。 ・割り込み処理突入、脱出時のレジスタ待避と復元が自動で行われている。 ・局所的にインラインアセンブラを利用している（それも拡張命令）。 ことが挙げられます。今回はCPU の性能に助けられている感が強いです。 装置の性能が満たされているかを判断する指標としてCPU占有率があります。占有率が高いと処理の追加が困難。占有率が 100% を越えていれば動作が重く、性能が満足していない。などと判断する事ができます。 このCPU占有率は多様な計算手法があります。これについては別項にて計算してみましょう。 参考までに。今回のサンプルプログラムではCPU占有率は多く見積もっても 76% 位です。 |
| （６）高速化のための方策 今回のサンプルプログラムでは一部でインラインアセンブラを利用しました。 インラインアセンブラは劇薬です。開発効率は低下しますが、その効果は絶大です。特に HI-TECH C コンパイラのLite版を利用している場合は非常に効果があります。反面、インラインアセンブラを多用すると移植性が悪くなるのが難点です。仕様変更、プログラムも難しくなります。 今回は仕様への影響を最小に抑え、かつ、効果が見込める場所にインラインアセンブラを適用しました。 ソースプログラムでは、device.c にある DevVrmFeed/DevVrmClear の各関数が該当します。 作業内容はどちらの関数も表示メモリ（VRAM）の大規模（？）編集です。 ・DevVrmFeed … ２行目を１行目に移動し、２行目を空白で満たす改行動作（１行あたり１６文字）。 ・DevVrmClear … １行目、２行目を空白で満たす消去動作。 今回は DrvVrmFeed（移動と設定）について３種類の実験を行いました。 |
| 実験関数名 | 方式 | 処理時間 | プログラム | 備考 | |
| DevVrmFeed_1 | memcpy&memset | 133.250us | 0word | 移植性は高い | |
| DevVrmFeed_2 | 直接参照、Ｃ言語 | 16.875us | +39word | 表示デバイス依存、移植可能 | |
| DevVrmFeed_3 | インラインアセンブラ | 7.875us | -104word | 表示デバイス依存、移植困難 |
| プログラム容量は相対サイズになります。 memcpy&memset 関数は他でも利用するのであればプログラム容量としては有利ですが、いかんせん遅い。 この遅さはコンパイラの性能（Lite版）だけでなく、PICマイコンの宿命かもしれません。 今回利用したインラインアセンブラでは PIC16F1xxx で装備された拡張命令を使っています。結構便利。 速度は約17倍。そして何より 230.4Kbps に耐える処理時間を得ることができました。 実験を簡単にできるので、アセンブラの展開具合を比べてみると結構面白いですよ ^ ^ v そうそう、これらの関数は元々は main.c に配置しましたが、依存性が高いので device.c に移動しました。 |
| （７）その他特記事項 main.c#26 で関数名置き換えをしていますが、気にしないで下さい。複数の機能を盛り込もうとした名残です。 プログラム容量に余裕があるので16進数表示機能を付けるのも良いかもしれません。 今回使用した PIC16F1823 にはラッチレジスタが装備されています。これ便利。 従来、出力ポートのビット操作を行う場合は ReadModifyWrite による操作対象外のビット変化に対応（専用の変数を編集してバイト書き換え）する必要がありましたが、ラッチレジスタを使うと直接ビット操作でも大丈夫です。 |
| 2011/03/01 2011/03/02 パフォーマンス、高速化のための方策を追記 |
| ▲ |
| （１）通信データの構成 今回使用したシリアル通信は、調歩同期式通信でパリティ無しです。通信ライン上は 1byte の構成要素である 8bit のビット列前後にSTARTビット、STOPビットが付与され、都合 10bit 構成になります。 |
 |
通信データの構成例です。 調歩同期式通信、8bits長、パリティ無し STOPビットは通常1bitで構成されますが、マイコンの種類により1/1.5/2bitsを指定できる場合があります。 Idleは無通信区間で最小値は0usです。 |
| 通信ルール上はストップビット直後のスタートビットを許すので、最短受信間隔は 10bit 時間です。 |
| （２）通信時間と割り込み占有率 装置の受信割り込み最大処理時間 27us(32MHz時) を基準に、通信速度と割り込み占有率を表にまとめます。 |
| 通信速度 | ビット時間 | 10bit通信時間 | 割り込み占有率 | |||
| 32MHz動作 | 16MHz動作 | 8MHz動作 | ||||
| 460800bps | 2.17us/bit | 21.70us/10bit | 124.4% | 248.8% | 497.7% | |
| 230400bps | 4.38us/bit | 43.40us/10bit | 62.2% | 124.4% | 248.8% | |
| 115200bps | 8.68us/bit | 86.81us/10bit | 31.1% | 62.2% | 124.4% | |
| 57600bps | 17.36us/bit | 173.61us/10bit | 15.6% | 31.1% | 62.2% | |
| 38400bps | 26.04us/bit | 260.42us/10bit | 10.4% | 20.7% | 41.5% | |
| 19200bps | 52.08us/bit | 520.83us/10bit | 5.2% | 10.4% | 20.7% | |
| 9600bps | 104.17us/bit | 1041.67us/10bit | 2.6% | 5.2% | 10.4% | |
| 4800bps | 208.33us/bit | 2083.33us/10bit | 1.3% | 2.6% | 5.2% | |
| 2400bps | 416.67us/bit | 4166.67us/10bit | 0.6% | 1.3% | 2.6% | |
| 源発振の選択により安全に利用できる通信速度帯域が変化することに注目して下さい。 今回のサンプルプログラムでは 230400bps を実現したいので 32MHz 動作は必須でした。言い換えると、割り込み処理時間が27usよりも小さいのであれば遅い源発振を選択することもできます。 |
| （３）ＵＡＲＴ通信の受信動作の仕組み PIC16F1xxx（他のPICマイコンもほぼ同様） におけるUART通信の仕組みを復習します。 PIC16F1xxx のUART機能には受信用のシフトレジスタの他に、受信データレジスタがあります。 受信データレジスタは2つの FIFO で構成され、読み出し操作を行うと過去のデータから順番に読み出せます。 受信データレジスタの読み出し操作が遅れた場合は FIFO にデータが積み上げられますが、シフトレジスタから受信データレジスタにデータを移動する際、2つある FIFO が未読状態の場合はオーバーランエラーが発生します。 |
 |
| 上図では FIFO #0/#1 と分けていますが、FIFO #0 が最過去のデータが格納されている事を示します。 おおざっぱな絵で恐縮です。厳密なタイミング、動作仕様についてはデータシートを確認願います。 さて、上図の例は一番厳しい状況での通信です。ストップビットの直後にスタートビットが存在します。 いわゆる Idle（バイト間時間）が 0us の状態です。言い換えると、この状態が最悪条件です。 |
| （４）理想的な割り込み処理動作 シリアル通信を利用した装置を作る上で、一番理想的なのは「最短受信間隔未満で処理が完了すること」です。 例えば以下の様な動作が理想的です。 |
 |
| 上図は割り込み発生直後に受信データレジスタを読み出したと仮定しています。このケースでは FIFO は常に空の状態で、オーバーランエラーは発生しません（メイン処理での割り込み禁止区間の考慮は必要）。 割り込み処理時間の後ろに空いた時間帯が存在しますが、この時間帯にメイン処理が実行されます。 |
| （５）割り込み占有率が100%を越える場合の動作 割り込み占有率が 100% を越えるとどうなるでしょうか？ |
 |
| 極端な例ですが、割り込み処理時間が 10bit 通信時間の 2 倍以上ある場合です（割り込み占有率200%以上）。 割り込み処理中に次の受信データが成立すると受信データは FIFO に格納されますが、FIFO からの取り出しが間に合わず、総ての FIFO が未読状態で次の受信データが成立した時にオーバーランエラーが発生します。 上図に限らず、割り込み占有率が100%以上でバイト間時間が 0us、すなわち最悪条件が成立した場合は、数バイト先でオーバーランエラーが発生します。また、この条件下ではメイン処理の実行は不可能です。 仮に「１秒に１バイトしか転送しないシステム」であれば問題はありません。その場合は低速通信で十分です。 |
| （６）割り込み占有率を下げるための方策 割り込み占有率を下げる手段。あるにはありますが、 ・バイト間時間を設ける。 ・通信速度を落とす。 ・受信バッファを設ける。 ・オーバーランエラーが発生しない様な通信相手との間でハンドシェイク手順を設ける。 ・源発振を高速な物に交換する。 でしょうか。実務では１つ、あるいは２つ以上の手法を組み合わせて対応することが多いです。 これらの方策の中から数点、注意事項をピックアップしてみます。 |
| （７）バイト間時間を設ける際の課題 バイト間時間を設ける。これは 1byte、1byte ゆっくり送信しましょう。ってことです。 瞬間瞬間の通信速度は速いのですが、通信速度に見合ったパフォーマンスを得ることはできません。 昨今、TCP/IP ネットワーク速度は 10Mbps から 100Mbps、そして 1Gbps と、どんどん早くなっていますが、その速度に見合ったデータ転送能力を体験することは少ないと思います。瞬間瞬間の通信速度は速いのですが、処理が間に合わず通信ラインは休んでいることが多いのです。これはこれで問題ですよね。 まぁ方策の１つとして否定はしませんが、仕様設定が難しくなる場合があります。ルールを破ったら？等々。 送信する側は全く気にしないのですけどね。むしろ、楽ができる場合が多いです（汗 |
| （８）受信バッファ設置時の注意点 受信バッファを設けることで見かけ上の割り込み処理の負荷を下げることはできますが、注意点が２つ。 ・メモリを多く必要とする。 ・受信バッファオーバーフローが発生する。 このうち、受信バッファオーバーフローについて補足します。 割り込み処理の中で行う作業が少なくなり割り込み占有率を下げることができます。が、注意して下さい。 受信バッファから取り出したデータを処理するまでが本当の作業時間です。 受信バッファのデータはメイン処理で取り出すことが多いと思いますが、のんびり処理を行っていると本来の１バイト処理時間が平気でオーバーします。すると今度は受信バッファオーバーフローが発生してしまいます。受信バッファをアクセスする作業が増えるので、よりいっそう１バイトの処理時間を気にする必要があります。 バッファがあるから言って気を緩めては駄目な例です。特に無手順の場合。 受信バッファを大きくして、通信相手とのハンドシェイク手順があるのであれば全く問題無いのですけどね。 |
| （９）利用可能な通信速度の選定 処理性能により利用可能な通信速度が限定されてしまいます。そのため割り込み処理、メイン処理を含めてトータルなデータ処理時間を検討することが大切です。 しかし、もう１つ大事な根本的な選定基準があります。それは「マイコンが通信速度を実現できるのか？」です。 ハードウェアの部品選定に依存する内容ですが、本件は次回ということで。 追記： 前述の高速化の項で memcpy&memset 方式について触れました。 仮に memcpy&memset 方式を採用した場合の割り込み処理時間は約 153us。になります。これを引用して計算した場合、源発振 32MHz 動作では 57600bps が限界点になります。この時の割り込み占有率は 88% まで上昇するのでメイン処理の動作状況は芳しくなさそうです。 |
| 2011/03/03 |
| ▲ |
| （１）通信速度の実現 今回作成したシリアル通信モニタでは、 |
| ・16bit ボーレートジェネレータの利用 | BRG16 = 1 | ||
| ・高速ボーレートモード | BRGH = 1 | … 効果大、PIC 側の対応に注意 | |
| ・高速な源発振 | 32MHz | … 効果大 |
| を利用する事で広範囲の通信速度に少ない誤差を実現しています。採用した PIC16F1823 では機能が備わっているので設定を実現できましたが、既存の PIC マイコンでは必要条件が足りなくて、広範囲、少ない誤差で通信できるとは限りません。特に230400bpsの実現（目標速度）は厳しいと思います。 |
| 目標速度 | 設定値 | 実効速度 | 誤差 | 備考 | |
| 230400bps | 34 | 228571.429bps | -0.79% | 通信速度計算早見表 pic_uart_speed.zip Excel2007を利用した自動計算です |
|
| 115200bps | 68 | 115942.029bps | 0.64% | ||
| 57600bps | 138 | 57553.957bps | -0.08% | ||
| 38400bps | 207 | 38461.538bps | 0.16% | ||
| 19200bps | 416 | 19184.652bps | -0.08% | ||
| 9600bps | 832 | 9603.842bps | 0.04% | ||
| 4800bps | 1666 | 4799.040bps | -0.02% | ||
| 2400bps | 3332 | 2400.240bps | 0.01% |
| 今回のプログラムでは シリアル通信用の汎用ライブラリ を利用しているので、上位プログラムはユーザ定義ファイルを修正（源発振を示す _XTAL_FREQ を定義、もしくは引用）するだけで誤差の少ない設定値を自動的に引用します。 |
| （２）誤差の許容範囲 シリアル通信の通信方式の中でも調歩同期式通信（非同期通信）は、双方の通信機器で 1 ビット時間の解釈が合致していないと通信できません。多少の誤差は許容されますが、その範囲は ±2% 以内に収める事を勧めます。 強引ですが、誤差 ±7% でも通信できる可能性はあります。が、この場合はフレーミングエラーが多発すると思います。本来の通信エラーと許容した故に発生したエラーの区別が付かなくなるので、この運用方法はお薦めできません。 マイコンのデータシートで ±5% の記述を見かけますが、これは相手装置が目標通信速度に対して誤差が少ない場合を想定しています。 双方の装置が誤差を含む通信速度を適用した場合、例えば一方が -2%、他方が +2% であれば、結果としての相対誤差は 4% になります。同様な解釈で一方が -5%。他方が +5% であれば 10% の相対誤差になります。 双方の装置で目標通信速度に対する誤差が +2% であれば…。これは偶然にも相対誤差は 0% です。 目標通信速度の誤差を少なくする方策としては、 ・源発振を変える（理想は精度の高い水晶発振子 参考ページ：発振子の精度） ・源発振からの分周単位を小さくする（前述の BRG16/BRGH を利用）、高速度の源発振を利用する。 ・内蔵クロックの場合は源発振の微調整（OSCTUNE を利用 参考ページ：内蔵クロックの選択と調整） でしょうか。 参考までに。 9600bps を誤差 ±0% で実現するのであれば、源発振に 11.0592/12.288/14.7456MHz あたりを選択することになりますが、各種通信速度に対応できるとは限りません。また、端数のある源発振を利用する事でタイマによる時間監視が甘くなる場合があります。 |
| 2011/03/18 |
| ▲ |
■少々お待ち下さい
| なんだかんだ… |
| 2011/0?/?? |
| ▲ |
■思案中
占有率試算 |
| ▲ |