本レビューは開発の進捗によって随時更新していきます。（最終更新2014/05/27）

さて、最近電子工作から離れ気味だったところへやってきました。

インテル　Galileo開発ボードです。

本体表

本体裏

ACアダプタはいろんな国のコンセント形状のアタッチメントが付属しています。

せっかくGalileoにはLANもあることなのでネットワークを有効活用できるといいな・・・

ってことでGalileoでの開発目標は・・・・

・NTPサーバとして使えるようにする。

・Galileo自体の時刻はGPSから自動で時刻あわせを行う。

・ボード自体の時刻表示は、ニキシー管で表示する。

・どうせならCADで書いた基盤を業者でプリント基板にしてもらう。

この４つを目標として開発していきたいと思います。

なお、レビューの最終期限は6/1迄の予定です。

う～ん・・・

Galileoだと１００％オーバースペックなGPS時計＆NTPサーバになってしまいますが、まぁいいでしょう。

というかニキシー管時計作りかけでおきっぱだったのでそのてこ入れと、今までなかなか手出しできなかったCADとプリント基板製造依頼をしたかったのでそこがメインになる予感です。

まずは開発に必要なIDEおダウンロードするのですが・・・

やはり注意は電源いれる前にUSBつないじゃダメってこと。

いつか間違えてやっちゃいそうな気がしますが・・・

あと、基板実装ヒューズですが・・・

これリセッタブルじゃないんですね。

付属の冊子にもこのヒューズのくだりが書いてますが、これ設計上なんでリセッタブルにしなかったんでしょうね？

それでは早速環境のインストールです。

これはインテルのサイトからダウンロードしてきます。

私の開発環境はWindows7 64Bitなので上図のものをダウンロードして解凍します。

その次はGalileoを認識させるべくドライバのインストールです。

Gadget Serial　v2.4がGalileoです。

Intel製品なのであっさり認識してくれるかと期待してたのですが仕方ありませんね。

それではドライバの手動インストールです。

ドライバは解凍したフォルダにDriversとあったのでそこにあるかとおもってドライバの検索先をそこにしてたのですが、そこではDriverを認識してくれずちょっとハマりました。

ドライバの検索先は先のダウンロードしたフォルダから検索をかけます。

これであっさりGalileoを認識してくれます。

認識したらまずはFirmWareの更新です。

開発ツールを起動して、Galileoの接続先を指定します。

これはデバイスマネージャをみれば確認できます。
私の環境ではCOM9ですね。

続いてFirmWareの更新はヘルプから行います。

実行中は電源を切ったり、USBケーブルを外したりしないようにします。
本当に壊れかねません。

この作業には数分かかります。
気長に待ちましょう。

さて、それでは実際に使ってみるのですが、Galileoは内部でLinuxが動いています。

コンソールが使えると色々内部の状態も見えるので是非シリアル接続できるようにしておきたいですね。

私は100円ショップのイヤホンを分解し、接続しました。

そして、スケッチでコンソール画面に出力するprintfの実行実験です。

printf　test

sample　programと表示されました。

これでデバッグもやりやすくなりましたね。

さて、Galieloは内部でLinuxが動いているのですが、このLinuxは機能が少ないのと、転送したスケッチが電源を切るたびに消えてしまうという問題があります。

簡単な試験ではこれでもいいのですが、運用となるとそうもいきませんね。

ということで、microSDからLinuxを起動してやるようにします。

インテル® Galileo ソフトウェア・パッケージからLINUX_IMAGE_FOR_SD_Intel_Galileo_v0.7.5.7zをダウンロードします。

ここでダウンロードしたファイルを解凍し、FAT32でフォーマットしたmicroSDに書き込むだけです。

書き込みには特に特別な処理は必要ありません。普通にコピペでいいようです。

これだけでmicroSDからブートするGalileoの完成です。

色々保存もできるし、Linuxの各種機能も豊富に使えるようになったのはありがたいですね。

ただし、内臓のLinuxよりは当然起動がおそくなりますが・・・ 

実際ここまで触ってきて特段難しいと感じるところはありませんでした。

特別な開発機器が必要なわけでもなく、Galileo単体で試験も行えることからちょっとした開発やセンサーやモジュールの試験には最適かもしれません。

