R&D daily

災害と新型構造

明日から外仕事、のはずだったのだが。
９号の影響で、周辺や内部が道路崩落やら土砂流出などしているらしく、イベント中止となったようだ。

まあ、災害復旧が最優先だよな。

なんだか気が抜けてしまう。

------

重い腰を上げ、駆動系のデザインを進めてみる。

ちょっと新しいレイアウトを思いついたので、作図してみる。

前のよりは良いような気がするけれど、金属と樹脂の接着をしなきゃいけないところが２箇所。
ここがうまく付いてくれると、成立するのだがどうだろう。
ちょっと部品を切り出して、試してみるか。

あと、ベアリングを頼まないと。手持ちには丁度良いのが無い。

これがうまく行くと、この構造でもっと小さいのも作れるから、少し先行できるな．．．．

初心者大会など

思い立って、中部支部の初心者大会を見学。

ちょっと遅れて到着すると、なんだか、初心者大会？って感じの大盛況。
初心者大会って、こんなんだっけ？
昔、最初に見に行ったときは、全部で５～６人でやってたような気がするんだが。

本戦終了後に、皆、空いているフル迷路で調整作業。
しまった、その手があったか、笑。

------

Javaアプレットは、なんとなく理解。
なるほど、まあなんとかなりそうだ。

しかしイマドキは、Javaは堅い業務用アプリ用途なんかで人気だが、一般には時代遅れ．．．どころかFlashすら対応をしない端末もあるらしい。アップルのアレとか。

そうなのか、と思い、さらにいろいろ検索したりしてみると、2010年の現在のトレンドは、HTML5のWeb Socketsだ、そうなのだが．．．

実は、さらにそれすら変わってて、Web Socketと呼称が微妙にかわって、HTML5からは独立した仕様になっているとか。

でも、対応しているブラウザはあまり無い？？とか。
どうしてくれようか．．．．って感じみたいだ。

とりあえず、WebSocketで作っとけば、その内、各ブラウザがついてくるってことでいいのかな？
仕様自体はシンプルな気がするのだけれど、HTTPと同じポートを使っているみたいだし、細かいところはまだよく分からない。

Javaアプレット

いまさらな事を色々勉強。

Javaアプリケーションと、Javaアプレットは、同じ物ではないようだ。
最初は勘違いしていて、ブラウザの上で起動できなかったのだけれど、Java入門編のサイトをあちこち参照して解決。

なるほど。

なんとなくブラウザ相手に、HelloWorldが動くようになった。

しかし、バイトコードを更新しても、ブラウザのキャッシュ？が効いているせいか、すぐには新しいものを読み込んでくれないようだ。

どうやったら、即、更新してくれるのだろう。

------

Javaアプレット上では、入出力や、ソケット間通信、グラフィックス描画でも、なんでもいけるので、lpc側からPCというか、ブラウザのコントロールができる．．．事になってほしいのだが。

要するにクライアントは、PCでなくても、Javaの動くブラウザならいけるので、あれをこうして．．．妄想中。うまく行くかな？

ここ最近の様子

本業のほうも色々片付いて、一息つけそうになってきた今日この頃。

------

なんだかずっと続けている、lpc1769+Ethernet。

ペースは遅いのだけれど、まあそれなりに進んで、最近はhttpが動くようになったので、スタイルシートとか、JAVAscriptとか。
作ってみると、なるほど、この辺って実にシンプルな話だが、なんだか色々セキュリティの問題ありすぎだよな．．．．

ところで、TCP/IPプロトコルスタックまでの作業（コーディング）と、http以降の間に大きな溝を感じる。
なんだかまったく別の世界だ。
そこを境に、ぜんぜん違う方面に混沌としている。（どちら側も、そんなにすっきりしてはいない。笑　）

次は、とりあえず時代遅れの感はあるけれど、JAVAアプレットの実装。（簡単に）
これが出来ると、lpc側からもブラウザ相手に色々できそうなのだが。

