fc2ブログ

773mbar

2024年03月 ≪  123456789101112131415161718192021222324252627282930 ≫ 2024年05月
TOP ≫ CATEGORY ≫ Intel Galileo
CATEGORY ≫ Intel Galileo
≪ 前ページ       

Intel Galileo : もしACアダプターを間違えたら…

Galileoは外部電源必須、しかも5V、これが内径2.1mmのジャック。
対して他のArduinoは同じ内径2.1mmのジャックで7〜12V。
いつか間違えて9Vとか12VとかのACアダプターを接続してしまいそう。
という事で、仮にACアダプターを間違えて(例えば9Vを接続して)しまった場合にどのようなダメージが想定されるか、回路図から確認してみた。

まず意外だったのが、この5V入力を直接使っている部品はそれほど多くない。
まずはUSBホスト端子のVCC端子に流す電流を制限するためのICであるTPS2051BDBVR、これの許容電圧が最大6V。これが破損する可能性はあるだろう。ただ、これが壊れてもUSBホスト端子に電源が供給されなくなるだけでGalileo自体が動作しなくなってしまうわけではない。

もうひとつがDC-DCコンバーターであるTPS652510。このICで5Vから内部動作に必用な3.3V、1.5V、1.0Vを作っている。このICの入力は最大16V。つまり9Vや12VのACアダプターを接続してしまったところでこのICが壊れる事は無く正規の電圧を出力してくれる。よってQuarkを含め多くの部品を破損させてしまうような事はなさそうだ。

問題はI/O関連。
IOREFのジャンパーを5V側に接続すると(つまり出荷時状態)、ACアダプターの電源が、I/OエキスパンダーのCY8C9540A、マルチプレクサとして使用しているアナログスイッチのTS5A23159、電圧レベルシフタTXS0108Eに接続される。これらは5V想定なので許容電圧をオーバーし、破損する可能性がある。また、シールドへの電源もACアダプターの電源がそのまま供給されることになる。
対してIOREFのジャンパーが3.3V側であれば、これらのICやシールドへの電源供給はTPS652510によって作られた3.3Vになる。
つまり、もし5V対応のシールドを接続しないのであれば、IOREFのジャンパーを3.3V側に設定しておいたほうが、ACアダプターを間違えて接続した場合のダメージを低く抑えることができるということだ(※)。

さらに念のため、簡単な保護回路を付けてみた。
ACアダプターの入力に6.2Vのツェナーダイオードを接続した。



まぁ、気休めではあるけれど…
ツェナーダイオードの定格は1W、ACアダプターはそれ以上の供給能力があるのでツェナーダイオードは破損するだろうが、ツェナーダイオードの破損モードはショートが多いようなのでそれに期待、ACアダプター出力が過電流になり保護回路が動作する…という期待だ。うまくツェナーダイオードが壊れてショートしてくれればいいが。ちなみに使用しているACアダプターの出力がショートすると保護回路が働く事は確認済み。…つまりショートさせてしまったことがあるという事だ(笑)。

※ちなみに日経Linux 2014年2月号の記事には「通常は、一般的な5VのAVアダプターを利用する設定」「3.3V(に設定した)の状態で5VのACアダプターを接続するとボードが破損します」という記載があるが大きな誤り。このジャンパーはあくまでもシールドの入出力電圧を設定するものであって電源入力を設定するものではなく、ジャンパー設定に関わらず5VのACアダプターを接続する必用がある。ボード内部のDC-DCコンバーターであるTPS652510の入力電圧は最低4.5Vであり、仮に3.3VのACアダプターを接続したら動作しないだろう。
この記事には他に、USBを接続してから電源を接続する(正しくは電源を接続してからUSBを接続する)、シリアル端子の出力レベルは3.3V (正しくはMAX3232の出力であり±5Vを越える)と、機器を壊しかねない危険な間違いがあり注意が必用。
Intel Galileo | Comments(-) | Trackbacks(-)

Galileoのmillis()

Galileoのmillos()関数の値がおかしい。
調べてみたら、こんな実装。
ソースは Java/hardware/arduino/x86/cores/arduino/UtilTime.cpp

unsigned long millis( void )
{
    return micros() / 1000;
}

これでは4294967(2^32/1000)、つまり約1時間11分でループしてしまう。
そこで以下のように書き換え。

unsigned long millis( void )
{
  struct timespec t;
  t.tv_sec = t.tv_nsec = 0;
  clock_gettime(CLOCK_REALTIME, &t);
  return (unsigned long)(t.tv_sec)*1000L + t.tv_nsec / 1000000L ;
}

これで32bitフルにカウントされた値が返るようになる。
ちなみにmicros()はこんな実装。それをちょこっと変更しただけ。

unsigned long micros( void )
{
  struct timespec t;
  t.tv_sec = t.tv_nsec = 0;
  /* Considering the system does not suspend CLOCK_REALTIME is welcome.
     However, if in the future our system suspend, we need to replace
     CLOCK_REALTIME by CLOCK_BOOTTIME and apply the proper patches in 
     the kernel. */ 
  clock_gettime(CLOCK_REALTIME, &t);
  return (unsigned long)(t.tv_sec)*1000000L + t.tv_nsec / 1000L ;
}
Intel Galileo | Comments(-) | Trackbacks(-)

Galileoのシリアル接続

Intel Galileoが国内にも入り始め、様々なBlogでもGalileoに関する情報が増え始めた。
ただ、その中でもLinuxにアクセスする際、シリアル(RS232)ではなくネットワーク経由がほとんど。やはり専用のインターフェースケーブルが現時点にて無いためか、シリアル接続での確認は後回し、という記事が多い。

しかし言おう。シリアル接続は絶対あったほうがいい。

スクリーンショット 2014-01-25

シリアル接続は、いわゆるコンソール。Linuxを使っている人には説明不要だと思うが、起動時の様々な情報や、USB端子に何か接続された時とか、スケッチがアップロードされた時とか、様々な情報が得られる。だから、例えばUSBとか接続しても無反応だった時とか、トラブル要因の確認がやりやすい。
ちなみに上記画面はmicroSDで起動したところ。ネットワーク接続はDHCPだけど、IPアドレスが192.168.0.52であることとか、書き込み済みのスケッチが起動したとか、容易に確認できる。

また、内蔵Flashのアップデートに失敗した時には復旧させるためにはシリアル接続が必須となる。

ただ、厄介なのはインターフェースがRS232という事だろう。今時RS232Cインターフェースを搭載したPCなんてほとんど無いのでUSB経由となる。Arduino等ではシリアル接続と言えばFTDIの6ピン端子がデファクトスタンダードだが、もちろんこの信号をGalileoに直接接続することはできない。RS232Cは負論理だから最低でもインバーターが必用になる。

現実的にはUSB-RS232C端子の変換ケーブルを使い、RS232C端子と3.5mmジャックとの変換ケーブルを自作する事になるだろうか。できるならばやってみることをお勧めする。

Intel Galileo | Comments(-) | Trackbacks(-)