KLab若手エンジニアの これなぁに?

KLab株式会社の若手エンジニアによる技術ブログです。phpやRubyなどの汎用LLやJavaScript/actionScript等のクライアントサイドの内容、MySQL等のデータベース、その他フレームワークまで幅広く面白い情報を発信します。

2011年07月

Amazon Web Services様、KLab合同勉強会を開催しました

はじめまして、manako-tです。 今年度の新卒として4月から入社し、今月で早4ヶ月目になります。まだまだ半人前ではございますが、よろしくお願いいたします。 先日、と言っても2週間ほど前ではありますが、Amazon Web Services様(以下AWS様と略記させていただきます)を社内にお招きし、合同勉強会を行わせていただきました。 AWS様と言えば、Amazon EC2をはじめとして、まさにこれからのクラウドとはかくあるべし!と言えるようなサービスの数々を提供されている企業様で、私自身、今回の勉強会を大変楽しみにしておりました。 その様子について、レポートさせていただきたく思います。 まず、弊社の方から、三浦、坂本が発表させていただきました。

三浦:パフォーマンスチューニングの裏側 〜インフラ編〜
坂本:パフォーマンスチューニングの裏側 〜アプリ編〜



近年、弊社においてはソーシャルゲーム事業にかなり注力しており、おかげさまで1日の平均PV数が億単位にのぼる案件も飛び出しています。 弊社はかねてよりDSAS Hosting for Socialの運用による負荷分散ノウハウを持ち合わせているものの、ソーシャルプラットフォームやゲームの内容によってユーザ数が大きく異なるのが現状で、ちょっとしたきっかけでユーザ数が急増することも珍しくありません。ちょうどここ数ヶ月にこうした事態に見舞われた現場の担当者2名に、どのように高負荷に対処したかについて、インフラ担当、アプリ担当それぞれの立場から説明してもらいました。 インフラ面でのアプローチとして、NICの割り込みの処理の中で、IRQのバランスをうまくセットすることにより、リクエスト単位でCPU負荷を分散することができ、ネットワークの流量の上限を大きく改善できたという説明がありました。 また、アプリ面でのアプローチとして、主にMySQLの同時コネクション数がボトルネックになることが問題として浮上し、クエリの数そのものの削減や、クエリキャッシュの無効化、MySQLのキャッシュの代替としての、memcachedやPHPのキャッシュ機能(Alternative PHP Cache)の適切な利用の仕方など、非常に具体的な説明がありました。 続いて、AWS様から、エバンジェリストの玉川様、ソリューションアーキテクトの大谷様、荒木様に発表いただきました。

玉川様:AWSでアジャイルなインフラを実現しよう



なんと、その場でAmazon EC2の最上プラン(!)で利用できる、スパコンの仮想サーバーを起動して物理計算を行うという、非常に貴重なデモをしていただきました! EC2には最初からサーバーのコピーイメージが多数用意されており、イメージを選択して起動するだけのたった数分の操作で、すぐにサーバーが使える状態になるそうです。また、基本的に1時間単位での課金なので、負荷分散のために複数のサーバーを利用したい場合、フレキシブルな運用が可能となりそうです。例えば、アクセスが集中するタイミングでサーバーの台数を増やし、使わないときはすぐにシャットダウンして台数を減らしたりと、動的に稼働サーバー数を変えることも簡単にできるわけですね。 実際にこうした運用の仕方を行っている企業もあるそうで、個人的にはこれからのWebサービス運用の主流となっていくのでは、という予感がしました。

大谷様:NoSQL超概説



AWS様のサービスの枠組みにとらわれない観点からNoSQLの概説をしていただき、大変勉強になりました。 Apache Cassandra, HBaseなど、近年オープンソースのソリューションも数多く出現してきているNoSQLですが、AWS様でも、Amazon SimpleDBというサービスを展開されているとのこと。Amazon DynamoというAmazon社内で利用されているKVSが元になっており、その技術概要については、論文も発表されているようです。 CAP定理で言う一貫性(Consistency)は保証されていませんが、DHTに基づき、全ノードがデータの格納場所がわかるような仕組みになっています。また、クエリ同期のリードライトは基本的にメモリ上で行うため、データはすべてメモリ上に持っており、バックアップのために非同期にストレージに書き込む仕組みになっているそうです。 KVSと言うと、KLabではPHPとも親和性の高いTokyoTyrantを利用しているのですが、今後新たなソリューションの検討を求められる時機に遭遇するかもしれません。