本格的に動かすには、lpcの内蔵flashに書き込んでおくのも限界があるので、ストレージが欲しいところ。
SDカードをやるといいのだけれど、そろそろ本末転倒臭くなってくるかも。

最近はflashが主流なので、この辺も動かせるといいなあ。
まあとりあえず、アプレットをなんとかするか。

------

追われるものが少なくなって、季節も秋だなあ（？）と、まったりしていると、天からなにやらお告げが．．．

えぇ～正気ですか？　そうですか．．．

文面で見ると、どこか気が触れているようにもみえるのだが、当人はいたって冷静（？？）な様子。
うーん．．．勝算は無いような気もするけど、そういったのもアリのような気もするし．．．
話に乗ってみるのも、まったくダメじゃないような気がしたりとか。

どう間違っても、うまい話じゃないところに惹かれたりしてるっぽいのだが、これは巧妙な罠か？笑

虎穴に入らずんば虎子を得ず？？年甲斐もなく迷ったりする。
まあ、やることになるのかあ．．．

帰省

先週の外仕事も、特にこれといったこともなく、無難に終了。
今日から今週いっぱいまで休み。
外仕事のおかげで、あちこちに分散する夏休みを消化する。
というわけで今週は、都内に帰省。

少し予定もあるのだけれど、久しぶりに秋葉原に行ってみようか。
色々仕入れたい物もあるし。

------

マウス用の新規部品は色々到着。

そろそろ、総重量10g前後の時代になってきたようなので、それなりのレイアウトを再構成。
外径7mmのベアリングさえ、重く感じるようになってきた。

stm32ですら、サイズが大きすぎる気もしてきたりとか。
もっと小さくて使いやすい石は無いものか？
この際、BGAパッケージでも．．．

なんだかんだと言っても、adxrs300だって、皆、実装して走らせていたし、やりゃあナントカなるのかも。

未だにこれだっ、てのは見つけられないのだけれど。

帰省

台風による雨の中、西に自走で帰省。

途中、車のエアコンが、どうにも利かなくなる。
動かなかったり、動いたり。
なんとか帰り着いたので、ちょっと見てもらう。

なんか、リレーが調子悪くて対策品があるとか？
それぞれのリレーを見比べると型番はまったく同じで、マーキングがちょっとついてるだけとか。

おいおい．．．

まあ、この車は結構走ってるから、どっかしら調子悪くなっても不思議じゃないんだけれど。
これって、設計上の問題だったりしないのかなあ。

DHCP

週末はDHCPで悩む。分かってしまえば、チェックサムの計算ミスだったのだけれど。

チェックサム計算が、TCPでは正しく動くのだけれど、UDPではうまく計算できてなかった。
Wiresharkは、特にエラーを返してないようだったので、うっかり見落としてしまった。

ちゃんとアドレス取得できるまでには、もうしばらくかかるけれど、とりあえずサーバーからofferは返ってくるようになった。

或る日のtelnet

telnetが通信途中でこける件について。

分かればなんてこと無い。いつものこと。

リングバッファに複数未処理パケットが有る状態で、割り込みで１個だけ処理して抜けてきてしまったのが原因。
定番のバグを仕込んでしまったようだ。
最初はポーリングで処理していて、ちゃんとバッファが空になるまで回すように作っていたのだけれど。
もしかして、取りこぼしがあるのかも、と思い、割り込みハンドラ内で処理するように変更したときにやらかしたようだ。

今のプログラムのバックグラウンドループは、平均で8usec、ワーストで220usec程度で回っているようだ。
ポーリングで処理しても、まだ問題なさそうに思える。

------

Ethernet MACの処理は、nxpのサンプルコードのまま。
このサンプルコードはよく出来ている。

