■なんか、だいぶ時間が経ったけれどようやく形にはなった。ただ今コードクレンジング中。RTOSも持たずにシングルプロセスで処理するのでそれはそれはみっともないものではあるのだけど、まあ、使えなくもない。これで何とかリファレンスを作れたような気がする。
リファレンスというのは、なにぶんハードもソフトも手探り状態で作っているから、何か不具合があってもハードに問題があるんだかソフトに問題があるんだか明確に切り分けることが難しかったのだけど、一度ハードとソフトでフィックスすれば、その切り分けの基準を持つことができる。なにしろブレッドボード上でジャンパ線を飛ばしまくったためか、ENC28J60の起動が不安的で、結構初期化に失敗したりするし、パケットを受信して暴走することもある。その不安定さというは今もあんまり変わらないのだけど、それでも少しずつ安定するようになったし、不具合が起きるなら起きるで再現できるようにもなった。再現できる不具合は、たいていはソフト的な問題だ。
ただまあ、プログラムデザインがいい加減なのはいかんともしがたい。使いまわしできるようにTCP/IPのスタックを下から積み上げるように作ったのだけど、シングルタスク環境でそれをやるとセッションは早い者勝ちにどうしてもなる。アプリケーション層の下にあるTCP層(という言い方は不正確なんですが便宜上)がステータスを持つので、そこに引きずられて上位のアプリケーションもステータスを持ってしまう。
でも、HTTPは本来ステートレスなので、そこに引きずられてしまうのはおかしい。解決策はTCPの処理をHTTPサーバの中に取り込んでしまうことだと考えているのだけど、そうすると今度はTCP/IPのスタックとしてはいびつになってしまう。
どういうことかと言うと、HTTPサーバとして全てのTCPパケットを受けて、HTTPサーバがTCPのセッション管理をするような造りにする。HTTPとしてのプロトコルはステータスが無いから、単に受信データの中にGETリクエストなりあれば、それに対応するコンテンツがあればそれを返すだけ。HTTPサーバがTCPのステータスを意識しないように作ると、TCPパケットの受信コンディションがSYN+ACKを返した直後とか、ACK待ちとか、状態を持ってしまうので要求に応えられたり応えられなかったりという状態が発生しやすい。なぜって、シングルタスクだから。
他にもリクエストのパーシングがメソッドとURIしか取得していないとか、いろいろと微妙なところが多い。
ただ、元々の用途としては今のままでも構わない。やりたいことって要するにwgetでリクエスト投げて、例えば温度データをXMLで取得したり、あるいはリモコン操作をさせたりとか、そういうことだから。
ちょっと時期的には微妙なのだけど、AVRとENC28J60を同居した（例によって）ブレッドボードともつなげることができる実験ボードを作成しようかなとか思っている。要件的にはAVRからENC28J60の電源を制御できるようにしたい。ソフトリセットでは解決できず、電源再投入を繰り返してまともに起動することがわりとあるからだ。ただ、やっぱりそれはジャンパ線がノイズを拾っているからではないかという疑いもあって、まあ、いろいろと微妙です。そういうところを愉しんでいるというところもありますけれども。