というか私はこれからセンサーやモジュールの試験用に重宝しそうな気がしてなりません。

さて、GPS衛星には原子時計という超高精度な時計が積まれています。

そしてその時刻データが信号として送られているのです。

GPS衛星に搭載されている原子時計の精度は不明ですが、原子時計は精度が低いものでも3000年に1秒程度の誤差、高精度のものになると3000万年に1秒程度の誤差というものです。

私たちが日常で使う分にはどちらにしても超高精度であることにはかわりありません。

さて、今回はGPS信号を受信するモジュールとして

秋月電子で購入したこのモジュールを使います。

受信した信号を1秒おきにRS-232CもしくはTTLレベルのシリアルデータとして出力してくれます。

ただしGPSの時計はうるう秒を計算していないそうです。

そのため実時刻より現在16秒進んでいるそうなのでソフト側でうるう秒の計算は必要になります。

それでは実際のデータを見てみます。

 $GPRMC,020316.000,V, 000.00000,N,00000.00000,E,0.0,0.0,120414,,,N*62

この出力で時刻取得ができそうです。

020316.000がUTC　timeのhhmmss.ssです。

なのでUTCでの02：03：16.000。つまり日本時間では+9:00の11:03:16ということですね。

120414はUTC　dateでddmmyyです。

つまり2014/04/12です。

実際の時計と比較してもその日時、時刻ですので間違いなさそうです。

ということはスケッチ上で＄GPRMCの行から,（カンマ）区切りで必要箇所を抽出してやればよさそうですね。

その処理のスケッチを書き込んでみましょう。

まずは、GPSモジュールとGalileoをどうつなぐか・・・です。

右下、Digitalの１，２番がUART0でシリアル通信できそうです。

こことGPSモジュールを接続することにしましょう。

それでは早速TTLレベルでつないでLinuxコンソールからデータが読めるか見てみます。

UART0は/dev/ttyS0として認識しています。

GPSモジュールのデータが流れてきてます。

ということはスケッチの流れとしては/dev/ttyS0のデータを取り込んで、$GPRMCのデータを読み込んで必要箇所のデータを切り取り、各時刻処理に渡すというのがよさそうです。

 ここでちょっと躓いた点・・・

スケッチでシリアルの読み書きをしたのにUART0、UART1共に出力されない・・・

なんで？って思ったら、USBのポートに吐き出してやがった・・・

シリアルのポートを変更する行を追加しないといけなさそうですね。

どうやらスケッチ上でSerialではなくSerial1と指定すればUART0のデータを読み込むことができそうです。

また、Galileoは”string.h”をincludeすることでC言語と同じような文字列操作ができます。

なので今回はstring.hを読み込ませて文字列操作をしています。

それではSerial1を指定して、さらに時間を読み取るべく $GPRMCの行のみを抽出させて見ます。

何気に普通に表示されました。

続いて必要項目を抜き出してRTCに渡します。

$GPRMCの後に処理をしてdateコマンドの実行をさせています。

衛星捕捉させていないので2014/04/12　10：48：39とかになっていますが、GPRMCの時刻とRTCの時刻は一致させることができました。

ただ、UTCなので9時間進めないといけませんが、システム上JSTにするのではなく、ニキシー管に表示する前に補正するようにしましょう。 

さて、このGalileoにはLANポートがついてます。

そして先の検証でGPSモジュールからGPSの時刻取得も成功しました。

なら、せっかくなのでNTPサーバーとして我が家の時刻同期にも活用できるようにしたいと思います。

まずはNTPについて調べてみます。

はじめにNTPの階層です。

NTPは原子時計やGPSなどがStratum0とし、それ以下がStratum1、Stratum2と階層を下っていきます。

今回のGalileoはGPSの信号を受信するのでStratum1になりますね。

外部に公開するわけではないにしても、しっかりと作りこんで正確な時刻配信できるようにしたいですね。

なお、自分のクロック制度などにより数十万分の一程度の誤差が出ているはずで、その誤差（ドリフト）の修正は 本来修正すべきですが、今回はひとまずNTP機能を搭載することを優先するため、後々の実装を目指すという方向ですすめます。

では、NTPはどのようなパケットを送っているのでしょう？

結構簡単なパケットですね。

それではそれぞれの中身をみてみます。

［ＬＩ］は閏秒の有無