この場合の、”よく出来ている”というのは、やたら凝ったつくりになっている、とか、ある種の美しさに満ちている、という類の話ではない。
ベタ書きのコードに限りなく近いのだが、ハードウエアの使い方が読み解きやすい、平易なコードになっている。
サンプルコードの役目として期待されるものに沿っていて、好感度高い。

サンプルコードと称して、やたら深い構造体の解析に付き合わされたり、どこまで追っても意味がよく分からない定数やマクロの海に泳がされたりするようなものが多い昨今、ありがたいことだ。

このサンプルコードでは、送受信のバッファサイズが、Ethernetパケットの最大サイズで定義されていて、そのため受信バッファとしては、４つしかブロックが存在しない。
最小サイズ付近のパケットがたくさん飛び交うようなときには、メモリの使用効率が悪くなる。
いや、もちろん、サンプルとしての分かりやすさを求めて、設定されているのだと思うけれど。

------

で、ようやくなんとなく動くようになったtelnet（受信側のみ）だけれど、実際のやり取りをパケットアナライザで観察してみる。

122byteほどのアスキー文字列を、lpc1769側に送信。
転送が終わるまでに、約220msecかかって、86個ほどのパケットが行き交っているようだ。（arpやsync、finとかは除く）
こんなもんかなあ？と思うのだけれど、内容を見ると再送要求だらけで、実際にデータの受け渡しに寄与しているパケットは、全部で8個しかない。半分はackだから、文字列を送っているパケットは4個だけ。

telnetの解説を見ていても、効率悪そう．．．と思っていたのだけれど、これは予想以上？
lpc側のプログラムをチューニングすれば、もっと良くはなるだろうけど。

まあ、telnetクライアント側が賢くて、もっとたくさんデータを送れば、サーバーの応答を観察して、だんだん効率のよい方法で転送を始めるのかもしれないけれど。

次は、標準出力側かな。
今度は大丈夫でしょう、多分．．．．

パケットアナライザ

LPC1769のEthernetコントローラ。

TCP/IPの実装をやっていて、どうにも行き詰ってきた。
簡易的にブラウザと通信するようなプログラムならば、その昔はうまく行ったのだけれど。

標準出力＆デバッグコンソールに、telnetが使えるとちょっと便利かもと思って、ぼちぼちやっているのだけれど。
時々予期し無いタイミングでこけてしまう。

ころあいなので、パケットモニタを導入して、telnetクライアント（といっても、ハイパーターミナルだけれど）がどういう動きをしているのか観察する。

WIRESHARKをインストールする。
昔使っていたのとは、大分変わっているような？

------

どうやら、通常のキーボード入力なんかは、１文字ごとに1個のパケットを送るようだ。（リターンキー入力でも、\rと\n別々に２個パケットが出る。）

テキストファイル送信でまとめて送信してやると、最初の１文字だけ1つのパケットで送出されたあと、あとは不規則な区切りで、ぱらぱら出て行くようだ。

で、最初のうちはパケットの送信間隔が広くて、lpcからackが戻るのが先なのだが、だんだん進んでいくと、一気に１０個くらいのパケットをほぼ同時に出してくる。
ここのところで、受け側のリングバッファがオーバーフローして、処理が回らなくなっているようだ。
バッファフルでそれ以上のパケットを受信しないように出来ているはずだけれど、どこかにまずいところがあって、処理済みのシーケンス番号を見失ってしまっているようだ。

何百キロバイトも受信バッファが用意できれば、こんな問題は起きないけれど、そんなメモリは用意できないので、他の方法を考える。

まあ、TCPのフロー制御を使えってことかも知れないけど、シーケンス番号が飛ばないようにして、知らん振りして応答すりゃいいだけのような気もする。

------

よく考えると、telnetにこだわることは無いような気がするけれど、なんだか一度手をつけてしまった以上、形にならないとすっきりしないような．．．

帰還

終了と同時に猛ダッシュで帰還。
なんとか本日中に戻ってこれた。