荒木様:AWSでインフラのトレーニングをしようぜ



常時稼働サーバーとしては、一般人には多少敷居の高い印象のあるEC2ですが、それならばということで、インフラのトレーニングの場としてのEC2の活用法についてご提案いただきました。私は寡聞にして知らなかったのですが、今現在AWS様のサイトからアカウントを新規登録すると、EC2をはじめとしたさまざまなサービスを、期間限定で無料で利用できる枠があるそうです(!) 詳しく知りたい方は、こちらをご覧ください。 gmakeを使った並列コンパイル、分散FSのテストなど、仮想サーバーだからこそできる利用法も色々あるようです。 Heroku、phpfog、PiCloudというPaaSサービスの名前も挙げていただきましたが、これらのサービスの一部はEC2上でホストされているんですね。


私だけでなく、他のKLabエンジニアにとっても、大変密度の濃い2時間になったと思います。 Amazon Web Servicesの皆様、本当にありがとうございました。 今後ともよろしくお願いいたします。

温度測定システム[5] 測定システムに纏わる3つの謎

uchikawa-yです 一応今回が最終回のつもりです。 今回は前回までと趣向を変えてDS2480Bを実際に使うにあたっていろいろぶつかったことや気になったことについて書いていきます。今回は最初に項目をあげておきましょう。
  • DS2480Bのシリアル入出力
  • byte単位のreadコマンド/モードが無い?
  • センサの電源を配線しないでも動いてしまった - 2線使用時の電源の謎 -

DS2480Bのシリアル入出力

なんでデータモードも含めてほとんどのコマンドで1byteの戻り値が帰ってくるのだろう

DS2480Bは1-Wireバスとシリアル(RS-232C TTLレベル)の変換器として動作しますが、シリアル入出力の仕様は以下の通りです。
  • TTLレベル 正/負論理(端子接続で切り替え可能)
  • 9600bps(デフォルト値)~115200bps
  • フロー制御なし
  • 送信バッファなし、受信バッファ1byte

DS2480Bには送信バッファはありませんがシリアル経由でPCなどのホストへ送られたデータはPC側の受信バッファにたまります。このため送られてきたデータは適切に処理するなり読み飛ばす必要があります。そうしておかないと必要なデータをバッファオーバーフローで失ったり、データのずれが起きたりする可能性があります。 ほとんど全てのコマンド、データモードの送信で1byteの戻り値があるのでDS2480Bでは基本的には「1byteの書き込みを行ったら1byte読む」という形に自然になります。最初はこの仕様を奇妙に思ったのですが実はちゃんと意味があった…というお話です。

1-Wireの最大データ転送レートはオーバードライブ(高速)モードで142kbps、標準モードでは実質的16kbps程度です。センサのDS18B20がオーバードライブに対応していないのでここでは標準モードを使用しています。この場合、9600bpsでもシリアル入出力のほうが高速なので、DS2480Bへの送信でデータオーバーフローの可能性があります。受信バッファが1byteしかないのでホスト側では1byteごとにチェックしなければならないわけです。

DS2480Bが受け取った1byte分の処理の完了は、ホスト側のDS2480Bの返す1byteの読み取り完了で検出できる 割合当然といえば当然なのですが、私は一番最初に引っかかってます。「実行例ちゃんと読めよ」ですね。CTS/RTS制御が使える環境でドライバ任せにするプログラムしか書いたことなかったですから…(ぶーぶー)。

データモードの戻り値についてはもう一つ別の大きな意味がありました。 というわけで次の項に続く

DS2480Bにはbyte単位のreadコマンド/モードが無い?

これは…何て言っていいのか、個人的には使うにあたって一番詰まったところだったりしますが… DS18B20は9バイトの読み出し可能なメモリ(Scratchpad)を持っていて、温度測定結果などが収められています。温度測定完了後にこれを読み出したいのですが、データモードでセンサに対してRead Scratchpadコマンドを送って待っていても9バイトのデータを受け取ることはできません。
  • シリアルポートに対してソフトウェア的にreadを行っても対向のポートには「read待ちの状態である」というような情報は伝わらない
  • 1-Wireではマスタ側がReadスロットを開始しないとスレーブ側はデータを送信しない