［ＶＮ］はプロトコルバージョン

［Ｍｏｄｅ］は動作モード

［Ｓｔｒａｔｕｍ］は階層

［Ｐｏｌｌ］はマルチキャスト時の送信間隔（２のべき乗）

［Precision］は精度を表す数値

［Root Delay］は最上位のＮＴＰサーバまでの往復遅延の合計

［Root Dispersion］は最上位ＮＴｐサーバとのゆらぎ（相対誤差)

［Reference Identifier］は参照識別子で時刻ソース源（ＧＰＳなど）のＡＳＣＩＩ文字もしくは参照元ＩＰアドレスがはいる。（左詰で後ろは０)

以降時刻が入るわけですが、時刻は1900/1/1 0:00:00からの積算秒となってます。

64bitのタイムスタンプは前半32bitが整数、後半32bitが少数になります。

というわけで早速ＮＴＰパケットの作成からはいります。

パラメータは以下の値で埋めます。

LI=0or3(00　or　11)

VN＝クライアントからの受信パケットからコピー

Mode＝４（１００）

Stratum=1（０００００００１）

Poll=0（００００００００）

Precision＝-17（１１１０１１１１） 　※実際に精度計算してませんので仮値として

Root Delay＝0（00000000000000000000000000000000)

Root Dispersion＝０（00000000000000000000000000000000)

Reference Identifier＝GPS（01000111010100000101001100000000）

Reference Timestamp＝GPSのデータを受信した最終時刻

Originate Timestamp＝クライアントからのコピー

Receive Timestamp＝クライアントからのパケット受信時間

Transmit Timestamp＝クライアントへのパケット送信時間

ほとんど固定値なので楽ですね。

それではスケッチを組んでいきましょう。

まずはUDPパケットの送受信というところから始まるのですが・・・

いきなり頓挫しちゃました。

サンプルソースを走らせ、192.168.1.101の端末から”Galileo UDP Test”という文字データのみのUDPパケットを送信

送信元IPが255.255.255.255、送信元ポート番号が0。

ただし、データはきちんと届いているようです。

さて、困りました。

IPアドレスはどうにかなるかもしれませんが、送信元のポート番号が取得できなければデータが返せません。

Galileoで同じような現象が起きているという情報はゲットできましたが解決策はネット上を探しても今のところ見つかっていません。

まさかGalileo特有の現象なのかな？

他のArduino＋Ethernetシールドを入手して検証したいところですが、たぶんこれは動くんだろうな・・・・

さて、NTPサーバ機能は実装できるのでしょうか？

色々解析をしているうち送信元IPとポートが正常に引けない原因が解明。

どうやらIntel　Galileo用のEthernetUDP.h、EthernetUDP.cppにremoteIP()、remotePort()の初期化はしているようですが、UDPヘッダーからremoteIPとremotePortを抜きだす部分が抜け落ちているようです。（Arduino版1.5.6-r2には有)

受信パケットを解析しようにもsocket FDにはUDPヘッダーが抜けた状態で格納されているようです。

Arduino1.5.6-r2版のソースを移植しようにも色々なファイルを参照しているようで、ちょっと難しそうです。

こうなるとちょっとNTP機能の搭載はGalileo用IDEのバージョンアップを待つしかなさそうですのでこの機能に関しては保留することにします。

はにゃさんよりremoteIP（）とremotePort（）が動くようにHackしていただけました。

はにゃさん版EthernetUDP.cppを使うことで

 見事に送信元IPとポートが引けるようになりました。

ということでこれからNTPサーバ機能の実装を進めていきます。

最初NTPは1900/1/1からの積算秒、LINUXは19701/1からの積算秒で時刻エラーって出てあせりました。 

しかし、なんとかNTPの実装までこぎつけることができました。

が・・・負荷がかかるのか熱によるものか一度NTPパケットを送信するとスケッチが応答しなくなります。

しばらく放置してリセットさせるとまた動き出すのでNTP運用の場合はヒートシンクも必要になりそうですね。

 実際のスケッチは今試験用のコードが多く混ざってるので後日きれいにまとめてからの更改とします。

基盤設計にはP板.comで無料配信されているCadlusサーキット、Cadlus Xを使用します。

これを利用する理由は・・・・

・無料（これが一番大きい）