内容は．．．．やっぱり．．．

ピースが足りてないジグゾーパズルを、皆してこねくり回して、なんとか絵として解釈しようとしている感じ。
もどかしいなあ、そりゃ無理があるでしょ。
ピースが足りてないことには、みな薄々気がついていると思うのだけれど、それすら含めて全てはバランスなのか。危うい．．．

まあ、大筋表面的にはまとまったかな。
明日からもがんばらねば。

外仕事

仙台も、ものすごく暑くて、しんどい．．．
日が翳ったり、夜になるとまあそれなりに、東北地方だなあ、と思う位にはなるのだけれど。
明日はどうなることやら。

telnet応答

あれこれちまちまと進めて、とりあえずtelnet（TCP 23）で、キャラクタがやり取りできるようになった。

手抜きを超えたインチキな実装で、ソケットを一度にひとつしか扱えないけど。
まあシリアルポート代わりに使うなら、これでもなんとか。
実際、ハイパーターミナルでつなげていると、シリアルとどこが違うのかと。

いや、これはこれで意味がある。はず．．．

さて。

------

今週末は、仙台で外仕事。
電車を乗り継いで移動。

宿作業に時間が取れるといいのだが。

ping

ベタベタなコードを書いて、とりあえず動かしてみる。
チェックサムは１の補数ってのは覚えていたのだけれど、最後ビット反転するのを忘れて悩んだ。

カニチップ当時は10base-Tだったのもあって、1kbyteくらいのデータでpingを打つと、応答に10msec以上かかっていたのだけれど、今時はこんなもんみたい。

とりあえず動くようになったので、ソースの整理をして、次はTCPかな。

------

マウスは、機構部品の検討中。

ネジサイズは、M1.4かM1.7かなあ．．．
うまく組み立てられるかな。

進捗

世間は３連休らしいのだが、祭日関係ないのはいつものこと。

週末は、色々な用事をこなして充実。
マウスや電子工作ネタは、深夜まで封印。

------

TCP/IP実装。
世間では、uIPみたいなものを実装して一丁上がり、ってのが今時のようだけれど、色々理解のために、贅沢にも自分で書いてみたりしている。
とりあえず、パケットの受信は出来てるみたいのなので、週末でpingに応答するところくらいまでできたらいいなあ．．．とか。

------

コツをつかむまでは、ちょっと悩んだ。
pingに応答するところまではとどかなかったけれど、とりあえず通信相手のPCのARPテーブルに、lpc1769側のMACアドレスが出てくるところまではできた。
要するにたった１個のパケットを返送しただけなのだけれど、ここまでくれば後は作業量だけだ。

------

Ethernetは、いったん動いてしまえば、必要とするCPUリソースは、調歩同期シリアルよりも少ないくらいだ。
ビットレートは何１００倍も速いし、PC側との相性もいい。無線やネットワーク制御の機器も他のものに比べても、ものすごく充実している。
ターゲットがワンチップマイコンであっても、がんばって動かす価値はあると思っている。

マウスだと、どこに使えるか、といわれれば．．．ログのダウンロードが一瞬で終わる、くらいかなあ。
macはいいとしても、phyの消費電力が酷くて、むずかしいかな．．．．

妄想

コーナでのターン中は、常に一定の状態で旋回していくのではなく、期間の最初から最後まで、バランスは変化していく。
姿勢を崩して壁に激突するのが、いつも大体同じあたりになるのが、それを証明しているような。

で、ターンする為の運動量は、ターンの期間中にタイヤのグリップから取り出すのだが。
速度が上がれば、獲得しなければならない運動量自体も増えるし、取り出す時間も短くなるので、必要な力のピークは上がっていく一方だ。

このピークがタイヤと路面の限界とバランスするところが、ターンの最適値になるのだけれど。

------

さて近年。
競技用車両に、マスダンパー、なんてものがついていたり、ついてなかったりする。