ということがあって、シリアルポートの向こう側から待っているだけではデータは出てこないのです。1bit単位のreadコマンドはコマンドモードで用意されているのですが、これを繰り返し使うのはいかにも無駄です。 ではどうすればいいのかというと……これも「データシートの実行例読めよ」が結論なのですが。 結論:byte単位でデータを読むにはデータモードでffh(全bit1の1byte)を送信して戻り値を読む。読み出した1バイトがスレーブの送ったデータである。 1-Wireの仕様をちゃんと理解した上で、DS2480Bのデータモード時の戻り値が1-Wireバス上の波形を反映したものである、という内容を考えれば想像つかないものでもないですが、この行間を読むのはちょっと厳しいです(実行例に書かれているので最終的には正解にたどり着けるようになっているとは言えるのかもしれませんが)。 本気でデータシートの本文に書いておいてほしいと思いました。

センサの電源を配線しないでも動いてしまった  - 2線使用時の電源の謎(strong pullupの意味) -

1-Wireは信号線と+電源(Vdd)を時分割して共有する配線も可能で、2線で使用できるようになっています。これはネットワークケーブルや電話線のUTPのうち1ペアが利用可能ならそれを流用した配線もできるようにと考えたものらしいです。 アプリケーションノートにはネットワークケーブルを使う例があげられています。DC等のルール的に問題があるかどうかは別としてラック間配線のためのパッチパネルなどが利用できると楽だったりしませんか? (なお以下の部分には「いくらか」アナログ回路設計の知識が必要な内容が含まれます。まあオームの法則程度なので気楽に読んで下さい) 信号線と+電源を共有するというと特別な方法を使っているような印象を持つかもしれませんが、これは回路的には大したものではなくて概念的にはダイオードとコンデンサを組み合わせた以下のような回路で接続されています。
2線接続の場合の電源