・部品データ、シンボルをタダで作ってくれる（作業効率UP)

この二つが大きな理由です。

他にもEagleも候補に挙がったのですが、基盤サイズに制限があるので却下しました。

というのもニキシー管をならべるとどうしても制限サイズギリギリかちょいオーバーしそうだったので・・・

ということで今回はメーカーにDCDCコンバーター制御IC

ＮＪＭ２３６０ＡＤ

それとニキシー管

これらのシンボル等データを作ってもらいました。

そして早速設計開始。

まずはCadlusサーキットで回路図を作ります。

まずはDCDC回路部分です。

ACアダプタから入力される１２Vを昇圧して１７０Vを作るところと、降圧で５Vを作る回路です。

といってもほとんど評価回路図のまんまです。全体が書けてきたらもう少し手直ししないといけませんね。

ひとまず電源部分とコネクタ周りの回路図完成しました。

後々PICでも動かせるようにPICまわりも強引に乗せたので一部回路図が見難いぐちゃぐちゃ状態ですね。

ソフトを使っての回路図なんて初めて書いたけどこれで動くのか！？

続いてドライブ回路との回路図も描いていきます。 

こちらはダイナミック点灯させるだけの回路なので単純な回路ですね。

ただ、ニキシー管が6本もあるので、線だけは多いですが・・・

基盤発注してから間違えに気づくとえらい目にあうので、よーくチェックしないといけませんね。

回路図が書けたので次は部品やデータ線の配置をしていきます。

慣れない作業で時間がかかりましたが、1枚目の部品配置、結線などのCADでの作図完了です。

部品や結線のレイアウトにセンスが無いというのは勘弁してください。 

そのうち上手くなると信じましょう。

 続いてニキシー管がのる2枚目の制作をすすめます。

なんとか2枚目のレイアウトも完了しました。

う～ん・・・線が多い。

配線ミスがないか要チェックですね。

もう１，２日十分にチェックしてから基板発注を出すとしましょう。
ちなみにこれらの基板は設計を間違っていなければ重ねて利用できるはずです。（ｗ

Cadlus Xはガーバーデータ出力できませんので基盤製作依頼先は必然的にP板.comになります。

このP板.comは国内の他同業者より安く、品質もよいとのこと。

さらに当然日本語でやり取りできるというのがいいですね。

それでは早速発注してみましょう。

発注は会員登録後、ログインしてから行います。

今回は２枚の基板を面付け（２枚の基板を１枚にして、後から切り取る）しています。

発注枚数が少ないのでどうしても割高になってしまいますが、今回はそれを見越しての発注なのでそのままいっちゃいます。

発注に必要なものは基板データと面付けレイアウトだけのはず。

なので、jpgでの面付けレイアウトとCADLUS　Xのデータを一緒に送って発注します。

見積もりの結果、製造枚数が５シートまで料金が同じだったので５シートの発注をかけます。

現在発注品到着予定は”2014/05/16(金)”となってます。

さて、仕上がりが楽しみですね～

発注から1週間（営業日5日）の2014/05/16に届きました。

自分で設計した基板が形になって届くとちょっとした感動です。

基板表

基板裏

さすがにきれいな仕上がりです。
自分で感光基板でつくると2層なんてめんどくて作れません。（ｗ

ただ、すでに数箇所の間違いを発見。
致命的なミスではないので修正可能ですが、配布するなら考えないといけませんね。

個人の試作用としては高価になりがちですが、配布してある程度製造費を回収できるならこういった業者をこれからもっと利用していきたいですね。 

 それでは届いた基板で早速部品やニキシー管を搭載していきましょう。

本来なら背の低い部品から取り付けていくのですが、今回は各ブロックごとに正常に動作しているか確認したいのでまずは約１７０V昇圧回路の作成です。

手持ちの抵抗が一部足りなかったので意味も無くキンピ抵抗が混ざってます。

ここはチョッパ式昇圧回路で

出力電圧＝１００ｋ÷７６０×1.25＋1.25
となり理論的な値としては約１６６Vくらいのところ１６７．２Vで安定していました。

十分誤差範囲内ですので正常に動作しています。

次に５V降圧部分を作成します。

こちらも特に問題なく５．０２Vと設計どおりの値を出力してます。

