いぐなっちさん＞
いえいえ、ありがとうございます！
個体差ではなかったんですね（ホッ

どちらかというと、I/Oが足りなくなりそだなという不安があります。
I2Cの部分もFAST対応のI/Oになってくれるのかな？と調べようかと思ってましたが、余力なく、現状I/Oも足りてるから、と棚上げにしてしまってます。

I2Cの通信速度は、サイプレスのIOエキスパンダの仕様の影響で、100kHzに制限されるそうです。
Intelフォーラム(キャッシュ)

いぐなっちさん＞
回路図を見て理解しました。
A4/A5に出ているI2Cは、ボード上のエキスパンダーの制御にも使われているんですね！
勘違いだったらすみません。

CPU側で、他のマイコンでいうマルチファンクションピンのような設定があれば、高速ポートとして使えるかと思っていました。
エキスパンダを使用している以上、そもそもI2C機能を眠らせることはできないということですね。
あとは、SPI1・UART1のポートでそれができるかどうかですが、カーネルレベルの話になりそうなので、今は深追いしないでおきます。

なお、先日アップした時計もどきで、ローアクティブのパルス発生器として、UART1をそのまま使用しています（内緒と言っていた部分です。雑談板に載せた動画も同様）。
0xFFを送信することで、スタートビット1bit分をローアクティブ信号代わりにしています。
とても素人的な発想ですみません。Linux側をいじるとか、H/Wで工夫するという発想がないもので．．．。
ノンブロッキングっぽかったのですが、上手くタイミングが合わず（ジラジラ表示になる）、delay(0)のお呪い（おまじない）を入れています。

Quark SoC の I2C は、MiniPCIE(3.3V, SMBus用)と、
IOREFにレベル変換されたあと、CYPRESS のポートエクスパンダーと Arduino Pin layout へ送られてます。
SoCとしてはSMBus用に用意しているのでしょうが、ポートエクスパンダーと Arduino I2Cで間借りした感じですね。

ADコンバータは速度の速いSPI0, D10-D13をSPI1に、OSレイヤがある以上GPIOは遅くても無問題っていう設計でしょう。

SPI1 については Arduino IDEで使えるのは default 4MHz, max 8MHz ということなんで、
SPIライブラリで普通に使うのがよさそうです。

はにゃさん＞
なるほど、やはり相乗りでしたか？
I2Cは、何気に要ですね！
これから先、PCIeも使う予定なので、やはりI2Cはキーポイントなんですね。

とりあえず、今やってることは、ポート数が足りてるので、ポート割付の障害はクリアしたと思います。

此方の、カラー漢字LCDシールドですが、

Arduino UNO R3+Arduino IDE 1.0.5では正常に動作しますが、Galileo+Arduino IDE 1.5.3では、全く動作しません。(;´･ω･)

シールド作者のページで確認したのですが、
「現在の Arduino IDE 1.5.3 の Wire ライブラリのバグにより、全然、動作しません。 Wire ライブラリのバグが解消された時に対応を講じる予定です。」
とありダメのようです。

バグの内容

カラー漢字LCDシールド

むむ、動かないなんて・・・残念＞＜

Wire クラスのバグですが、
I2C Repeated Start
endTransmission(false) の不具合と、返り値の不具合ってところでしょうか？

試したセンサーのどれかで Repeated Start のせいかうまく行かないから、
I2C.h を使ったというサンプルがあったのですが、その後 Wire でもちゃんと動いた記憶があります。

どのセンサーで、どのページの記事だったのかあとで調べてみます。

みなさんこんちわ。
Galileoで躓いたのでコミュ参加してみました。

［ファイル］メニュー内の［スケッチの例］－［Ethernet］－［UDPSendReceiveString]
ですが、Udp.remoteIP()、Udp.remotePort()の値が正常に引けません。

Galileo特有の現象かな？って思うのですが・・・

なかなかGalileoは一筋縄ではいきませんね。

いろいろ解析してみた結果・・・

どうやら未実装らしき結果です。

Udp.remoteIP()、Udp.remotePort()共に初期化してるだけで対象データ引きにいってないみたい。
バージョンアップまで待つしかないのかな？