1-Wireの信号線はデータのやり取りを行っているときには短時間0となる場合がありますが、大部分の時間では1(プルアップ抵抗を介して+5Vに接続している状態となっています。
信号線QDが1
QDからダイオード経由で電源が供給される
信号線がQDが0
ダイオードによってQDは切り離され、コンデンサに蓄えられた電荷が(短時間の)電源供給に利用される
もし、1-Wireバス上のスレーブデバイス全体の消費電流が小さい(数μA程度のオーダー)ならばこれはこのまま何もしなくても動作してしまうと考えられます。実際にはそうも行かなくて、DS18B20の場合温度測定を開始したり、設定内容の書き換えを行う場合はデータシート上、最大1mA電流が流れるとあります。 1mA電流が流れるとして、仮にプルアップ抵抗を推奨回路の通り4.7kΩとするとプルアップ抵抗の両端の電圧Vrは、 Vr = I×R = 1×10^(-3)×(4.7×10^3) = 4.7(V) DS18B20のDQの電圧は5-4.7=0.3(V)となり、電源電圧として必要な電圧に達しません。正常に温度測定できないことになります(実際には規格上の電流の最大値まで流れないことも多いようですが)。この問題に対応するため、2線で使う場合はプルアップ抵抗をバイパスできるような回路が必要です。バイパス回路はDS2480Bには内蔵されていてソフトウェアから制御可能になっています。 バイパスした状態をDS2480Bではstrong pullupと呼んでいます。 以下の図はDS2480B経由で1-Wire上にセンサ4個を2線接続して温度変換コマンドを送り、DQ端子の電圧を見たものです。
strong pullupの効果


DS2480Bは単純なプルアップ抵抗を使用しているわけではなく、アクティブプルアップとなっているので多少事情は異なりますが、strong pullupを使用すると電圧の低下が少なくなることがわかります。 ところでDS18B20は電源電圧は最低3Vなのでこの測定結果によればstrong pullupなしでもぎりぎり動作するような気がします。実際に動かしてみると完全に規格外の使い方ですがstrong pullupを行わなくても動作してしまいます。 実は先に2線接続をしてstrong pullupを行わずに測定プログラムを動かしてみたら「あれ?動いちゃった」状態だったので調べてみたのですが、元々動いてもおかしくない状態だったようです。 ただ、調子に乗ってセンサをいくつもつないだりすれば誤動作しやすいでしょう。また、1-Wire上を流れる電流はセンサ全ての合算ですから、全てのセンサで同じタイミングで温度測定を行うと誤動作しやすいということもわかります。

最後に

温度測定システムの紹介ということで5回にわたって書きましたが、なにぶん書き慣れないことなのでどの程度伝わったか不安ではあります。 Perlで書いた測定プログラムは公開してありますし、メーカーのデータシートには十分な情報が含まれていますし、含めるとかなり煩雑になりそうだったので、今回は具体的なコマンド体系・シーケンスについてはあえて書きませんでした。なので具体的なコマンドの解説もあったほうがいい等の感想があったら教えていただけるとありがたいです。 温度センサDS18B20は中々よくできているセンサで使わないのはもったいないと感じています。1-Wireのデバイスは温度センサ以外は品揃えがいまいちなのが残念ですが汎用のA/Dコンバータがあるのでいろいろな場面で選択肢の一つとして考えられるものだと思います。

C2DMアプリ「Chrome to Phone」を改造しました。

こんにちは。maruyama-r(@h13i32maru)です。 最近C2DMというものを知ったんですが、みなさんはC2DMってご存知ですか?C2DMはGoogleが提供しているもので、Androidアプリに外部からデータをプッシュ配信できる仕組みです。 Android Cloud to Device Messaging Framework - Google Projects for Android そのC2DMを使ったアプリでGoogleが開発している「Chrome to Phone」というのがあります。このChrome to Phoneを使うと、AndroidへGoogleChromeからURLを送信できます。URLを受け取ったChrome to PhoneはURLに応じてブラウザやGoogleマップ、YoutubePlayerなどを自動で起動します。


Chrome to Phoneはサーバサイド、Androidアプリ、Chrome Extensionのソースコードが公開されています。今回はC2DMの勉強をかねてChrome to Phoneのソースコードを読んでいくつか改造してみました。
  • URLを複数のAndroid端末に送信できるようにした
  • URLを別のGoogleChromeに送信できるようにした
  • C2DMのサーバからAndroid端末の登録情報を削除できるようにした


ダウンロードはhttp://h13i32maru.jp/chrometophone/からできます。AndroidアプリとGoogle Chromeにそれぞれインストールして試すことができます。 ※僕が個人的に勝手に改造しただけなので、自己責任でご利用ください。 詳しい内容はスライドにまとめたので興味のある方はご覧ください(C2DMについてもまとめています)



弊社KLabでは毎月ALMという誰でも参加できる社内発表会があります。内容は20分の通常枠と5分のLT枠があります。先月のALMでは「勝手に改造Chrome to Phone」を発表しました。ちょうどのそのときのALMはエンジニア祭りということでピザやお酒を飲みながらいつもと違った雰囲気で行われました。そのときの様子はKLab広報ブログに載っています。こういう発表の場は発表の練習、社内交流、モチベーションアップなんかにつながって非常に良い感じです!しかも発表することでちゃんと評価もされます。と、弊社のいいところ宣伝でしたw

温度測定システム[4]DS2480BとROMコード(アドレス情報)検索

uchikawa-yです 今回は前回に引き続く形で、DS2480Bを使う場合のメリットの一つ、1-Wireデバイスのアドレス検索(ROMコードの検索)について書きます。 DS2480B(現在は鉛フリーパッケージのDS2480B+に置き換えられています)は5mm角程度の大きさの8pinの表面実装パッケージでとても小さなものですが、中々使いでのあるICです。 なお具体的なコマンドのシーケンスについてはここには書きませんでした。こちらについてはDS2480Bのデータシートを参照してください。

DS2480Bについて

DS2480Bは入出力をRS-232シリアルインターフェース(TTLレベル)で行うように設計された1-Wireバスドライバです。 1-Wireはビット単位のデータ入出力は実時間に強く依存した非同期バスですが、このレベルについてはDS2480Bに完全に任せることができます。電気的特性上の要求から設定可能な部分はありますが、少数のデバイスを数m程度の配線で使う分にはデフォルト値のままで全く問題ありません。 DS2480Bには各種初期設定、ビット単位のデータ送受信を行うコマンドモードと、バイト単位のWriteがそのまま1バイト分の1-WireバスへのWriteとなるデータモードがあります。 1-Wireデバイスに対するコマンド(たとえば温度測定開始、測定データの転送などのコマンド)およびデータの送受信はほとんどバイト単位で行うようになっていますから、初期設定的など一部の処理をコマンドモードで行い、大部分の処理はデータモードを使う形になります。後述する検索アクセラレータや単一bitの読み書きを行う場合はコマンドモードを使います。 詳細な状態遷移図はDS2480Bのデータシート上で公開されていますが、大まかな状態遷移は以下のようになっています。
DS2480の大まかな状態遷移


  • コマンドモード: 各種のコマンドを受け付けるモード
  • データモード: "E3"を除いて受け取った1バイトをそのまま1-Wireに出力するモード
  • チェックモード: データモードからコマンドモードへ遷移する途中の一時的なモードで、"E3"を受け取ると1-Wireに"E3"を送ってデータモードに戻る以外はコマンドモードと同じ
チェックモードはデータモードからコマンドモードへ遷移するためのコマンド"E3"のエスケープ処理上発生する一時的な状態です。"E3"を出力する場合は"E3,E3"と2回続けて同じデータを送ることを表現したものです。 なお、チェックモードから電源offの遷移がありませんが、これは元の詳細の状態遷移図に従いました。

ROMコードのSearch と検索アクセラレータ

1-Wireのデバイス(スレーブデバイス)には工場出荷時に64bitのユニークな「ROMコード」が書き込まれており、デバイスを指定するアドレスとして利用されます。64bitのうち8bitはエラーチェック用のCRCコードなので実質56bitのアドレスになります。また56bitのうち8bitは製品の種別を示すファミリコード(温度センサの場合は28h)として使われています。 ROMコードはソフトウェア的に読み取り可能で、複数のデバイスが一つの1-Wireに接続されていてもROM Searchコマンドを使って全てのスレーブのROMコードを読み出すことができるようになっています。 このコマンドは特殊なコマンドで同時に複数のスレーブデバイスが出力行い1-Wire上では複数のデバイスの出力が合成されます。一般のCMOS回路の出力では通常出力端子同士を接続しては使えませんが、1-Wireではオープンドレイン出力なのでこの形は通常の動作です。以前にも書いたとおり出力動作をしているデバイス全ての出力をAND接続した結果が1-Wireの出力になります。 ROM Searchの詳細についてはMAXIM社の公開している資料を読んでいただきたいのですが、要点は以下のようなものです。

ソフトウェアによるROMコードの検索

DS2480Bを使わない場合1-Wireに用意されているSearch ROMコマンドとソフトウェアによる処理の組み合わせでROMコードの値を取得します。 Search ROMコマンドを使うと初期状態では1-Wire上のスレーブデバイス全てが応答します。スレーブはLSBから順番にROMコードの各ビットの値、値を反転したものを出力していきます。 (0bit目の値),(0bit目の値を反転), (1bit目の値),(1bit目の値の反転)…… 1-Wireでは全ての出力がAND接続されていますから、スレーブの中で一つでも0を出力しているものがあれば結果は0になります。たとえば[n bit目の値]と[n bit目の値を反転]の組み合わせについては以下のことが言えます。

  1. [n bit目の値]と[n bit目の値の反転]の値が異なる値であれば全てのデバイスのROMコードのn bit目は[n bit目の値]と同じである
  2. [n bit目の値]と[n bit目の値の反転]が両方とも0なら0bit目が1のデバイスと0のデバイス両方がある(値の衝突がある)
  3. [n bit目の値]と(n bit目の値の反転)が両方とも1なら、正常な動作をしていない。バス、デバイスの異常、シーケンス中にデバイスが取り外された、等が考えられる
この3種類の状態を表にすると以下のようになります
n bit目の値
0 1
n bit目の値の反転 0 出力には0,1両方ある (2) 全ての出力が1 (1)
1 全ての出力が0 (1) 正常動作ならこの状態にはならない (3)



3つめの状態の場合は中断するなり、最初からやり直しですね。1.の場合はそのまま次のbitについて同じ操作を続行します。2.のデバイスによりどちらもあり、の場合は0か1を選んで検索を続行します。この場合、選ばなかった「枝」に属するデバイスはそのまま動作していると、そこより葉に近いノードでは偽の「衝突」の原因になります。 ホストデバイスは「直前に調べたbitのROMコードの値が0(あるいは1)のデバイスは次にバスリセットを行うまで動作を停止する」という指示を行い、検索の対象とならない枝のデバイスはその後の検索に影響を与えないようにします。 これを64bit目まで繰り返すと最終的には1-Wire上で動作しているデバイスは1つだけになり、64bitの値が1つ決定します。1-Wire上のデバイスのROMコードが1つ求められたことになります。 簡単な例を示しましょう。ROMコードを64bitではなく仮に4bitとして、1-Wire上に0101, 0110, 1001(LSB first表記)のROMコードを持つデバイス3台が存在するとします。

  bit位置
デバイス 0123
0101
B0110
C1001

ここで0bit目から値0の枝を優先して検索を行うと以下のようになります
0bit目
初期状態で全てのデバイスが動作している。 A,B:0 C:1と値が不一致で衝突しているので0側の枝を選択、1の側(1xxx)に属するデバイス(ここではCのみ)を停止させる--(1)
1bit目
デバイスA,Bが動作している。 A,Bの値は1で一致しているので1の枝を選び検索を続行
2bit目
デバイスA,Bが動作している。 A:0, B:1と値が不一致。 0側の枝を選択、1側(011x)に属するデバイス(B)を停止させる--(2)
3bit目
デバイスAが動作している A:1で4bit分全てが確定、これが得られたROMコード(0101:4bit)になる

ROMコード検索木



全ての1-Wire上のデバイスのROMコードを求めるには、各デバイスのROMコードが見つかったら、バックトラックを行い64bitのROMコード全体の木検索を行えばいいことになります。ROMコードの値の衝突が起きていないbitでは一意に値が決まりますので実際に検索しなければならない範囲は64bitの木全体から見れば小さい範囲になります。 これはbit演算主体のプログラムになり、結構面倒ですね。MAXIMはサンプルプログラムも公開していますので興味があったら参照してみてください。

DS2480BによるROMコードの検索

DS2480Bを使う場合は上記のROMコードの検索処理のかなりの部分をハードウェアが半自動で行ってくれます。 DS2480Bの「検索アクセラレータ」をOnにして必要なパラメータを送ると、そのパラメータに適合したデバイスのROMコードが戻り値に返されます。上の4bitの例であればデバイスAのROMコード:0101と値の衝突が発生した位置(0bitと2bitで発生):1010の2つの情報がいきなり得られます。値の衝突が発生した位置のデータは「不一致フラグ」と呼ばれます。 入力で使用するパラメータは「値の衝突があった場合どちらの枝を検索するか」を示すデータです。これはインデックス値と呼ばれ、ROMコードの各bitに対応する64bit分ですがフォーマットの関係で128bit(=16byte)のデータをホストは送ります。条件に合致するデバイスのROMコード(64bit)と検索中に値の衝突が発生したビット位置(=検索木の分岐がある位置)のデータ(64bit)の128bit(=16byte)の情報を返してくれます。 たとえば値の衝突を検出した場合に、全ての場合で'0'の側の枝をたどる検索を行うのであればパラメータ64bit分に全て0をセットして検索を行います。 得られた不一致フラグとROMコードから次の検索を行う場合のインデックス値を作り出し、新しいデバイスが見つからなくなるまで検索を繰り返せば1-Wire上の全てのデバイスのROMコードが得られます。

インデックス値の作成と不一致フラグ

ここではDS2480Bで検索アクセラレータを使う場合でもれなく全てのデバイスを検索するためのインデックス値を決める方法について説明します。初期状態ではインデックス値には全bit0の値を与えることにします。 いくつかの1-Wireデバイスが接続され、正常に動作しているならそのうちの一つのデバイスのROMコードと不一致フラグが得られます。2回目以降の検索では今得られたROMコードと、不一致フラグから「未検索の枝」を見つけてそちらを検索するようにインデックス値で指定してやります。 最初の検索では不一致を検出した場合に0を選ぶように指定していますので不一致を検出し、かつ対応するROMコードのbit位置の値が0のものは「未検索の枝」が残っていることになります。ここでは「未検索の枝」のうちMSBに近い側から1の側の枝を選んで検索するよう指定していきます。 インデックス値のフォーマット、作成方法はデータシートを丹念に読めばわかるようになっていますが、一見わかりにくいところもあるので図示します。
  • 検索アクセラレータの出力  128bit(=16byte)の出力は奇数ビットにROMコード、偶数ビットに不一致フラグとビット毎交互に情報が収められています
  • 検索アクセラレータ出力


  • インデックス値の作成
    1. 前回の検索アクセラレータ出力の最大不一致ビットに対応するROMコードのビットを1にする
    2. インデックス値作成1


    3. 今1.の手順で1にしたROMコードのビットよりMSBに近いビットを全て0にする
    4. インデックス値作成2


    5. 作成した64bitのデータを奇数ビットにして128bitに拡張する。偶数ビットの値は任意でよい
    6. インデックス値作成3


ここで得られた値を次の検索で使うインデックス値として使うと先の検索で見つかったデバイスとは別のデバイスのROMコードが得られます。これをLSBまで行うと全てのデバイスが見つかります。ただし最初の検索で無効にした枝の中に複数のデバイスが含まれる場合もありますので、最初に見つかった「不一致フラグ」の1の数より多くのデバイスが1-Wire上にあることもあります。 インデックス値、ROMコードの出力、不一致フラグのフォーマットはハードウェアの都合が極めて強く出たもののようでソフトウェアを作成する立場からすれば無駄に複雑な構造に見えるかもしれません。ホスト側からはシリアルインターフェースからbyte単位でデータの送受信をしますが、DS2480BはROMコード検索のbit単位処理をシリアル送受信の合間にやっているんですよねぇ…… あくまで印象ですが、DS2480Bは比較的小規模な回路追加で可能なシーケンス処理に絞って実現したように思います。その分いくらかはソフトウェア側にしわ寄せが行っているというような点もあるかもしれません。データシートの記述はもう少しわかりやすいものであれば良かったとは思いますが、実行例などが記載されているのでかなり助けられました。 今回は主に1-WireデバイスのROMコード(1-Wireのアドレス情報)の検索について書きました。 次回は今回書けなかったDS2480Bを使う場合の注意点、そのほかの機能について書くつもりです。

FireMobileSimulatorにホストごとに端末設定できる機能を作りました

こんばんは。maruyama-r(@h13i32maru)です。 弊社では携帯電話やスマホ向けコンテンツを作ってるので、結構みんなFireMobileSimulator(FMS)を使っています。 で、先日同僚が「接続先のホストごとに端末の設定変えれたら良いのに」というようなことを言ってました。 よし、じゃあその機能作りましょう! というわけで業務時間中仕事が終わった後に作って社内のMLに投稿してみました。そしたら割と評判がよかったのでバグフィックスとリファクタリングをして作者にパッチ投稿しました。昨日返事があって、今週末あたりに本体にマージしてくださるとのこと!やった(・∀・)


どんなふうに機能追加したかというと、FMSにはもともとホスト制限機能(この機能、実は弊社の社員がパッチ投稿しています)というものがあります。これは指定したホストでのみしかFMSを動作させないというものです。ホストごとの端末はこのホストに端末を関連づけておくというものです。ホスト制限を追加するときに一緒に端末も設定することで、そのホストではかならず設定した端末が動作するようになります。 (ただし、タブごとの端末設定を有効にしているとタブごとの端末が優先されます) こんな感じです。


ホスト設定のところに端末設定が増えています。


ホストを設定するときに端末一覧から選択します。「なし」を設定すれば今まで通りの動作です。 パッチと機能追加済みアドオンは以下のページからダウンロードできるので、興味がある方は試してみてください。バグ等あったら教えてください。



そうそう、四半期ごとに行われる社内のKLab Awardsで敢闘賞をもらいました!所属しているエンジニアグループを活性化するための率先した技術発表を評価してもらいました。こういう制度ってエンジニアのやる気があがりますよね!他にも色々な賞があるのでもっと上を目指したいと思います!
 KLab若手エンジニアブログのフッター