色々な人が、色々な解釈をしているけれど、まあようするに。
真空のエネルギーじゃないけれど、瞬間的に運動量を借りてきて、つじつまを合わせようってことだと思う。
一連の動きの中で、一番厳しいところだけひょい、とかわすようなイメージ。
ピークを（時間的前後に）分散させ、トータルでの性能を稼ごうって寸法なのではないかと。

マウスで言えば。
たとえば、ターンに入る前に、質量（イナーシャ）の大部分を前もって旋回させておき、いざターンの時には、最低限の質量のみのターンで済ますような事を実行すると、早く曲がれないか？とか。
そういった発想のバリエーション。

最短走行なんて、いつ、どこで、どれくらい曲がらなきゃいけないか、あらかじめ分かっているのだから、色々策はあるような、無いような．．．

------

とはいえ、そのために複雑な機構が必要になるようでは本末転倒。
現行のものに比べても、ほとんどハンデにならない程度のもので実現しないといけない．．．．

マウスは、まだまだ速くなる、と思うこの頃。

RMIIのクロック

PHYから出てくるのだとばっかり思っていた。
やけに短いパケットしか出てこないなあ．．と思っていたら、こんなことか。
50MHzのオシレーターに直結して解消。

受信したパケットをダンプしてみると、なんか久しぶりの面子が並んでいて、笑
当たり前だけれど。

カニチップ以来の１０年ぶりだけれど、プロトコルは何にも変わらない。
あの頃に比べると、ルーターがタダみたいな値段になってたり、クロスケーブルなんてものが絶滅したりしているけれど。笑
使っているチップも、H8→SH→LPC→STM32→．．．と何世代も交代しているけれど、のっかっているプロトコルは微動だにして無いな。
いまだにIPv4だし．．．

------

そういえばカニチップには、いろいろ苦労した覚えが。
その前にDP83902なんてのをしばらくいじっていたから、なんとかなったけど。
たしかこれが紙のドキュメントを取り寄せた、最後のチップだったような気がする。

周りには、いきなりRTL8019ASに取り組んで、沈没してた人も多かったような。

当時、秋月からH8-3048+RTL8019ボードがでて、皆入手して色々試していた。
まともに動かすには、ちょっと問題のある回路だったし、DMAを使わないと、H8ではかなり苦しかった。
おかげさまでH8の理解は進んだけれど。
コアの性能が低い分、ペリフェラルをうまく使うと、すごく性能が上がった感じがあって、楽しかったかも。
イマドキのやつらは、しょっぱなから出来がよすぎるよな。

あと、シリアルROMで設定しないと、うまく設定できないコンフィグビットがあったりとか．．．
NE2000互換のワンチップ素子だから、構成自体の合理性とかそんなものは実装されてなかったような。
まあ、それはそれで、面白かったかな？

------

なんか．．．マウスからは遠いなあ。

新デバイス評価

いろいろやってみるのだが、どうにもうまく返事をしてくれない．．．
データシートにある消費電流から推測すると、どうもスリープモードからぬけ出てきて無いような気がするのだが。

どうしよう、これ抜きで設計を進めるか。
新ネタがことごとく外しているなあ．．．

------

AS5040のために入手したネオジム磁石をいじってみて思うのだが、わずか数ミリくらいのサイズなのに非常に強力だ。
なんとなく、自分でモーターを巻いてみたくなったかも。

最近の超軽量のRC飛行機では、自作のアクチュエータも普通に使われているようだし。

ハーフサイズに使えるモーターは、エンコーダーなどの事情も絡んで、選択肢が非常に狭いし、自作の可能性を探るのもありかも、と思っていたりする。

まあ、実際まいてみると、だめだこりゃ、ってことになるのだろうけど。

stm32でSPI その２

ユーザーズマニュアルを眺めていると、stm32の非同期シリアルは、SPIマスタとして使用できると書いてある。これはいい。
そういや、よくあるUARTじゃなくて、USARTと称しているよな。