ただ、ブレッドボード時には気が付かなかったのですが、わずかに鳴きが発生しています。
といってもよーく聞くと鳴ってるのがわかる程度であまり気になるものではないですね。
まぁDCDC回路なので高周波によるコイル鳴きの可能性が大きいですね。
ここはコイルを交換するか発信用コンデンサを交換すれば落ち着くでしょうが今回はデータシート上の推奨値を利用します。

この基板の残りの部分（コネクタ部を除く）はGalileoでなくPIC単体もしくは連動動作させることを目的に追加している部分ですので、Galileo単体で動作させる場合は必要ありません。

ただ、そこで2箇所、タクトスイッチのGNDラインの間違え、PIC用RTCのバックアップ用スーパーキャパシタの穴のサイズを間違ってました。

まぁここはGNDラインをカットしてジャンパでつなぐのと スーパーキャパシタの足をリード線でつなぎかえることで修正可能です。

次にニキシー管搭載基板です。

とりあえず試験なのでニキシー管1本だけ搭載です。
ちなみにニキシー管の下についている黒いプラスチック製のものは足を伸ばす治具らしいのですが、基板搭載に足が隠れてちょうどいいのでそのままつけちゃいました（ｗ

74138と

K1551ID1はICソケットに挿します。

動作試験時は入力PINの一部をオープンにしてしまって期待どおりの動作をせずに一瞬冷や汗をかきましたが、きちんとつないだときは正常に動作していたので大丈夫でしょう。

さて、あとは上下基板を接続するのですが、私のミスでコネクタのストックが切れており急いで発注したため今はここまでです。

明日には届く予定ですので続きは明日以降かな？

合わせてGalileoのスケッチも仕上げないといけませんね。

さて、コネクタ部品も届いたので一気にくみ上げましたが・・・

何かおかしい・・・

３と６が点灯しないうえ、０から９まで順番に点灯させたつもりでも、点く数字がバラバラ・・・

よーく基板とデータシートをみていると・・・

ピンアサイン左右逆でした。

大体のデータシートはトップビューですのでそのつもりで配線しちゃいましたが、今回使うニキシー管はボトムビューだったんですね。

なので結構な数の修正を施します。

とりあえずあとはスケッチ側の修正でどうにかなりそうですので今回はこれで進めます。

早速データは修正しておくので追加で製造してもらうことになったらこんなことにはならないはずです。

さて、それでは組んでみます。

まずは点灯試験の写真です。

横にGalileoがあります。

すべてのニキシー管ですべての数字が点灯しましたので時刻の表示をダイナミック点灯させてみます。

２２：０３：２６にシャッタースピードを遅くして撮影したものですが・・・

やはりゴーストと呼ばれる別の数字が表示されちゃってますね。

前々から情報が出てたIOポートの速度によるものでしょう。

見えなくはありませんが綺麗ではありません。

ここは改善の必要がありそうですが今回の場合、全部で7本のピンが必要です。
しかし、ニキシー管の表示は元々数字切り替えが遅いのでニキシー管の切り替え部分だけでも高速化できれば違ってくるかもしれません。

ここでちょっとこのゴーストについて考察してみます。

このドライブ回路では74HC138の3-8デコーダと呼ばれるものを利用しています。

74HC138はA、B、Cと呼ばれる３つのポートのどれがHIGH（５V）でどれがLOW(GND)でどのポートをLOW（GND)にするか決定しています。

