Welcome to the blocks wiki!

Mini-PLCとしてRasPiの様なlinuxベースのものを使った場合に不具合発生。linuxはリアルタイム処理が出来ず、適切なタイミングでデータをschedulerへ送信できない。そうすると、scheduler側の他の割り込み処理の影響でUART受信バッファ溢れとなり、データ欠損が発生。本問題は、LCDのようなアクチュエータ制御時に深刻。

• Linuxを使わない。RTOS, mbedやOSレスなものを使う。
• I2C backplaneを2系統用意する。センサー系とアクチュエータ系。
• PICのclock speedを上げる。

SSP1CON2のSENがenableされてなかったので、clock strechingが無効であった。従い、I2C slave側で時間がかかる処理を行うとI2Cのステートマシン崩れとなり、通信不能となる。

SSP1CON2のSEN(bit 0)を1に設定し clock stretching を有効にしたら、本問題は発生しなくなった。

プルアップ抵抗としてPIC内臓のWPUを使ったところ、バスのケーブル長が長くなるにつれて通信が不安定に。

プルアップ抵抗を可変抵抗(最大5kΩ、2.5kΩに設定）に置き換えたところ安定した。

I2Cの通信距離が80cmを超えたあたりで通信が不安定に。

80cmまではI2C、80cmを超える構成にはCANバスを適用＝＞2017年７～８月に開発する。

システムを激しく揺らしたとき、Scheduler(I2C master)とLCD(I2C slave)間の通信が不能になる。Mini-PLCとScheduler間のUART接続でピンヘッダ・ピンソケットを使った接続が原因：接触不良が発生。

開発用ボードでは対策不要。デモ用ボードでは、各種ケーブルを電話線のモジュラープラグ・ジャック(RJ11)や端子台などでケーブルを固定する。

Clock speedを上げる。内部クロック(Frc)を使う。

FOSCを500kHzから32MHzへ上げたらI2Cの送信が出来なくなった。FOSC変更したのにI2Cボーレートを適切なものへ設定していなかった。

I2C Master側のボーレートジェネレータ(SSPxADD)を100kHzや400kHzへ設定する。

FOSCを500kHzから32MHzへ上げたらI2Cの送信が出来なくなった。I2Cのクロックを超えるスピードでI2Cマスターが処理を行ったためデータ送信エラーとなっていた。

ループの中で連続してデータ送信する場合、__delay_us(...)を入れる。