SPIｘ２と、USARTx3で、全部で５個も使えるなら十分だ。
しかしUSARTのポートは、LSBファーストに固定されるっぽい。
これではちょっと厳しいかも。

他であまり見かけない機能として、SPIなのに半２重通信ができるようだ。
１つのデータピンが、タイミングで入力になったり出力になったりするのか。
何に使えるのだろう？

stm32でSPI

stm32でSPI評価。

乗っかってるのは、オリジナルのstm32ボード。１インチ角。
下は、秋月Cタイプ基板。
セットでいつもの評価用ボード。

------

非同期シリアルや、ADCではどのチップでも、まあだいたい同じようなことができるもので、設計するときに悩むことはまれだ。

ところが、SPIあたりでは、使える機能がチップごとに結構違う。
扱えるビット数とか、受信の取り扱いとか。まあ色々。
古くは、昔のSHのクロック同期シリアルI/Fに、SDカードを接続しようとして、結局頓死したこともいい思い出だ．．．？

かように、想定している相手と問題なく接続できるかどうかは、じっくり考えてみないと分からない（こともある）。

まあ、実際のチップ、実機で試してみればはっきりするので、早速仕立。

------

そういえば、stm32でSPIを使うのは初めてだ。
他のチップでは実に日常的に使っているのだが。

いまさら、ハードウエアマニュアルを熟読．．．

評価中

こちらでも評価されているAS5040。
磁石はなるべく小さいのがいいので、ネオジムのφ３のものをここから購入。

用意した磁石で、電源だけ接続するとA,B,Z相の出力が出てくる。
調整とかも必要なし。

ただ選択した磁石の所為か、適正なＩＣと磁石の距離がちょっとシビアなようだ。

シビアといっても、適正な範囲にあるかどうかの出力信号もあるし、1mmくらいは範囲があるので、実用上は問題ないと思う。

本当言えば、もうちょっと小さいパッケージのが欲しいところだけれど、まぁなんとかなるかな。

------

＃うちでは、出力が振れたりしないようです。
＃１番and/or２番ピンを使っていますか？

マニュアル

引き続き、LPC1769。

周辺I/Oをちょっとづつ試しているのだけれど、なかなか順調だ。
nxpのユーザーズマニュアルがよく出来ている．．．気がする。

user.manual.lpc17xx.pdf

コアも周辺も、勝手知ったるってのもあるけれど、各章の構成が分かりやすい。

各章の最初に、それぞれの機能を使うときに、設定必須な（パワーダウンコントロールや、クロック配分とか）彼方此方に散在するレジスタが、まとめて書いてある。
これは助かる。

また、stm32ではチップ固有のハードウエアマニュアルには、cortexの部分の機能についての言及が無いので、ベクタ割り込みコントローラーがどう繋がっているかとか、システムタイマの使い方など、色々分かりにくかったけれど。
LPC1769では、cortex-M3の解説に１章割いてあって、なかなか親切な気がする。

あと、flash書き込みはいつものツールなのだけれど、内蔵クロックを使う所為もあるのか、230kbpsで通信設定して書き込むと、本当に速く書き込める。

LPC17xxは、LPC23xxのコアをcortex-M3とした。だけ、という風に見ていたけれど、実際には、あちこち改良されているようなのだ。
特にマニュアルについては、大幅に良くなっているような印象。

------

ただLPC17xxは、マウスに使うには、ちょっと規模が大きい。
さりとてLPC13xxでは、メモリなどが小さすぎて、ちょっととどかない。

この間を埋める、LPC15xxなんてのが出てきて（32～64ピンくらい？）くれたら、マウスにぴったりな気がする。

想定される性能としては、stm32の1.5倍位は出るのではないかなあ。
ちよっと期待している。

-----