今回の回路はLOWになった出力ポート(上記Yn）に対応したニキシー管が点灯する仕組みになってます。

今回のGalileoはA->B->Cの順で設定しています。

なので、例えばC:０　B:１　A:１（３）の点灯状態からC:１　B:0　C:０（４）の点灯状態へ推移するのを考えてみます。

まずAをセットし、C:0 B:1 A:0（２）、次にBをセットしC:0 B:0 A:0 (0)、最後にCをセットしC:1 B:0 A:0(4)の点灯状態へ移行します。

こういった状態推移でゴーストが発生する要因になります。

次に点灯する数字制御しているのが74141互換ICの

コレを使用しています。

これもA,B,C,DのポートのどれがHight(５V)かによって点灯する数字を決定させています。

やはりここでもポートレジスタが使えないため上記74HC138と同じく、4bit分の出力が完了するまでは他の数字の出力になりかねません。

この二つが要因になって現状はゴーストを発生させているようです。

実際IOの出力が高速であれば問題はないのかもしれませんが、Galileoは標準でIOポートは230hz。
つまり切り替えに約4.3msかかっていることになります。

しかし、２，３番ポートのみ477khz（２uｓ）もしくは683khz(1.4us)まで高速化できます。

とりあえずの対策として74141互換ICのK1551ID1のC,DをHIGHにすれば完全消灯ができます。

２，３番ポートをK1551ID1のC,Dに接続変えして全消灯、点灯の制御をいれてやればゴースト退治できるかも？

色々チューニングして２，３番ポートのport_fastも利用してみました。

だいぶきれいに表示されましたがちらつきがある程度から改善しません。

Galileo単体ではこのあたりが限界なのでしょうか？

とりあえず時刻の表示はできているので、ひとまずこれで構築はおいておいて、レビューを進めていきたいと思います。

しかし、これで完成というのはあまりに 中途半端なので時間をかけて改善していきたいと思います。

さて、ある程度目標としていた機能の実装も完了したので、お披露目をかねてリビングにもって行き運用開始・・・

したんですが、やはりちらついて目障りなんて酷評をいただきました（ｗ

やはりか・・・

でもGalileo単体でこれ以上のちらつき軽減は難しそうです。

となると・・・GPS,NTP部はGalileoに処理してもらい、ニキシー管による表示部はPICに処理してもらうとしましょう。

ということで急いでPICのプログラミングを開始。

といってもポートレジスタのON,OFFとGalileoとの接続部分としてUARTの読み込み部分だけ（ｗ

接続は

ニキシー管（PIC制御）－＞　Galileo　－＞　GPS

となってます。

Galileoで時刻を取得し、PICにその時刻を渡します。

PICは入ってきた時刻を元にダイナミック点灯で表示させてます。

実際の表示がコレです。

若干ちらついているように見えますが、それはカメラによるもので実際はちらつきもなく、きれいに点灯されています。

Galileo単体でちらつくのはやはりIOポートの速度によるものでまちがいなさそうですね。

ただ、今回の機能はすべてPIC単体でもできるのでこのままでいいのか！？

って言われると悩みどころですが、今回はGalileoが中心なのでひとまずここで区切りとします。

Arduino互換ということで開発のしやすさ、とりつきやすさは非常にいいですね。

Arduino系は初めての開発でしたが、言語的にもC言語に近く非常に理解しやすいものでした。

ただ、IOの速度が遅いということやIDEに実装されていない（動かない）関数があったりとまだまだ一癖も二癖もある状態です。

しかし、IO速度を必要としなければ、内部処理も早く、複雑な処理もこなせるのは開発する側としては選択肢が多くていいのではないでしょうか？

実際、Galileoが複雑な処理をする中心部となり、末端はPICやAVRにI2CやUARTで通信して制御するという手法をとればかなり大きなシステムもできるのでは？という可能性は感じることができました。

ただ、まだまだ癖があるのがGalileoです。

これからIDEのバージョンアップももとより、Galileo自体のバージョンアップも進んでGalileo単体で、もっと便利に使えるようになるといいですね。

更新履歴

2014/04/10　　初投稿

2014/04/12　　GPSモジュールの実装を追記 

2014/04/13　　開発準備を追記

2014/04/14　　GPSモジュールの実装を追記

2014/04/16　　GPSモジュールの実装を追記

2014/04/16　　CADによる基板設計を追記

2014/04/16　　GPSモジュールの実装を追記

2014/04/17　　CADによる基板設計を追記

2014/04/20　　ＮＴＰサーバ機能の実装 追記

2014/04/25　　CADによる基板設計を追記

2014/04/26　　ＮＴＰサーバ機能の実装 追記

2014/05/01　　CADによる基板設計を追記

2014/05/07　　プリント基板製造依頼を追記

2014/05/13　　ＮＴＰサーバ機能の実装 追記

2014/05/14　　ＮＴＰサーバ機能の実装 追記

2014/05/19　　構築を追記

2014/05/22　　構築を追記

2014/05/23　　構築を追記

2014/05/26　　運用を追記

2014/05/27　　NTPサーバ機能の実装　追記

2014/05/27　　運用を追記

2014/05/27　　まとめを追記