■だらだらとAVR HTTPサーバの話。今は上っ面のアプリケーション層であるHTTPサーバを少しずつ拡張してテストしつつTCP/IPのスタックライブラリのコードクレンジング中。クレンジングっていうか、デバッグって言いますが。
wgetコマンドでデバッグする段階からブラウザで普通にアクセスできるようにはなった。マルチユーザーは無理だけど、シングルアクセスではいける。
ブレッドボードであれこれやっていたときにさんざん悩まされたENC28J60の起動不良はすっかり出なくなりました。初期化シーケンスでENC28J60のH/Wリセットをかけるようにしたのが良かったのかもしれない。
ただ、拾いこぼしが出ます。たぶん、これはどうにもならない気がしています。ENC28J60自体はキューイングの仕掛けを持っていますが、TCPの3ウェイハンドシェークのパッシブオープンでリモートから最後のACK発行直後にHTTPのリクエストが発行されると、それを拾えていません。拾えてなくても、リモートの側で再送してくれるのでそれでＯＫなんですが、ちょっと待たされ感があります。スイッチサイエンスさんあたりで扱っているWIZnetなら大丈夫なのかしらん。TCP/IPスタックもオンチップみたいだし。
それはそれとしてレスポンスのパケットは、３回に分けています。本当は分ける必要はないはずなんですが、分けています。
最初にACKを送り、次にHTTPレスポンスヘッダを送り、最後にコンテンツを送っています。見かけとしてはIPフラグメントですね。
今はボードにセンサ類は実装していないんですが、LEDが乗っていて、これをピカピカさせています。その発光パターンをGETメソッドのパラメータで変更するようにしました。
もちろん、センサを載せて、データをXMLにくるんで(SOAPみたく)応答させるといったこともしたいんですが、レスポンスデータの長さが可変だとHTTPレスポンスヘッダを作るのが大変になります。普通にサーバであれば、出力結果を一旦バッファさせて、その長さを調べればContents-lengthは簡単に解るんですが、AVRではそのバッファさせるメモリが無い。もちろん、固定部分と可変部分を丁寧に分けておけばContents-lengthは事前に算出できますが、それは要するにContents-length算出のルーチンをコンテンツごとに用意しなければならないわけで、HTTPサーバスタックとはちょっと区切りつけたいかな。
HTTPのプラットフォームを作ったのは、別に小さなアプライアンスサーバーが欲しかったわけではなくて(素直にAtomのベアボーンにする)、PCから距離を置いた場所にコントロール可能なデバイスを置きかったので。最近流行りのArduinoだとUSB接続ですが、USBの線には長さの制限があるので、どこにでもというわけにもいかず。XBee使えばいいのかな。XBeeのピンが2.56ミリピッチだったら便利なんですが。（でもXBeeだとENC28J60に比べるとパーツ単価の総合計が倍以上にはなるかな）
それはともかく、うちは全部屋にCAT5が通っているので、各部屋にリモートデバイスをばらまくならイーサの方が便利なわけです。とりあえずは。
そろそろ名古屋から引き揚げになりそうな気配で、あんまり手間をかけられなくなってきたので、デバイスのプロトとしての仕上げは後回しかな。とりあえず温度センサだけでも載せてみようかしらん。