あ、そういえば、LPC17xxには、位相計数カウンタが１個しかないな。
まあマウスに使うなら、ソフトウエアのみだけでカウントしてもいけると思うけれど．．．

撤収

１回分としては、かなり色々な出来事があった。

しかしなんで、そこまでは気配もないのに、いきなり本番ででるかなあ。笑

思うに、皆、本番になるまでは本気でやらないのだろうなあ、と思う。
普段から本気でやっていれば、本番でいきなり出るってことは無いと思うのだけど。

どうしても練習？では無意識に手加減してしまうのか、本番と思うとちょっと力が入ってしまうのか．．．

戦略物資

発送されたとのこと。
ちょっと難産だった。

タイミング的には、ばっちりなのだが．．．．うまく行くといいのだけれど。
他のものも手配しないと。

外仕事、現地到着

電車３時間、飛行機７時間でようやく到着。

着陸して、ターミナルに止まり、ドアが開くのを待っているとき。
向かい側に、最近なにかと話題の、LCCのターミナルがあるのに気づく。
見慣れないカラーリングの飛行機ばかり止まっている。

皆、飛行機から降りて、荷物を手にぞろぞろと徒歩で、ターミナルの中に移動しているのが遠目に見える。

この暑い中、大変そうだ。

その分、チケットはものすごく安いのだろうなあ。
なんでもターミナルの待合室には、エアコンも無いそうだし．．．．

学生とかなら、こんなので旅してみるのも面白いかもしれないけど、今の自分では体がついていかないだろうなあ。

復旧中

今年モデルの再構築をする為に、キーデバイスの手配をしてみる。
最近話題になったもの、まだ誰も話題にして無いもの、などなど．．．さて、どうなるかな。

------

LPC1769。
ペリフェラルの初期化を延々と記述する。
これといって引っかかっているところは無い、と思ったのだけれど、 PCONPレジスタでちょっとつまづく。

データシートによると、未使用の"Reserved"ビットは、０にしろ、とあるのだが．．．
ビット15は1にしておかないと、RITの割り込みが利かなかった。
errataにもそれらしいのは無いし、全ての組み合わせの動作を検証したわけでは無いのだが。

しかし、PCONPレジスタのReservedビットは、リセット時の初期値が不定となっているし．．．怪しい．．．
本当に０でいいのか、これ？

------

昨日のはやぶさの帰還の高解像度のニュース動画があちこちで見られる。
わずか数十秒の映像なのだけれど、実に立体感というか、空間のスケールを感じる。
どのくらいの高度のところが見えているのだろうか。

直前に、日本上空で直接目視できるのでは？と思っていたのだけれど、オフィシャルサイトでは、良くても１２等以下とのこと。

こりゃあ、ちょっとやそっとでは見えないなあ、と思っていたら、なんと、すばるでの観測画像が公開されていた。
そういや、日本には、こんな強力なのがあったのだよな。
これで見えなきゃ、何を持ってきても見えないだろう。
自前の道具で、融通がきいたってことだろうけど。

こういうことを思うと、借り物を集めて、その場しのぎで切り抜けることばかりでは、だめだと感じる。
普段から鍛えてないと、本当に必要となったときに、力が足りなくてそこで終わってしまう。

とはいえ、あのクラスの設備だ。稼動予定はびっしり入っていただろうになぁ。

いかにもこともなげな、粋な計らいに感心した。
自分も、こうありたいものだ。

------

明日は、餃子の町へ、頭脳＆度胸仕事。
１日で終わるといいのだけれど。

終わらなかったら泊まりだけれど、そうなると木曜からの遠出と繋がってしまうからなあ。

とりあえず明日は、７時の新幹線か．．．

帰還

よい知らせだ。
明日への活力になる、いいニュースだ。

運営の皆さんも、お疲れ様でした。

暑い

今日は、今シーズン初めて冷房が入った。
水蒸気がたくさん上がったようで、夕方はいつもと違った風景に。

------

色々事情により、明日も仕事。
午前中で終わればいいのだが．．．

難航

新型の駆動系を試しているのだけれど、ちょっとフリクションが大き過ぎるような。
この構造では、大分エネルギー効率が悪くなりそう。
もっと摩擦の少ない構造にしないといけないかなあ。

そうなると出力軸位置の取得の方法を、考え直さなければならないのだが．．．うーむ。

------

digikeyで、アナデバのジャイロの取り扱いが復活している。
ADXRS600系だけれども。
戦略物資じゃなくなったのかな。

検出のゲインを落とせないと、マウスに積むのは難しいか。
いまどきは、STのジャイロのほうが、安い小さい入手可能で、主流となってしまっているのかも。

nxpのcortex-M3

ちと思い立って、nxpのcortex-M3であるところの、LPC1769をいじってみたりしている。
コアはstm32と同じなので、スタートアップはstm32のを微修正でお手軽に。

周辺はLPCなので、こっちも特に問題なし。
LPCのシリーズには色々お世話になっている。
自分の現行モデルのマウスもプロセッサはLPC2138だ。

ほとんど苦も無く、テストコードをflash書き込みしてCPU起動。

------

120MHzは、すごいよなあ。
STM32では（なぜか）出来なかった、内蔵クロックでの最高速動作も、普通に可能だ。

100pinパッケージに、etherを初めとして、ありとあらゆるものが詰め込まれている。
LPC2368を見たときも、これ以上何を載せるの？って感じだったけれど、まだまだ新機構が入っているようだ。

GPIOもLPC2368のときは、ただのIOポートだったはずだけれど、LPC1769では、入出力とは独立してプルアップ、プルダウン、オープンドレイン　とありとあらゆる設定が出来るみたい。

リピーターモードなんてのもあるようだ。
これがあれば、外付け抵抗一本で、任意のヒステリシスを持たせたシュミットトリガの入力ポートが作れたりするわけか？

で、全ＩＯポートは、リセット時、入力ポート設定で、プルアップ有効ときている。
正論理出力の何かを作るときは、リセット時要注意だな。

いやはや、まだまだ（機能を）盛るところは有るもんだなあ。

作業中

ここのところの本業での攻撃ターンも、ひと段落してきた感あり。
ちょっと遠目の外仕事のために、機材一式が出かけてしまっていて、なんとなく間が空いてしまっている。

そんなわけで長らく停滞していた、ハーフの足回りを再開してみる。
dNANOのタイヤを使う為に、ホイールを準備している。

直径で11mmほどの部品なのだけれど、樹脂の切削加工が、なんだか精度が出てない気がする。真円度とか．．．

やっぱり樹脂の厚さ1mmとかで、ちょっと入り組んだ構造になってくると、刃物での加工時に変形して狙った寸法がでないのかな。
金属なら、材料と刃物を選んで、ゆっくり加工すればいいのかもしれないけど、プラスチックはゆっくり加工するわけにいかないのだろうなあ。

加工しやすい簡単な形状で済むような機構を考えるか、今のまま行くなら材料を金属にするべきか．．．

------

ところで直近の大会でデビューした、このマウスの出力軸センサの構造は秀逸だ。
言い始めると色々あるのかもしれないけれど、秘めたる（？）素性の良さを感じる。

ひとまず自分の構想とは違うので、胸をなでおろして（？？）は居るのだけれど、その見切りのよさに心引かれる。

------

一般論．．．いや自分のことだけれど、物事を複雑にして解決を図ろうとしている時ってのは、苦し紛れってことが多い気がする。
変遷がいろいろあるにせよ、最終的にシンプルで美しい形に収まるのが、うまく行っていることの証なのだと思う。

どうも目先のことが難航して、気の迷いが出たりして、ちょっと弱気になってしまっていたりするようだ。

まあ、もうちょっと粘ってみるか。